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

Esta página foi traduzida pela API Cloud Translation.

Definição de compatibilidade do Android 4.2

Revisão 2
Última atualização: 17 de fevereiro de 2013

Índice

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

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

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

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

3.3. Compatibilidade com a API nativa

3.3.1 Interfaces binárias do aplicativo

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView
3.4.2. Compatibilidade com navegadores

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

3.8.1. Widgets
3.8.2. Notificações
3.8.3. Pesquisa
3.8.4. Toasts
3.8.5. Temas
3.8.6. Planos de fundo interativos
3.8.7. Exibição de aplicativos recentes
3.8.8. Configurações de gerenciamento de entrada
3.8.9. Widgets da tela de bloqueio e da tela inicial
3.8.10. Controle remoto de mídia da tela de bloqueio
3.8.11. Sonhos

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

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

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

6. Compatibilidade com ferramentas e opções para desenvolvedores

6.1. Ferramentas para desenvolvedores
6.2. Opções do desenvolvedor

7. Compatibilidade de hardware

7.1. Tela e gráficos

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

7.2. Dispositivos de entrada

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

7.3. Sensores

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

7.4. Conectividade de dados

7.4.1. Telefonia
7.4.2. IEEE 802.11 (Wi-Fi)

7.4.2.1. Wi-Fi Direct

7.4.3. Bluetooth
7.4.4. Comunicação a curta distância
7.4.5. Capacidade mínima de rede

7.5. Câmeras

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

7.6. Memória e armazenamento

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

7.7. USB

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

9.1. Permissões
9.2. Isolamento de UID e de processo
9.3. Permissões do sistema de arquivos
9.4. Ambientes de execução alternativos
9.5. Suporte a vários usuários
9.6. Aviso de SMS premium

10. Teste de compatibilidade de software

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

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

1. Introdução

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

O uso de "precisa", "não pode", "requer", "deve", "não deve", "recomendado", "pode" e "opcional" é conforme o padrão IETF definido na RFC2119 [Resources, 1].

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

Para serem consideradas compatíveis com o Android 4.2, as implementações de dispositivos PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos incorporados por referência.

Quando essa definição ou os testes de software descritos na Seção 10 forem silenciosos, ambíguos ou incompletos, será responsabilidade do implementador do dispositivo garantir a compatibilidade com implementações existentes.

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

2. Recursos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guia de estilo de ícones da barra de status: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

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

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

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

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

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

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

Referência do DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Câmera: http://developer.android.com/reference/android/hardware/Camera.html

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

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

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

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

DownloadManager do Android: http://developer.android.com/reference/android/app/DownloadManager.html

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

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

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

Transferência de conexão NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Pareamento simples e seguro do Bluetooth usando NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

API Wifi Multicast: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

Especificação de carregamento USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html

Áudio USB do Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Configurações de compartilhamento de NFC do Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wifi Direct (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Widget de tela de bloqueio e tela inicial: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

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

Referência de armazenamento externo: https://source.android.com/docs/core/storage

APIs de armazenamento externo: http://developer.android.com/reference/android/os/Environment.html

Código abreviado de SMS: http://en.wikipedia.org/wiki/Short_code

Cliente de controle remoto de mídia: http://developer.android.com/reference/android/media/RemoteControlClient.html

Gerenciador de tela: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

Configurações relacionadas ao desenvolvimento de apps Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

Câmera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

Muitos desses recursos são derivados diretamente ou indiretamente do SDK do Android 4.2 e são funcionalmente idênticos às informações na documentação do SDK. Em qualquer caso em que esta definição de compatibilidade ou o Conjunto de teste de compatibilidade não concordar com a documentação do SDK, a documentação do SDK será considerada oficial. Todos os detalhes técnicos fornecidos nas referências acima são considerados parte desta definição de compatibilidade.

3. Software

3.1. Compatibilidade com a API gerenciada

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

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

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

3.2. Compatibilidade de API flexível

Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API "soft" significativa somente para execução, na forma de Intents, permissões e aspectos semelhantes de apps Android que não podem ser aplicados no momento da compilação do aplicativo.

3.2.1. Permissões

Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na página de referência de permissões [Resources, 5]. A seção 10 lista outros requisitos relacionados ao modelo de segurança do Android.

3.2.2. Parâmetros do build

As APIs do Android incluem várias constantes na classe android.os.Build [Resources, 6] que têm a finalidade de descrever o dispositivo atual. Para fornecer valores consistentes e significativos em todas as implementações de dispositivos, a tabela abaixo inclui outras restrições sobre os formatos desses valores aos quais as implementações de dispositivos PRECISAM se conformar.

Parâmetro	Comentários
android.os.Build.VERSION.RELEASE	A versão do sistema Android em execução no momento, em formato legível por humanos. Esse campo PRECISA ter um dos valores de string definidos em [Resources, 7].
android.os.Build.VERSION.SDK	A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros. Para o Android 4.2, esse campo PRECISA ter o valor inteiro 17.
android.os.Build.VERSION.SDK_INT	A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros. Para o Android 4.2, esse campo PRECISA ter o valor inteiro 17.
android.os.Build.VERSION.INCREMENTAL	Um valor escolhido pelo implementador do dispositivo que designa o build específico do sistema Android em execução no momento, em um formato legível por humanos. Esse valor NÃO PODE ser reutilizado para builds diferentes disponibilizados aos usuários finais. Um uso típico deste campo é indicar qual número de build ou identificador de mudança de controle de origem foi usado para gerar o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
android.os.Build.BOARD	Um valor escolhido pelo implementador do dispositivo que identifica o hardware interno específico usado pelo dispositivo em um formato legível por humanos. Um possível uso desse campo é indicar a revisão específica da placa que alimenta o dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.BRAND	Um valor escolhido pelo implementador do dispositivo que identifica o nome da empresa, organização, indivíduo etc. que produziu o dispositivo em formato legível por humanos. Um possível uso desse campo é indicar o OEM e/ou a operadora que vendeu o dispositivo. O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.CPU_ABI	O nome do conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a Seção 3.3: Compatibilidade com a API nativa.
android.os.Build.CPU_ABI2	O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) do código nativo. Consulte a Seção 3.3: Compatibilidade com a API nativa.
android.os.Build.DEVICE	Um valor escolhido pelo implementador do dispositivo que identifica a configuração ou revisão específica do corpo (às vezes chamado de "design industrial") do dispositivo. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.FINGERPRINT	Uma string que identifica exclusivamente esse build. Ele PRECISA ser razoavelmente legível para humanos. Ele precisa seguir este modelo: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Por exemplo: `acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys` A impressão digital NÃO pode incluir caracteres de espaço em branco. Se outros campos incluídos no modelo acima tiverem caracteres de espaço em branco, eles PRECISAM ser substituídos na impressão digital do build por outro caractere, como o sublinhado ("_"). O valor desse campo PRECISA ser codificável como ASCII de 7 bits.
android.os.Build.HARDWARE	O nome do hardware (da linha de comando do kernel ou /proc). Ele PRECISA ser razoavelmente legível por humanos. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.HOST	Uma string que identifica de forma exclusiva o host em que o build foi criado, em formato legível por humanos. Não há requisitos para o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
android.os.Build.ID	Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em um formato legível por humanos. Esse campo pode ser o mesmo que android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente significativo para que os usuários finais distingam entre builds de software. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.MANUFACTURER	O nome comercial do fabricante de equipamento original (OEM) do produto. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
android.os.Build.MODEL	Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. Ele DEVE ser o mesmo nome usado para comercializar e vender o dispositivo para os usuários finais. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
android.os.Build.PRODUCT	Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código do produto (SKU). PRECISA ser legível por humanos, mas não é necessariamente destinada a ser visualizada por usuários finais. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.SERIAL	Um número de série do hardware, se disponível. O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^([a-zA-Z0-9]{0,20})$"`.
android.os.Build.TAGS	Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que diferenciam ainda mais o build. Por exemplo, "unsigned,debug". O valor desse campo PRECISA ser codificável como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TIME	Um valor que representa o carimbo de data/hora de quando o build ocorreu.
android.os.Build.TYPE	Um valor escolhido pelo implementador do dispositivo que especifica a configuração do ambiente de execução do build. Esse campo PRECISA ter um dos valores correspondentes às três configurações típicas de ambiente de execução do Android: "user", "userdebug" ou "eng". O valor desse campo PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.USER	Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos sobre o formato específico desse campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").

3.2.3. Compatibilidade de intents

As implementações de dispositivos precisam respeitar o sistema de intents de acoplamento flexível do Android, conforme descrito nas seções abaixo. "Atendida" significa que o implementador do dispositivo PRECISA fornecer uma atividade ou serviço do Android que especifique um filtro de intent correspondente e se vincule e implemente o comportamento correto para cada padrão de intent especificado.

3.2.3.1. Intents principais do aplicativo

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

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

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

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

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

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

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

3.2.3.2. Substituições de intent

Como o Android é uma plataforma extensível, as implementações de dispositivos precisam permitir que cada padrão de intent referenciado na seção 3.2.3.2 seja substituído por aplicativos de terceiros. A implementação de código aberto upstream do Android permite isso por padrão. Os implementadores de dispositivos NÃO PODEM anexar privilégios especiais ao uso desses padrões de intent por aplicativos do sistema nem impedir que aplicativos de terceiros se associem a eles e assumam o controle. Essa proibição inclui especificamente, mas não se limita a, desativar a interface do usuário "Chooser", que permite ao usuário selecionar entre vários apps que processam o mesmo padrão de intent.

No entanto, as implementações de dispositivos PODEM fornecer atividades padrão para padrões de URI específicos (por exemplo, http://play.google.com) se a atividade padrão fornecer um filtro mais específico para o URI de dados. Por exemplo, um filtro de intent que especifica o URI de dados "http://www.android.com" é mais específico que o filtro do navegador para "http://". As implementações de dispositivos precisam fornecer uma interface do usuário para que os usuários modifiquem a atividade padrão para intents.

3.2.3.3. Namespaces de intent

As implementações de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou broadcast usando uma string de chave ACTION, CATEGORY ou outra no namespace android.* ou com.android.*. Os implementadores de dispositivos NÃO PODEM incluir componentes do Android que respeitem novos padrões de intent ou broadcast usando uma string de chave ACTION, CATEGORY ou outra em um espaço de pacote pertencente a outra organização. Os implementadores de dispositivos NÃO PODEM alterar ou ampliar nenhum dos padrões de intent usados pelos apps principais listados na seção 3.2.3.1. As implementações de dispositivos PODEM incluir padrões de intent usando namespaces associados de forma clara e óbvia à própria organização.

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

3.2.3.4. Intents de transmissão

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

3.3. Compatibilidade com a API nativa

3.3.1 Interfaces binárias do aplicativo

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

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

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

As APIs de código nativo abaixo PRECISAM estar disponíveis para apps que incluem código nativo:

libc (biblioteca C)
libm (biblioteca matemática)
Suporte mínimo para C++
Interface JNI
liblog (registro do Android)
libz (compactação Zlib)
libdl (vinculador dinâmico)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (gerenciamento de superfície OpenGL nativa)
libjnigraphics.so
libOpenSLES.so (suporte a áudio do OpenSL ES 1.0.1)
libOpenMAXAL.so (suporte ao OpenMAX AL 1.0.1)
libandroid.so (suporte nativo à atividade do Android)
Suporte para OpenGL, conforme descrito abaixo

Versões futuras do Android NDK podem oferecer suporte a ABIs adicionais. Se uma implementação de dispositivo não for compatível com uma ABI predefinida, ela NÃO PODERÁ informar suporte para nenhuma ABI.

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

3.4. Compatibilidade com a Web

3.4.1. Compatibilidade com a WebView

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

As implementações de android.webkit.WebView das implementações de dispositivos PRECISAM ser baseadas no build 534.30 do WebKit da árvore Android Open Source upstream para o Android 4.2. Esse build inclui um conjunto específico de correções de segurança e funcionalidade para a WebView. Os implementadores de dispositivos PODEM incluir personalizações na implementação do WebKit. No entanto, essas personalizações NÃO PODEM alterar o comportamento da WebView, incluindo o comportamento de renderização.
A string do user agent informada pela WebView PRECISA estar neste formato:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
- O valor da string $(VERSION) PRECISA ser igual ao valor de android.os.Build.VERSION.RELEASE.
- O valor da string $(LOCALE) DEVE seguir as convenções ISO para código de país e idioma e DEVE se referir à localidade configurada atual do dispositivo
- O valor da string $(MODEL) PRECISA ser igual ao valor de android.os.Build.MODEL.
- O valor da string $(BUILD) PRECISA ser igual ao valor de android.os.Build.ID.
- As implementações de dispositivos PODEM omitir Mobile na string do user agent

O componente WebView DEVE incluir suporte para o maior número possível de recursos HTML5 [Resources, 11]. No mínimo, as implementações de dispositivos precisam oferecer suporte a cada uma dessas APIs associadas ao HTML5 na WebView:

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

Além disso, as implementações de dispositivos precisam oferecer suporte à API HTML5/W3C Webstorage [Resources, 15] e à API IndexedDB HTML5/W3C [Resources, 16]. Observação Como os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer o IndexedDB em vez do WebStorage, espera-se que ele se torne um componente obrigatório em uma versão futura do Android.

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

3.4.2. Compatibilidade de navegadores

As implementações de dispositivos precisam incluir um aplicativo de navegador independente para navegação geral do usuário na Web. O navegador independente PODE ser baseado em uma tecnologia de navegador diferente do WebKit. No entanto, mesmo que um aplicativo de navegador alternativo seja usado, o componente android.webkit.WebView fornecido a aplicativos de terceiros PRECISA ser baseado no WebKit, conforme descrito na Seção 3.4.1.

As implementações podem enviar uma string de user agent personalizada no aplicativo de navegador independente.

O aplicativo de navegador independente (seja baseado no aplicativo de navegador WebKit upstream ou em uma substituição de terceiros) PRECISA incluir suporte para o maior número possível de recursos de HTML5 [Resources, 11]. No mínimo, as implementações de dispositivos precisam oferecer suporte a cada uma das APIs associadas ao HTML5:

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

3.5. Compatibilidade comportamental da API

Os comportamentos de cada um dos tipos de API (gerenciada, soft, nativa e da Web) precisam ser consistentes com a implementação preferencial do projeto de código aberto Android upstream [Resources, 3]. Algumas áreas específicas de compatibilidade são:

Os dispositivos NÃO podem mudar o comportamento ou a semântica de uma intent padrão.
Os dispositivos NÃO PODEM alterar a semântica do ciclo de vida de um determinado tipo de componente do sistema (como Service, Activity, ContentProvider etc.)
Os dispositivos NÃO PODEM mudar a semântica de uma permissão padrão.

A lista acima não está completa. O conjunto de teste de compatibilidade (CTS) testa partes significativas da plataforma para compatibilidade comportamental, mas não todas. É responsabilidade do implementador garantir a compatibilidade com o Android Open Source Project. Por esse motivo, os implementadores de dispositivos devem usar o código-fonte disponível no Projeto Android Open Source sempre que possível, em vez de implementar novamente partes significativas do sistema.

3.6. Namespaces de API

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

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

As modificações proibidas incluem:

As implementações de dispositivos NÃO PODEM modificar as APIs expostas publicamente na plataforma Android alterando assinaturas de método ou classe ou removendo classes ou campos de classe.
Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas essas modificações NÃO PODEM afetar o comportamento declarado e a assinatura do idioma Java de nenhuma API exposta publicamente.
Os implementadores de dispositivos NÃO PODEM adicionar elementos expostos publicamente (como classes ou interfaces, ou campos ou métodos para classes ou interfaces existentes) às APIs acima.

Um "elemento exposto publicamente" é qualquer construção que não seja decorada com o marcador "@hide" usado no código-fonte do Android upstream. Em outras palavras, os implementadores de dispositivos NÃO PODEM expor novas APIs ou alterar APIs existentes nos namespaces mencionados acima. Os implementadores de dispositivos PODEM fazer modificações apenas internas, mas essas modificações NÃO PODEM ser anunciadas ou expostas aos desenvolvedores.

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

Se um implementador de dispositivo propor a melhoria de um dos namespaces de pacote acima (por exemplo, adicionando uma nova funcionalidade útil a uma API existente ou adicionando uma nova API), ele PRECISA acessar source.android.com e iniciar o processo de contribuição de mudanças e código, de acordo com as informações deste site.

As restrições acima correspondem a convenções padrão para nomear APIs na linguagem de programação Java. Esta seção tem como objetivo reforçar essas convenções e torná-las obrigatórias com a inclusão nesta definição de compatibilidade.

3.7. Compatibilidade com máquinas virtuais

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

As implementações de dispositivos precisam configurar o Dalvik para alocar memória de acordo com a plataforma Android upstream e conforme especificado na tabela a seguir. Consulte a Seção 7.1.1 para ver definições de tamanho e densidade da tela.

Os valores de memória especificados abaixo são considerados mínimos, e as implementações de dispositivos PODEM alocar mais memória por aplicativo.

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

3.8. Compatibilidade da interface do usuário

3.8.1. Widgets

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

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

As implementações de dispositivos precisam ser capazes de renderizar widgets de 4 x 4 no tamanho padrão da grade. Consulte as diretrizes de design de widgets de app na documentação do SDK do Android [Resources, 18] para mais detalhes.

3.8.2. Notificações

O Android inclui APIs que permitem que os desenvolvedores notifiquem os usuários sobre eventos importantes [Resources, 19], usando recursos de hardware e software do dispositivo.

Algumas APIs permitem que os aplicativos realizem notificações ou chamem a atenção usando hardware, especificamente som, vibração e luz. As implementações de dispositivos PRECISAM oferecer suporte a notificações que usam recursos de hardware, conforme descrito na documentação do SDK, e na medida do possível com o hardware de implementação do dispositivo. Por exemplo, se uma implementação de dispositivo incluir um vibrador, ela PRECISA implementar corretamente as APIs de vibração. Se uma implementação de dispositivo não tiver hardware, as APIs correspondentes PRECISAM ser implementadas como no-ops. Esse comportamento é detalhado na Seção 7.

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

O Android 4.2 inclui suporte a notificações avançadas, como visualizações interativas para notificações em andamento. As implementações de dispositivos precisam mostrar e executar notificações avançadas corretamente, conforme documentado nas APIs do Android.

3.8.3. Pesquisar

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

As implementações de dispositivos precisam incluir uma interface do usuário de pesquisa única, compartilhada e em todo o sistema capaz de sugerir resultados em tempo real em resposta à entrada do usuário. As implementações de dispositivos precisam implementar as APIs que permitem que os desenvolvedores reutilizem essa interface do usuário para oferecer a pesquisa nos próprios aplicativos. As implementações de dispositivos precisam implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões à caixa de pesquisa quando ela é executada no modo de pesquisa global. Se nenhum aplicativo de terceiros que use essa funcionalidade estiver instalado, o comportamento padrão DEVE ser mostrar os resultados e as sugestões do mecanismo de pesquisa da Web.

3.8.4. Avisos

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

3.8.5. Temas

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

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

3.8.6. Planos fundo interativos

O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os aplicativos exponham um ou mais "papéis de parede animados" ao usuário final [Resources, 26]. Os planos de fundo animados são animações, padrões ou imagens semelhantes com recursos de entrada limitados que aparecem como um plano de fundo, atrás de outros aplicativos.

O hardware é considerado capaz de executar papéis de parede animados de forma confiável se for capaz de executar todos os papéis de parede animados, sem limitações de funcionalidade, a uma taxa de quadros razoável sem efeitos adversos em outros aplicativos. Se limitações no hardware causarem falhas em planos de fundo e/ou aplicativos, funcionamento incorreto, consumo excessivo de bateria ou CPU ou execução com taxas de frames inaceitáveis, o hardware será considerado incapaz de executar o plano de fundo em tempo real. Por exemplo, alguns planos de fundo animados podem usar um contexto do Open GL 1.0 ou 2.0 para renderizar o conteúdo. O papel de parede animado não será executado de forma confiável em hardwares que não oferecem suporte a vários contextos OpenGL porque o uso de um contexto OpenGL por um papel de parede animado pode entrar em conflito com outros aplicativos que também usam um contexto OpenGL.

As implementações de dispositivos capazes de executar planos de fundo interativos de forma confiável, conforme descrito acima, DEVEM implementar planos de fundo interativos. Implementações de dispositivos determinadas a não executar planos de fundo interativos de forma confiável, conforme descrito acima, NÃO PODEM implementar planos de fundo interativos.

3.8.7. Exibição de apps recentes

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

3.8.8. Configurações de gerenciamento de entrada

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

3.8.9. Widgets da tela inicial e de bloqueio

O Android 4.2 inclui suporte a widgets de aplicativos que os usuários podem incorporar na tela inicial ou de bloqueio. Consulte as diretrizes de design de widgets de apps na documentação do Android SDK [Resources, 69] para mais detalhes. Os widgets de apps permitem o acesso rápido a dados e serviços de apps sem iniciar uma nova atividade. Os widgets declaram suporte para uso na tela inicial ou na tela de bloqueio declarando a tag de manifesto android:widgetCategory, que informa ao sistema onde o widget pode ser colocado. Especificamente, as implementações de dispositivos precisam atender aos seguintes requisitos.

As implementações de dispositivos precisam oferecer suporte a widgets de apps na tela inicial.
As implementações de dispositivos precisam oferecer suporte à tela de bloqueio. Se as implementações de dispositivo incluem suporte à tela de bloqueio, as implementações de dispositivo precisam oferecer suporte a widgets de app na tela de bloqueio.

3.8.10. Controle remoto de mídia na tela de bloqueio

O Android 4.2 inclui suporte à API de controle remoto, que permite que aplicativos de mídia sejam integrados a controles de reprodução exibidos em uma visualização remota, como a tela de bloqueio do dispositivo[Resources, 74]. As implementações de dispositivos precisam incluir suporte à incorporação de controles remotos na tela de bloqueio do dispositivo.

3.8.11. Sonhos

O Android 4.2 inclui suporte a protetores de tela interativos chamados Dreams [Resources, 76]. O Daydream permite que os usuários interajam com os aplicativos quando um dispositivo de carregamento está ocioso ou conectado a uma base para mesa. As implementações de dispositivos PRECISAM incluir suporte para o Dreams e oferecer uma opção de configurações para os usuários.

3.9 Administração de dispositivos

O Android 4.2 inclui recursos que permitem que aplicativos com segurança realizem funções de administração de dispositivos no nível do sistema, como a aplicação de políticas de senha ou a exclusão remota, pela API Administration de dispositivos Android [Resources, 27]. As implementações de dispositivo precisam fornecer uma implementação da classe DevicePolicyManager [Resources, 28] e precisam oferecer suporte a toda a gama de políticas de administração de dispositivos definidas na documentação do SDK do Android [Resources, 27].

Observação:embora alguns dos requisitos descritos acima sejam indicados como "SHOULD" para o Android 4.2, as implementações de dispositivos que oferecem suporte à tela de bloqueio PRECISAM oferecer suporte a políticas de dispositivos para gerenciar widgets na tela de bloqueio, conforme definido na documentação do SDK do Android [Resources, 27].

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

3.10 Acessibilidade

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

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

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

3.11 Conversão de texto em voz

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

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

4. Compatibilidade de empacotamento de apps

As implementações de dispositivos precisam instalar e executar arquivos ".apk" do Android conforme gerados pela ferramenta "aapt" incluída no SDK oficial do Android [Resources, 33].

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

5. Compatibilidade com multimídia

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

5.1. Codecs de mídia

As implementações de dispositivos PRECISAM oferecer suporte aos formatos de mídia principais especificados na documentação do SDK do Android [Resources, 58], exceto quando expressamente permitido neste documento. Especificamente, as implementações de dispositivos PRECISAM oferecer suporte aos formatos de mídia, codificadores, decodificadores, tipos de arquivo e formatos de contêiner definidos nas tabelas abaixo. Todos esses codecs são fornecidos como implementações de software na implementação preferida do Android do Android Open Source Project.

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

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

Tipo	Formato/Codec	Codificador	Decodificador	Detalhes	Tipos de arquivo/Formatos de contêiner
Áudio	Perfil MPEG-4 AAC (AAC LC)	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone`.	REQUIRED	Compatível com conteúdo mono/estéreo/5.0/5.1* com taxas de amostragem padrão de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC bruto ADTS (.aac, decodificado no Android 3.1+, codificado no Android 4.0+, sem suporte a ADIF) MPEG-TS (.ts, não pesquisável, Android 3.0+)
	Perfil MPEG-4 HE AAC (AAC+)	OBRIGATÓRIO para implementações de dispositivos que incluem hardware de microfone e definem android.hardware.microphone	REQUIRED	Suporte a conteúdo mono/estéreo/5.0/5.1* com taxas de amostragem padrão de 16 a 48 kHz.
	Perfil MPEG-4 HE AAC v2 (AAC+ aprimorado)		REQUIRED	Suporte a conteúdo mono/estéreo/5.0/5.1* com taxas de amostragem padrão de 16 a 48 kHz.
	MPEG-4 Audio Object Type ER AAC ELD (AAC aprimorado com atraso baixo)	OBRIGATÓRIO para implementações de dispositivos que incluem hardware de microfone e definem android.hardware.microphone	REQUIRED	Suporte a conteúdo mono/estéreo com taxas de amostragem padrão de 16 a 48 kHz.
	AMR-NB	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone`.	REQUIRED	4,75 a 12,2 kbps com amostragem a 8 kHz.	3GPP (.3gp)
	AMR-WB	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de microfone e definem `android.hardware.microphone`.	REQUIRED	9 taxas de 6,60 kbit/s a 23,85 kbit/s com amostragem a 16 kHz.	3GPP (.3gp)
	FLAC		OBRIGATÓRIO (Android 3.1+)	Mono/estéreo (sem multicanal). Taxas de amostragem de até 48 kHz (mas o valor de até 44,1 kHz é recomendado em dispositivos com saída de 44,1 kHz, já que o redutor de 48 para 44,1 kHz não inclui um filtro passa baixa). Recomendação de 16 bits; sem pontilhamento aplicado para 24 bits.	Somente FLAC (.flac)
	MP3		REQUIRED	Taxa de bits mono/estéreo constante (CBR) ou variável (VBR) de 8-320 kbps.	MP3 (.mp3)
	MIDI		REQUIRED	MIDI tipos 0 e 1. DLS versões 1 e 2. XMF e XMF para celular. Compatível com os formatos de toque RTTTL/RTX, OTA e iMelody.	Tipo 0 e 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		REQUIRED		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE	REQUIRED	REQUIRED	PCM linear de 8 e 16 bits** (taxas até o limite de hardware). Os dispositivos precisam oferecer suporte a taxas de amostragem para gravação PCM bruta em frequências de 8.000,16.000 e 44.100 Hz	WAVE (.wav)
Imagem	JPEG	REQUIRED	REQUIRED	Básico+progressivo	JPEG (.jpg)
	GIF		REQUIRED		GIF (.gif)
	PNG	REQUIRED	REQUIRED		PNG (.png)
	BMP		REQUIRED		BMP (.bmp)
	WEBP	REQUIRED	REQUIRED		WebP (.webp)
Vídeo	H.263	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de câmera e definem `android.hardware.camera` ou `android.hardware.camera.front`.	REQUIRED		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	OBRIGATÓRIO Obrigatório para implementações de dispositivos que incluem hardware de câmera e definem `android.hardware.camera` ou `android.hardware.camera.front`.	REQUIRED	Perfil de referência (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, AAC exclusivo de áudio, não pesquisável, Android 3.0+)
	MPEG-4 SP		REQUIRED		3GPP (.3gp)
	VP8		OBRIGATÓRIO (Android 2.3.3+)		WebM (.webm) e Matroska (.mkv, Android 4.0+)

*Observação: apenas o downmix de conteúdo 5.0/5.1 é obrigatório. A gravação ou renderização de mais de dois canais é opcional. **Observação: a captura de PCM linear de 16 bits é obrigatória. A captura de PCM linear de 8 bits não é obrigatória.

5.2 Codificação de vídeo

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

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

5.3 Decodificação de vídeo

As implementações de dispositivos Android precisam oferecer suporte aos seguintes perfis de decodificação de vídeo VP8.

	SD (baixa qualidade)	SD (alta qualidade)	HD 720p (quando compatível com o hardware)	HD 1080p (quando tiver suporte de hardware)
Resolução do vídeo	320 x 180 px	640 x 360 px	1.280 x 720 px	1.920 x 1.080 px
Frame rate do vídeo	30 fps	30 fps	30 fps	30 fps
Taxa de bits do vídeo	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.4. Gravação em áudio

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

O dispositivo DEVE apresentar uma amplitude aproximadamente plana em relação às características de frequência, especificamente ±3 dB, de 100 Hz a 4.000 Hz.
A sensibilidade de entrada de áudio PRECISA ser definida de modo que uma fonte de nível de potência de som (SPL) de 90 dB a 1.000 Hz produza um RMS de 2.500 para amostras de 16 bits.
Os níveis de amplitude do PCM precisam acompanhar linearmente as mudanças de SPL de entrada em pelo menos uma faixa de 30 dB de -18 dB a +12 dB em relação a 90 dB SPL no microfone.
A distorção harmônica total DEVE ser menor que 1% para 1 kHz em 90 dB SPL.

Além das especificações de gravação acima, quando um app começa a gravar um stream de áudio usando a fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

O processamento de redução de ruído, se presente, PRECISA ser desativado.
O controle de ganho automático, se presente, PRECISA ser desativado.

5.5. Latência de áudio

A latência de áudio é o tempo de atraso enquanto um sinal de áudio passa por um sistema. Muitas classes de aplicativos dependem de latências curtas para conseguir efeitos em tempo real, como efeitos sonoros ou comunicação VOIP.

Para os fins desta seção:

A "latência de saída" é definida como o intervalo entre o momento em que um aplicativo grava um frame de dados codificados em PCM e o momento em que o som correspondente pode ser ouvido por um listener externo ou observado por um transdutor.
A "latência de saída fria" é definida como a latência de saída do primeiro frame, quando o sistema de saída de áudio está inativo e desligado antes da solicitação.
A "latência de saída contínua" é definida como a latência de saída para frames subsequentes, depois que o dispositivo já está reproduzindo áudio.
A "latência de entrada" é o intervalo entre o momento em que um som externo é apresentado ao dispositivo e o momento em que um aplicativo lê o frame correspondente de dados codificados em PCM.
A "latência de entrada fria" é definida como a soma do tempo de entrada perdido e a latência de entrada do primeiro frame, quando o sistema de entrada de áudio ficou inativo e desativado antes da solicitação.
A "latência de entrada contínua" é definida como a latência de entrada para frames subsequentes, enquanto o dispositivo já está capturando áudio.
"API OpenSL ES PCM buffer queue" é o conjunto de APIs OpenSL ES relacionadas ao PCM no Android NDK. Consulte NDK_root/docs/opensles/index.html

De acordo com a Seção 5, todas as implementações de dispositivos compatíveis PRECISAM incluir pelo menos uma forma de saída de áudio. As implementações de dispositivos precisam atender ou exceder estes requisitos de latência de saída:

latência de saída a frio de 100 milissegundos ou menos
latência de saída contínua de 45 milissegundos ou menos

Se uma implementação de dispositivo atender aos requisitos desta seção após qualquer calibração inicial ao usar a API OpenSL ES PCM buffer queue, para latência de saída contínua e latência de saída fria em pelo menos um dispositivo de saída de áudio com suporte, ele PODE informar suporte para áudio de baixa latência, informando o recurso "android.hardware.audio.low-latency" pela classe android.content.pm.PackageManager. [Resources, 37] Por outro lado, se a implementação do dispositivo não atender a esses requisitos, ela NÃO PODERÁ informar suporte para áudio de baixa latência.

De acordo com a Seção 7.2.5, o hardware do microfone pode ser omitido pelas implementações do dispositivo.

As implementações de dispositivos que incluem hardware de microfone e declaram android.hardware.microphone precisam atender a estes requisitos de latência de áudio de entrada:

latência de entrada fria de 100 milissegundos ou menos
latência de entrada contínua de 50 milissegundos ou menos

5.6. Protocolos de rede

Os dispositivos precisam oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, conforme especificado na documentação do SDK do Android [Resources, 58]. Especificamente, os dispositivos precisam oferecer suporte a estes protocolos de rede de mídia:

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

6. Compatibilidade de ferramentas e opções para desenvolvedores

6.1 Ferramentas para desenvolvedores

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

Android Debug Bridge (conhecida como adb) [Resources, 33]
As implementações de dispositivos PRECISAM oferecer suporte a todas as funções adb, conforme documentado no SDK do Android. O daemon adb do dispositivo PRECISA estar inativo por padrão, e é PRECISO ter um mecanismo acessível ao usuário para ativar a Android Debug Bridge.

O Android 4.2.2 inclui suporte para adb seguro. O adb seguro ativa o adb em hosts autenticados conhecidos. É altamente recomendável que os dispositivos atuais e novos que executam o Android 4.2.2 atendam a esse requisito no Android 4.2, caso contrário, eles não poderão alcançar a compatibilidade com o Android quando forem atualizados para a versão futura.

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

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

6.2 Opções do desenvolvedor

O Android 4.2 inclui suporte para que os desenvolvedores configurem as configurações relacionadas ao desenvolvimento de apps. As implementações de dispositivos precisam respeitar a intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar as configurações relacionadas ao desenvolvimento do app [Resources, 77]. A implementação upstream do Android esconde o menu "Opções do desenvolvedor" por padrão e permite que os usuários iniciem as Opções do desenvolvedor após pressionar sete (7) vezes no item de menu "Configurações > Sobre o dispositivo > Número da versão". As implementações de dispositivos PRECISAM oferecer uma experiência consistente para as Opções do desenvolvedor. Especificamente, as implementações de dispositivos precisam ocultar as Opções do desenvolvedor por padrão e fornecer um mecanismo para ativar as Opções do desenvolvedor que seja consistente com a implementação upstream do Android.

7. Compatibilidade de hardware

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

As definições de classe completas (como documentadas pelo SDK) para as APIs do componente PRECISAM estar presentes.
Os comportamentos da API precisam ser implementados como no-ops de maneira razoável.
Os métodos da API precisam retornar valores nulos quando permitido pela documentação do SDK.
Os métodos da API precisam retornar implementações sem operação de classes em que valores nulos não são permitidos pela documentação do SDK.
Os métodos da API NÃO PODEM gerar exceções não documentadas pela documentação do SDK.

Um exemplo típico de um cenário em que esses requisitos se aplicam é a API de telefonia: mesmo em dispositivos que não são smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

As implementações de dispositivos precisam informar corretamente as informações de configuração de hardware usando os métodos getSystemAvailableFeatures() e hasSystemFeature(String) na classe android.content.pm.PackageManager. [Resources, 37]

7.1. Tela e gráficos

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

As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte maneira:

"Tamanho físico da diagonal" é a distância em polegadas entre dois cantos opostos da parte iluminada da tela.
"dpi" (que significa "pontos por polegada") é o número de pixels englobados por uma extensão linear horizontal ou vertical de 1". Quando os valores de dpi são listados, o dpi horizontal e vertical precisa estar dentro do intervalo.
"Proporção" é a relação entre a dimensão mais longa da tela e a mais curta. Por exemplo, uma tela de 480 x 854 pixels seria 854 / 480 = 1,779, ou aproximadamente "16:9".
Um "pixel independente de densidade" ou ("dp") é a unidade de pixel virtual normalizada para uma tela de 160 dpi, calculada como: pixels = dps * (density / 160).

7.1.1. Configuração da tela

Tamanho da tela

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

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

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

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

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

Proporção da tela

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

Densidade da tela

O framework de IU do Android define um conjunto de densidades lógicas padrão para ajudar os desenvolvedores a segmentar os recursos do aplicativo. As implementações de dispositivos PRECISAM informar uma das seguintes densidades de framework lógico do Android pelas APIs android.util.DisplayMetrics e PRECISAM executar aplicativos nessa densidade padrão.

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

As implementações de dispositivos DEVEM definir a densidade padrão do framework do Android que é numericamente mais próxima da densidade física da tela, a menos que essa densidade lógica empurre o tamanho da tela informado abaixo do mínimo suportado. Se a densidade do framework padrão do Android que é numericamente mais próxima da densidade física resultar em um tamanho de tela menor do que o menor tamanho de tela compatível com suporte (largura de 320 dp), as implementações de dispositivo precisam informar a próxima densidade padrão mais baixa do framework do Android.

7.1.2. Métricas de tela

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

7.1.3. Orientação da tela

Os dispositivos precisam oferecer suporte à orientação dinâmica por aplicativos para orientação de tela retrato ou paisagem. Ou seja, o dispositivo precisa respeitar a solicitação do aplicativo para uma orientação de tela específica. As implementações do dispositivo podem selecionar a orientação retrato ou paisagem como padrão.

Os dispositivos precisam informar o valor correto para a orientação atual do dispositivo sempre que forem consultados pelo android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.

Os dispositivos NÃO podem mudar o tamanho ou a densidade da tela informada ao mudar a orientação.

Os dispositivos precisam informar quais orientações de tela são compatíveis ( android.hardware.screen.portrait e/ou android.hardware.screen.landscape) e precisam informar pelo menos uma orientação compatível. Por exemplo, um dispositivo com uma tela de orientação paisagem de orientação fixa, como uma televisão ou um laptop, SÓ PODE informar android.hardware.screen.landscape.

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

As implementações de dispositivos precisam oferecer suporte ao OpenGL ES 1.0 e 2.0, conforme definido e detalhado na documentação do SDK do Android. As implementações de dispositivos também precisam oferecer suporte ao RenderScript do Android, conforme detalhado na documentação do SDK do Android [Resources, 8].

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

As APIs gerenciadas (como pelo método GLES10.getString()) PRECISAM informar suporte para o OpenGL ES 1.0 e 2.0.
As APIs OpenGL C/C++ nativas (ou seja, as disponíveis para apps por meio de libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) PRECISAM informar suporte para OpenGL ES 1.0 e 2.0.

As implementações de dispositivos PODEM implementar qualquer extensão do OpenGL ES desejada. No entanto, as implementações de dispositivos precisam informar, pelas APIs gerenciadas e nativas do OpenGL ES, todas as strings de extensão com suporte e, inversamente, NÃO precisam informar as strings de extensão sem suporte.

O Android 4.2 inclui suporte para aplicativos que podem especificar opcionalmente que eles exigem formatos de compactação de textura OpenGL específicos. Esses formatos geralmente são específicos do fornecedor. As implementações de dispositivos não são necessárias pelo Android 4.2 para implementar qualquer formato de compactação de textura específico. No entanto, eles precisam informar com precisão todos os formatos de compactação de textura com suporte pelo método getString() na API OpenGL.

O Android 4.2 inclui um mecanismo para que os aplicativos declarem que queriam ativar a aceleração de hardware para gráficos 2D no nível do aplicativo, da atividade, da janela ou da visualização usando uma tag de manifesto android:hardwareAccelerated ou chamadas diretas de API [Resources, 9].

No Android 4.2, as implementações de dispositivo PRECISAM ativar a aceleração de hardware por padrão e PRECISAM desativá-la se o desenvolvedor solicitar definindo android:hardwareAccelerated="false" ou desativando a aceleração de hardware diretamente pelas APIs do Android View.

Além disso, as implementações de dispositivos precisam apresentar um comportamento consistente com a documentação do SDK do Android sobre a aceleração de hardware [Resources, 9].

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

7.1.5. Modo de compatibilidade de aplicativos legados

O Android 4.2 especifica um "modo de compatibilidade" em que o framework opera em um modo de tamanho de tela "normal" equivalente (largura de 320 dp) para o benefício de aplicativos legados não desenvolvidos para versões antigas do Android que antecedem a independência do tamanho da tela. As implementações de dispositivos precisam incluir suporte ao modo de compatibilidade de aplicativos legados conforme implementado pelo código de origem aberto do Android. Ou seja, as implementações de dispositivos NÃO PODEM alterar os gatilhos ou limites em que o modo de compatibilidade é ativado e NÃO PODEM alterar o comportamento do próprio modo de compatibilidade.

7.1.6. Tipos de tela

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

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

Implementações de dispositivos de pixels fixos

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

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

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

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

Implementações de dispositivos de pixel variável

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

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

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

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

7.1.7. Tecnologia da tela

A plataforma Android inclui APIs que permitem que os aplicativos renderizem gráficos avançados na tela. Os dispositivos PRECISAM oferecer suporte a todas essas APIs, conforme definido pelo SDK do Android, a menos que seja permitido especificamente neste documento. Especificamente:

Os dispositivos PRECISAM oferecer suporte a telas capazes de renderizar gráficos coloridos de 16 bits e DEVEM oferecer suporte a telas capazes de renderizar gráficos coloridos de 24 bits.
Os dispositivos precisam oferecer suporte a telas capazes de renderizar animações.
A tecnologia de exibição usada PRECISA ter uma proporção de pixels (PAR) entre 0,9 e 1,1. Ou seja, a proporção de pixels PRECISA estar próxima de um quadrado (1,0) com uma tolerância de 10%.

7.1.8. Telas externas

O Android 4.2 inclui suporte para tela secundária para ativar recursos de compartilhamento de mídia e APIs para desenvolvedores acessarem telas externas. Se um dispositivo oferece suporte a uma tela externa por conexão com fio, sem fio ou integrada, a implementação do dispositivo PRECISA implementar a API do gerenciador de tela, conforme descrito na documentação do SDK do Android [Resources, 75]. As implementações de dispositivos que oferecem suporte à saída de vídeo segura e são capazes de oferecer suporte a superfícies seguras PRECISAM declarar suporte a Display.SECURE_FLAG. Especificamente, as implementações de dispositivos que declaram suporte a Display.SECURE_FLAG PRECISAM oferecer suporte a HDCP 2.x ou mais recente para telas sem fio Miracast ou HDCP 1.2 ou mais recente para telas com fio. A implementação de código aberto upstream do Android inclui suporte a telas sem fio (Miracast) e com fio (HDMI) que atendem a esse requisito.

7.2. Dispositivos de entrada

7.2.1. Teclado

Implementações de dispositivos:

É PRECISO incluir suporte para o Input Management Framework, que permite que desenvolvedores de terceiros criem mecanismos de gerenciamento de entrada, como detalhado em http://developer.android.com.
É PRECISO fornecer pelo menos uma implementação de teclado virtual (mesmo que um teclado físico esteja presente)
PODE incluir outras implementações de teclado virtual
PODE incluir um teclado de hardware
NÃO PODE incluir um teclado de hardware que não corresponda a um dos formatos especificados em android.content.res.Configuration.keyboard [Resources, 40], ou seja, QWERTY ou 12 teclas.

Implementações de dispositivos:

PODE omitir uma opção de navegação sem toque (ou seja, pode omitir um trackball, um botão direcional ou uma roda)
É necessário informar o valor correto para android.content.res.Configuration.navigation [Resources, 40].
É PRECISO fornecer um mecanismo de interface do usuário alternativo razoável para a seleção e edição de texto, compatível com os mecanismos de gerenciamento de entrada. A implementação de código aberto upstream do Android inclui um mecanismo de seleção adequado para uso com dispositivos que não têm entradas de navegação não por toque.

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

O Android 4.2 inclui suporte à ação de assistência [Resources, 63]. As implementações de dispositivos precisam disponibilizar a ação de assistência ao usuário o tempo todo ao executar aplicativos. Essa função PODE ser implementada por chaves de hardware ou software.

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

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

7.2.4. Entrada por tela touchscreen

Implementações de dispositivos:

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

As implementações de dispositivos precisam informar o recurso correto correspondente ao tipo de entrada usado. O Android 4.2 inclui o recurso android.hardware.faketouch, que corresponde a um dispositivo de entrada não por toque de alta fidelidade (ou seja, baseado em ponteiro), como um mouse ou trackpad que pode emular adequadamente a entrada por toque (incluindo suporte a gestos básicos) e indica que o dispositivo oferece suporte a um subconjunto emulado de recursos da tela sensível ao toque. As implementações de dispositivos que incluem uma tela touchscreen (single-touch ou melhor) também precisam informar android.hardware.faketouch. Implementações de dispositivos que não incluem uma tela touchscreen (e dependem apenas de um dispositivo de ponteiro) NÃO PODEM informar nenhum recurso de tela touchscreen e APENAS android.hardware.faketouch.

7.2.5. Microfone

As implementações de dispositivos PODEM omitir um microfone. No entanto, se uma implementação de dispositivo omitir um microfone, ela NÃO PODERÁ informar a constante do recurso android.hardware.microphone e precisará implementar a API de gravação de áudio como no-ops, conforme a Seção 7. Por outro lado, as implementações de dispositivos que têm um microfone:

É OBRIGATÓRIO informar a constante de recurso android.hardware.microphone
DEVEM atender aos requisitos de qualidade de áudio da Seção 5.4.
DEVEM atender aos requisitos de latência de áudio na Seção 5.5

7.3. Sensores

O Android 4.2 inclui APIs para acessar vários tipos de sensores. As implementações de dispositivos geralmente PODEM omitir esses sensores, conforme previsto nas subseções a seguir. Se um dispositivo incluir um tipo de sensor específico que tenha uma API correspondente para desenvolvedores terceirizados, a implementação do dispositivo PRECISA implementar essa API conforme descrito na documentação do SDK do Android. Por exemplo, implementações de dispositivo:

É PRECISO informar com precisão a presença ou ausência de sensores por classe android.content.pm.PackageManager. [Resources, 37]
PRECISA retornar uma lista precisa de sensores compatíveis pelo SensorManager.getSensorList() e métodos semelhantes
PRECISA se comportar de maneira razoável para todas as outras APIs de sensor (por exemplo, retornando "true" ou "false" conforme apropriado quando os aplicativos tentam registrar listeners, não chamando listeners de sensor quando os sensores correspondentes não estão presentes etc.).
É PRECISO informar todas as medições do sensor usando os valores relevantes do sistema internacional de unidades (ou seja, métricas) para cada tipo de sensor, conforme definido na documentação do SDK do Android [Resources, 41].

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

Alguns tipos de sensores são sintéticos, ou seja, podem ser derivados de dados fornecidos por um ou mais outros sensores. Os exemplos incluem o sensor de orientação e o sensor de aceleração linear. As implementações de dispositivos precisam implementar esses tipos de sensores, quando eles incluem os sensores físicos necessários.

O Android 4.2 inclui um sensor de "streaming", que retorna dados continuamente, em vez de apenas quando os dados mudam. As implementações de dispositivos precisam fornecer continuamente amostras de dados periódicos para qualquer API indicada pela documentação do SDK do Android 4.2 como um sensor de streaming. As implementações do dispositivo precisam garantir que o fluxo do sensor não impeça a CPU do dispositivo de entrar ou sair de um estado de suspensão.

7.3.1. Acelerômetro

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

Deve ser capaz de enviar eventos a 120 Hz ou mais. Embora a frequência do acelerômetro acima seja indicada como "SHOULD" para o Android 4.2, a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Ou seja, esses padrões são opcionais no Android 4.2, mas serão obrigatórios em versões futuras. É altamente recomendável que os dispositivos novos e atuais que executam o Android 4.2 atendam a esses requisitos no Android 4.2 para que possam fazer upgrade para as versões futuras da plataforma.
PRECISA estar em conformidade com o sistema de coordenadas do sensor do Android, conforme detalhado nas APIs do Android (consulte [Resources, 41]).
PRECISA ser capaz de medir de queda livre até o dobro da gravidade (2g) ou mais em qualquer vetor tridimensional
PRECISA ter 8 bits de precisão ou mais
Deve ter um desvio padrão não maior que 0,05 m/s^2

7.3.2. Magnetômetro

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

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

7.3.3. GPS

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

7.3.4. Giroscópio

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

PRECISA ser compensada por temperatura
É PRECISO medir mudanças de orientação de até 5,5*Pi radianos/segundo (aproximadamente 1.000 graus por segundo)
DEVE ser capaz de enviar eventos a 200 Hz ou mais. Embora a frequência do giroscópio acima seja indicada como "SHOULD" para o Android 4.2, a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Ou seja, esses padrões são opcionais no Android 4.2, mas serão obrigatórios em versões futuras. É altamente recomendável que os dispositivos novos e atuais que executam o Android 4.2 atendam a esses requisitos no Android 4.2 para que possam fazer upgrade para as versões futuras da plataforma.
PRECISA ter 12 bits de precisão ou mais
A variância PRECISA ser menor que 1e-7 rad^2 / s^2 por Hz (variância por Hz ou rad^2 / s). A variação pode variar com a taxa de amostragem, mas precisa ser limitada por esse valor. Em outras palavras, se você medir a variação do giroscópio com uma taxa de amostragem de 1 Hz, ela não deve ser maior que 1e-7 rad^2/s^2.
PRECISA ter carimbos de data/hora o mais próximo possível do momento em que o evento de hardware ocorreu. A latência constante precisa ser removida.

7.3.5. Barômetro

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

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

7.3.7. Termômetro

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

7.3.7. Fotômetro

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

7.3.8. Sensor de proximidade

As implementações de dispositivos PODEM incluir um sensor de proximidade. Se uma implementação de dispositivo incluir um sensor de proximidade, ele PRECISA medir a proximidade de um objeto na mesma direção da tela. Ou seja, o sensor de proximidade PRECISA ser orientado para detectar objetos próximos à tela, já que a intenção principal desse tipo de sensor é detectar um smartphone em uso pelo usuário. Se uma implementação de dispositivo incluir um sensor de proximidade com qualquer outra orientação, ele NÃO PODE ser acessível por essa API. Se uma implementação de dispositivo tiver um sensor de proximidade, ela PRECISA ter 1 bit de precisão ou mais.

7.4. Conectividade de dados

7.4.1. Telefonia

"Telefonia", conforme usado pelas APIs do Android 4.2 e neste documento, se refere especificamente a hardware relacionado a ligações de voz e envio de mensagens SMS por uma rede GSM ou CDMA. Embora essas chamadas de voz possam ou não ser comutadas por pacotes, para fins do Android 4.2, elas são consideradas independentes de qualquer conectividade de dados que possa ser implementada usando a mesma rede. Em outras palavras, a funcionalidade "telefonia" do Android e as APIs se referem especificamente a chamadas de voz e SMS. Por exemplo, implementações de dispositivos que não podem fazer ligações ou enviar/receber mensagens SMS NÃO PODEM informar o recurso "android.hardware.telephony" ou qualquer subrecurso, independentemente de usar uma rede celular para conectividade de dados.

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

7.4.2. IEEE 802.11 (Wi-Fi)

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

As implementações de dispositivos precisam implementar a API multicast conforme descrito na documentação do SDK [Resources, 62]. As implementações de dispositivos que incluem suporte a Wi-Fi precisam oferecer suporte a DNS multicast (mDNS). As implementações de dispositivos NÃO PODEM filtrar pacotes mDNS (224.0.0.251) em nenhum momento da operação, inclusive quando a tela não está em um estado ativo.

7.4.2.1. Wi-Fi Direct

As implementações de dispositivos precisam incluir suporte ao Wi-Fi Direct (Wi-Fi ponto a ponto). Se uma implementação de dispositivo incluir suporte ao Wi-Fi Direct, ela PRECISA implementar a API Android correspondente, conforme descrito na documentação do SDK [Resources, 68]. Se uma implementação de dispositivo incluir suporte para Wi-Fi Direct, ela:

PRECISA ter suporte a operação regular de Wi-Fi
DEVE oferecer suporte a operações simultâneas de Wi-Fi e Wi-Fi Direct

7.4.3. Bluetooth

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

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

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

As implementações de dispositivos devem incluir um transceptor e hardware relacionado para comunicações a curta distância (NFC). Se uma implementação de dispositivo incluir hardware NFC, ela:

É PRECISO informar o recurso android.hardware.nfc do método android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37]
PRECISA ser capaz de ler e gravar mensagens NDEF pelos seguintes padrões de NFC:
- PRECISA ser capaz de atuar como leitor/gravador do NFC Forum (conforme definido pela especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0) pelos seguintes padrões de NFC:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS 6319-4)
  - IsoDep (ISO 14443-4)
  - Tipos de tag do NFC Forum 1, 2, 3 e 4 (definidos pelo NFC Forum)
DEVE ser capaz de ler e gravar mensagens NDEF usando os seguintes padrões de NFC. Embora os padrões NFC abaixo sejam indicados como "SHOULD" para o Android 4.2, a definição de compatibilidade para uma versão futura está planejada para mudar para "MUST". Ou seja, esses padrões são opcionais no Android 4.2, mas serão obrigatórios em versões futuras. É recomendado fortemente que os dispositivos atuais e novos que executam o Android 4.2 atendam a esses requisitos no Android 4.2 para que possam fazer upgrade para as versões futuras da plataforma.
- NfcV (ISO 15693)
PRECISA transmitir e receber dados pelos seguintes padrões e protocolos ponto a ponto:
- ISO 18092
- LLCP 1.0 (definido pelo NFC Forum)
- SDP 1.0 (definido pelo Fórum de NFC)
- Protocolo NDEF Push [Resources, 43]
- SNEP 1.0 (definido pelo NFC Forum)
É necessário incluir suporte ao Android Beam [Resources, 65]:
- É PRECISO implementar o servidor padrão do SNEP. Mensagens NDEF válidas recebidas pelo servidor SNEP padrão PRECISAM ser enviadas para aplicativos que usam a intent android.nfc.ACTION_NDEF_DISCOVERED. A desativação do Android Beam nas configurações NÃO pode desativar o envio de mensagens NDEF recebidas.
- As implementações de dispositivos precisam honrar a intent android.settings.NFCSHARING_SETTINGS para mostrar as configurações de compartilhamento de NFC [Resources, 67].
- É PRECISO implementar o servidor NPP. As mensagens recebidas pelo servidor NPP precisam ser processadas da mesma forma que o servidor padrão do SNEP.
- PRECISA implementar um cliente SNEP e tentar enviar P2P NDEF de saída para o servidor SNEP padrão quando o Android Beam estiver ativado. Se nenhum servidor SNEP padrão for encontrado, o cliente PRECISA tentar enviar para um servidor NPP.
- É necessário permitir que as atividades em primeiro plano definam a mensagem P2P NDEF de saída usando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback e android.nfc.NfcAdapter.enableForegroundNdefPush.
- É necessário usar um gesto ou uma confirmação na tela, como "Tocar para transmitir", antes de enviar mensagens P2P NDEF de saída.
- DEVE ativar o Android Beam por padrão
- PRECISA oferecer suporte à transferência de conexão NFC para Bluetooth quando o dispositivo oferece suporte ao perfil de envio de objeto Bluetooth. As implementações de dispositivos precisam oferecer suporte à transferência de conexão para Bluetooth ao usar android.nfc.NfcAdapter.setBeamPushUris, implementando a "Transferência de conexão versão 1.2" [Resources, 60] e o "Pareamento simples e seguro por Bluetooth usando NFC versão 1.0" [Resources, 61] do Fórum NFC. Essa implementação PRECISA usar solicitações SNEP GET para trocar a solicitação de transferência / selecionar registros por NFC e PRECISA usar o perfil de envio de objeto Bluetooth para a transferência real de dados Bluetooth.
É PRECISO pesquisar todas as tecnologias compatíveis no modo de descoberta NFC.
DEVE estar no modo de descoberta de NFC enquanto o dispositivo está ativo com a tela ativa e a tela de bloqueio desbloqueada.

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

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

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

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

PRECISA implementar as APIs do Android correspondentes, conforme documentado pelo SDK do Android.
É PRECISO informar o recurso com.nxp.mifare do método android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37] Esse não é um recurso padrão do Android e, como tal, não aparece como uma constante na classe PackageManager.
NÃO IMPLEMENTE as APIs do Android correspondentes nem informe o recurso com.nxp.mifare, a menos que ele também implemente o suporte geral ao NFC, conforme descrito nesta seção.

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

Como as classes android.nfc.NdefMessage e android.nfc.NdefRecord representam um formato de representação de dados independente de protocolo, as implementações de dispositivos precisam implementar essas APIs, mesmo se elas não incluírem suporte a NFC ou declararem o recurso android.hardware.nfc.

7.4.5. Capacidade mínima de rede

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

Implementações de dispositivos em que um padrão de rede física (como Ethernet) é a conexão de dados principal também precisam incluir suporte a pelo menos um padrão de dados sem fio comum, como 802.11 (Wi-Fi).

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

7,5. Cameras

As implementações de dispositivos PRECISAM incluir uma câmera traseira e PODEM incluir uma câmera frontal. Uma câmera traseira é uma câmera localizada na lateral do dispositivo, oposta à tela. Ou seja, ela captura imagens do lado oposto do dispositivo, como uma câmera tradicional. Uma câmera frontal é uma câmera localizada no mesmo lado do dispositivo que a tela, ou seja, uma câmera normalmente usada para capturar imagens do usuário, como em videoconferências e aplicativos semelhantes.

7.5.1. Câmera traseira

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

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

7.5.2. Câmera frontal

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

TERÃO que ter uma resolução mínima de VGA (ou seja, 640 x 480 pixels)
NÃO use uma câmera frontal como padrão para a API Camera. Ou seja, a API Camera no Android 4.2 tem suporte específico para câmeras frontais e as implementações de dispositivos NÃO PODEM configurar a API para tratar uma câmera frontal como a câmera traseira padrão, mesmo que seja a única câmera do dispositivo.
PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras, conforme descrito na seção 7.5.1.
PRECISA refletir horizontalmente (ou seja, espelhar) o stream exibido por um app em uma CameraPreview, conforme mostrado a seguir:

Se a implementação do dispositivo puder ser girada pelo usuário (por exemplo, automaticamente por um acelerômetro ou manualmente pela entrada do usuário), a visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação atual do dispositivo.
Se o aplicativo atual solicitou explicitamente que a tela da câmera fosse girada por uma chamada ao método android.hardware.Camera.setDisplayOrientation() [Resources, 50], a visualização da câmera PRECISA ser espelhada horizontalmente em relação à orientação especificada pelo aplicativo.
Caso contrário, a visualização PRECISA ser espelhada ao longo do eixo horizontal padrão do dispositivo.

DEVE espelhar a imagem mostrada pela visualização pós-postagem da mesma forma que o fluxo de imagem de visualização da câmera. Se a implementação do dispositivo não oferecer suporte à pós-visualização, esse requisito obviamente não se aplica.
NÃO ESPELHAR as imagens estáticas ou os streams de vídeo capturados finais retornados a callbacks de aplicativos ou comprometidos com o armazenamento de mídia

7.5.3. Comportamento da API Camera

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

Se um aplicativo nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int), o dispositivo PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização fornecidos a callbacks de aplicativos.
Se um aplicativo registrar uma instância android.hardware.Camera.PreviewCallback e o sistema chamar o método onPreviewFrame() quando o formato de visualização for YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame() precisam estar no formato de codificação NV21. Ou seja, o NV21 PRECISA ser o padrão.
As implementações de dispositivos precisam oferecer suporte ao formato YV12 (conforme indicado pela constante android.graphics.ImageFormat.YV12) para visualizações de câmera tanto para câmeras frontais quanto traseiras. O codificador de vídeo e a câmera de hardware podem usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à conversão para YV12.

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

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

As implementações de dispositivos precisam transmitir a intent Camera.ACTION_NEW_PICTURE sempre que uma nova foto for tirada pela câmera e a entrada da foto tiver sido adicionada à loja de mídia.

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

7.5.4. Orientação da câmera

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

7.6. Memória e armazenamento

7.6.1. Memória e armazenamento mínimos

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

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

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

7.6.2. Armazenamento compartilhado do aplicativo

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

As implementações de dispositivos precisam ser configuradas com armazenamento compartilhado montado por padrão, "fora da caixa". Se o armazenamento compartilhado não estiver montado no caminho /sdcard do Linux, o dispositivo PRECISA incluir um link simbólico do Linux de /sdcard para o ponto de montagem real.

As implementações de dispositivos precisam aplicar a permissão android.permission.WRITE_EXTERNAL_STORAGE conforme documentado neste armazenamento compartilhado. O armazenamento compartilhado PRECISA ser gravável por qualquer aplicativo que receba essa permissão.

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

Independentemente da forma de armazenamento compartilhado usada, as implementações de dispositivo precisam oferecer algum mecanismo para acessar o conteúdo do armazenamento compartilhado em um computador host, como armazenamento em massa USB (UMS) ou protocolo de transferência de mídia (MTP). As implementações do dispositivo PODEM usar o armazenamento em massa USB, mas PRECISAM usar o protocolo de transferência de mídia. Se a implementação do dispositivo oferecer suporte ao protocolo de transferência de mídia:

A implementação do dispositivo PRECISA ser compatível com o host de MTP de referência do Android, o Android File Transfer [Resources, 57].
A implementação do dispositivo DEVE informar uma classe de dispositivo USB de 0x00.
A implementação do dispositivo DEVE informar um nome de interface USB de "MTP".

Se a implementação do dispositivo não tiver portas USB, ela PRECISA fornecer a um computador host o acesso ao conteúdo do armazenamento compartilhado por outros meios, como um sistema de arquivos de rede.

Para ilustrar, considere dois exemplos comuns. Se uma implementação de dispositivo incluir um slot de cartão SD para atender ao requisito de armazenamento compartilhado, um cartão SD com formato FAT de 1 GB ou maior PRECISA ser incluído com o dispositivo vendido aos usuários e PRECISA ser montado por padrão. Como alternativa, se uma implementação de dispositivo usar armazenamento fixo interno para satisfazer esse requisito, esse armazenamento PRECISA ter o tamanho de 1 GB ou mais e ser montado em /sdcard (ou /sdcard PRECISA ser um link simbólico para o local físico se ele for montado em outro lugar).

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

7.7. USB

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

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

A porta PRECISA ser conectável a um host USB com uma porta USB-A padrão
a porta DEVE usar o formato micro USB no dispositivo. É altamente recomendável que os dispositivos novos e atuais que executam o Android 4.2 atendam a esses requisitos no Android 4.2 para que possam fazer upgrade para as versões futuras da plataforma.
a porta DEVE estar centralizada no meio de uma borda. As implementações de dispositivos PRECISAM localizar a porta na parte de baixo do dispositivo (de acordo com a orientação natural) ou ativar a rotação da tela de software para todos os apps (incluindo a tela inicial), para que a tela seja renderizada corretamente quando o dispositivo estiver orientado com a porta na parte de baixo. É recomendado que os dispositivos novos e atuais que executam o Android 4.2 atendam a esses requisitos para que possam fazer upgrade para versões futuras da plataforma.
Se o dispositivo tiver outras portas (como uma porta de carregamento que não seja USB), ela DEVE estar na mesma borda que a porta micro-USB
Ele PRECISA permitir que um host conectado ao dispositivo acesse o conteúdo do volume de armazenamento compartilhado usando o armazenamento em massa USB ou o protocolo de transferência de mídia.
Ele PRECISA implementar a API e a especificação do acessório aberto do Android conforme documentado na documentação do SDK do Android e PRECISA declarar suporte ao recurso de hardware android.hardware.usb.accessory [Resources, 52]
Ele PRECISA implementar a classe de áudio USB conforme documentado na documentação do SDK do Android [Resources, 66].
Ele PRECISA implementar suporte para a especificação de carregamento de bateria USB [Resources, 64]. É altamente recomendável que os dispositivos atuais e novos que executam o Android 4.2 atendam a esses requisitos no Android 4.2 para que possam fazer upgrade para as próximas versões da plataforma.

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

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

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

8. Compatibilidade de performance

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

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

9. Compatibilidade do modelo de segurança

As implementações de dispositivos PRECISAM implementar um modelo de segurança consistente com o modelo de segurança da plataforma Android conforme definido no documento de referência de segurança e permissões nas APIs [Resources, 54] na documentação para desenvolvedores do Android. As implementações de dispositivos precisam oferecer suporte à instalação de aplicativos autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades. Especificamente, os dispositivos compatíveis precisam oferecer suporte aos mecanismos de segurança descritos nas subseções a seguir.

9.1. Permissões

As implementações de dispositivos precisam oferecer suporte ao modelo de permissões do Android, conforme definido na documentação para desenvolvedores Android [Resources, 54]. Especificamente, as implementações precisam aplicar cada permissão definida, conforme descrito na documentação do SDK. Nenhuma permissão pode ser omitida, alterada ou ignorada. As implementações PODEM adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace android.*.

9.2. Isolamento de UID e processo

As implementações de dispositivos precisam oferecer suporte ao modelo de sandbox de aplicativos Android, em que cada aplicativo é executado como um UID no estilo Unix e em um processo separado. As implementações de dispositivos precisam oferecer suporte à execução de vários aplicativos como o mesmo ID de usuário do Linux, desde que os aplicativos sejam assinados e criados corretamente, conforme definido na referência de segurança e permissões [Resources, 54].

9.3. Permissões do sistema de arquivos

As implementações de dispositivos precisam oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na referência de segurança e permissões [Resources, 54].

9.4. Ambientes de execução alternativos

As implementações de dispositivos PODEM incluir ambientes de execução que executam apps usando algum outro software ou tecnologia que não seja a máquina virtual Dalvik ou o código nativo. No entanto, esses ambientes de execução alternativos NÃO podem comprometer o modelo de segurança do Android ou a segurança dos aplicativos Android instalados, conforme descrito nesta seção.

Os ambientes de execução alternativos precisam ser aplicativos Android e obedecer ao modelo de segurança padrão do Android, conforme descrito em outro lugar na seção 9.

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

Os ambientes de execução alternativos NÃO PODEM permitir que os aplicativos usem recursos protegidos por permissões do Android restritas a aplicativos do sistema.

Os ambientes de execução alternativos precisam obedecer ao modelo de sandbox do Android. Especificamente:

Os ambientes de execução alternativos PRECISAM instalar apps pelo PackageManager em sandboxes do Android separados (ou seja, IDs de usuário do Linux etc.).
Os ambientes de execução alternativos PODEM fornecer um único sandbox do Android compartilhado por todos os aplicativos que usam o ambiente de execução alternativo.
Os runtimes alternativos e os aplicativos instalados que usam um runtime alternativo NÃO PODEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos mecanismos padrão do Android de ID do usuário compartilhado e certificado de assinatura.
Os ambientes de execução alternativos NÃO PODEM ser iniciados com, conceder ou receber acesso aos sandboxes correspondentes a outros apps Android.

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

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

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

9.5. Suporte a vários usuários

O Android 4.2 inclui suporte para vários usuários e oferece suporte para isolamento total do usuário [Resources, 70].

As implementações de dispositivos precisam atender a estes requisitos relacionados ao suporte multiusuário[Resources, 71]:

Como o comportamento das APIs de telefonia em dispositivos com vários usuários ainda não foi definido, as implementações de dispositivos que declaram android.hardware.telephony NÃO PODEM ativar o suporte a vários usuários.
As implementações de dispositivos PRECISAM implementar, para cada usuário, um modelo de segurança consistente com o modelo de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs [Resources, 54]

Cada instância de usuário em um dispositivo Android PRECISA ter diretórios de armazenamento externo separados e isolados. As implementações de dispositivos PODEM armazenar dados de vários usuários no mesmo volume ou sistema de arquivos. No entanto, a implementação do dispositivo PRECISA garantir que os apps pertencentes a um determinado usuário e executados em nome dele não possam listar, ler ou gravar dados de outro usuário. As mídias removíveis, como slots de cartão SD, podem permitir que um usuário acesse os dados de outro por meio de um PC host. Por esse motivo, as implementações de dispositivos que usam mídia removível para as APIs de armazenamento externo PRECISAM criptografar o conteúdo do cartão SD se a opção de vários usuários estiver ativada usando uma chave armazenada apenas em mídia não removível acessível apenas ao sistema. Como isso torna a mídia ilegível para um PC host, as implementações de dispositivos precisam mudar para MTP ou um sistema semelhante para fornecer aos PCs host acesso aos dados do usuário atual. Portanto, as implementações de dispositivos PODEM, mas NÃO DEVEM, ativar o modo multiusuário se usarem mídia removível [Resources, 72] para armazenamento externo principal. O projeto upstream de código aberto do Android inclui uma implementação que usa o armazenamento interno do dispositivo para APIs de armazenamento externo do aplicativo. As implementações do dispositivo devem usar essa configuração e implementação de software. As implementações de dispositivos que incluem vários caminhos de armazenamento externo NÃO podem permitir que os apps Android gravem no armazenamento externo secundário

9.6. Aviso de SMS premium

O Android 4.2 inclui suporte para avisar os usuários sobre qualquer mensagem SMS premium enviada. SMS premium são mensagens de texto enviadas para um serviço registrado com uma operadora que pode gerar cobranças para o usuário. As implementações de dispositivos que declaram suporte a android.hardware.telephony PRECISAM avisar os usuários antes de enviar uma mensagem SMS para números identificados por expressões regulares definidas no arquivo /data/misc/sms/codes.xml no dispositivo. O projeto de código aberto upstream do Android oferece uma implementação que atende a esse requisito.

10. Teste de compatibilidade de software

As implementações de dispositivos precisam passar em todos os testes descritos nesta seção.

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

10.1. Conjunto de teste de compatibilidade

As implementações de dispositivos PRECISAM ser aprovadas no conjunto de teste de compatibilidade do Android (CTS) [Resources, 2] disponível no Projeto Android Open Source usando o software de envio final no dispositivo. Além disso, os implementadores de dispositivos PRECISAM usar a implementação de referência na árvore de código-fonte aberta do Android o máximo possível e PRECISAM garantir a compatibilidade em casos de ambiguidade no CTS e para qualquer nova implementação de partes do código-fonte de referência.

O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs. A versão do CTS será independente dessa definição de compatibilidade, e várias revisões do CTS poderão ser lançadas para o Android 4.2. As implementações de dispositivos precisam passar na versão mais recente do CTS disponível no momento em que o software do dispositivo é concluído.

10.2. Verificador do CTS

As implementações de dispositivos precisam executar corretamente todos os casos aplicáveis no CTS Verifier. O Verificador do CTS está incluído no conjunto de testes de compatibilidade e é destinado a ser executado por um operador humano para testar a funcionalidade que não pode ser testada por um sistema automatizado, como o funcionamento correto de uma câmera e sensores.

O Verificador do CTS tem testes para muitos tipos de hardware, incluindo alguns opcionais. As implementações de dispositivos precisam ser aprovadas em todos os testes de hardware que eles têm. Por exemplo, se um dispositivo tiver um sensor de aceleração, ele precisa executar corretamente o caso de teste do sensor de aceleração no CTS Verifier. Os casos de teste para recursos indicados como opcionais por este documento de definição de compatibilidade podem ser pulados ou omitidos.

Todos os dispositivos e builds precisam executar corretamente o CTS Verifier, conforme observado acima. No entanto, como muitos builds são muito semelhantes, não esperamos que os implementadores de dispositivos executem explicitamente o Verificador do CTS em builds que diferem apenas de maneiras triviais. Especificamente, implementações de dispositivos que diferem de uma implementação que passou no Verificador do CTS apenas pelo conjunto de localidades incluídas, branding etc. PODEM omitir o teste do Verificador do CTS.

10.3. Aplicativos de referência

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

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

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

11. Software atualizável

As implementações de dispositivos precisam incluir um mecanismo para substituir todo o software do sistema. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, uma reinicialização do dispositivo PODE ser necessária.

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

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

O mecanismo de atualização usado PRECISA oferecer suporte a atualizações sem apagar os dados do usuário. Ou seja, o mecanismo de atualização PRECISA preservar os dados particulares e compartilhados do aplicativo. O software upstream do Android inclui um mecanismo de atualização que atende a esse requisito.

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

12. Entre em contato

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

Apêndice A: procedimento de teste de Bluetooth

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

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

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

Configuração e instalação

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

Testar o controle Bluetooth por apps

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

Testar o pareamento e a comunicação

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

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

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

Testar re-lançamentos

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

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