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

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

Esta definição de compatibilidade é emitida para corresponder à atualização 2.3.3 do Android, que é o nível 10 da API. Essa definição é obsoleta e substitui a definição de compatibilidade para versões do Android 2.3 anteriores à 2.3.3. As versões 2.3.1 e 2.3.2 estão obsoletas. Os dispositivos compatíveis com o Android que executam o Android 2.3 PRECISAM ser enviados com a versão 2.3.3 ou mais recente.

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 2.3: http://source.android.com/docs/compatibility/2.3/versions.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

Planos de fundo interativos: https://android-developers.googleblog.com/2010/02/live-wallpapers.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

Lista de recursos de hardware do Android: 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

Espaço de coordenadas do sensor: 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

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

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

A plataforma Android inclui um conjunto de APIs gerenciadas, um conjunto de APIs nativas e um conjunto de APIs chamadas "soft", como o sistema de intents e as APIs de aplicativos da Web. Esta seção detalha as APIs rígidas e flexíveis que são essenciais para a compatibilidade, além de alguns outros comportamentos técnicos e de interface do usuário relevantes. As implementações de dispositivos precisam obedecer a todos os requisitos desta seção.

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 2.3 [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 desse 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. Esta seção detalha as APIs "soft" e os comportamentos do sistema necessários para a compatibilidade com o Android 2.3. As implementações de dispositivos precisam atender a todos os requisitos apresentados nesta seção.

3.2.1. Permissões

Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões [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 2.3, esse campo PRECISA ter o valor inteiro 9.
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.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/generic:2.3/ERC77/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.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.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 dispositivo. PRECISA ser legível por humanos, mas não é necessariamente destinada a ser visualizada por usuários finais. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
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

O Android usa intents para conseguir uma integração frouxa entre apps. Esta seção descreve os requisitos relacionados aos padrões de intent que PRECISAM ser atendidos pelas implementações de dispositivos. "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 associe 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 um discador de telefone, uma agenda, um livro de contatos, um player de música etc. 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
Calculadora
Contatos
E-mail
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, os implementadores de dispositivos PRECISAM permitir que cada padrão de intent referenciado na seção 3.2.3.1 seja substituído por aplicativos de terceiros. O projeto 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 de esses padrões de intent por aplicativos do sistema nem impedir que aplicativos de terceiros se associem e assumam o controle desses padrões. Essa proibição inclui especificamente a desativação da interface do usuário "Chooser", que permite que o usuário selecione entre vários aplicativos que processam o mesmo padrão de intent.

3.2.3.3. Namespaces de intent

Os implementadores de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou broadcast intent usando uma string de chave ACTION, CATEGORY ou outra no namespace android.*. Os implementadores de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou broadcast intent usando uma string de ação, categoria ou outra chave em um espaço de pacote pertencente a outra organização. Os implementadores de dispositivos NÃO PODEM alterar ou estender nenhum dos padrões de intent usados pelos apps principais listados na seção 3.2.3.1.

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

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 de áudio da Biblioteca de áudio aberta)
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

Muitos desenvolvedores e aplicativos dependem do comportamento da classe android.webkit.WebView [Resources, 8] para as interfaces do usuário. Portanto, a implementação da WebView precisa ser compatível com as implementações do Android. Da mesma forma, um navegador da Web completo e moderno é fundamental para a experiência do usuário do Android. As implementações de dispositivos precisam incluir uma versão de android.webkit.WebView consistente com o software upstream do Android e um navegador moderno compatível com HTML5, conforme descrito abaixo.

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 533.1 do WebKit da árvore Android Open Source upstream para o Android 2.3. 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/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- 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 do HTML5 [Resources, 9]. 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, 10]
a tag <video> [Resources, 11].
geolocalização [Recursos, 12]

Além disso, as implementações de dispositivos precisam oferecer suporte à API HTML5/W3C Webstorage [Resources, 13] e à API IndexedDB HTML5/W3C [Resources, 14]. 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, 9]. 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 [Resources, 10]
a tag <video> [Resources, 11]
geolocalização [Recursos, 12]

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 Dalvik Executable (DEX) e à semântica da máquina virtual Dalvik [Resources, 15].

Implementações de dispositivos com telas classificadas como de densidade média ou baixa PRECISAM configurar o Dalvik para alocar pelo menos 16 MB de memória para cada aplicativo. Implementações de dispositivos com telas classificadas como de alta densidade ou extra-alta densidade PRECISAM configurar o Dalvik para alocar pelo menos 24 MB de memória para cada aplicativo. As implementações de dispositivos podem alocar mais memória do que esses valores.

3.8. Compatibilidade da interface do usuário

A plataforma Android inclui algumas APIs que permitem aos desenvolvedores se conectar à interface do usuário do sistema. As implementações de dispositivos PRECISAM incorporar essas APIs padrão de interface do usuário nas interfaces do usuário personalizadas que desenvolvem, conforme explicado abaixo.

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, 16]. A versão de referência do Android Open Source inclui um app de tela inicial que inclui elementos da interface do usuário que permitem adicionar, visualizar e remover AppWidgets da tela inicial.

Os implementadores 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 elementos 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, o implementador do dispositivo PRECISA fornecer um aplicativo separado acessível pelo iniciador que permita aos usuários adicionar, configurar, visualizar e remover AppWidgets.

3.8.2. Notificações

O Android inclui APIs que permitem que os desenvolvedores notifiquem os usuários sobre eventos importantes [Resources, 17]. Os implementadores de dispositivos precisam oferecer suporte a cada classe de notificação definida, especificamente: sons, vibração, luz e barra de status.

Além disso, a implementação PRECISA renderizar corretamente todos os recursos (ícones, arquivos de som etc.) fornecidos nas APIs [Resources, 18] ou no guia de estilo de ícones da barra de status [Resources, 19]. Os implementadores de dispositivos PODEM oferecer uma experiência do usuário alternativa para notificações diferente da fornecida pela implementação de referência do Android Open Source. No entanto, esses sistemas de notificação alternativos PRECISAM oferecer suporte aos recursos de notificação existentes, conforme acima.

3.8.3. Pesquisar

O Android inclui APIs [Resources, 20] 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 interface do usuário única em todo o sistema que permite a entrada de consultas, mostra sugestões à medida que os usuários digitam e exibe os resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para oferecer a pesquisa nos próprios apps e fornecer resultados à interface de 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.

As implementações de dispositivos PODEM enviar interfaces do usuário de pesquisa alternativas, mas DEVEM incluir um botão de pesquisa dedicado, rígido ou flexível, que possa ser usado a qualquer momento em qualquer app para invocar o framework de pesquisa, com o comportamento fornecido na documentação da API.

3.8.4. Avisos

Os aplicativos podem usar a API Toast (definida em [Resources, 21]) 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. 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, 22]. 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.

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

As implementações de dispositivos NÃO PODEM estender os formatos .apk [Resources, 24], Android Manifest [Resources, 25] ou bytecode Dalvik [Resources, 15] de forma que impeça 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 implementar todas as APIs multimídia. As implementações de dispositivos precisam incluir suporte a todos os codecs multimídia descritos abaixo e precisam atender às diretrizes de processamento de som descritas abaixo. As implementações do dispositivo 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 codecs multimídia, conforme detalhado nas seções a seguir. Todos esses codecs são fornecidos como implementações de software na implementação preferida do Android do Projeto Open Source do Android.

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. Quem pretende usar esse código-fonte em produtos de hardware ou software deve saber que as implementações desse código, inclusive em software de código aberto ou shareware, podem exigir licenças de patente dos detentores de patente relevantes.

As tabelas abaixo não listam os requisitos de taxa de bits específicos para a maioria dos codecs de vídeo. Isso ocorre porque, na prática, o hardware atual do dispositivo 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 maior bitrate possível no hardware, até os limites definidos pelas especificações.

5.1.1. Decodificadores de mídia

As implementações de dispositivo precisam incluir uma implementação de um decodificador para cada codec e formato descritos na tabela abaixo. Os decodificadores para cada um desses tipos de mídia são fornecidos pelo projeto upstream do Android Open Source.

Áudio
	Nome	Detalhes	Formato de arquivo/contêiner
	AAC LC/LTP	Conteúdo mono/estéreo em qualquer combinação de taxas de bits padrão de até 160 kbps e taxas de amostragem entre 8 e 48 kHz	3GPP (.3gp) e MPEG-4 (.mp4, .m4a). Não há suporte para AAC bruto (.aac)
	HE-AACv1 (AAC+)
	HE-AACv2 (AAC+ aprimorado)
	AMR-NB	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
	AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz.	3GPP (.3gp)
	MP3	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps.	MP3 (.mp3)
	MIDI	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). Também RTTTL/RTX (.rtttl, .rtx), OTA (.ota) e iMelody (.imy)
	Ogg Vorbis		Ogg (.ogg)
	PCM	PCM linear de 8 e 16 bits (taxas até o limite do hardware)	WAVE (.wav)
Image
	JPEG	base+progressivo
	GIF
	PNG
	BMP
Vídeo
	H.263		Arquivos 3GPP (.3gp)
	H.264		Arquivos 3GPP (.3gp) e MPEG-4 (.mp4)
	Perfil simples MPEG4		Arquivo 3GPP (.3gp)

5.1.2. Codificadores de mídia

As implementações de dispositivos devem incluir codificadores para o maior número possível de formatos de mídia listados na seção 5.1.1. No entanto, alguns codificadores não fazem sentido para dispositivos que não têm determinados hardwares opcionais. Por exemplo, um codificador para o vídeo H.263 não faz sentido se o dispositivo não tiver câmeras. Portanto, as implementações de dispositivos precisam implementar codificadores de mídia de acordo com as condições descritas na tabela abaixo.

Consulte a seção 7 para saber mais sobre as condições em que o hardware pode ser omitido pelas implementações do dispositivo.

Áudio
	Nome	Detalhes	Formato de arquivo/contêiner	Condições
	AMR-NB	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)	Implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone` PRECISAM incluir codificadores para esses formatos de áudio.
	AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz.	3GPP (.3gp)
	AAC LC/LTP	Conteúdo mono/estéreo em qualquer combinação de taxas de bits padrão de até 160 kbps e taxas de amostragem entre 8 e 48 kHz	3GPP (.3gp) e MPEG-4 (.mp4, .m4a).
Image	JPEG	base+progressivo		Todas as implementações de dispositivo PRECISAM incluir codificadores para esses formatos de imagem, já que o Android 2.3 inclui APIs que os aplicativos podem usar para gerar arquivos desses tipos de forma programática.
Image	PNG
Vídeo	H.263		Arquivos 3GPP (.3gp)	Implementações de dispositivos que incluem hardware de câmera e definem `android.hardware.camera` ou `android.hardware.camera.front` PRECISAM incluir codificadores para esses formatos de vídeo.

Além dos codificadores listados acima, as implementações de dispositivos precisam incluir um codificador H.264. A definição de compatibilidade para uma versão futura está planejada para mudar esse requisito para "OBRIGATÓRIO". Ou seja, a codificação H.264 é opcional no Android 2.3, mas será obrigatória em uma versão futura. Dispositivos novos e existentes que executam o Android 2.3 são fortemente recomendados a atender a esse requisito no Android 2.3, caso contrário, não será possível alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

5.2. Gravação em áudio

Quando um aplicativo usa a API android.media.AudioRecord para começar a gravar um stream de áudio, as implementações do dispositivo precisam amosar e gravar áudio com cada um desses comportamentos:

O processamento de redução de ruído, se presente, DEVE ser desativado.
O controle de ganho automático, se presente, DEVE ser desativado.
O dispositivo DEVE apresentar uma amplitude aproximadamente plana em relação às características de frequência, especificamente ±3 dB, de 100 Hz a 4.000 Hz.
A sensibilidade da entrada de áudio PRECISA ser definida de modo que uma fonte de nível de potência de som (SPL) 90 dB a 1.000 Hz produza um RMS de 5.000 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.

Observação:embora os requisitos descritos acima sejam indicados como "SHOULD" para o Android 2.3, 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 2.3, mas serão obrigatórios em uma versão futura. É muito importante que os dispositivos atuais e novos que executam o Android 2.3 atendam a esses requisitos, caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

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

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

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, 23]
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, mas é necessário 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) [Recursos, 23]
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, 26]
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

O Android tem como objetivo permitir que os implementadores de dispositivos criem formatos e configurações inovadores. Ao mesmo tempo, os desenvolvedores do Android escrevem aplicativos inovadores que dependem de vários hardwares e recursos disponíveis nas APIs do Android. Os requisitos desta seção buscam um equilíbrio entre as inovações disponíveis para implementadores de dispositivos e as necessidades dos desenvolvedores para garantir que os apps estejam disponíveis apenas para dispositivos em que eles funcionam corretamente.

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

As definições de classe completas (documentadas pelo SDK) para as APIs do componente ainda precisam 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 de no-op 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, 27]

7.1. Tela e gráficos

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

7.1.1. Configurações da tela

As implementações de dispositivos PODEM usar telas de qualquer dimensão de pixel, desde que atendam aos seguintes requisitos:

As telas precisam ter pelo menos 6,35 cm de tamanho físico na diagonal
A densidade PRECISA ser de pelo menos 100 dpi
A proporção precisa estar entre 1,333 (4:3) e 1,779 (16:9).
a tecnologia de exibição usada consiste em pixels quadrados

Implementações de dispositivos com uma tela que atenda aos requisitos acima são consideradas compatíveis, e nenhuma outra ação é necessária. A implementação do framework do Android calcula automaticamente as características de exibição, como o bucket de tamanho de tela e de densidade. Na maioria dos casos, as decisões do framework são as corretas. Se as computações do framework padrão forem usadas, nenhuma outra ação será necessária. Os implementadores de dispositivos que quiserem mudar os padrões ou usar uma tela que não atenda aos requisitos acima PRECISAM entrar em contato com a equipe de compatibilidade do Android para receber orientações, conforme previsto na seção 12.

As unidades usadas pelos requisitos acima 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".

As implementações de dispositivos precisam usar apenas telas com uma única configuração estática. Ou seja, as implementações de dispositivos NÃO PODEM ativar várias configurações de tela. Por exemplo, como uma televisão comum oferece suporte a várias resoluções, como 1080p, 720p e assim por diante, essa configuração não é compatível com o Android 2.3. No entanto, o suporte a essas configurações está sendo investigado e planejado para uma versão futura 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, 29].

7.1.3. Suporte declarado à tela

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, médias e grandes, conforme descrito na documentação do SDK do Android.

7.1.4. Orientação da tela

Os dispositivos compatíveis 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. Dispositivos que não podem ser girados fisicamente PODEM atender a esse requisito com "letterboxing" de aplicativos que solicitam o modo retrato, usando apenas uma parte da tela disponível.

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.

7.1.5. Aceleração de gráficos 3D

As implementações de dispositivos precisam oferecer suporte ao OpenGL ES 1.0, conforme exigido pelas APIs do Android 2.3. Para dispositivos sem hardware de aceleração 3D, uma implementação de software do OpenGL ES 1.0 é fornecida pelo projeto de código aberto upstream do Android. As implementações de dispositivos precisam oferecer suporte ao OpenGL ES 2.0.

As implementações PODEM omitir o suporte ao Open GL ES 2.0. No entanto, se o suporte for omitido, as implementações de dispositivo NÃO PODEM informar que oferecem suporte ao OpenGL ES 2.0. Especificamente, se uma implementação de dispositivo não tiver suporte ao OpenGL ES 2.0:

As APIs gerenciadas (como pelo método GLES10.getString()) NÃO PODEM informar suporte ao OpenGL ES 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) NÃO PODEM informar suporte para OpenGL ES 2.0.

Por outro lado, se uma implementação de dispositivo tiver suporte ao OpenGL ES 2.0, ela PRECISA informar com precisão esse suporte pelas rotas listadas.

O Android 2.3 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 2.3 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.

7.2. Dispositivos de entrada

O Android 2.3 oferece suporte a várias modalidades de entrada do usuário. As implementações de dispositivos precisam oferecer suporte a dispositivos de entrada do usuário, conforme indicado nesta seção.

7.2.1. Teclado

Implementações de dispositivos:

É OBRIGATÓRIO incluir suporte ao framework de gerenciamento de entrada, que permite que desenvolvedores terceirizados criem mecanismos de gerenciamento de entrada (por exemplo, teclado virtual), conforme detalhado em developer.android.com
É PRECISO fornecer pelo menos uma implementação de teclado virtual (independente de um teclado físico estar 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, 30], 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.
É PRECISO informar o valor correto para android.content.res.Configuration.navigation [Resources, 30].
É 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 código de origem do Android Open Source inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não táctil.

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, independentemente do estado do aplicativo. Essas funções precisam ser implementadas usando botões dedicados. Elas PODEM ser implementadas usando software, gestos, painel de toque etc., mas, se forem, elas PRECISAM estar sempre acessíveis e não obscurecer ou interferir na área de exibição do aplicativo disponível.

Os implementadores de dispositivos também precisam fornecer uma chave de pesquisa dedicada. Os implementadores de dispositivos também podem fornecer teclas de envio e encerramento para ligações.

7.2.4. Entrada por tela touchscreen

Implementações de dispositivos:

É OBRIGATÓRIO ter uma tela touchscreen
PODE ter touchscreen resistiva ou capacitiva
É necessário informar o valor de android.content.res.Configuration [Resources, 30] refletindo o tipo de tela de toque específica no dispositivo.
DEVE oferecer suporte a ponteiros rastreados de forma totalmente independente, se a tela sensível ao toque oferecer suporte a vários ponteiros

7.3. Sensores

O Android 2.3 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, 27]
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.).

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 2.3 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 2.3 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
É OBRIGATÓRIO obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android (consulte [Resources, 31]).
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 obedecer ao sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android (consulte [Resources, 31]).
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:

É 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 8 bits de precisão ou mais

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

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

A conectividade de rede e o acesso à Internet são recursos vitais do Android. Enquanto isso, a interação entre dispositivos agrega valor significativo aos dispositivos e aplicativos Android. As implementações de dispositivos PRECISAM atender aos requisitos de conectividade de dados nesta seção.

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android 2.3 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 ligações de voz possam ou não ser comutadas por pacotes, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade "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 2.3 PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android 2.3 é 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 do Android 2.3 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, 32]. 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, 27]

PRECISA ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões NFC:

PRECISA ser capaz de atuar como um leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS 6319-4)
- NfcV (ISO 15693)
- IsoDep (ISO 14443-4)
- Tipos de tag do NFC Forum 1, 2, 3 e 4 (definidos pelo NFC Forum)
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 de push NDEF [Resources, 33]
É PRECISO verificar todas as tecnologias com suporte no modo de descoberta NFC.
DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa.

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 devem oferecer suporte às seguintes tecnologias MIFARE amplamente implantadas.

MIFARE Classic (NXP MF1S503x [Resources, 34], MF1S703x [Resources, 35])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 36], MF0ICU2 [Resources, 37])
NDEF no MIFARE Classic (NXP AN130511 [Resources, 38], AN130411 [Resources, 39])

O Android 2.3.3 inclui APIs para esses tipos de MIFARE. Se uma implementação de dispositivo oferecer suporte a MIFARE, 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, 27] 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, 27] e PRECISA implementar a API NFC do Android 2.3 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 Camera no Android 2.3 tem suporte específico para câmeras frontais e as implementações de dispositivos PRECISAM configurá-la para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera do dispositivo.
PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.
PRECISA refletir horizontalmente (ou seja, espelhar) o stream exibido por um app em uma CameraPreview, conforme mostrado 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, 40], 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 os dados de imagem retornados para qualquer gerenciador de callback de câmera "postview", da mesma maneira que o fluxo de imagem de visualização da câmera. Se a implementação do dispositivo não oferecer suporte a callbacks pós-visualização, esse requisito 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 aos callbacks do aplicativo.
Se um aplicativo registrar uma instância de android.hardware.Camera.PreviewCallback e o sistema chamar o método onPreviewFrame() quando o formato de pré-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 para câmeras frontal e traseira. A definição de compatibilidade para uma versão futura está planejada para mudar esse requisito para "OBRIGATÓRIO". Ou seja, o suporte a YV12 é opcional no Android 2.3, mas será necessário em uma versão futura. É recomendado que os dispositivos atuais e novos que executam o Android 2.3 atendam a esse requisito no Android 2.3, caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

As implementações de dispositivos PRECISAM implementar a API Camera completa incluída na documentação do SDK do Android 2.3 [Resources, 41], independentemente 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.

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 nessa orientação. Isso se aplica independentemente da orientação natural do dispositivo, ou seja, se aplica a dispositivos com orientação principal de paisagem e retrato.

7.6. Memória e armazenamento

A função fundamental do Android 2.3 é executar aplicativos. As implementações de dispositivos precisam atender aos requisitos desta seção para garantir armazenamento e memória adequados para que os aplicativos sejam executados corretamente.

7.6.1. Memória e armazenamento mínimos

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

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

Além dos requisitos acima, as implementações de dispositivos PRECISAM ter pelo menos 1 GB de armazenamento não volátil disponível para dados do usuário. Esse requisito mais alto está planejado para se tornar um mínimo rígido em uma versão futura do Android. Recomendamos que as implementações de dispositivos atendam a esses requisitos agora. Caso contrário, elas podem não ser qualificadas para a compatibilidade com uma versão futura do Android.

As APIs do Android incluem um gerenciador de downloads que os apps podem usar para fazer o download de arquivos de dados. A implementação do Gerenciador de downloads PRECISA ser capaz de fazer o download de arquivos individuais com tamanho de 55 MB ou mais. A implementação do Gerenciador de downloads PRECISA ser capaz de fazer o download de arquivos de 100 MB ou maiores.

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 dispositivos precisam oferecer algum mecanismo para acessar o conteúdo do armazenamento compartilhado de um computador host, como armazenamento em massa USB ou protocolo de transferência de mídia.

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

Implementações de dispositivos:

É PRECISO implementar um cliente USB, conectável a um host USB com uma porta USB-A padrão
PRECISA implementar o Android Debug Bridge por USB (conforme descrito na Seção 7)
PRECISA implementar a especificação de armazenamento em massa USB para permitir que um host conectado ao dispositivo acesse o conteúdo do volume /sdcard
DEVE usar o formato micro USB no dispositivo
PODE incluir uma porta não padrão no dispositivo, mas, se for o caso, DEVE ser enviada com um cabo capaz de conectar a pinagem personalizada à porta USB-A padrão.

8. Compatibilidade de performance

As implementações compatíveis precisam garantir que os aplicativos sejam executados corretamente no dispositivo, mas também que o façam com um desempenho razoável e uma boa experiência do usuário. As implementações de dispositivos PRECISAM atender às principais métricas de desempenho de um dispositivo compatível com o Android 2.3 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 MMS/SMS: menos de 700 ms AlarmClock: menos de 650 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 dispositivo PRECISAM implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs [Resources, 42] na documentação para desenvolvedores do Android. As implementações de dispositivos precisam oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis precisam oferecer suporte aos mecanismos de segurança descritos nas subseções a seguir.

9.1. Permissões

As implementações de dispositivos precisam oferecer suporte ao modelo de permissões do Android, conforme definido na documentação para desenvolvedores do Android [Resources, 42]. 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, 42].

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

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

O Android Open Source Project inclui várias ferramentas de teste para verificar se as implementações do dispositivo são compatíveis. As implementações de dispositivos precisam passar em todos os testes descritos nesta seção.

No entanto, nenhum pacote de teste de software é totalmente abrangente. Por esse motivo, os implementadores de dispositivos são fortemente incentivados a fazer o menor número possível de mudanças na implementação de referência e preferida do Android 2.3 disponível no Projeto Android Open Source. Isso vai minimizar o risco de introduzir bugs que criam incompatibilidades que exigem retrabalho e possíveis atualizações do dispositivo.

10.1. Conjunto de teste de compatibilidade

As implementações de dispositivos PRECISAM ser aprovadas no conjunto de teste de compatibilidade do Android (CTS) [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 2.3. 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.

PRECISA passar na versão mais recente do conjunto de teste de compatibilidade do Android (CTS, na sigla em inglês) disponível no momento em que a implementação do software do dispositivo é concluída. O CTS está disponível como parte do Android Open Source Project [Resources, 2]. O CTS testa muitos, mas não todos, os componentes descritos neste documento.

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, 43].
Replica Island (disponível no Android Market; necessário apenas para implementações de dispositivos com suporte ao OpenGL ES 2.0)

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. O software upstream do Android inclui um mecanismo de atualização que satisfaz 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.