O uso de "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" e "optional" é de acordo com o padrão IETF definido em RFC2119 [ Recursos, 1 ].

Conforme usado neste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve uma solução de hardware/software executando o Android 2.3. Uma "implementação de dispositivo" ou "implementação" é a solução de hardware/software assim desenvolvida.

Para serem consideradas compatíveis com Android 2.3, as implementações de dispositivos DEVEM atender aos requisitos apresentados nesta Definição de Compatibilidade, incluindo quaisquer documentos incorporados por referência.

Quando esta definição ou os testes de software descritos na Seção 10 forem silenciosos, ambíguos ou incompletos, é responsabilidade do implementador do dispositivo garantir a compatibilidade com as implementações existentes. Por esta razão, o Android Open Source Project [ Resources, 3 ] é tanto a referência quanto a implementação preferida do Android. Os implementadores de dispositivos são fortemente incentivados a basear suas implementações, tanto quanto possível, no código-fonte "upstream" disponível no Android Open Source Project. Embora alguns componentes possam hipoteticamente ser substituídos por implementações alternativas, esta prática é fortemente desencorajada, pois passar nos testes de software se tornará substancialmente mais difícil. É responsabilidade do implementador garantir total compatibilidade comportamental com a implementação padrão do Android, incluindo e além do Conjunto de testes de compatibilidade. Finalmente, observe que certas substituições e modificações de componentes são explicitamente proibidas por este documento.

Observe que esta definição de compatibilidade foi emitida para corresponder à atualização 2.3.3 para Android, que é API de nível 10. Esta definição torna-se obsoleta e substitui a definição de compatibilidade para versões do Android 2.3 anteriores à 2.3.3. (Ou seja, as versões 2.3.1 e 2.3.2 estão obsoletas.) Os futuros dispositivos compatíveis com Android que executam o Android 2.3 DEVEM ser fornecidos com a versão 2.3.3 ou posterior.

2. Recursos

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

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

Projeto de código aberto Android: 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 android.os.Build: http://developer.android.com/reference/android/os/Build.html

Strings de versão permitidas no 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 de geolocalização HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API de banco de dados da web HTML5/W3C: http://www.w3.org/TR/webdatabase/

API HTML5/W3C IndexedDB: 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 do ícone 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

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

Papéis de parede animados: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Documentação da ferramenta de referência (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 de macaco: https://developer.android.com/studio/test/other-testing-tools/monkey

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

Suporte para múltiplas 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

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

Muitos desses recursos são derivados direta ou indiretamente do SDK do Android 2.3 e serão funcionalmente idênticos às informações contidas na documentação desse SDK. Em qualquer caso em que esta Definição de Compatibilidade ou o Conjunto de Testes de Compatibilidade discordem da documentação do SDK, a documentação do SDK será considerada oficial. Quaisquer detalhes técnicos fornecidos nas referências incluídas acima são considerados, por inclusão, como parte desta Definição de Compatibilidade.

3. Programas

A plataforma Android inclui um conjunto de APIs gerenciadas, um conjunto de APIs nativas e um corpo das chamadas APIs "soft", como o sistema Intent e APIs de aplicativos da web. Esta seção detalha as APIs físicas e flexíveis que são essenciais para a compatibilidade, bem como alguns outros comportamentos técnicos e de interface do usuário relevantes. As implementações de dispositivos DEVEM cumprir todos os requisitos desta seção.

3.1. Compatibilidade de API gerenciada

O ambiente de execução gerenciado (baseado em Dalvik) é o principal veículo para aplicativos Android. A interface de programação de aplicativos (API) Android é o conjunto de interfaces da plataforma Android expostas a aplicativos em execução no ambiente de VM gerenciada. As implementações de dispositivos DEVEM fornecer implementações completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK do Android 2.3 [ Recursos, 4 ].

As implementações de dispositivos NÃO DEVEM omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar-se do comportamento documentado ou incluir operações autônomas, exceto quando especificamente permitido por esta Definição de Compatibilidade.

Esta definição de compatibilidade permite que alguns tipos de hardware para os quais o Android inclui APIs sejam omitidos nas implementações de dispositivos. Nesses casos, as APIs DEVEM ainda estar presentes e se comportar de maneira razoável. Consulte a Seção 7 para requisitos específicos para este cenário.

3.2. Compatibilidade de API suave

Além das APIs gerenciadas da Seção 3.1, o Android também inclui uma API "soft" significativa somente em tempo de execução, na forma de itens como Intents, permissões e aspectos semelhantes de aplicativos Android que não podem ser aplicados no tempo de compilação do aplicativo. Esta seção detalha as APIs "soft" e os comportamentos do sistema necessários para compatibilidade com o Android 2.3. As implementações de dispositivos DEVEM atender a todos os requisitos apresentados nesta seção.

3.2.1. Permissões

Os implementadores de dispositivos DEVEM oferecer suporte e impor todas as constantes de permissão, conforme documentado na página de referência de permissão [ Recursos, 5 ]. Observe que a Seção 10 lista requisitos adicionais relacionados ao modelo de segurança do Android.

3.2.2. Parâmetros de construção

As APIs do Android incluem uma série de constantes na classe android.os.Build [ Resources, 6 ] que se destinam a descrever o dispositivo atual. Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui restrições adicionais sobre os formatos desses valores aos quais as implementações de dispositivos DEVEM estar em conformidade.

Parâmetro	Comentários
android.os.Build.VERSION.RELEASE	A versão do sistema Android atualmente em execução, em formato legível por humanos. Este campo DEVE ter um dos valores de string definidos em [ Resources, 7 ].
android.os.Build.VERSION.SDK	A versão do sistema Android atualmente em execução, em um formato acessível ao código do aplicativo de terceiros. Para Android 2.3, este campo DEVE ter o valor inteiro 9.
android.os.Build.VERSION.INCREMENTAL	Um valor escolhido pelo implementador do dispositivo que designa a versão específica do sistema Android em execução no momento, em formato legível por humanos. Este valor NÃO DEVE ser reutilizado para diferentes compilações disponibilizadas aos usuários finais. Um uso típico desse campo é indicar qual número de compilação ou identificador de alteração de controle de origem foi usado para gerar a compilação. Não há requisitos quanto ao formato específico deste campo, exceto que NÃO DEVE 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 formato legível por humanos. Uma possível utilização deste campo é indicar a revisão específica da placa que alimenta o dispositivo. O valor deste campo DEVE 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. Uma possível utilização deste campo é indicar o OEM e/ou operadora que vendeu o dispositivo. O valor deste campo DEVE ser codificável 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 deste campo DEVE 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 esta compilação. DEVE ser razoavelmente legível por humanos. DEVE 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 DEVE incluir caracteres de espaço em branco. Se outros campos incluídos no modelo acima tiverem caracteres de espaço em branco, eles DEVEM ser substituídos na impressão digital de construção por outro caractere, como o caractere de sublinhado ("_"). O valor deste campo DEVE ser codificável como ASCII de 7 bits.
android.os.Build.HOST	Uma string que identifica exclusivamente o host no qual o build foi criado, em formato legível por humanos. Não há requisitos quanto ao formato específico deste campo, exceto que NÃO DEVE 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 formato legível por humanos. Este campo pode ser igual a android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente significativo para que os usuários finais possam distinguir entre compilações de software. O valor deste campo DEVE 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 contendo o nome do dispositivo conhecido pelo usuário final. DEVE ser o mesmo nome sob o qual o dispositivo é comercializado e vendido aos usuários finais. Não há requisitos quanto ao formato específico deste campo, exceto que NÃO DEVE 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 nome de código do dispositivo. DEVE ser legível por humanos, mas não se destina necessariamente à visualização pelos usuários finais. O valor deste campo DEVE ser codificável 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 distinguem ainda mais a compilação. Por exemplo, "não assinado, depuração". O valor deste campo DEVE 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 especificando a configuração de tempo de execução do build. Este campo DEVE ter um dos valores correspondentes às três configurações típicas de tempo de execução do Android: "user", "userdebug" ou "eng". O valor deste campo DEVE ser codificável 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 quanto ao formato específico deste campo, exceto que NÃO DEVE ser nulo ou a string vazia ("").

3.2.3. Compatibilidade de intenções

O Android usa Intents para obter integração fraca entre aplicativos. Esta seção descreve os requisitos relacionados aos padrões de Intent que DEVEM ser respeitados pelas implementações de dispositivos. Por "honrado", significa que o implementador do dispositivo DEVE fornecer uma atividade ou serviço Android que especifique um filtro de intenção correspondente e se vincule e implemente o comportamento correto para cada padrão de intenção especificado.

3.2.3.1. Principais intenções do aplicativo

O projeto upstream do Android define uma série de aplicativos principais, como discador telefônico, calendário, agenda de contatos, reprodutor de música e assim por diante. Os implementadores de dispositivos PODEM substituir esses aplicativos por versões alternativas.

No entanto, quaisquer versões alternativas DEVEM respeitar os mesmos padrões de Intenção fornecidos pelo projeto upstream. Por exemplo, se um dispositivo contiver um reprodutor de música alternativo, ele ainda deverá respeitar o padrão de Intent emitido por aplicativos de terceiros para escolher uma música.

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

Relógio de mesa
Navegador
Calendário
Calculadora
Contatos
E-mail
Galeria
Pesquisa Global
Lançador
Música
Configurações

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

Para cada atividade ou serviço definido em um dos principais aplicativos do sistema Android que não esteja marcado como não público por meio de um atributo android:exported com o valor "false", as implementações de dispositivos DEVEM incluir um componente do mesmo tipo implementando o mesmo filtro de Intent padrões como o principal aplicativo do sistema Android.

Em outras palavras, uma implementação de dispositivo PODE substituir os principais aplicativos do sistema Android; no entanto, se isso acontecer, a implementação do dispositivo DEVE suportar todos os padrões de intenção definidos por cada aplicativo principal do sistema Android que está sendo substituído.

3.2.3.2. Substituições de intenção

Como o Android é uma plataforma extensível, os implementadores de dispositivos DEVEM permitir que cada padrão de Intent mencionado na Seção 3.2.3.1 seja substituído por aplicativos de terceiros. O projeto de código aberto Android upstream permite isso por padrão; os implementadores de dispositivos NÃO DEVEM atribuir privilégios especiais ao uso desses padrões de Intenção pelos aplicativos do sistema ou impedir que aplicativos de terceiros se vinculem e assumam o controle desses padrões. Esta proibição inclui especificamente, mas não está limitada a desabilitar a interface do usuário "Seletor", que permite ao usuário selecionar entre vários aplicativos que lidam com o mesmo padrão de Intenção.

3.2.3.3. Namespaces de intenção

Os implementadores de dispositivos NÃO DEVEM incluir nenhum componente Android que honre quaisquer novos padrões de Intent ou Broadcast Intent usando uma ACTION, CATEGORY ou outra string de chave no namespace android.*. Os implementadores de dispositivos NÃO DEVEM incluir nenhum componente Android que honre quaisquer novos padrões de Intent ou Broadcast Intent usando uma ACTION, CATEGORY ou outra string de chave em um espaço de pacote pertencente a outra organização. Os implementadores de dispositivos NÃO DEVEM alterar ou estender nenhum dos padrões de Intent usados pelos aplicativos principais listados na Seção 3.2.3.1.

Esta proibição é análoga àquela especificada para classes de linguagem Java na Seção 3.6.

3.2.3.4. Intenções de transmissão

Aplicativos de terceiros dependem da plataforma para transmitir determinadas intenções e notificá-los sobre alterações no ambiente de hardware ou software. Os dispositivos compatíveis com Android DEVEM transmitir as intenções de transmissão pública em resposta aos eventos apropriados do sistema. As intenções de transmissão estão descritas na documentação do SDK.

3.3. Compatibilidade de 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 do dispositivo apropriada. Como o código nativo é altamente dependente da tecnologia de processador subjacente, o Android define uma série de interfaces binárias de aplicativos (ABIs) no Android NDK, no arquivo docs/CPU-ARCH-ABIS.txt . Se a implementação de um dispositivo for compatível com uma ou mais ABIs definidas, DEVE implementar a compatibilidade com o Android NDK, conforme abaixo.

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

DEVE incluir suporte para código em execução no ambiente gerenciado para chamar código nativo, usando a semântica padrão Java Native Interface (JNI).
DEVE ser compatível com a fonte (ou seja, compatível com o cabeçalho) e compatível com o binário (para a ABI) com cada biblioteca necessária na lista abaixo
DEVE relatar com precisão a Application Binary Interface (ABI) nativa suportada pelo dispositivo, por meio da API android.os.Build.CPU_ABI
DEVE relatar apenas as ABIs documentadas na versão mais recente do Android NDK, no arquivo docs/CPU-ARCH-ABIS.txt
DEVE ser construído usando o código-fonte e os arquivos de cabeçalho disponíveis no projeto de código aberto Android upstream

As seguintes APIs de código nativo DEVEM estar disponíveis para aplicativos que incluem código nativo:

libc (biblioteca C)
libm (biblioteca matemática)
Suporte mínimo para C++
Interface JNI
liblog (registro do Android)
libz (compressã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 nativo)
libjnigraphics.so
libOpenSLES.so (suporte de áudio da Open Sound Library)
libandroid.so (suporte nativo à atividade do Android)
Suporte para OpenGL, conforme descrito abaixo

Observe que versões futuras do Android NDK poderão introduzir suporte para ABIs adicionais. Se uma implementação de dispositivo não for compatível com uma ABI predefinida existente, ela NÃO DEVE relatar suporte para qualquer ABI.

A compatibilidade do código nativo é um desafio. Por esta razão, deve ser repetido que os implementadores de dispositivos são MUITO fortemente encorajados a usar as implementações upstream das bibliotecas listadas acima para ajudar a garantir a compatibilidade.

3.4. Compatibilidade Web

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

3.4.1. Compatibilidade com WebView

A implementação do Android Open Source usa o mecanismo de renderização 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 DEVEM usar a construção upstream específica do WebKit na implementação do WebView. Especificamente:

As implementações de android.webkit.WebView das implementações de dispositivos DEVEM ser baseadas na versão 533.1 WebKit da árvore upstream de código-fonte aberto do Android para Android 2.3. Esta compilação inclui um conjunto específico de funcionalidades e correções de segurança para o WebView. Os implementadores de dispositivos PODEM incluir personalizações na implementação do WebKit; no entanto, tais personalizações NÃO DEVEM alterar o comportamento do WebView, incluindo o comportamento de renderização.
A string do agente do usuário relatada pelo WebView DEVE 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) DEVE 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 referir-se à localidade atualmente configurada do dispositivo
- O valor da string $(MODEL) DEVE ser igual ao valor de android.os.Build.MODEL
- O valor da string $(BUILD) DEVE ser igual ao valor de android.os.Build.ID

O componente WebView DEVE incluir suporte para o máximo possível de HTML5 [ Resources, 9 ]. No mínimo, as implementações de dispositivos DEVEM suportar cada uma destas APIs associadas ao HTML5 no WebView:

cache de aplicativo/operação offline [ Recursos, 10 ]
a tag <video> [ Recursos, 11 ]
geolocalização [ Recursos, 12 ]

Além disso, as implementações de dispositivos DEVEM oferecer suporte à API de armazenamento na web HTML5/W3C [ Recursos, 13 ] e DEVEM oferecer suporte à API HTML5/W3C IndexedDB [ Recursos, 14 ]. Observe que, à medida que os órgãos de padrões de desenvolvimento web estão fazendo a transição para favorecer o IndexedDB em vez do armazenamento na web, espera-se que o IndexedDB se torne um componente obrigatório em uma versão futura do Android.

As APIs HTML5, como todas as APIs JavaScript, DEVEM ser desabilitadas por padrão em um WebView, a menos que o desenvolvedor as ative explicitamente por meio das APIs Android usuais.

3.4.2. Compatibilidade do navegador

As implementações de dispositivos DEVEM 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 para aplicativos de terceiros DEVE ser baseado no WebKit, conforme descrito na Seção 3.4.1.

As implementações PODEM enviar uma string de agente de usuário personalizada no aplicativo de navegador independente.

O aplicativo de navegador independente (seja baseado no aplicativo WebKit Browser upstream ou em um substituto de terceiros) DEVE incluir suporte para o máximo de HTML5 [ Resources, 9 ] quanto possível. No mínimo, as implementações de dispositivos DEVEM suportar cada uma destas APIs associadas ao HTML5:

cache de aplicativo/operação offline [ Recursos, 10 ]
a tag <video> [ Recursos, 11 ]
geolocalização [ Recursos, 12 ]

3.5. Compatibilidade comportamental da API

Os comportamentos de cada um dos tipos de API (gerenciado, flexível, nativo e web) devem ser consistentes com a implementação preferida do projeto de código aberto Android upstream [ Recursos, 3 ]. Algumas áreas específicas de compatibilidade são:

Os dispositivos NÃO DEVEM alterar o comportamento ou a semântica de uma intenção padrão
Os dispositivos NÃO DEVEM 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 DEVEM alterar a semântica de uma permissão padrão

A lista acima não é abrangente. O Compatibility Test Suite (CTS) testa partes significativas da plataforma quanto à compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android Open Source Project. Por esta razão, os implementadores de dispositivos DEVEM usar o código-fonte disponível através do Android Open Source Project sempre que possível, em vez de reimplementar partes significativas do sistema.

3.6. Namespaces de API

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

Java.*
javax.*
sol.*
andróide.*
com.android.*

As modificações proibidas incluem:

As implementações de dispositivos NÃO DEVEM modificar as APIs expostas publicamente na plataforma Android, alterando qualquer método ou assinaturas de classe, ou removendo classes ou campos de classe.
Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas tais modificações NÃO DEVEM impactar o comportamento declarado e a assinatura da linguagem Java de quaisquer APIs expostas publicamente.
Os implementadores de dispositivos NÃO DEVEM adicionar quaisquer elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos a classes ou interfaces existentes) às APIs acima.

Um "elemento exposto publicamente" é qualquer construção que não seja decorada com o marcador "@hide" conforme usado no código-fonte original do Android. Em outras palavras, os implementadores de dispositivos NÃO DEVEM 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 DEVEM ser anunciadas ou expostas de outra forma aos desenvolvedores.

Os implementadores de dispositivos PODEM adicionar APIs personalizadas, mas essas APIs NÃO DEVEM estar em um namespace de propriedade ou referência a outra organização. Por exemplo, os implementadores de dispositivos NÃO DEVEM adicionar APIs ao namespace com.google.* ou similar; somente o Google pode fazer isso. Da mesma forma, o Google NÃO DEVE 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, essas APIs DEVEM ser empacotadas em uma biblioteca compartilhada do Android para que apenas os aplicativos que as utilizam explicitamente (por meio do mecanismo <uses-library> ) sejam afetados pelo aumento do uso de memória. dessas APIs.

Se um implementador de dispositivo propor melhorar um dos namespaces de pacote acima (como adicionando novas funcionalidades úteis a uma API existente ou adicionando uma nova API), o implementador DEVE visitar source.android.com e iniciar o processo para contribuir com alterações e código, de acordo com as informações desse site.

Observe que as restrições acima correspondem às convenções padrão para nomenclatura de APIs na linguagem de programação Java; esta secção visa simplesmente reforçar essas convenções e torná-las vinculativas através da inclusão nesta definição de compatibilidade.

3.7. Compatibilidade de Máquina Virtual

As implementações de dispositivos DEVEM suportar a especificação completa de bytecode Dalvik Executable (DEX) e a semântica da Dalvik Virtual Machine [ Recursos, 15 ].

Implementações de dispositivos com telas classificadas como de média ou baixa densidade DEVEM configurar a Dalvik para alocar pelo menos 16 MB de memória para cada aplicação. Implementações de dispositivos com telas classificadas como de alta densidade ou extra-alta densidade DEVEM configurar a Dalvik para alocar pelo menos 24 MB de memória para cada aplicação. Observe que as implementações de dispositivos PODEM alocar mais memória do que esses números.

3.8. Compatibilidade da interface do usuário

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

3.8.1. Widgets

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

Os implementadores de dispositivos PODEM substituir uma alternativa ao Launcher de referência (ou seja, tela inicial). Iniciadores alternativos DEVEM incluir suporte integrado para AppWidgets e expor elementos da interface do usuário para adicionar, configurar, visualizar e remover AppWidgets diretamente no Iniciador. Lançadores alternativos PODEM omitir esses elementos da interface do usuário; entretanto, se forem omitidos, o implementador do dispositivo DEVE fornecer um aplicativo separado, acessível a partir do Launcher, que permita aos usuários adicionar, configurar, visualizar e remover AppWidgets.

3.8.2. Notificações

O Android inclui APIs que permitem aos desenvolvedores notificar os usuários sobre eventos notáveis [ Recursos, 17 ]. Os implementadores de dispositivos DEVEM fornecer suporte para cada classe de notificação assim definida; especificamente: sons, vibração, luz e barra de status.

Além disso, a implementação DEVE renderizar corretamente todos os recursos (ícones, arquivos de som, etc.) previstos nas APIs [ Recursos, 18 ] ou no guia de estilo de ícones da Barra de Status [ Recursos, 19 ]. Os implementadores de dispositivos PODEM fornecer uma experiência de usuário alternativa para notificações do que aquela fornecida pela implementação de referência do Android Open Source; no entanto, tais sistemas de notificação alternativos DEVEM apoiar os recursos de notificação existentes, como acima.

3.8.3. Procurar

O Android inclui APIs [ Resources, 20 ] que permitem aos desenvolvedores incorporar pesquisas em seus aplicativos e expor os dados de seus aplicativos na pesquisa global do sistema. De modo geral, essa funcionalidade consiste em uma interface de usuário única para todo o sistema que permite aos usuários inserir consultas, exibir sugestões à medida que os usuários digitam e exibir resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para fornecer pesquisa em seus próprios aplicativos e permitem que os desenvolvedores forneçam resultados para a interface de usuário de pesquisa global comum.

As implementações de dispositivos DEVEM incluir uma interface de usuário de pesquisa única e compartilhada em todo o sistema, capaz de sugestões em tempo real em resposta à entrada do usuário. As implementações de dispositivos DEVEM implementar APIs que permitam aos desenvolvedores reutilizar essa interface de usuário para fornecer pesquisa em seus próprios aplicativos. As implementações de dispositivos DEVEM 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 estiver instalado que faça uso dessa funcionalidade, o comportamento padrão DEVE ser exibir resultados e sugestões de mecanismos de pesquisa na web.

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

3.8.4. Torradas

Os aplicativos podem usar a API "Toast" (definida em [ Recursos, 21 ]) para exibir strings curtas não modais para o usuário final, que desaparecem após um breve período de tempo. As implementações de dispositivos DEVEM exibir brindes de aplicativos para usuários finais de forma de alta visibilidade.

3.8.5. Papel de parede animados

O Android define um tipo de componente e API e ciclo de vida correspondentes que permitem que os aplicativos exponham um ou mais "Live Wallpapers" ao usuário final [ Recursos, 22 ]. Papéis de parede animados são animações, padrões ou imagens semelhantes com recursos de entrada limitados que são exibidos como papel de parede, atrás de outros aplicativos.

O hardware é considerado capaz de executar papéis de parede animados de forma confiável se puder 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 fizerem com que os papéis de parede e/ou aplicativos travem, funcionem mal, consumam energia excessiva da CPU ou da bateria ou sejam executados com taxas de quadros inaceitavelmente baixas, o hardware será considerado incapaz de executar papéis de parede ao vivo. Por exemplo, alguns papéis de parede animados podem usar um contexto Open GL 1.0 ou 2.0 para renderizar seu conteúdo. O papel de parede ao vivo não será executado de forma confiável em hardware que não suporta vários contextos OpenGL porque o uso do papel de parede ao vivo de um contexto OpenGL pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

Implementações de dispositivos capazes de executar papéis de parede animados de maneira confiável, conforme descrito acima, DEVEM implementar papéis de parede animados. As implementações de dispositivos determinadas a não executar papéis de parede animados de forma confiável, conforme descrito acima, NÃO DEVEM implementar papéis de parede animados.

4. Compatibilidade de pacotes de aplicativos

As implementações do dispositivo devem instalar e executar arquivos Android ".apk", conforme gerado pela ferramenta "AAPT" incluída no Android SDK oficial [ Recursos, 23 ].

As implementações de dispositivos não devem estender os formatos .apk [ Recursos, 24 ], Android manifestos [ Recursos, 25 ] ou Dalvik Bytecode [ Recursos, 15 ] de tal maneira que impediria que esses arquivos instalassem e executem corretamente em outros dispositivos compatíveis . Os implementadores de dispositivos devem usar a implementação de referência a montante do Dalvik e o sistema de gerenciamento de pacotes da implementação de referência.

5. Compatibilidade multimídia

As implementações do dispositivo devem implementar totalmente todas as APIs multimídia. As implementações do dispositivo devem incluir suporte para todos os codecs multimídia descritos abaixo e devem atender às diretrizes de processamento de som descritas abaixo. As implementações de dispositivos devem incluir pelo menos uma forma de saída de áudio, como alto -falantes, fone de ouvido, conexão de alto -falante externa, etc.

5.1. Codecs de mídia

As implementações do dispositivo devem suportar os 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 de código aberto do Android.

Observe que nem o Google nem a Open Handet Alliance fazem qualquer representação de que esses codecs não tenham onerado por patentes de terceiros. Aqueles que pretendem usar esse código fonte em produtos de hardware ou software são informados de que as implementações desse código, incluindo o software de código aberto ou o ShareWare, podem exigir licenças de patentes dos titulares de patentes relevantes.

As tabelas abaixo não listam requisitos de taxa de bits específicos para a maioria dos codecs de vídeo. A razão para isso é que, na prática, o hardware atual do dispositivo não suporta necessariamente as taxas de bits que mapeiam exatamente para as taxas de bits necessárias especificadas pelos padrões relevantes. Em vez disso, as implementações do dispositivo devem suportar a maior taxa de bits prática no hardware, até os limites definidos pelas especificações.

5.1.1. Decodificadores de mídia

As implementações do dispositivo devem incluir uma implementação de um decodificador para cada codec e formato descrito na tabela abaixo. Observe que os decodificadores para cada um desses tipos de mídia são fornecidos pelo projeto de código aberto Android a montante.

Á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 a 48kHz	3GPP (.3GP) e MPEG-4 (.mp4, .m4a). Sem suporte para AAC bruto (.AAC)
	He-AACV1 (AAC+)
	He-AACV2 (AAC+aprimorado)
	AMR-NB	4,75 a 12,2 kbps amostrados @ 8kHz	3GPP (.3GP)
	AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s amostradas @ 16kHz	3GPP (.3GP)
	MP3	Constante mono/estéreo 8-320kbps (CBR) ou taxa de bit variável (VBR)	Mp3 (.mp3)
	MIDI	MIDI TIPO 0 e 1. DLS Versão 1 e 2. XMF e Mobile XMF. Suporte para 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 de hardware)	Onda (.wav)
Imagem
	JPEG	base+progressiva
	GIFs
	png
	Veículo de combate de infantaria
Vídeo
	H.263		Arquivos 3GPP (.3gp)
	H.264		Arquivos 3GPP (.3GP) e MPEG-4 (.mp4)
	MPEG4 Perfil simples		Arquivo 3GPP (.3GP)

5.1.2. Codificadores de mídia

As implementações do dispositivo devem incluir codificadores para tantos formatos de mídia listados na Seção 5.1.1. que possível. No entanto, alguns codificadores não fazem sentido para dispositivos que não possuem certos hardware opcional; Por exemplo, um codificador para o vídeo H.263 não faz sentido, se o dispositivo não possui câmeras. As implementações do dispositivo devem, portanto, implementar os codificadores de mídia de acordo com as condições descritas na tabela abaixo.

Consulte a Seção 7 para obter detalhes sobre as condições sob as quais 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 amostrados @ 8kHz	3GPP (.3GP)	As implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone` devem incluir codificadores para esses formatos de áudio.
	AMR-WB	9 taxas de 6,60 kbit/s a 23,85 kbit/s amostradas @ 16kHz	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 a 48kHz	3GPP (.3GP) e MPEG-4 (.mp4, .m4a).
Imagem	JPEG	base+progressiva		Todas as implementações do dispositivo devem incluir codificadores para esses formatos de imagem, pois o Android 2.3 inclui APIs que os aplicativos podem usar para gerar programaticamente arquivos desses tipos.
Imagem	png
Vídeo	H.263		Arquivos 3GPP (.3gp)	As implementações de dispositivos que incluem hardware da câmera e definem `android.hardware.camera` ou `android.hardware.camera.front` devem incluir codificadores para esses formatos de vídeo.

Além dos codificadores listados acima, as implementações do dispositivo devem incluir um codificador H.264. Observe que a definição de compatibilidade para uma versão futura está planejada para alterar esse requisito para "deve". Ou seja, a codificação H.264 é opcional no Android 2.3, mas será exigida por uma versão futura. Os dispositivos novos e existentes que executam o Android 2.3 são fortemente incentivados a atender a esse requisito no Android 2.3 , ou não serão capazes de atingir a compatibilidade do Android quando atualizados para a versão futura.

5.2. Gravação de áudio

Quando um aplicativo usou a API android.media.AudioRecord para começar a gravar um fluxo de áudio, as implementações de dispositivos devem experimentar e gravar áudio com cada um desses comportamentos:

O processamento de redução de ruído, se presente, deve ser desativado.
O controle automático de ganho, se presente, deve ser desativado.
O dispositivo deve exibir características de amplitude aproximadamente plana versus frequência; Especificamente, ± 3 dB, de 100 Hz a 4000 Hz
A sensibilidade à entrada de áudio deve ser definida de modo que uma fonte de nível de potência de som de 90 dB (SPL) a 1000 Hz produz RMS de 5000 para amostras de 16 bits.
Os níveis de amplitude do PCM devem rastrear linearmente as alterações de SPL em pelo menos uma faixa de 30 dB de -18 dB a +12 dB RE 90 dB SPL no microfone.
A distorção harmônica total deve ser inferior a 1% de 100 Hz a 4000 Hz no nível de entrada SPL de 90 dB.

NOTA: Embora os requisitos descritos acima sejam declarados como "deveriam" para o Android 2.3, a definição de compatibilidade para uma versão futura está planejada para alterá -los para "deve". Ou seja, esses requisitos são opcionais no Android 2.3, mas serão necessários por uma versão futura. Os dispositivos novos e existentes que executam o Android 2.3 são fortemente incentivados a atender a esses requisitos no Android 2.3 , ou não serão capazes de atingir a compatibilidade do Android quando atualizados para a versão futura.

5.3. Latência de áudio

A latência de áudio é amplamente definida como o intervalo entre quando um aplicativo solicita uma reprodução de áudio ou operação de registro e quando a implementação do dispositivo realmente inicia a operação. Muitas classes de aplicações dependem de latências curtas, para obter efeitos em tempo real, tais efeitos sonoros ou comunicação VoIP. As implementações de dispositivos que incluem hardware de microfone e declaram android.hardware.microphone devem atender a todos os requisitos de latência de áudio descritos nesta seção. Consulte a Seção 7 para obter detalhes sobre as condições sob as quais o hardware do microfone pode ser omitido pelas implementações do dispositivo.

Para os propósitos desta seção:

"Latência de saída a frio" é definida como o intervalo entre quando um aplicativo solicita a reprodução de áudio e quando o som começa a ser reproduzido, quando o sistema de áudio estiver ocioso e desligado antes da solicitação
"Latência de saída quente" é definida como o intervalo entre quando um aplicativo solicita a reprodução de áudio e quando o som começa a reproduzir, quando o sistema de áudio foi usado recentemente, mas atualmente está ocioso (ou seja, silencioso)
"Latência contínua de saída" é definida como o intervalo entre quando um aplicativo emite uma amostra a ser reproduzida e quando o falante toca fisicamente o som correspondente, enquanto o dispositivo está atualmente reproduzindo áudio
"Latência de entrada a frio" é definida como o intervalo entre quando um aplicativo solicita gravação de áudio e quando a primeira amostra é entregue ao aplicativo por meio de seu retorno de chamada, quando o sistema de áudio e o microfone estão ociosos e desligados antes da solicitação
"Latência contínua de entrada" está definida como quando ocorre um som ambiente e quando a amostra correspondente a esse som é entregue a um aplicativo de gravação por meio de seu retorno de chamada, enquanto o dispositivo está no modo de gravação

Usando as definições acima, as implementações do dispositivo devem exibir cada uma dessas 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 contínua de saída 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 do dispositivo atender aos requisitos desta seção, ele poderá relatar suporte para áudio de baixa latência, relatando o recurso "Android.hardware.audio.low-latência" via android.content.pm.PackageManager . [ Recursos, 27 ] Por outro lado, se a implementação do dispositivo não atender a esses requisitos, ele não deverá relatar suporte para áudio de baixa latência.

6. Compatibilidade da ferramenta de desenvolvedor

As implementações do dispositivo devem suportar as ferramentas de desenvolvedor Android fornecidas no Android SDK. Especificamente, os dispositivos compatíveis com Android devem ser compatíveis com:

Android Debug Bridge (conhecido como ADB) [ Recursos, 23 ]
As implementações do dispositivo devem suportar todas as funções adb , conforme documentado no Android SDK. O daemon adb do lado do dispositivo deve estar inativo por padrão, mas deve haver um mecanismo acessível ao usuário para ativar a ponte de depuração do Android.
Dalvik Debug Monitor Service (conhecido como DDMS) [ Recursos, 23 ]
As implementações do dispositivo devem suportar todos os recursos ddms , conforme documentado no Android SDK. Como ddms usa adb , o suporte para ddms deve estar inativo por padrão, mas deve ser suportado sempre que o usuário ativou a ponte de depuração do Android, como acima.
Macaco [ Recursos, 26 ]
As implementações do dispositivo devem incluir a estrutura do macaco e disponibilizá -lo para os aplicativos usarem.

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

7. Compatibilidade de hardware

O Android destina -se a permitir que os implementadores de dispositivos criem fatores e configurações inovadores de forma. Ao mesmo tempo, os desenvolvedores do Android escrevem aplicativos inovadores que dependem dos vários hardware e recursos disponíveis através das APIs do Android. Os requisitos nesta seção atingem um equilíbrio entre inovações disponíveis para os implementadores de dispositivos e as necessidades dos desenvolvedores para garantir que seus aplicativos estejam disponíveis apenas para dispositivos onde eles serão executados corretamente.

Se um dispositivo incluir um componente de hardware específico que possui uma API correspondente para desenvolvedores de terceiros, a implementação do dispositivo deve implementar essa API, conforme descrito na documentação do Android SDK. Se uma API no SDK interage com um componente de hardware que é declarado opcional e a implementação do dispositivo não possui esse componente:

Definições de classe completas (conforme documentado pelo SDK) para as APIs do componente ainda devem estar presentes
Os comportamentos da API devem ser implementados como ninguém de alguma maneira razoável
Os métodos da API devem retornar valores nulos, quando permitido pela documentação do SDK
Os métodos da API devem retornar implementações de não-operação de classes onde os valores nulos não são permitidos pela documentação do SDK
Os métodos da API não devem lançar 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 sejam de telefone, essas APIs devem ser implementadas como NOPs razoáveis.

As implementações do dispositivo devem relatar com precisão informações precisas de configuração de hardware por meio dos métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager . [ Recursos, 27 ]

7.1. Exibição e gráficos

O Android 2.3 inclui instalações que ajustam automaticamente os ativos de aplicativos e os layouts da interface do usuário adequadamente para o dispositivo, para garantir que os aplicativos de terceiros funcionem bem em uma variedade de configurações de hardware [ Recursos, 28 ]. Os dispositivos devem implementar adequadamente essas APIs e comportamentos, conforme detalhado nesta seção.

7.1.1. Configurações de tela

As implementações de dispositivos podem usar telas de quaisquer dimensões de pixels, desde que atendam aos seguintes requisitos:

As telas devem ter pelo menos 2,5 polegadas no tamanho da diagonal física
A densidade deve ser pelo menos 100 dpi
A proporção deve estar entre 1,333 (4: 3) e 1,779 (16: 9)
A tecnologia de exibição usada consiste em pixels quadrados

As implementações de dispositivos com uma tela que atendem aos requisitos acima são consideradas compatíveis e nenhuma ação adicional é necessária. A implementação da estrutura do Android calcula automaticamente características de exibição, como balde de tamanho de tela e balde de densidade. Na maioria dos casos, as decisões da estrutura são as corretas. Se os cálculos de estrutura padrão forem usados, nenhuma ação adicional será necessária. Os implementadores de dispositivos que desejam alterar os padrões ou usam uma tela que não atende aos requisitos acima devem entrar em contato com a equipe de compatibilidade do Android para obter orientação, conforme previsto na Seção 12.

As unidades usadas pelos requisitos acima são definidas da seguinte forma:

"Tamanho da diagonal físico" é a distância em polegadas entre dois cantos opostos da porção iluminada da tela.
"DPI" (que significa "pontos por polegada") é o número de pixels englobados por uma extensão horizontal ou vertical linear de 1 ". Onde os valores de DPI são listados, o DPI horizontal e vertical deve se enquadrar dentro do intervalo.
"Razão" é a proporção da dimensão mais longa da tela para a dimensão mais curta. Por exemplo, uma exibição de 480x854 pixels seria 854 /480 = 1,779, ou aproximadamente "16: 9".

As implementações do dispositivo devem usar apenas exibições com uma única configuração estática. Ou seja, as implementações do dispositivo não devem ativar várias configurações de tela. Por exemplo, como uma televisão típica suporta 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á sob investigação e planejado para uma versão futura do Android.)

7.1.2. Exibir métricas

As implementações do dispositivo devem relatar valores corretos para todas as métricas de exibição definidas em android.util.DisplayMetrics [ Recursos, 29 ].

7.1.3. Declarou suporte da tela

Opcionalmente, os aplicativos indicam quais tamanhos de tela suportam através do atributo <supports-screens> no arquivo AndroidManifest.xml. As implementações do dispositivo devem honrar corretamente o suporte declarado dos aplicativos para telas pequenas, médias e grandes, conforme descrito na documentação do Android SDK.

7.1.4. Orientação da tela

Os dispositivos compatíveis devem suportar orientação dinâmica por aplicativos para a orientação da tela de retrato ou paisagem. Ou seja, o dispositivo deve respeitar a solicitação do aplicativo para uma orientação específica da tela. As implementações do dispositivo podem selecionar a orientação de retrato ou paisagem como padrão. Dispositivos que não podem ser girados fisicamente podem atender a esse requisito por aplicativos de "caixa de correio" que solicitam o modo retrato, usando apenas uma parte da tela disponível.

Os dispositivos devem relatar o valor correto para a orientação atual do dispositivo, sempre que consultado através do android.content.res.configuration.orientation, android.view.display.getorientation () ou outras APIs.

7.1.5. Aceleração gráfica 3D

As implementações do dispositivo devem suportar o OpenGL ES 1.0, conforme exigido pelas APIs do Android 2.3. Para dispositivos que não possuem hardware de aceleração em 3D, uma implementação de software do OpenGL ES 1.0 é fornecida pelo projeto Android Android. As implementações do dispositivo devem suportar o OpenGL ES 2.0.

As implementações podem omitir suporte aberto GL ES 2.0; No entanto, se o suporte for omitido, as implementações de dispositivos não devem relatar como suportando o OpenGL ES 2.0. Especificamente, se as implementações de um dispositivo não possuem suporte de OpenGL ES 2.0:

As APIs gerenciadas (como através do método GLES10.getString() ) não devem relatar suporte para o OpenG ES 2.0
As APIs nativas de C/C ++ OpenGL (ou seja, aquelas disponíveis para aplicativos via libgles_v1cm.so, libgles_v2.so ou libegl.so) não devem relatar suporte ao OpenGL ES 2.0.

Por outro lado, se uma implementação de dispositivo suportar o OpenGL ES 2.0, ele deverá relatar com precisão que o suporte através das rotas acabou de ser listadas.

Observe que o Android 2.3 inclui suporte para aplicativos para especificar opcionalmente que requerem formatos específicos de compactação de textura OpenGL. Esses formatos são tipicamente específicos para fornecedores. As implementações do dispositivo não são exigidas pelo Android 2.3 para implementar qualquer formato específico de compressão de textura. No entanto, eles devem relatar com precisão qualquer formato de compactação de textura que eles apoiem, através do método getString() na API OpenGL.

7.2. Dispositivos de entrada

O Android 2.3 suporta uma série de modalidades para entrada do usuário. As implementações do dispositivo devem suportar os dispositivos de entrada do usuário, conforme previsto nesta seção.

7.2.1. Teclado

Implementações de dispositivos:

Deve incluir suporte para a estrutura de gerenciamento de entrada (que permite que desenvolvedores de terceiros criem mecanismos de gerenciamento de entrada - ou seja, teclado soft) conforme detalhado no desenvolvedor.android.com
Deve fornecer pelo menos uma implementação de teclado suave (independentemente de um teclado rígido estar presente)
Pode incluir implementações adicionais de teclado suave
Pode incluir um teclado de hardware
Não deve incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard [ Recursos, 30 ] (isto é, Qwerty ou 12 teclas)

Implementações de dispositivos:

Pode omitir uma opção de navegação não touch (ou seja, pode omitir um trackball, D-pad ou roda)
Deve relatar o valor correto para android.content.res.Configuration.navigation [ Recursos, 30 ]
Deve fornecer um mecanismo de interface alternativo de usuário razoável para a seleção e edição do texto, compatível com os mecanismos de gerenciamento de entrada. O código de código aberto Android a montante inclui um mecanismo de seleção adequado para uso com dispositivos que não possuem entradas de navegação não-touch.

As funções domésticas, menus e costas são essenciais para o paradigma de navegação Android. As implementações do dispositivo devem disponibilizar essas funções ao usuário o tempo todo, independentemente do estado do aplicativo. Essas funções devem ser implementadas através de botões dedicados. Eles podem ser implementados usando software, gestos, painel de toque, etc., mas se assim for, devem estar sempre acessíveis e não obscurecer ou interferir na área de exibição do aplicativo disponível.

Os implementadores do dispositivo também devem fornecer uma chave de pesquisa dedicada. Os implementadores de dispositivos também podem fornecer chaves de envio e final para chamadas telefônicas.

7.2.4. Entrada de tela sensível ao toque

Implementações de dispositivos:

Deve ter uma tela sensível ao toque
Pode ter tela sensível ao toque capacitiva ou resistiva
Deve relatar o valor de android.content.res.Configuration [ Recursos, 30 ] refletindo correspondente ao tipo de tela sensível ao toque específica no dispositivo
Deve apoiar os ponteiros totalmente rastreados de forma independente, se a tela sensível ao toque suportar vários ponteiros

7.3. Sensores

O Android 2.3 inclui APIs para acessar uma variedade de 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 possui uma API correspondente para desenvolvedores de terceiros, a implementação do dispositivo deve implementar essa API, conforme descrito na documentação do Android SDK. Por exemplo, implementações de dispositivos:

Deve relatar com precisão a presença ou ausência de sensores de acordo com a classe android.content.pm.PackageManager . [ Recursos, 27 ]
Deve retornar uma lista precisa de sensores suportados por meio do SensorManager.getSensorList() e métodos similares
Deve se comportar razoavelmente com todas as outras APIs do sensor (por exemplo, retornando verdadeiro ou falso conforme apropriado quando os aplicativos tentam registrar ouvintes, não chamando os ouvintes do sensor quando os sensores correspondentes não estão presentes; etc.)

A lista acima não é abrangente; O comportamento documentado do Android SDK deve ser considerado autoritário.

Alguns tipos de sensores são sintéticos, o que significa que podem ser derivados dos 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 do dispositivo devem implementar esses tipos de sensores, quando incluem os sensores físicos de pré -requisito.

As APIs do Android 2.3 introduzem uma noção de um sensor de "streaming", que é aquele que retorna os dados continuamente, e não apenas quando os dados mudam. As implementações do dispositivo devem fornecer continuamente amostras de dados periódicas para qualquer API indicada pela documentação do Android 2.3 SDK como um sensor de streaming.

7.3.1. Acelerômetro

As implementações do dispositivo devem incluir um acelerômetro de 3 eixos. Se uma implementação de dispositivo incluir um acelerômetro de 3 eixos, ele:

Deve ser capaz de entregar eventos a 50 Hz ou mais
Deve cumprir o sistema de coordenadas do sensor Android, conforme detalhado nas APIs Android (ver [ Recursos, 31 ])
Deve ser capaz de medir de queda livre até duas vezes gravidade (2g) ou mais em qualquer vetor tridimensional
Deve 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 do dispositivo devem incluir um magnetômetro de 3 eixos (ou seja, bússola). Se um dispositivo incluir um magnetômetro de 3 eixos, ele:

Deve ser capaz de entregar eventos a 10 Hz ou mais
Deve cumprir o sistema de coordenadas do sensor Android, conforme detalhado nas APIs Android (ver [ Recursos, 31 ]).
Deve ser capaz de provar uma variedade de forças de campo adequadas para cobrir o campo geomagnético
Deve ter 8 bits de precisão ou mais
Deve ter um desvio padrão não maior que 0,5 µt

7.3.3. GPS

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

7.3.4. Giroscópio

As implementações do dispositivo devem incluir um giroscópio (ou seja, os dispositivos de mudança de mudança angular.) Não devem incluir um sensor de giroscópio, a menos que um acelerômetro de 3 eixos também esteja incluído. Se uma implementação de dispositivo incluir um giroscópio, ele:

Deve ser capaz de medir mudanças de orientação até 5,5*Pi Radians/segundo (ou seja, aproximadamente 1.000 graus por segundo)
Deve ser capaz de entregar eventos a 100 Hz ou mais
Deve 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, sensor de pressão de ar ambiente.) Se uma implementação de dispositivo incluir um barômetro, ele:

Deve ser capaz de entregar eventos a 5 Hz ou mais
Deve ter precisão adequada para permitir a estimativa de altitude

7.3.7. Termômetro

As implementações do dispositivo podem, mas não devem incluir um termômetro (ou seja, sensor de temperatura). Se uma implementação do dispositivo incluir um termômetro, ele deve medir a temperatura da CPU do dispositivo. Não deve medir nenhuma outra temperatura. (Observe que esse tipo de sensor está depreciado nas APIs Android 2.3.)

7.3.7. Fotômetro

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

7.3.8. Sensor de proximidade

As implementações do dispositivo podem incluir um sensor de proximidade. Se uma implementação de dispositivo incluir um sensor de proximidade, ele deve medir a proximidade de um objeto na mesma direção que a tela. Ou seja, o sensor de proximidade deve ser orientado para detectar objetos próximos à tela, pois a intenção primária desse tipo de sensor é detectar um telefone em uso pelo usuário. Se uma implementação de dispositivo incluir um sensor de proximidade com qualquer outra orientação, ele não deve ser acessível através desta API. Se uma implementação de dispositivo tiver um sensor de proximidade, ele deve 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 dispositivo a dispositivo agrega valor significativo aos dispositivos e aplicativos Android. As implementações do dispositivo devem atender aos requisitos de conectividade de dados nesta seção.

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android 2.3 e este documento se refere especificamente ao hardware relacionado à colocação de chamadas de voz e envio de mensagens SMS por meio de uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutadas por pacotes, elas são para fins do Android 2.3 considerados independentes de qualquer conectividade de dados que possam ser implementados usando a mesma rede. Em outras palavras, a funcionalidade de "telefonia" do Android e as APIs se refere especificamente a chamadas de voz e SMS; Por exemplo, as implementações do dispositivo que não podem fazer chamadas ou enviar/receber mensagens SMS não devem relatar o recurso "Android.hardware.telephony" ou quaisquer sub-fumantes, independentemente de usarem 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 telefones. No entanto, se uma implementação de dispositivo incluir GSM ou telefonia CDMA, ele deve implementar suporte completo para a API para essa tecnologia. As implementações de dispositivos que não incluem hardware de telefonia devem implementar as APIs completas como não-OPS.

7.4.2. IEEE 802.11 (wifi)

As implementações do dispositivo Android 2.3 devem incluir suporte para uma ou mais formas de 802.11 (b/g/a/n, etc.) Se uma implementação de dispositivo incluir suporte para 802.11, ele deve implementar a API Android correspondente.

7.4.3. Bluetooth

As implementações do dispositivo devem incluir um transceptor Bluetooth. As implementações de dispositivos que incluem um transceptor Bluetooth devem ativar a API Bluetooth baseada em RFComm, conforme descrito na documentação do SDK [ Recursos, 32 ]. As implementações do dispositivo devem implementar perfis relevantes do Bluetooth, como A2DP, AVRCP, Obex etc. conforme apropriado para o dispositivo.

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

7.4.4. Comunicações de campo próximo

As implementações de dispositivos devem incluir um transceptor e hardware relacionado para comunicações de campo próximo (NFC). Se uma implementação de dispositivo incluir hardware NFC, ele:

Deve relatar o recurso Android.hardware.nfc do android.content.pm.PackageManager.hasSystemFeature() . [ Recursos, 27 ]

Deve ser capaz de ler e escrever mensagens NDEF através dos seguintes padrões da NFC:

Deve ser capaz de atuar como um leitor/escritor do fórum da NFC (conforme definido pela especificação técnica do fórum da NFC NFCFORUM-TS-DigitalProtocol-1.0) através dos seguintes padrões da NFC:
- NFCA (ISO14443-3A)
- NFCB (ISO14443-3B)
- NFCF (JIS 6319-4)
- NFCV (ISO 15693)
- ISODEP (ISO 14443-4)
- NFC Fórum Tags Tipos 1, 2, 3, 4 (definido pelo fórum da NFC)
Deve ser capaz de transmitir e receber dados através dos seguintes padrões e protocolos ponto a ponto:
- ISO 18092
- LLCP 1.0 (definido pelo fórum da NFC)
- SDP 1.0 (definido pelo fórum da NFC)
- Protocolo Push NDEF [ Recursos, 33 ]
Deve digitalizar todas as tecnologias suportadas enquanto estiver no modo de descoberta da NFC.
Deve estar no modo de descoberta NFC enquanto o dispositivo está acordado com a tela ativa.

(Observe que os links disponíveis ao público não estão disponíveis para as especificações do fórum JIS, ISO e NFC citadas acima.)

Além disso, as implementações de dispositivos devem suportar as seguintes tecnologias Mifare amplamente implantadas.

Mifare Classic (NXP MF1S503X [ Recursos, 34 ], MF1S703X [ Recursos, 35 ])
Mifare Ultralight (NXP MF0ICU1 [ Recursos, 36 ], Mf0icu2 [ Recursos, 37 ])
NDEF no Mifare Classic (NXP AN130511 [ Recursos, 38 ], AN130411 [ Recursos, 39 ])

Observe que o Android 2.3.3 inclui APIs para esses tipos de mifare. Se uma implementação de dispositivo suportar Mifare, ele:

Deve implementar as APIs Android correspondentes, conforme documentado pelo Android SDK
Deve relatar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature() . [ Recursos, 27 ] Observe que esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe PackageManager .
Não deve implementar as APIs Android correspondentes nem relatar o recurso com.nxp.mifare, a menos que também implemente o suporte geral à NFC, conforme descrito nesta seção

Se uma implementação de dispositivo não incluir hardware NFC, ele não deve declarar o recurso Android.hardware.nfc do android.content.pm.PackageManager.hasSystemFeature() [ Recursos, 27 ], e implementar o Android 2.3 NFC API como um não-op.

Como as classes android.nfc.NdefMessage e android.nfc.NdefRecord representam um formato de representação de dados independente do protocolo, as implementações de dispositivos devem implementar essas APIs, mesmo que não incluam suporte para NFC ou declare o recurso Android.hard.nfc.

7.4.5. Capacidade mínima de rede

As implementações do dispositivo devem incluir suporte para uma ou mais formas de rede de dados. Especificamente, as implementações do dispositivo devem incluir suporte para pelo menos um padrão de dados capaz de 200kbit/s ou mais. Exemplos de tecnologias que atendem a esse requisito incluem Edge, HSPA, EV-Do, 802.11g, Ethernet, etc.

As implementações de dispositivos em que um padrão de rede física (como Ethernet) é a conexão de dados primária também deve incluir suporte para pelo menos um padrão de dados sem fio comum, como 802.11 (WiFi).

Os dispositivos podem implementar mais de uma forma de conectividade de dados.

7.5. Câmeras

As implementações do dispositivo devem incluir uma câmera voltada para trás e podem incluir uma câmera frontal. Uma câmera traseira é uma câmera localizada na lateral do dispositivo em frente à tela; Ou seja, imagens de cenas do outro lado 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 imaginar o usuário, como para videoconferência e aplicativos semelhantes.

7.5.1. Câmera voltada para trás

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

Deve ter uma resolução de pelo menos 2 megapixels
Deve ter foco automático de hardware ou foco automático de software implementado no driver da câmera (transparente para o software de aplicativo)
Pode ter foco fixo ou hardware de eDOF (profundidade de campo prolongada)
Pode incluir um flash. Se a câmera incluir um flash, a lâmpada flash não deve ser acesa enquanto um Android.hardware.camera.previewCallback A instância foi registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha atribuído explicitamente o flash, permitindo o FLASH_MODE_AUTO ou FLASH_MODE_ON . Objeto Camera.Parameters . Observe que essa restrição não se aplica ao aplicativo de câmera do sistema interno do dispositivo, mas apenas a aplicativos de terceiros usando 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, ele:

Deve ter uma resolução de pelo menos VGA (ou seja, 640x480 pixels)
Não deve usar uma câmera frontal como padrão para a API da câmera. Ou seja, a API da câmera no Android 2.3 possui suporte específico para câmeras frontais, e as implementações de dispositivos não devem configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera na o dispositivo.
Pode incluir recursos (como foco automático, flash etc.) disponíveis para as câmeras voltadas para trás, conforme descrito na Seção 7.5.1.
Deve refletir horizontalmente (ou seja, espelho) o fluxo exibido por um aplicativo em uma camerapreview, como segue:

If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
Otherwise, the preview MUST be mirrored along the device's default horizontal axis.

MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3. Camera API Behavior

Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

7.5.4. Camera Orientation

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, a cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6. Memory and Storage

The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

7.6.1. Minimum Memory and Storage

Device implementations MUST have at least 128MB of memory available to the kernel and userspace. The 128MB MUST be in addition to any memory dedicated to hardware components such as radio, memory, and so on that is not under the kernel's control.

Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

7.6.2. Application Shared Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

7.7. USB

Implementações de dispositivos:

MUST implement a USB client, connectable to a USB host with a standard USB-A port
MUST implement the Android Debug Bridge over USB (as described in Section 7)
MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
SHOULD use the micro USB form factor on the device side
MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

8. Performance Compatibility

Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

Métrica	Limiar de desempenho	Comentários
Application Launch Time	The following applications should launch within the specified time. Navegador: menos de 1300ms MMS/SMS: menos de 700ms AlarmClock: menos de 650ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

9. Security Model Compatibility

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

9.1. Permissões

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; Nenhuma permissões pode ser omitida, alterada ou ignorada. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

9.2. UID and Process Isolation

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

9.3. Permissões de sistema de arquivos

Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 42 ].

9.4. Alternate Execution Environments

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. Especificamente:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

10. Software Compatibility Testing

The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Compatibility Test Suite

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

10.2. Verificador CTS

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Reference Applications

Device implementers MUST test implementation compatibility using the following open-source applications:

The "Apps for Android" applications [ Resources, 43 ].
Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. Updatable Software

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades -- that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. Entre em contato conosco

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

Appendix A - Bluetooth Test Procedure

The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

a candidate device implementation running the software build to be tested
a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

Setup and Installation

Build BluetoothChat.apk via 'make samples' from an Android source code tree.
Install BluetoothChat.apk on the known-good device.
Install BluetoothChat.apk on the candidate device.

Test Bluetooth Control by Apps

Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

Test Pairing and Communication

Launch the Bluetooth Chat app on both devices.
Make the known-good device discoverable from within BluetoothChat (using the Menu).
On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
Send 10 or more messages from each device, and verify that the other device receives them correctly.
Close the BluetoothChat app on both devices by pressing Home .
Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

Launch the Bluetooth Chat app on both devices.
Make the candidate device discoverable from within BluetoothChat (using the Menu).
On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
Send 10 or messages from each device, and verify that the other device receives them correctly.
Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

Re-launch the Bluetooth Chat app on both devices.
Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.

Definição de compatibilidade do Android 2.3

Índice

1. Introdução

2. Recursos

3. Programas

3.1. Compatibilidade de API gerenciada

3.2. Compatibilidade de API suave

3.2.1. Permissões

3.2.2. Parâmetros de construção

3.2.3. Compatibilidade de intenções

3.2.3.1. Principais intenções do aplicativo

3.2.3.2. Substituições de intenção

3.2.3.3. Namespaces de intenção

3.2.3.4. Intenções de transmissão

3.3. Compatibilidade de API nativa

3.4. Compatibilidade Web

3.4.1. Compatibilidade com WebView

3.4.2. Compatibilidade do navegador

3.5. Compatibilidade comportamental da API

3.6. Namespaces de API

3.7. Compatibilidade de Máquina Virtual

3.8. Compatibilidade da interface do usuário

3.8.1. Widgets

3.8.2. Notificações

3.8.3. Procurar

3.8.4. Torradas

3.8.5. Papel de parede animados

4. Compatibilidade de pacotes de aplicativos

5. Compatibilidade multimídia

5.1. Codecs de mídia

5.1.1. Decodificadores de mídia

5.1.2. Codificadores de mídia

5.2. Gravação de áudio

5.3. Latência de áudio

6. Compatibilidade da ferramenta de desenvolvedor

7. Compatibilidade de hardware

7.1. Exibição e gráficos

7.1.1. Configurações de tela

7.1.2. Exibir métricas

7.1.3. Declarou suporte da tela

7.1.4. Orientação da tela

7.1.5. Aceleração gráfica 3D

7.2. Dispositivos de entrada

7.2.1. Teclado

7.2.2. Navegação não-touch

7.2.3. Teclas de navegação

7.2.4. Entrada de tela sensível ao toque

7.3. Sensores

7.3.1. Acelerômetro

7.3.2. Magnetômetro

7.3.3. GPS

7.3.4. Giroscópio

7.3.5. Barômetro

7.3.7. Termômetro

7.3.7. Fotômetro

7.3.8. Sensor de proximidade

7.4. Conectividade de dados

7.4.1. Telefonia

7.4.2. IEEE 802.11 (wifi)

7.4.3. Bluetooth

7.4.4. Comunicações de campo próximo

7.4.5. Capacidade mínima de rede

7.5. Câmeras

7.5.1. Câmera voltada para trás

7.5.2. Câmera frontal

7.5.3. Camera API Behavior

7.5.4. Camera Orientation

7.6. Memory and Storage

7.6.1. Minimum Memory and Storage

7.6.2. Application Shared Storage

7.7. USB

8. Performance Compatibility

9. Security Model Compatibility

9.1. Permissões

9.2. UID and Process Isolation

9.3. Permissões de sistema de arquivos

9.4. Alternate Execution Environments

10. Software Compatibility Testing

10.1. Compatibility Test Suite

10.2. Verificador CTS