Definição de compatibilidade do Android 2.2

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Copyright © 2010, Google Inc. Todos os direitos reservados.
compatibility@android.com

Índice

1. Introdução

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

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

Para serem consideradas compatíveis com o Android 2.2, as implementações de dispositivos:

• PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos incorporados por referência.
• 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.

Quando essa definição ou o CTS for silencioso, ambíguo ou incompleto, 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. Recomendamos que os implementadores de dispositivos baseiem as implementações no código-fonte "upstream" disponível no Android Open Source Project. Embora alguns componentes possam ser hipoteticamente substituídos por implementações alternativas, essa prática é desencorajada, já que passar nos testes do CTS vai se tornar muito mais difícil. É responsabilidade do implementador garantir a compatibilidade comportamental total com a implementação padrão do Android, incluindo e além do conjunto de testes de compatibilidade. Por fim, observe que algumas substituições e modificações de componentes são explicitamente proibidas por este documento.

2. Recursos

1. Níveis de requisito do IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. Visão geral do Programa de compatibilidade do Android: http://source.android.com/docs/compatibility/index.html
3. Android Open Source Project: http://source.android.com/
4. Definições e documentação da API: http://developer.android.com/reference/packages.html
5. Referência de permissões do Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Referência do android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Strings de versão permitidas do Android 2.2: http://source.android.com/docs/compatibility/2.2/versions.html
8. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Especificação da máquina virtual Dalvik: disponível no código-fonte do Android, em dalvik/docs
11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. Notificações: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. Recursos do aplicativo: http://code.google.com/android/reference/available-resources.html
14. Guia de estilo de ícones da barra de status: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. Gerenciador de pesquisa: http://developer.android.com/reference/android/app/SearchManager.html
16. Toasts: http://developer.android.com/reference/android/widget/Toast.html
17. Planos de fundo interativos: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. Apps para Android: http://code.google.com/p/apps-for-android
19. Documentação de referência da ferramenta (para adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. Descrição do arquivo apk do Android: http://developer.android.com/guide/topics/fundamentals.html
21. Arquivos de manifesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. Ferramenta de teste do Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
23. Lista de recursos de hardware do Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. Suporte a várias telas: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. Espaço de coordenadas do sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Referência de segurança e permissões do Android: http://developer.android.com/guide/topics/security/security.html
30. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

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.2. 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.2, esse campo PRECISA ter o valor inteiro 8.
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. 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.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. 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.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. 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.FINGERPRINT	Uma string que identifica exclusivamente esse build. Ele PRECISA ser razoavelmente legível para humanos. Ele precisa seguir este modelo: $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por exemplo: acme/mydevice/generic/generic:2.2/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 ("_").
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. 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.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. 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.TAGS	Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que diferenciam ainda mais o build. Por exemplo, "unsigned,debug". Este campo NÃO PODE ser nulo ou a string vazia (""), mas uma única tag (como "release") é aceitável.
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".
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
• Câmera
• Contatos
• E-mail
• Galeria
• GlobalSearch
• Tela de início
• LivePicker (ou seja, o aplicativo de seleção de plano de fundo interativo; PODE ser omitido se o dispositivo não oferecer suporte a planos de fundo interativos, de acordo com a seção 3.8.5).
• Mensagens (também conhecidas como "Mms")
• Música
• Telefone
• Configurações
• Gravador de som

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. As implementações de dispositivos precisam incluir suporte para código executado no ambiente gerenciado para chamar o código nativo, usando a semântica padrão da Java Native Interface (JNI). As APIs abaixo PRECISAM estar disponíveis para o código nativo:

• libc (biblioteca C)
• libm (biblioteca matemática)
• Interface JNI
• libz (compactação Zlib)
• liblog (registro do Android)
• Suporte mínimo para C++
• Suporte para OpenGL, conforme descrito abaixo

As implementações de dispositivos precisam oferecer suporte ao OpenGL ES 1.0. Dispositivos que não têm aceleração de hardware PRECISAM implementar o OpenGL ES 1.0 usando um renderizador de software. As implementações de dispositivos PRECISAM implementar o máximo possível do OpenGL ES 1.1 que o hardware do dispositivo oferece suporte. As implementações de dispositivos precisam oferecer uma implementação para o OpenGL ES 2.0, se o hardware for capaz de oferecer um desempenho razoável nessas APIs.

Essas bibliotecas PRECISAM ser compatíveis com a origem (ou seja, com o cabeçalho) e com o binário (para uma determinada arquitetura de processador) com as versões fornecidas no Bionic pelo projeto Android Open Source. Como as implementações do Bionic não são totalmente compatíveis com outras implementações, como a biblioteca C do GNU, os implementadores de dispositivos DEVEM usar a implementação do Android. Se os implementadores de dispositivos usarem uma implementação diferente dessas bibliotecas, eles PRECISAM garantir a compatibilidade de cabeçalho, binário e comportamento.

As implementações de dispositivo precisam informar com precisão a interface binária nativa do aplicativo (ABI, na sigla em inglês) suportada pelo dispositivo pela API android.os.Build.CPU_ABI. A ABI PRECISA ser uma das entradas documentadas na versão mais recente do Android NDK, no arquivo docs/CPU-ARCH-ABIS.txt. Versões adicionais do Android NDK podem introduzir suporte a outras ABIs.

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, uma experiência completa da Web é 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 Android upstream 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.2. 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.

A configuração da WebView PRECISA incluir suporte para o banco de dados HTML5, o cache do aplicativo e as APIs de geolocalização [Resources, 9]. A WebView PRECISA incluir suporte para a tag <video> HTML5. 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 pelas APIs usuais 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 enviado, 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 à geolocalização HTML5, ao cache de aplicativo e às APIs de banco de dados e à tag <video> no aplicativo de navegador independente.

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 o significado de uma intent padrão.
• Os dispositivos NÃO PODEM alterar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de componente do sistema (como serviço, atividade, ContentProvider etc.).
• Os dispositivos NÃO PODEM mudar a semântica de uma permissão específica.

A lista acima não é abrangente, e a responsabilidade é dos implementadores de dispositivos para garantir a compatibilidade comportamental. Por esse motivo, os implementadores de dispositivos DEVEM usar o código-fonte disponível no Projeto Android Open Source sempre que possível, em vez de reimplementar partes significativas do sistema.

O conjunto de teste de compatibilidade (CTS) testa partes significativas da plataforma em busca de compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android Open Source Project.

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" no código-fonte do Android upstream. Em outras palavras, os implementadores de dispositivos NÃO PODEM expor novas APIs nem alterar APIs existentes nos namespaces indicados 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.

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

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 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, 11]. 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, 12]. 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, 13] ou no guia de estilo de ícones da barra de status [Resources, 14]. 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, 15] 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, 16]) 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 "Wallpapers animados" ao usuário final [Resources, 17]. 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 com software de referência

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

• Calculadora (incluída no SDK)
• Lunar Lander (incluído no SDK)
• Os aplicativos "Apps for Android" [Resources, 18].
• 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.

Além disso, as implementações de dispositivos precisam testar cada item de menu (incluindo todos os submenus) de cada um desses aplicativos de teste de fumaça:

• ApiDemos (incluídas no SDK)
• Testes de fumaça manual (incluídos no CTS)

Cada caso de teste nos aplicativos acima PRECISA ser executado corretamente na implementação do dispositivo.

5. 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, 19].

As implementações de dispositivos NÃO PODEM estender os formatos .apk [Resources, 20], Android Manifest [Resources, 21] ou bytecode Dalvik [Resources, 10] de forma que impeça a instalação e a execução desses arquivos corretamente 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.

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

6.1. Codecs de mídia

As implementações de dispositivos precisam oferecer suporte aos seguintes codecs multimídia. Todos esses codecs são fornecidos como implementações de software na implementação Android preferida do Android Open Source Project.

Nem o Google nem a Open Handset Alliance fazem qualquer representação de que esses codecs não estão sujeitos a patentes de terceiros. 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.

Áudio
	Nome	Codificador	Decodificador	Detalhes	Formato de arquivo/contêiner
	AAC LC/LTP		X	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+)		X
	HE-AACv2 (AAC+ aprimorado)		X
	AMR-NB	X	X	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
	AMR-WB		X	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz.	3GPP (.3gp)
	MP3		X	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps.	MP3 (.mp3)
	MIDI		X	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		X		Ogg (.ogg)
	PCM		X	PCM linear de 8 e 16 bits (taxas até o limite do hardware)	WAVE (.wav)
Image
	JPEG	X	X	base+progressivo
	GIF		X
	PNG	X	X
	BMP		X
Vídeo
	H.263	X	X		Arquivos 3GPP (.3gp)
	H.264		X		Arquivos 3GPP (.3gp) e MPEG-4 (.mp4)
	Perfil simples MPEG4		X		Arquivo 3GPP (.3gp)

A tabela acima não lista os requisitos de bitrate 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.

6.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.2, 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.2, mas serão obrigatórios em uma versão futura. Os dispositivos novos e atuais que executam o Android 2.2 são fortemente recomendados a atender a esses requisitos no Android 2.2, caso contrário, não será possível alcançar a compatibilidade do Android ao fazer upgrade para a versão futura.

6.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. As implementações de dispositivos precisam atender a todos os requisitos de latência de áudio descritos nesta seção.

Para os fins desta seção:

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

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

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

Observação:embora os requisitos descritos acima sejam indicados como "SHOULD" para o Android 2.2, 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.2, mas serão obrigatórios em uma versão futura. Os dispositivos novos e atuais que executam o Android 2.2 devem atender a esses requisitos no Android 2.2. Caso contrário, eles não poderão alcançar a compatibilidade do Android ao fazer upgrade para a versão futura.

7. 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, 19]
  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, 19]
  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, 22]
  As implementações de dispositivos PRECISAM incluir o framework Monkey e disponibilizá-lo para uso de aplicativos.

8. Compatibilidade de hardware

O Android tem como objetivo oferecer suporte aos implementadores de dispositivos que criam formatos e configurações inovadores. Ao mesmo tempo, os desenvolvedores do Android esperam certos hardwares, sensores e APIs em todos os dispositivos Android. Esta seção lista os recursos de hardware com suporte em todos os dispositivos compatíveis com o Android 2.2.

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 definido 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 para as APIs do componente precisam estar presentes
• Os comportamentos da API precisam ser implementados como no-ops de maneira razoável
• Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
• Os métodos da API precisam retornar implementações de no-op de classes em que valores nulos não são permitidos 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, 23]

8.1. Tela

O Android 2.2 inclui recursos que executam determinadas operações de escalonamento e transformação automática em algumas circunstâncias, para garantir que os aplicativos de terceiros sejam executados de forma razoável em várias configurações de hardware [Resources, 24]. Os dispositivos precisam implementar esses comportamentos corretamente, conforme detalhado nesta seção.

Para o Android 2.2, estas são as configurações de tela mais comuns:

Tipo de tela	Largura (pixels)	Altura (pixels)	Intervalo de comprimento diagonal (polegadas)	Grupo de tamanhos de tela	Grupo de densidade da tela
QVGA	240	320	2.6 a 3.0	Pequeno	Baixa
WQVGA	240	400	3.2 a 3.5	Normal	Baixa
FWQVGA	240	432	3.5 a 3.8	Normal	Baixa
HVGA	320	sobreposição ou	3.0 a 3.5	Normal	Médio
WVGA	sobreposição ou	800	3.3 a 4.0	Normal	Alta
FWVGA	sobreposição ou	854	3.5 a 4.0	Normal	Alta
WVGA	sobreposição ou	800	4,8 a 5,5	Grande	Médio
FWVGA	sobreposição ou	854	5.0 - 5.8	Grande	Médio

As implementações de dispositivo correspondentes a uma das configurações padrão acima precisam ser configuradas para informar o tamanho da tela indicado aos aplicativos pela classe android.content.res.Configuration [Resources, 24].

Alguns pacotes .apk têm manifestos que não os identificam como compatíveis com um intervalo de densidade específico. Ao executar esses aplicativos, as seguintes restrições se aplicam:

• As implementações de dispositivos PRECISAM interpretar os recursos em um .apk que não tem um qualificador de densidade como padrão para "medium" (conhecido como "mdpi" na documentação do SDK).
• Ao operar em uma tela de densidade "baixa", as implementações de dispositivo precisam redimensionar os recursos de média/mdpi para um fator de 0,75.
• Ao operar em uma tela de densidade "alta", as implementações de dispositivos precisam aumentar os recursos de média/mdpi em um fator de 1,5.
• As implementações de dispositivos NÃO PODEM dimensionar recursos dentro de um intervalo de densidade e PRECISAM dimensionar recursos exatamente por esses fatores entre intervalos de densidade.

8.1.2. Configurações de tela não padrão

As configurações de exibição que não correspondem a uma das configurações padrão listadas na seção 8.1.1 exigem mais consideração e trabalho para serem compatíveis. Os implementadores de dispositivos PRECISAM entrar em contato com a equipe de compatibilidade do Android, conforme descrito na seção 13, para receber classificações para o intervalo de tamanho de tela, densidade e fator de escalonamento. Quando essas informações são fornecidas, as implementações de dispositivo precisam implementá-las conforme especificado.

Algumas configurações de tela (como telas muito grandes ou muito pequenas e algumas proporções) são incompatíveis com o Android 2.2. Portanto, recomendamos que os implementadores de dispositivos entrem em contato com a equipe de compatibilidade do Android o mais cedo possível no processo de desenvolvimento.

8.1.3. Métricas de tela

As implementações de dispositivos precisam informar os valores corretos para todas as métricas de tela definidas em android.util.DisplayMetrics [Resources, 26].

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

8.2. 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, 25], ou seja, QWERTY ou 12 teclas.

8.3. Navegação sem toque

Implementações de dispositivos:

• PODE omitir opções de navegação sem toque (ou seja, pode omitir um trackball, um botão direcional ou uma roda)
• DEVE informar o valor correto para android.content.res.Configuration.navigation [Resources, 25]

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

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.

8.5. Entrada por tela touchscreen

Implementações de dispositivos:

• É OBRIGATÓRIO ter uma tela touchscreen
• PODE ter touchscreen capacitiva ou resistiva
• É necessário informar o valor de android.content.res.Configuration [Resources, 25] refletindo o tipo de tela touchscreen 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

8.6. 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.
• DEVE implementar suporte à especificação de armazenamento em massa USB para que o armazenamento removível ou fixo no dispositivo possa ser acessado em um PC host

8.7. Teclas de navegação

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.

8.8. Rede de dados sem fio

As implementações de dispositivos precisam incluir suporte para redes de dados sem fio de alta velocidade. Especificamente, as implementações de dispositivos precisam incluir suporte a pelo menos um padrão de dados sem fio com capacidade de 200 Kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem EDGE, HSPA, EV-DO, 802.11g etc.

Se uma implementação de dispositivo incluir uma modalidade específica para a qual o SDK do Android incluir uma API (ou seja, Wi-Fi, GSM ou CDMA), a implementação PRECISA oferecer suporte à API.

Os dispositivos PODEM implementar mais de uma forma de conectividade de dados sem fio. Os dispositivos PODEM implementar conectividade de dados com fio (como Ethernet), mas precisam incluir pelo menos uma forma de conectividade sem fio, como acima.

8.9. Câmera

As implementações de dispositivos precisam incluir uma câmera traseira. A câmera traseira incluída:

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

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

1. 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.
2. 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. Esse é o formato usado de forma nativa pela família de hardware 7k. Ou seja, o NV21 PRECISA ser o padrão.

As implementações de dispositivos precisam implementar a API Camera completa incluída na documentação do SDK do Android 2.2 [Resources, 27], independente de o dispositivo incluir foco automático de hardware ou outros recursos. Por exemplo, câmeras sem foco automático PRECISAM chamar qualquer instância registrada de android.hardware.Camera.AutoFocusCallback, mesmo que isso não tenha relevância para uma câmera sem foco automático.

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

As implementações de dispositivos PODEM incluir uma câmera frontal. No entanto, se uma implementação de dispositivo incluir uma câmera frontal, a API de câmera implementada no dispositivo NÃO PODE usar a câmera frontal por padrão. Ou seja, a API de câmera no Android 2.2 é apenas para câmeras traseiras, e as implementações de dispositivos NÃO PODEM reutilizar ou sobrecarregar a API para atuar em uma câmera frontal, se houver uma. Todas as APIs personalizadas adicionadas por implementadores de dispositivos para oferecer suporte a câmeras frontais PRECISAM obedecer às seções 3.5 e 3.6. Por exemplo, se uma subclasse android.hardware.Camera ou Camera.Parameters personalizada for fornecida para oferecer suporte a câmeras frontais, ela NÃO PODERÁ ser localizada em um namespace existente, conforme descrito nas seções 3.5 e 3.6. A inclusão de uma câmera frontal não atende ao requisito de que os dispositivos incluam uma câmera traseira.

8.10. Acelerômetro

As implementações de dispositivos precisam incluir um acelerômetro de três eixos e precisam ser capazes de enviar eventos a 50 Hz ou mais. O sistema de coordenadas usado pelo sensor de aceleração PRECISA estar em conformidade com o sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android (consulte [Resources, 28]).

8.11. Bússola

As implementações de dispositivos precisam incluir uma bússola de 3 eixos e precisam ser capazes de enviar eventos de 10 Hz ou mais. O sistema de coordenadas usado pela bússola PRECISA estar em conformidade com o sistema de coordenadas do sensor do Android, conforme definido na API Android (consulte [Resources, 28]).

8.12. GPS

As implementações de dispositivos precisam incluir um receptor de GPS e devem incluir alguma forma de técnica de "GPS assistido" para minimizar o tempo de bloqueio do GPS.

8.13. Telefonia

O Android 2.2 PODE ser usado em dispositivos que não incluem hardware de telefonia. Ou seja, o Android 2.2 é compatível com dispositivos que não são smartphones. No entanto, se uma implementação de dispositivo incluir telefonia GSM ou CDMA, ela PRECISA implementar o suporte 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.

Consulte também a seção 8.8, Redes de dados sem fio.

8.14. Memória e armazenamento

As implementações de dispositivos precisam ter pelo menos 92 MB de memória disponível para o kernel e o espaço do usuário. Os 92 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 128 MB de memória disponível para o kernel e o espaço do usuário, além de qualquer memória dedicada a componentes de hardware que não estejam sob o controle do kernel. As implementações de dispositivos precisam ter pelo menos 1 GB de armazenamento não volátil disponível para dados do usuário. Esses requisitos mais altos estão planejados para se tornarem mínimos rígidos em uma versão futura do Android. As implementações de dispositivos são fortemente recomendadas para atender a esses requisitos agora. Caso contrário, elas não poderão ser compatíveis com uma versão futura do Android.

8.15. Armazenamento compartilhado do aplicativo

As implementações de dispositivos precisam oferecer armazenamento compartilhado para aplicativos. O armazenamento compartilhado fornecido PRECISA ter pelo menos 2 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, ele PRECISA implementar o armazenamento em massa USB, conforme descrito na seção 8.6. Como enviado da caixa, o armazenamento compartilhado PRECISA ser montado com o sistema de arquivos FAT.

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 2 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 2 GB ou mais, ser formatado como FAT e 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.

8.16. Bluetooth

As implementações de dispositivos precisam incluir um transceptor Bluetooth. As implementações do dispositivo precisam ativar a API Bluetooth baseada em RFCOMM, conforme descrito na documentação do SDK [Resources, 30]. As implementações de dispositivos PRECISAM implementar perfis 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.

9. Compatibilidade de performance

Uma das metas do Programa de compatibilidade do Android é oferecer uma experiência consistente do app aos consumidores. As implementações compatíveis precisam garantir que os aplicativos sejam executados corretamente no dispositivo, mas também que o façam com desempenho razoável e uma boa experiência geral 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.2 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.

10. Compatibilidade do modelo de segurança

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

10.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, 29]. 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.*.

10.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, 29].

10.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, 29].

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

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.

11. 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.2. 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.

12. 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 usando uma atualização de software disponível que possa ser aplicada de acordo com o mecanismo descrito.

13. 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 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 abaixo.

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

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

Testar o controle Bluetooth por apps

1. Inicie o BluetoothChat no dispositivo candidato com o Bluetooth desativado.
2. 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

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

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

1. Abra o app Chat por Bluetooth nos dois dispositivos.
2. Torne o dispositivo candidato detectável no BluetoothChat (usando o Menu).
3. No dispositivo conhecido, procure dispositivos Bluetooth no BluetoothChat (usando o Menu) e faça o pareamento com o dispositivo candidato.
4. Envie 10 mensagens de cada dispositivo e verifique se o outro dispositivo as recebe corretamente.
5. 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

1. Reinicie o app Chat por Bluetooth nos dois dispositivos.
2. 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.