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

Definição de compatibilidade do Android 4.1
Revisão 3
Última atualização: 24 de junho de 2013
Copyright © 2012, Google Inc. Todos os direitos reservados.
compatibility@android.com
Sumário
1. Introdução
2. Recursos
3. Software
3.1. Compatibilidadeda API gerenciada
3.2. Compatibilidade de API flexível
3.2.1. Permissões
3.2.2. Crie parâmetros
3 .2.3. Compatibilidade de intent
3.2.3.1. Core Application Intents
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 da API nativa
3.3.1 Interfaces binárias do aplicativo 3.4.
Compatibilidade da Web
3.4.1. Compatibilidade com a WebView
3.4.2. Compatibilidade do navegador
3.5. Compatibilidade comportamental da API
3.6. Namespaces de API
3.7. Compatibilidade de máquinas virtuais
3.8. Compatibilidade da 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. Papéis de parede ao vivo
3.8.7. Exibição de aplicações recentes
3.8.8. Configurações de gerenciamento de entrada
3.8.9. Controle remoto da tela de bloqueio
3.9 Device Administration
3.10 Accessibility
3.11 Text-to-Speech
4. Compatibilidade de empacotamento de aplicativos
5. Compatibilidade multimídia
5.1. Codecs de mídia
5.2. Codificação de vídeo
5.3. Gravação de áudio
5.4. Latência de áudio
5.5. Protocolos de rede
6. Developer Tool Compatibility
7. Compatibilidade de hardware
7.1. Exibição 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 de tela
7.2. Em put Devices
7.2.1. Teclado
7.2.2. Navegação sem toque
7.2.3. Teclas de navegação
7.2.4. Entrada na tela touch
7.2.5. Entrada de toque simulada
7.2.6. Microfone
7.3. Sensores
7.3.1. Acelerômetro

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. Fotometro
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 da rede
7.5. Câ€‹câ€‹
7.5.1. Câmeratraseira
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 mínima e armazenamento
7.6.2. Armazenamento compartilhado do app
7.7. USB
8. Performance Compatibilidade
9. Compatibilidade do modelo de segurança
9.1. Permissões
9.2. UID e isolamento de processo
9.3. Permissões do sistema de arquivos
9.4. Ambientes de execução alternativos
10. Teste de compatibilidade de software
10.1. Conjunto de teste de compatibilidade
10.2. Verificador do CTS
10.3. Aplicativos de referência
11. Update Software
12. Contact Us
Apêndice A - Procedimento de Test Bluetooth

1. Introdução
Este documento enumera os requisitos que precisam ser atendidos para que os dispositivos
sejam compatíveis com o Android 4.1.
O uso de "must", "must not", "required", "shal ", "shal  not", "should", "should not",
"recommended", "may" e "optional" é conforme o padrão IETF definido na RFC2119
[Resources, 1].
No uso deste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou
organização que desenvolve uma solução de hardware/software que executa o Android 4.1. Uma "implementação
do dispositivo" ou "implementação" é a solução de hardware/software desenvolvida.
Para ser considerada compatível com o Android 4.1, as implementações de dispositivo PRECISAM atender
os 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 desenvolvedorgarantir
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
incentivados a
basear suas implementações o máximo possível no
código-fonte"upstream" disponível no Projeto Android Open Source. Embora alguns
componentes possam ser hipoteticamente substituídos por implementações alternativas, essa
prática é fortemente desaconselhada, pois a aprovação dos testes de software vai ficar
significativamente mais difícil. É responsabilidade do implementador garantir a compatibilidade com o comportamento
com a implementação padrão do Android, incluindo e além do conjunto de testes de compatibilidade
. Finalmente, observe que certas substituições de componentes e
modificações são explicitamente proibidas por este documento.
2. Recursos
1.  Níveis de requisito do IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2.  Visão geral do Programa de compatibilidade do Android:
http://source.android.com/compatibility/index.html
3.  Android Open Source Project: http://source.android.com/
4.  Definições e documentação da API:
http://developer.android.com/reference/packages.html
5.  Referência de permissões do Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  Referência android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  Android 4.1 al owed version strings:
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  Aceleração de hardware:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  Classe android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  Capacidades off-line do HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13.  Tag de vídeo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  API Geolocation HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15.  HTML5/W3C webdatabase API: http://www.w3.org/TR/webdatabase/
16.  API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17.  Especificação da máquina virtual Dalvik: disponível no código-fonte do Android, em
dalvik/docs
18.  AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  Notificações:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  Recursos do aplicativo: http://code.google.com/android/reference/available-
resources.html
21.  Guia de estilo de ícones da barra de status:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Gerenciador de pesquisa:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Toasts: http://developer.android.com/reference/android/widget/Toast.html
24.  Temas: http://developer.android.com/guide/topics/ui/themes.html

25.  Classe R.style: http://developer.android.com/reference/android/R.style.html
26.  Papéis de parede dinâmicos: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Gerenciamento de dispositivos Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  Classe android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  APIs do Android Accessibility Service:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  APIs de acessibilidade do Android:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  Projeto Eyes Free: http://code.google.com/p/eyes-free
32.  APIs Text-To-Speech:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  Documentação da ferramenta de referência (para adb, aapt e dms):
http://developer.android.com/guide/developing/tools/index.html
34.  Descrição do arquivo apk do Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  Arquivos de manifesto: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  Ferramenta de teste Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Classe android.content.pm.PackageManager e Recursos de Armadamento
Lista:
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  Suporte a várias telas:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  API Bluetooth:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  Protocolo NDEF Push: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  API de orientação da câmera:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Acessórios abertos do Android:
http://developer.android.com/guide/topics/usb/accessory.html
53.  API USB Host: http://developer.android.com/guide/topics/usb/host.html
54.  Referência de segurança e permissões do Android:
http://developer.android.com/guide/topics/security/security.html
55.  Apps para Android: http://code.google.com/p/apps-for-android
56.  Classe android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: http://www.android.com/filetransfer
58.  Formatos de mídia do Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  Protocolo de rascunho do HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  Transferência de conexão NFC: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  Pareamento simples e seguro do Bluetooth usando NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  API Wifi Multicast:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Assistente de ação:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  Especificação de carregamento USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  Áudio USB Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  Configurações de compartilhamento de NFC do Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wifi Direct (Wifi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Cliente de controle remoto de mídia:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  API Motion Event:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Configuração de entrada por toque: http://source.android.com/tech/input/touch-
devices.html
Muitos desses recursos são derivados diretamente ou indiretamente do SDK do Android 4.1,
e vão ser funcionais idênticos às informações na documentação do SDK. Em
todos os casos em que esta definição de compatibilidade ou o conjunto de testes de compatibilidade não concordam com
a documentação do SDK, a documentação do SDK é considerada a autoridade. Todos os
detalhes técnicos fornecidos nas referências incluídas 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 aplicativos
do Android. A interface de programação do aplicativo Android (API) é o conjunto de
interfaces da plataforma Android expostas a aplicativos executados no ambiente
de VM gerenciada. As implementações de dispositivos PRECISAM fornecer implementações completas,
incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK
4.1 do Android [Resources, 4].
As implementações de dispositivo MUST NÃO omitirem nenhuma API gerenciada, alterar interfaces de API ou
assinaturas, desviar do comportamento documentado ou incluir no-ops, exceto quando
específicas permitidas 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 do dispositivo. Nesses casos, as APIs
precisam
estar presentes e se comportar de maneira razoável. Consulte a seção 7 para ver os requisitos
específicos desse cenário.
3.2. Compatibilidade com APIs leves
Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API
"leve" significativa somente de 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
.
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 requisitos adicionais relacionadas ao modelo de segurança do Android.
3.2.2. Parâmetros de 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 dispositivo, a tabela abaixo inclui outras
restrições sobre os formatos desses valores que as implementações de dispositivo
precisam
conformar.
Parâmetro
Comentários
A versão do sistema Android em execução no momento, em formato legível. Esse campo PRECISA ter um
android.os.Build.VERSION.RELEASE
dos valores de string definidos em [Resources, 7].
A versão do sistema Android em execução no momento, em um formato acessível ao código de aplicativos de terceiros.
android.os.Build.VERSION.SDK
No Android 4.1, esse campo PRECISA ter o valor inteiro 16.

A versão do sistema Android em execução, em um formato acessível ao código de aplicativos de terceiros.
android.os.Build.VERSION.SDK_INT
Para o Android 4.1, este campo PRECISA ter o valor inteiro 16.
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 para
android.os.Build.VERSION.INCREMENTAL
usuários finais. Um uso típico desse 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 para o formato específico desse campo, exceto que ele
NÃO
pode ser nulo ou uma string vazia ("").
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 está alimentando
android.os.Build.BOARD
o dispositivo. O valor deste campo PRECISA ser codificado como ASCI de 7 bits e corresponder à expressão regular
"^[a-zA-Z0-9.,_-]+$".
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
android.os.Build.BRAND
e/ou a operadora que vendeu o dispositivo. O valor deste campo PRECISA ser codificado como ASCI de 7 bits e corresponder à expressão regular
"^[a-zA-Z0-9.,_-]+$".
O nome do conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3: API nativa
android.os.Build.CPU_ABI
Compatibilidade.
O nome do segundo conjunto de instruções (tipo de CPU + convenção ABI) de código nativo. Consulte a seção 3.3:
android.os.Build.CPU_ABI2
API Compatibilidade.
Um valor escolhido pelo implementador do dispositivo que identifica a configuração ou revisão específica do corpo
android.os.Build.DEVICE
(às vezes chamado de "design industrial") do dispositivo. O valor deste campo PRECISA ser codificado como
ASCI de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9.,_-]+$".
Uma string que identifica exclusivamente este build. Ele PRECISA ser legível por humanos. Ele PRECISA seguir este
modelo:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Por exemplo:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
A impressão digital NÃO PODE incluir caracteres de espaço. Se outros campos incluídos no modelo acima tiverem caracteres de espaço
, eles PRECISAM ser substituídos na impressão digital do build por outro caractere, como o
sublinhado ("_"). O valor deste campo PRECISA ser codificado como ASCI de 7 bits.
O nome do hardware (da linha de comando do kernel ou /proc). Ele DEVE ser razoavelmente legível por humanos
android.os.Build.HARDWARE
. O valor deste campo PRECISA ser codificado como ASCI de 7 bits e corresponder à expressão regular "^[a-
zA-Z0-9.,_-]+$".
Uma string que identifica de forma única o host em que o build foi criado, em formato legível por humanos. Não há
android.os.Build.HOST
requisitos no formato específico deste campo, exceto que ele NÃO PRECISA ser nulo ou a string vazia ("").
Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão específica, em formato legível por humanos. Esse campo
pode ser o mesmo que android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor suficientemente
android.os.Build.ID
significativo para que os usuários finais distingam entre builds de software. O valor deste campo PRECISA ser encodável
como ASCI de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9.,_-]+$".
O nome comercial do fabricante do equipamento original (OEM) do produto. Não há requisitos em
android.os.Build.MANUFACTURER
o formato específico deste campo, exceto que ele NÃO PRECISA ser nulo ou a string vazia ("").
Um valor escolhido pelo implementador do dispositivo que contém o nome do dispositivo conhecido pelo usuário final. O
android.os.Build.MODEL
PRECISA ser o mesmo nome com que o dispositivo é comercializado e vendido aos usuários finais. Não há
requisitos no formato específico deste campo, exceto que ele NÃO PRECISA ser nulo ou a string vazia ("").
Um valor escolhido pelo implementador do dispositivo que contém o nome de desenvolvimento ou o nome de código do produto
android.os.Build.PRODUCT
(SKU). PRECISA ser legível por humanos, mas não necessariamente para visualização por usuários finais. O valor deste campo
PRECISA ser codificado como ASCII de 7 bits e corresponder à expressão regular "^[a-zA-Z0-9.,_-]+$".
Um número de série de hardware, se disponível. O valor deste campo PRECISA ser encodável como ASCI de 7 bits e corresponder
a android.os.Build.SERIAL
a expressão regular "^([a-zA-Z0-9]{0,20})$".
Uma lista de tags separadas por vírgulas escolhidas pelo implementador do dispositivo que diferenciam ainda mais o build. Para
android.os.Build.TAGS
exemplo, "unsigned,debug". O valor deste campo PRECISA ser codificado como ASCI 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 em que o build ocorreu.
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 do ambiente de execução do Android: "user",
android.os.Build.TYPE
"userdebug" ou "eng". O valor deste campo PRECISA ser codificado como ASCI de 7 bits e corresponder à expressão regular
"^[a-zA-Z0-9.,_-]+$".
Um nome ou ID do usuário (ou usuário automatizado) que gerou o build. Não há requisitos em
android.os.Build.USER
o formato específico deste campo, exceto que ele NÃO PRECISA ser nulo ou a string vazia ("").
3.2.3. Compatibilidade com 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 associe e implemente o comportamento correto para cada padrão de intent especificado.
3.2.3.1. Intents de aplicativo principal
O projeto upstream do Android define várias aplicações principais, como contatos,
agenda, galeria de fotos, reprodutor de músicas 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 respeitar o padrão de Intent emitido por aplicativos de terceiros para escolher uma música.
Os seguintes apps são considerados apps do sistema Android principais:
Relógio de mesa
Navegador
Calendário
Contatos
Gal eria
Pesquisa global
Início
Música
Configurações
Os apps do sistema Android principais incluem vários componentes de atividade ou serviço
que são considerados "públicos". Ou seja, o atributo "android:exported" pode estar ausente, ou
pode ter o valor "true".
Para cada atividade ou serviço definido em um dos apps do sistema Android que não é
marcado como não público usando um atributo android:exported com o valor "false", as implementações
do dispositivo precisam incluir um componente do mesmo tipo que implementa os
mesmos padrões de filtro de intent que o app do sistema Android.
Em outras palavras, uma implementação do dispositivo pode substituir apps do sistema Android.
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 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 do Android upstream permite isso por padrão. Os
implementadores de dispositivos NÃO PRECISAM anexar privilégios especiais ao uso de aplicativos do sistema de
esses padrões de intent ou impedir que aplicativos de terceiros se vinculem e assumam
o controle deles. Essa proibição inclui, entre outras coisas,
desativar a interface do usuário "Chooser", que permite que o usuário selecione entre vários
aplicativos que processam o mesmo padrão de intent.
No entanto, as implementações de dispositivos podem fornecer atividades padrão para padrões específicos de URI
(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 do que o filtro do navegador para "http://". As implementações de dispositivo
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 padrões de intent
novos ou de intent de transmissão usando uma ACTION, CATEGORY ou outra string de chave
no namespace android.* ou com.android.*. Os implementadores de dispositivos NÃO
devem incluir componentes do Android que respeitem padrões de intent ou broadcast intent
novos usando uma ACTION, CATEGORY ou outra string de chave em um espaço de pacote pertencente a
outra organização. Os implementadores de dispositivos NÃO PODEM alterar ou estender 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 apps de terceiros dependem da plataforma para transmitir certas Intents e notificar os usuários

de mudanças no ambiente de hardware ou software. Os dispositivos compatíveis com o Android
PRECISAM transmitir as intents de transmissão pública em resposta a eventos
do sistema. As intents de transmissão são descritas na documentação do SDK.
3.3. Compatibilidade com API nativa
3.3.1 Interfaces binárias de aplicativos
O código gerenciado executado no Dalvik pode ser convertido em código nativo fornecido no arquivo do aplicativo
.apk como um arquivo ELF .so compilado para a arquitetura de hardware do dispositivo adequado.
Como o código nativo é altamente dependente da tecnologia do processador, o Android
define um número de Interfaces binárias de aplicativos (ABIs) no NDK do Android, no arquivo
docs/CPU-ARCH-ABIS.html. Se uma implementação de dispositivo for compatível com uma ou mais
definidas, ela DEVE implementar compatibilidade com o Android NDK, conforme abaixo.
Se uma implementação de dispositivo incluir suporte a uma ABI do Android, ela:
PRECISA incluir suporte para código executado no ambiente gerenciado para cal em código nativo
, usando a semântica padrão da interface nativa Java (JNI).
PRECISA ser compatível com a fonte (ou seja, compatível com cabeçalho) e com binário (para
a ABI) com cada biblioteca necessária na lista abaixo
PRECISA informar com precisão a interface binária de aplicativo nativa (ABI, do inglês) compatível
com o dispositivo, usando a API android.os.Build.CPU_ABI
PRECISA ser criado usando o código-fonte e os arquivos de cabeçalho disponíveis no
projeto de código-fonte aberto 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 de matemática)
Suporte mínimo para C++
interface JNI
liblog (registro do Android)
libz (compactação Zlib)
libdl (vinculação dinâmica)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (gerenciamento de superfície OpenGL nativo)
libjnigraphics.so
libOpenSLES.so (suporte a áudio OpenSL ES 1.0.1)
libOpenMAXAL.so (suporte a OpenMAX AL 1.0.1)
libandroid.so (suporte a atividade nativa do Android)
Suporte a OpenGL, conforme descrito abaixo
Observe que versões futuras do NDK do Android podem introduzir suporte para outras ABIs
.

Se uma implementação de dispositivo não for compatível com uma ABI predefinida existente, ela
NÃO PRECISA informar suporte para nenhuma ABI em alguma forma .
A compatibilidade com o código nativo é um desafio. Por esse motivo, recomendamos que os implementadores de
dispositivos usem as implementações
upstream das bibliotecas listadas acima para garantir a 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 completo para um sistema de renderização da Web, os implementadores devem usar
o build upstream específico do WebKit na implementação da WebView. Especificamente:
As implementações de android.webkit.WebView de implementações de dispositivos
precisam ser baseadas na versão 534.30 do WebKit da árvore de origem do Android Open Source
para o Android 4.1. Esse build inclui um conjunto específico de correções de funcionalidade e segurança
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 de 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.1
Mobile Safari/534.30
O valor da string $(VERSION) PRECISA ser o mesmo que o valor de

O valor da string $(VERSION) PRECISA ser o mesmo que o valor de
android.os.Build.VERSION.RELEASE
O valor da string $(LOCALE) PRECISA seguir as convenções ISO para o código e o idioma
do país, e PRECISA se referir à localidade
configurada do dispositivo.
O valor da string $(MODEL) PRECISA ser o mesmo que o valor de
android.os.Build.MODEL
O valor da string $(BUILD) PRECISA ser o mesmo que o valor de
android.os.Build.ID
As implementações do dispositivo PODEM omitir "Mobile" na string de user agent
O componente WebView PRECISA incluir suporte para o maior número possível de HTML5
[Recursos, 11]. As implementações de dispositivo mínimas precisam oferecer suporte a cada uma
das APIs associadas ao HTML5 na WebView:
operação de cache/off-line do aplicativo [Resources, 12]
a tag <video> [Resources, 13]
geolocalização [Resources, 14]
Além disso, as implementações de dispositivo precisam oferecer suporte à API webstorage do HTML5/W3C
[Resources, 15] e DEVEM oferecer suporte à API IndexedDB do HTML5/W3C [Resources,
16]. Observe que, à medida que os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer
IndexedDB em vez de webstorage, espera-se que IndexedDB se torne um componente obrigatório
em uma versão futura do Android.
As APIs HTML5, assim como as APIs JavaScript, PRECISAM ser desativadas por padrão em uma WebView,
a menos que o desenvolvedor as ative explicitamente pelas APIs Android convencionais.
3.4.2. Compatibilidade do navegador
As implementações de dispositivos precisam incluir um aplicativo de navegador independente para navegação geral
na Web. O navegador independente pode ser baseado em uma tecnologia de navegador
diferente de WebKit. No entanto, mesmo se um aplicativo de navegador alternativo for usado, o
componente android.webkit.WebView fornecido a aplicativos de terceiros deve 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
upstream ou uma substituição de terceiros) DEVE incluir suporte para o maior número de
HTML5 [Recursos, 11] possível.As implementações de dispositivo mínimas precisam oferecer suporte
a cada uma das APIs associadas ao HTML5:
operação de cache/desconectado do aplicativo [Resources, 12]
a tag <video> [Resources, 13]
geolocalização [Resources, 14]
Além disso, as implementações de dispositivo precisam oferecer suporte à API Web Storage do HTML5/W3C
[Resources, 15] e DEVEM oferecer suporte à API IndexedDB do HTML5/W3C [Resources,
16]. Observe que, à medida que os órgãos de padrões de desenvolvimento da Web estão fazendo a transição para favorecer a
IndexedDB em vez do IndexedDB do armazenamento da Web, espera-se que a IndexedDB se torne um componente
obrigatório em uma versão futura do Android.
3.5. Compatibilidade comportamental da API
O comportamento de cada um dos tipos de API (gerenciada, soft, nativa e da Web) precisa ser
consistente com a implementação preferencial do projeto
de código aberto upstream do Android [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 devices NÃO podem mudar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico
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 é exaustiva. O conjunto de teste de compatibilidade (CTS) testa
partes significativas da plataforma para compatibilidade comportamental, mas não toda . A
responsabilidade do implementador é garantir a compatibilidade comportamento com o Android
Open Source Project. Por esse motivo, os implementadores de dispositivos DEVEM usar o código
de fonte disponível pelo Android Open Source Project sempre que possível, em vez de
implementar novamente partes importantes do sistema.
3.6. Namespaces de API
O Android segue as convenções de namespace de pacote e de 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 (consulte abaixo) nesses namespaces de pacote
:
java.*
javax.*
sun.*
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 a classes ou interfaces existentes) às
APIs acima.
Um "elemento exposto publicamente" é qualquer construção que não seja decorada com o marcador
"@hide" conforme usado no código-fonte upstream do Android. Em outras palavras, os implementadores
de dispositivos NÃO PRECISAM EXPORIR novas APIs ou alterar as APIs existentes nos namespaces
indicados acima. Os implementadores de dispositivos podem fazer modificações apenas internas, mas essas
modificações não podem ser anunciadas ou expostas aos desenvolvedores.
Os implementadores de dispositivos PODEM adicionar APIs personalizadas, mas elas NÃO PODEM estar em um namespace
de propriedade ou que se refira a outra organização. Por exemplo, os implementadores de
dispositivos NÃO PRECISAM adicionar APIs ao namespace com.google.* ou semelhante; somente
o Google pode fazer isso. Da mesma forma, o Google NÃO PRECISA adicionar APIs a outros namespaces
de empresas. Além disso, se uma implementação do dispositivo incluir APIs personalizadas fora
do espaço de nome padrão do Android, essas APIs PRECISAM ser empacotadas em uma biblioteca compartilhada
do Android para que apenas os apps que as usam explicitamente (por meio do mecanismo <uses-library>
) sejam afetados pelo aumento do uso de memória dessas APIs.
Se um implementador de dispositivo propor melhorias em um dos namespaces de pacote acima
(por exemplo, adicionando uma nova funcionalidade útil a uma API existente ou adicionando uma nova API), o implementador
DEVE acessar source.android.com e iniciar o processo de contribuir com mudanças e códigos
, de acordo com as informações disponíveis neste 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 pela inclusão nesta definição de compatibilidade.
3.7. Compatibilidade com máquinas virtuais
As implementações de dispositivos precisam oferecer suporte à especificação de bytecode
Dalvik Executable (DEX) completa e à semântica da máquina virtual Dalvik [Resources, 17].
As implementações do dispositivo PRECISAM configurar o Dalvik para alocar memória de acordo
com a plataforma upstream do Android e conforme especificado na tabela a seguir. Consulte a
seção 7.1.1 para ver as definições de tamanho e densidade da tela.
Os valores de memória especificados abaixo são considerados mínimos, e a implementação do dispositivo
pode alocar mais memória por aplicativo.
Tamanho da tela
Densidade da tela
Memória do app
pequeno  / normal / grande
ldpi / mdpi
16 MB
pequeno  / normal / grande
tvdpi / hdpi
32 MB
pequeno  / normal / grande
xhdpi
64 MB
extragrande
mdpi
32 MB
extragrande
tvdpi / hdpi
64 MB
extragrande
xhdpi
128 MB
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

aos aplicativos exibir um "AppWidget" ao usuário final [Resources, 18]. A versão de referência do
Android
de código aberto inclui um app de início que oferece aos usuários a possibilidade de adicionar, visualizar e remover widgets de app da tela inicial
.
As implementações do dispositivo PODEM substituir uma alternativa ao iniciador de referência (por exemplo, a tela inicial
). Os iniciadores alternativos DEVEM incluir suporte integrado a AppWidgets,
e exibir affordances 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 que os usuários adicionem,
configurem, visualizem e removam widgets de app.
As implementações de dispositivos precisam ser capazes de renderizar widgets de 4 x 4 no tamanho de grade padrão
. 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 aos desenvolvedores notificar os usuários sobre eventos importantes
[Resources, 19], usando recursos de hardware e software do dispositivo.
Algumas APIs permitem que os apps realizem notificações ou atraiam atenção usando
hardware, som, vibração e luz específicos. As implementações de dispositivo
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 implementation PRECISA renderizar corretamente todos os recursos (ícones, arquivos de som
, etc.) fornecidos nas APIs [Resources, 20] ou no guia de estilo do ícone
Status/Barra do sistema [Resources, 21]. Os implementadores de dispositivos podem oferecer uma experiência
alternativa do usuário 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 aos recursos
de notificação existentes, conforme descrito acima.
O Android 4.1 oferece suporte a notificações interativas, como
notificações em andamento. As implementações de dispositivos precisam mostrar e executar corretamente notificações
com recursos, conforme documentado nas APIs do Android.
3.8.3. Pesquisa
O Android inclui APIs [Resources, 22] que permitem que os desenvolvedores incorporem a pesquisa aos
apps e exponham os dados deles à pesquisa global do sistema.
De modo geral, essa funcionalidade consiste em uma única interface de usuário do sistema
que permite que os usuários insiram consultas, mostre sugestões conforme os usuários digitam e mostre
os resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para fornecer pesquisa
nos próprios apps e permitem que os desenvolvedores forneçam resultados à interface de usuário global
comum.
As implementações de dispositivos precisam incluir uma interface
de 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
do dispositivo
precisam implementar as APIs que permitem que os desenvolvedores reutilizem essa interface para oferecer a pesquisa nos próprios aplicativos. As implementações de dispositivo
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 for
instalado que faça uso dessa funcionalidade, o comportamento padrão DEVE ser exibir
resultados e sugestão do motor de pesquisa da Web.
3.8.4. Toasts
Os aplicativos podem usar a API Toast (definida em [Resources, 23]) para mostrar strings
modal curtas para o usuário final, que desaparecem após um breve período. As implementações
do dispositivo precisam mostrar os avisos
dos aplicativos aos usuários finais de uma forma de alta
visibilidade.
3.8.5. Temas
O Android oferece "temas" como um mecanismo para aplicativos aplicarem estilos em uma
atividade ou aplicativo inteiro. O Android 3.0 apresentou um novo tema
"Holo" ou
"holográfico" como um conjunto de estilos definidos para os desenvolvedores de aplicativos usarem se quiserem combinar
a aparência e a sensação do tema Holo conforme definido pelo SDK do Android [Resources, 24]. As implementações do
dispositivo NÃO PRECISAM alterar nenhum dos atributos do tema Holo expostos a

aplicativos [Resources, 25].
O Android 4.0 apresentou um novo tema "Padrão do dispositivo" como um conjunto de estilos definidos para
desenvolvedores de aplicativos usar se eles quiserem combinar a aparência e a sensação do tema
do dispositivo conforme definido pelo implementador do dispositivo. As implementações de dispositivos PODEM modificar os atributos do tema
DeviceDefault expostos aos aplicativos [Refontes, 25].
3.8.6. Planos de fundo interativos
O Android define um tipo de component e a API e o ciclo de vida correspondentes que permitem
aplicativos exibir um ou mais "planos de fundo interativos" ao usuário final [Resources, 26].
Planos de fundo interativos são animações, padrões ou imagens semelhantes com recursos de entrada
limitados que são exibidos 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 puder executar todos os papéis de parede animados
, sem limitações de funcionalidade, a uma taxa de quadros razoável sem
efeitos adversos em outros aplicativos. Se as limitações no hardware causarem o travamento de papel de parede
e/ou aplicativos, falhas, consumo excessivo de CPU ou bateria, ou
execução a taxas de frames inaceitáveis, o hardware é considerado incapaz de executar
papel de parede ao vivo. Por exemplo, alguns papéis de parede interativos podem usar um contexto Open GL 1.0 ou 2.0
para renderizar o conteúdo. O papel de parede interativo não funcionará de forma confiável em hardwares que
não oferecem suporte a vários contextos do OpenGL, porque o uso do papel de parede interativo de um contexto do OpenGL pode entrar em conflito com outros aplicativos que também usam um contexto do OpenGL.

As implementações de dispositivo capazes de executar papéis de parede animados de forma confiável, conforme descrito
acima, DEVEM implementar papéis de parede animados. As implementações de dispositivo determinadas a não
executar papéis de parede dinâmicos de forma confiável, conforme descrito acima, NÃO DEVEM implementar papéis de parede dinâmicos.
3.8.7. Exibição de apps recentes
O código-fonte upstream do Android 4.1 inclui uma interface do usuário para exibir apps
recentes usando uma imagem em miniatura do estado gráfico do app no
momento em que o usuário saiu do app. As implementações de dispositivos PODEM alterar ou
eliminar essa interface do usuário. No entanto, uma versão futura do Android está planejada para fazer um uso
mais amplo dessa funcionalidade. As implementações de dispositivo são fortemente
recomendadas a usar a interface do usuário do Android 4.1 (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.1 inclui suporte a motores de gerenciamento de entrada. As APIs do Android 4.1
per mit a entradas de texto de app personalizadas para especificar configurações ajustáveis pelo usuário. As implementações de 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 exibido.
3.8.9. Controle remoto da tela de bloqueio
O Android 4.0 introduziu o suporte à API de controle remoto que permite que aplicativos de mídia
sejam integrados a controles de reprodução que são exibidos em uma visualização remota, como a tela de bloqueio do dispositivo
[Resources, 69]. As implementações de dispositivos PRECISAM incluir suporte para
incorporação de controles remotos na tela de bloqueio do dispositivo.
3.9 Administração de dispositivos
O Android 4.1 inclui recursos que permitem que apps com segurança ativada realizem funções de administração de dispositivos
no nível do sistema, como aplicar políticas de senha ou
realizar apagamento remoto, usando a API de administração de dispositivos do Android [Recursos,
27].As implementações de dispositivo PRECISAM fornecer uma implementação da classe
DevicePolicyManager [Resources, 28] e DEVEM oferecer suporte ao

Observação:embora alguns dos requisitos descritos acima sejam "RECOMENDADOS" para
o Android 4.1, a definição de compatibilidade para uma versão futura está planejada para mudar essas
para "OBRIGATÓRIO". Ou seja, esses requisitos são opcionais no Android 4.1, mas serão
necessários em uma versão futura. É recomendado
que os dispositivos atuais e novos com Android 4.1 cumpram esses requisitos, senão eles
não poderão ser compatíveis com o Android quando forem atualizados para a versão futura.
3.10 Acessibilidade
O Android 4.1 oferece uma camada de acessibilidade que ajuda os usuários com deficiência a navegar
nos dispositivos com mais facilidade. Além disso, o Android 4.1 oferece APIs de plataforma que permitem

implementações de serviço de acessibilidade receber cal backs para eventos do usuário e do sistema
e gerar mecanismos de feedback alternativos, como texto para fala, feedback
tátil e navegação com trackball /D-pad [Resources, 29]. Asimplementações do dispositivo
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 requisitos abaixo.
As implementações de dispositivo PRECISAM oferecer suporte a implementações de serviço de acessibilidade de terceiros
por meio das APIs android.accessibilityservice [Resources,
30].
As implementações de dispositivo PRECISAM gerar eventos de acessibilidade e enviá-los
a todas as implementações de AccessibilityService registradas de uma
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 serviços de acessibilidade e PRECISAM exibir essa interface em resposta
à intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
Além disso, as implementações de dispositivo DEVEM fornecer uma implementação de um serviço de acessibilidade
no dispositivo e DEVEM fornecer um mecanismo para que os usuários
ativem o serviço de acessibilidade durante a configuração do dispositivo. Uma implementação
de serviço de acessibilidade de código aberto está disponível no projeto Eyes Free [Resources, 31].
3.11 Conversão de texto em voz
O Android 4.1 inclui APIs que permitem aos apps usar serviços de conversão de texto em voz (TTS, na sigla em inglês) e permitem aos provedores de serviços oferecer implementações de serviços de TTS
[Resources, 32].
As implementações de dispositivo PRECISAM atender aos requisitos relacionados ao
modelo TTS do Android:
As implementações de dispositivo PRECISAM oferecer suporte às APIs do Android TTS e
PRECISAM incluir um motor TTS que ofereça suporte aos idiomas disponíveis no
dispositivo. O software de código aberto do Android upstream inclui uma implementação de mecanismo de TTS com recursos completos.
As implementações de dispositivo precisam oferecer suporte à instalação de mecanismos de TTS de terceiros.
As implementações de dispositivo 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 do empacotamento do aplicativo
As implementações de dispositivos precisam instalar e executar arquivos ".apk" do Android gerados pela ferramenta
"aapt" incluída no SDK oficial do Android [Resources, 33].
As implementações de dispositivos NÃO PODEM estender os formatos .apk [Resources, 34], manifesto do Android
[Resources, 35], bytecode do Dalvik [Resources, 17] ou bytecode do renderscript
de forma a impedir que esses arquivos sejam instalados e executados corretamente
em outros dispositivos compatibiles.As implementações do dispositivo DEVEM 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 multimídia
As implementações do dispositivo PRECISAM incluir pelo menos uma forma de saída de áudio, como
alto-falantes, entrada 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 Android [Recursos, 58], exceto onde explicitamente permitido neste
documento. Especificamente, as implementações de dispositivo 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 Android
preferencial do Android Open Source Project.
O Google nem a Open Handset Alliance fazem qualquer
declaração de que esses codecs estão livres de patentes de terceiros.
Aqueles que pretendem usar esse código-fonte em produtos de hardware ou software são
avisados de que as implementações desse código, incluindo em software de código aberto
ou shareware, podem requerer licenças de patente dos proprietários de patente relevantes.
Essas tabelas não listam requisitos de bitrate específicos para a maioria dos codecs de vídeo
porque o hardware do dispositivo atual não oferece suporte a bitrates que mapeiam
exatamente para os bitrates necessários especificados pelos padrões relevantes. Em vez disso, as implementações
do dispositivo DEVEM oferecer suporte ao maior bitrate possível no hardware, até

os limites definidos pelas especificações.

Tipos de arquivo /
Formato /
Tipo
Codificador
Decodificador
Detalhes
Contêiner
Codec
Formatos
Suporte a
OBRIGATÓRIO
mono/estéreo/5.0/5.1*
MPEG-4
OBRIGATÓRIO para implementações de dispositivo
conteúdo com
Perfil AAC
que incluem hardware de microfone
OBRIGATÓRIO
amostragem padrão
(AAC LC)
e define
3GPP
taxas de 8 a 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
Suporte a
(.mp4,
MPEG-4
mono/stereo/5.0/5.1*
.m4a)
HE AAC
conteúdo com
ADTS raw

OBRIGATÓRIO
Perfil
de amostragem
padrão AAC (.aac,
(AAC+)
taxas de 16 a 48
decodificação em
kHz.
Android
3.1+,
Suporte a
MPEG-4
OBRIGATÓRIO para o dispositivo
codificar em
mono/estéreo/5.0/5.1*
HE AAC v2
implementações que incluem
Android
conteúdo com
Perfil
microfone de hardware e

4.0+, ADIF
amostragem padrão
(
definido
não
taxas de 16 a 48
AAC+
android.hardware.microphone
suportado)
kHz.
MPEG-TS
MPEG-4
(.ts, não
áudio
OBRIGATÓRIO para dispositivo
Suporte para
pesquisável,
implementações de tipo de objeto
que incluem
conteúdo mono/estéreo
Android
ER AAC
microfone de hardware e
OBRIGATÓRIO
com o padrão
3.0+)
ELD
define
taxas de amostragem de
(
android.hardware.microphone
16 a 48 kHz.
Baixo atraso
AAC)
OBRIGATÓRIO
Obrigatório para implementações de dispositivo
4,75 a 12,2 kbps
AMR-NB
que incluem hardware de microfone
OBRIGATÓRIO
3GPP (.3gp)
amostrado a 8 kHz
e define
android.hardware.microphone.
OBRIGATÓRIO
Obrigatório para implementações de dispositivo
9 taxas de 6,60
AMR-WB
que incluem hardware de microfone
OBRIGATÓRIO
kbit/s a 23,85 kbit/s
3GPP (.3gp)
e define
amostragem a 16 kHz
android.hardware.microphone.
Mono/estéreo (sem
multicanal).
Áudio
Taxas de amostragem de até
48 kHz (mas até
44,1 kHz é
recomendado em
dispositivos com 44,1
OBRIGATÓRIO
FLAC

kHz de saída, como o 48
FLAC (.flac) somente
(Android 3.1+)
para 44,1 kHz
redutor não
inclui um filtro passa baixa
.
Recomendado de 16 bits; nenhum
pontilhamento aplicado para 24
bits.
Mono/estéreo 8-
320 Kbps constante
MP3

OBRIGATÓRIO
MP3 (.mp3)
(CBR) ou taxa de bits
variável (VBR)
Tipo 0 e
MIDI Tipo 0 e 1.
1 (.mid,
DLS versão 1 e
.xmf, .mxmf)
2. XMF e Mobile
RTTTL/RTX
MIDI

OBRIGATÓRIO
XMF. Suporte a
(.rtttl, .rtx)
formatos de toque
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
e iMelody
(.imy)

Ogg (.ogg)
Vorbis

REQUIRED

Matroska
(.mkv)
8 e 16 bits
linear PCM** (taxas
até o limite de
hardware).Os dispositivos
PRECISAM oferecer suporte
PCM/WAVE
REQUIRED
REQUIRED
WAVE (.wav)
taxas de amostragem para
gravação PCM não processada
em 8000,16000 e
44100 Hz
frequências
JPEG
REQUIRED
REQUIRED
Base+progressivo
JPEG (.jpg)
GIF

REQUIRED

GIF (.gif)
Imagem
PNG
REQUIRED
REQUIRED

PNG (.png)
BMP

REQUIRED

BMP (.bmp)
WEBP
REQUIRED
REQUIRED

WebP (.webp)
REQUIRED
Obrigatório para implementações de dispositivo
3GPP
que incluem hardware de câmera e
(.3gp)
H.263
REQUIRED

define android.hardware.camera
MPEG-4
ou
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
OBRIGATÓRIO
MPEG-4
(.mp4)
Obrigatório para implementações de dispositivo
MPEG-TS
que incluem hardware de câmera e
Perfil de base
Vídeo
H.264 AVC
OBRIGATÓRIO
(.ts, AAC
define android.hardware.camera
(BP)
somente áudio,
ou
não
android.hardware.camera.front.
buscável,
Android
3.0+)
MPEG-4

OBRIGATÓRIO

3GPP (.3gp)
SP
WebM (.webm)
OBRIGATÓRIO
e Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Observação: somente o downmix de conteúdo 5.0/5.1 é requerido; gravar ou renderizar mais de 2
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
As implementações de dispositivos Android que incluem uma câmera traseira e declaram
android.hardware.camera PRECISAM oferecer suporte aos perfis de codificação de vídeo a seguir.
HD (quando compatível)

hardware)
H.264 Baseline
H.264 Baseline
Codec de vídeo
H.264 Baseline Profile
Profile
Profile
Vídeo
176 x 144 px
480 x 360 px
1280 x 720 px
resolução
Vídeo frame 12 fps
30 fps
30 fps
taxa
500 Kbps ou
taxa de vídeo 56 Kbps
2 Mbps ou mais
mais
Codec de áudio AAC-LC
AAC-LC
AAC-LC

Áudio
1 (mono)
2 (estéreo)
2 (estéreo)
canais
Taxa de áudio 24 Kbps
128 Kbps
192 Kbps
5.3.
Gravação de áudio
Quando um app usa a API android.media.AudioRecord para iniciar a gravação
de um fluxo 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 PRECISA exibir aproximadamente amplitude plana em relação às características
de frequência; específica y, ±3 dB, de 100 Hz a 4000 Hz
A sensibilidade de entrada de áudio PRECISA ser definida de forma que uma fonte de 90 dB de nível de som
(SPL) a 1000 Hz produza RMS de 2500 para amostras de 16 bits.
Os níveis de amplitude PCM PRECISAM rastrear linearmente as mudanças de SPL de entrada em pelo menos um
intervalo de 30 dB de -18 dB a +12 dB re 90 dB SPL no microfone.
A distorção harmônica total PRECISA ser menor do que 1% para 1 kHz a 90 dB de nível de entrada
SPL.
Além das especificações de gravação acima, quando um aplicativo começa a
gravar um stream de áudio usando a
fonte de áudio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
O processamento de redução de ruído, se presente, PRECISA ser desativado.
O controle de ganho automático, se presente, PRECISA ser desativado.
Observação:embora alguns dos requisitos descritos acima sejam "RECOMENDADOS" para
Android 4.1, a definição de compatibilidade para uma versão futura está planejada para mudar esses
para "OBRIGATÓRIO". Ou seja, esses requisitos são opcionais no Android 4.1, mas serão
necessários em uma versão futura. É recomendado
que os dispositivos atuais e novos com Android 4.1 cumpram esses requisitos, senão eles
não poderão ser compatíveis com o Android quando forem atualizados para a versão futura.
5.4. Latência de áudio
A latí¼ncia de áudio é definida de forma geral como o intervalo entre o momento em que um aplicativo solicita
uma operação de reprodução ou gravação de áudio e o momento em que a implementação do dispositivo realmente
inicia a operação. Muitas classes de aplicativos dependem de latí¼ncias curtas para atingir
efeitos em tempo real, como efeitos de som ou comunicação VOIP. As implementações de dispositivo
que incluem hardware de microfone e declaram android.hardware.microphone
PRECISAM atender a todos os requisitos de latência de áudio descritos nesta seção. Consulte a seção 7
para saber mais sobre as condições em que o hardware do microfone pode ser omitido pelas
implementações de dispositivo.
Para os fins desta seção:
"Latência de saída fria" é o intervalo entre o momento em que um aplicativo
solicita a reprodução de áudio e o momento em que o som começa a ser reproduzido, quando o sistema de áudio
está ocioso e desligado antes da solicitação
"Latência de saída quente" é o intervalo entre o momento em que um aplicativo
emitirá um sample para ser reproduzido e o momento em que o alto-falante o reproduzirá
, enquanto o dispositivo estiver reproduzindo áudio
"Latência de entrada fria" é o intervalo entre o momento em que um aplicativo
solicita a gravação de áudio e o momento em que o primeiro sample é enviado ao aplicativo
pela resposta do call back, quando o sistema de áudio e o microfone
estão ociosos e desligados antes da solicitação
"Latência de entrada contínua" é o intervalo entre o momento em que um som ambiente ocorre e
o momento em que o sample correspondente a esse som é enviado a um aplicativo
de gravação pela resposta do call back, enquanto o dispositivo está no modo de gravação
Usando as definições acima, as implementações de dispositivo DEVEM exibir cada uma destas propriedades
:
Latência de saída fria de 100 mil iises ou menos
Latência de saída quente de 10 mil iises ou menos
Latência de saída contínua de 45 mil iises ou menos
Latência de entrada fria de 100 mil iises ou menos
Latência de entrada contínua de 50 mil iises ou menos
Observação:embora os requisitos descritos acima sejam "RECOMENDADOS" para o Android 4.1,

a definição de compatibilidade para uma versão futura está planejada para mudar para "OBRIGATÓRIO".
Ou seja, esses requisitos são opcionais no Android 4.1, mas serão obrigatórios em uma versão futura
.

É recomendado
que os dispositivos novos e existentes com Android 4.1 cumpram esses requisitos no Android 4.1, senão eles não poderão
atingir a compatibilidade do Android quando forem atualizados para a versão futura.
Se uma implementação de dispositivo atender aos requisitos desta seção, ela PODERÁ informar o suporte
ao á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, ele
NÃO
poderá informar suporte para áudio de baixa latência.
5.5. Protocolos de rede
Os dispositivos PRECISAM oferecer suporte aos protocolos de rede de mídia para reprodução de áudio e vídeo, como
especificado na documentação do SDK do Android [Recursos, 58]. Especificamente, os dispositivos
PRECISAM oferecer suporte aos seguintes protocols de rede de mídia:
RTSP (RTP, SDP)
HTTP(S) streaming progressivo
HTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]
6. Compatibilidade com 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 o Android PRECISAM ser compatíveis com:
Android Debug Bridge (conhecida como adb) [Recursos, 33]
As implementações de dispositivos PRECISAM oferecer suporte a todas as funções do adb como documentadas no
SDK do Android. O daemon adb do dispositivo PRECISA estar inativo por padrão, e
PRECISA haver um mecanismo acessível pelo usuário para ativar a Android Debug
Bridge.
Dalvik Debug Monitor Service (conhecido como ddms) [Resources, 33]
As implementações do dispositivo PRECISAM oferecer suporte a todos os recursos ddms, conforme documentado no
SDK do Android. Como o ddms usa o adb, o suporte a ele DEVE estar inativo por
padrão, mas PRECISA ser suportado sempre que o usuário ATIVAR a ponte de depuração do
Android, como acima.
Monkey [Resources, 36]
As implementações do dispositivo PRECISAM incluir o framework Monkey e disponibilizá-lo
para uso deaplicações ou.
A maioria dos sistemas baseados em Linux e os sistemas Apple Macintosh reconhecem dispositivos Android
usando as ferramentas padrão do SDK do 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 como
fornecida no SDK padrão do Android, os implementadores precisam fornecer drivers
do Windows para permitir que os desenvolvedores se conectem ao dispositivo usando o protocolo adb. Esses
drivers PRECISAM ser fornecidos para Windows XP, Windows Vista e Windows 7, nas versões
de 32 e 64 bits.
7. Compatibilidade de hardware
Se um dispositivo inclui um componente de hardware específico que tem uma API correspondente para
desenvolvedores de terceiros, a implementação do dispositivo PRECISA implementar essa API como
descrita na documentação do SDK do Android. Se uma API no SDK interagir com um componente
de hardware que seja declarado como opcional e a implementação do dispositivo não
possuir esse componente:
definições de classe completas (conforme documentado pelo SDK) para as APIs
do componente precisam ainda estar presentes
o comportamento da API PRECISA ser implementado como no-ops de forma razoável
os métodos da API PRECISAM não 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 não smartphones, essas APIs precisam ser implementadas como no-ops razoáveis.

As implementações do dispositivo precisam informar corretamente as informações de configuração do 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.1 inclui facilidades que automaticamente ajustam os recursos do app e os layouts da interface
adequadamente para o dispositivo, para garantir que os apps de terceiros funcionem bem em uma
variedade de configurações de hardware [Resources, 38]. Os dispositivos precisam implementar
corretamente essas APIs e comportamentos, conforme detalhado nesta seção.
As unidades referenciadas pelos requisitos nesta seção são definidas da seguinte forma:
"Tamanho físico diagonal" é a distância em polegadas entre dois cantos opostos
da parte iluminada da tela.
"dpi" (significa "pontos por polegada") é o número de pixels englobados por uma distância linear
horizontal ou vertical de 1". Quando os valores de dpi são listados, o dpi horizontal e
vertical precisam estar dentro do intervalo.
"Proporção" é a relação da dimensão maior da tela com a dimensão
menor. 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 * (densidade / 160).
7.1.1. Configuração da tela
Tamanho da tela
O framework da interface do Android oferece suporte a vários tamanhos de tela diferentes e permite que
aplicativos consultem o tamanho da tela do dispositivo (também conhecido como "layout da tela") por meio de
android.content.res.Configuration.screenLayout com
SCREENLAYOUT_SIZE_MASK. As implementações de dispositivo precisam informar o tamanho
correto da tela, conforme definido na documentação do SDK do Android [Resources, 38] e determinado pela
plataforma upstream do Android. Especificamente, as implementações de dispositivo precisam informar o
tamanho correto da tela de acordo com as seguintes dimensões da tela
densidade-independent de pixel (dp) lógicas.
Os dispositivos PRECISAM ter tamanhos de tela de pelo menos 426 dp x 320 dp ('pequena ')
Os dispositivos que informam tamanho de tela 'normal' PRECISAM ter tamanhos de tela de pelo menos 480
dp x 320 dp
Os dispositivos que informam tamanho de tela 'grande' PRECISAM ter tamanhos de tela de pelo menos 640
dp x 480 dp
Os dispositivos que informam tamanho de tela 'extra grande' PRECISAM ter tamanhos de tela de pelo menos 2, 5 polegadas em tamanho físico diagonal
.

Os dispositivos NÃO PODEM mudar o tamanho da tela informado a qualquer momento.
Os apps opcionalmente indicam os tamanhos de tela com que são compatíveis pelo atributo <supports-
screens> no arquivo AndroidManifest.xml. As implementações de dispositivo
precisam
honrar 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 direcionar os recursos do aplicativo. As implementações de dispositivo
precisam
informar uma das densidades do framework Android lógico
abaixo usando as APIs
android.util.DisplayMetrics e executar aplicativos nessa densidade padrão
.
120 dpi, conhecida como 'ldpi'
160 dpi, conhecida como 'mdpi'
213 dpi, conhecida como 'tvdpi'
240 dpi, conhecida como 'hdpi'
320 dpi, conhecida como 'xhdpi'
480 dpi, conhecida como 'xxhdpi'
As implementações de dispositivos DEVEM definir a densidade padrão do framework Android que
é mais próxima da densidade física da tela, a menos que essa densidade lógica

seja 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
do Android padrão que é numericamente mais próximo à densidade física resultar em um tamanho
da tela menor do que o menor tamanho de tela compatível (320 dp de largura),
as implementações do dispositivo DEVEM informar a próxima densidade do framework
do Android padrão mais baixa.
7.1.2. Métricas de tela
As implementações do dispositivo PRECISAM informar os valores corretos para todas as métricas de tela 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 de dispositivos podem selecionar a orientação
de retrato ou paisagem como padrão.
Os dispositivos PRECISAM informar o valor correto para a orientação atual do dispositivo, sempre
consultado pela 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 paisagem de orientação fixa, como uma televisão ou um laptop, SÓ PRECISA informar
android.hardware.screen.landscape.
7.1.4. Aceleração de gráficos 2D e 3D
As implementações do dispositivo PRECISAM oferecer suporte a ambos os OpenGL ES 1.0 e 2.0, como definido
e detalhado na documentação do SDK Android. As implementações de dispositivo
devem
oferecer suporte ao Renderscript do Android, conforme detalhado na documentação do SDK do Android
[Resources, 8].
As implementações do dispositivo TAMBÉM precisam se identificar corretamente como compatíveis
com o OpenGL ES 1.0 e 2.0. Ou seja:
as APIs gerenciadas (como através do método GLES10.getString()) PRECISAM informar o suporte a
OpenGL ES 1.0 e 2.0
As APIs nativas C/C++ OpenGL (ou seja, aquelas disponíveis para apps através de
libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) PRECISAM informar o suporte a
OpenGL ES 1.0 e 2.0.
As implementações de dispositivos PODEM implementar qualquer extensão OpenGL ES desejada.
No entanto, as implementações de dispositivos PRECISAM informar pelas APIs OpenGL ES gerenciadas e
nativas as strings de extensão às quais elas oferecem suporte. Por outro lado, elas NÃO PODEM informar as strings de extensão que não oferecem suporte.

O Android 4.1 inclui suporte para aplicativos para opcionalmente especificar que eles
requerem formatos de compactação de textura OpenGL específicos. Esses formatos são típicos e específicos do fornecedor.
As implementações de dispositivo não são necessárias para o Android 4.1 implementar
qualquer formato de compactação de textura específico. No entanto, eles DEVEM informar com precisão qualquer
formato de compactação de textura com que eles têm suporte, usando o método getString() na API
OpenGL.
O Android 4.1 inclui um mecanismo para aplicativos declararem que eles queriam
ativar a aceleração de hardware para gráficos 2D no nível do aplicativo, atividade, janela ou
visualização usando uma tag de manifesto android:hardwareAccelerated ou API direta
cal s [Resources, 9].
No Android 4.1, as implementações de dispositivo PRECISAM ativar a aceleração de hardware por
padrão e PRECISAM desativar a aceleração de hardware se o desenvolvedor solicitar isso
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.1 inclui um objeto TextureView que permite que os desenvolvedores integrem diretamente
texturas OpenGL ES aceleradas por hardware como alvos de renderização em uma hierarquia de IU.
As implementações do dispositivo PRECISAM oferecer suporte à API TextureView e PRECISAM exibir

comportamento consistente com a implementação upstream do Android.
7.1.5. Modo de compatibilidade de apps legados
O Android 4.1 especifica um "modo de compatibilidade" em que a estrutura opera em um modo de tamanho de tela
'normal' equivalente (largura de 320 dp) para o benefício de apps
legados não desenvolvidos para versões antigos do Android que antecedem a independência
do tamanho da tela. As implementações de dispositivo precisam incluir suporte ao modo de compatibilidade de aplicativo
legado conforme implementado pelo código de código aberto do Android. Ou seja,
as implementações de dispositivo NÃO PODEM alterar os gatilhos ou limites em que o
modo de compatibilidade é ativado, nem o comportamento do próprio
modo de compatibilidade.
7.1.6. Tipos de tela
As telas de implementação do dispositivo são classificadas como um de dois tipos:
Implementações de tela de pixel fixo: a tela é um único painel que oferece suporte
a apenas uma largura e altura de pixel. Normalmente, a tela é física e integrada
ao dispositivo. Exemplos incluem smartphones, tablets e assim por diante.
Implementações de tela de pixels variáveis: a implementação do dispositivo não tem
tela embutida e inclui uma porta de saída de vídeo como VGA, HDMI ou uma
porta sem fio para tela, ou tem uma tela embutida que pode mudar as dimensões
dos pixels. Exemplos incluem televisões, 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
os seguintes requisitos:
O dispositivo PRECISA informar a mesma configuração de tela e métricas de tela, como
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 idênticas ou muito próximas
às da tela de pixels fixos.
Por exemplo, um tablet com 7" de diagonal e resolução de 1024x600 pixels é
considerado uma implementação de tela mdpi grande de pixels fixos. Se ele contiver uma porta de saída de vídeo
que exiba em 720p ou 1080p, a implementação do dispositivo PRECISA dimensionar a
saída para que os apps sejam executados apenas em uma janela grande mdpi, independente de
a tela de pixels fixos ou a porta de saída de vídeo estar em uso.
Implementações de dispositivo de pixel variável
As implementações de dispositivo de pixel variável precisam oferecer suporte a 1280x720 ou
1920x1080 (ou seja, 720p ou 1080p). As implementações de dispositivo com telas
de pixel variável NÃO PODEM oferecer suporte a nenhuma outra configuração ou modo de tela. As implementações
do dispositivo com telas de pixel variável PODEM mudar a configuração da tela ou o
modo no momento da execução ou da inicialização. Por exemplo, um usuário de uma caixa de TV pode substituir uma tela
720p por uma 1080p, e a implementação do dispositivo pode ser ajustada
de acordo.
Outras implementações de dispositivo 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 dispositivo com dimensões de pixel variáveis são restritas a
720p ou 1080p no Android 4.1 e precisam ser configuradas para informar o tamanho da tela e os
buckets de densidade, conforme observado acima.
7.1.7. Tecnologia de tela
O plataforma Android inclui APIs que permitem a apresentação de gráficos avançados na
tela. Os dispositivos PRECISAM oferecer suporte a todas essas APIs, conforme definido pelo SDK Android
, a menos que seja especificado neste documento. Especificamente:
Os dispositivos PRECISAM oferecer suporte a telas com capacidade de renderização de gráficos em 16 bits e
PRECISAM oferecer suporte a telas com capacidade de gráficos em 24 bits.
Os dispositivos PRECISAM oferecer suporte a telas com capacidade de renderização de animações.
A tecnologia de tela usada PRECISA ter uma proporção de pixel (PAR, na sigla em inglês) entre 0,9

e 1,1. Ou seja, a proporção dos pixels PRECISA estar próxima de quadrada (1,0) com uma tolerância de 10%
.
7.2. Dispositivos de entrada
7.2.1. Teclado
Implementações do dispositivo:
PRECISA incluir suporte ao framework de gerenciamento de entrada (que permite que desarrolladores de terceiros criem motores de gerenciamento de entrada, ou seja, teclas virtuais) conforme
detalhado em http://developer.android.com
PRECISA fornecer pelo menos uma implementação de teclas virtuais (independentemente de se
uma teclas física está presente)
PODE incluir implementações adicionais de teclas virtuais
PODE incluir uma teclas física
NÃO PRECISA incluir uma teclas física que não corresponda a um dos formatos
especificados em android.content.res.Configuration.keyboard [Resources, 40]
(ou seja, QWERTY ou 12 teclas)
7.2.2.
Navegação sem toque
Implementações de dispositivo:
podem omitir uma opção de navegação sem toque (ou seja, podem omitir um trackball, um d-pad ou
roda)
PRECISA informar o valor correto para
android.content.res.Configuration.navigation [Resources, 40]
PRECISA fornecer um mecanismo de interface do usuário alternativo razoável para a
seleção e edição de texto, compatível com mecanismos de gestão de entrada. O
software de código aberto do Android upstream inclui um mecanismo de seleção
adequado para uso com dispositivos que não têm entradas de navegação não por toque.
7.2.3. Teclas de navegação
As funções "Início", "Menu" e "Voltar" são essenciais para o paradigma de navegação
do Android. As implementações de dispositivos precisam disponibilizar essas funções ao usuário
sempre que os aplicativos são executados. Essas funções podem ser implementadas usando
botões físicos específicos (como botões mecânicos ou capacitivos de toque) ou podem
ser implementadas usando teclas de software, gestos, painel de toque etc. O Android
4.1 oferece suporte para ambas as implementações.
O Android 4.1 adicionou suporte à ação de assistência [Resources, 63]. As implementações do
dispositivo PRECISAM disponibilizar a ação de assistência ao usuário sempre que
os apps estão em execução. Essa função PODEM ser implementada por hardware ou software
.
As implementações do dispositivo PODEM usar uma parte distinta da tela para mostrar as teclas de navegação
, mas, se o fizerem, precisam atender a estes requisitos:
As teclas de navegação da implementação do dispositivo PRECISAM usar uma parte distinta da tela
, que não esteja disponível para os aplicativos, e PRECISAM NÃO obscurecer ou
interferir na parte da tela disponível para os aplicativos.
As implementações do dispositivo PRECISAM disponibilizar uma parte da tela para os aplicativos
que atendam aos requisitos definidos na seção 7.1.1.
As implementações do dispositivo 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 do dispositivo PRECISAM apresentar as teclas de navegaçãoem um modo de perfil baixo
(por exemplo, escurecido) não intrusivo 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 <= 10 e NÃO PRECISA apresentar uma chave de menu quando a
targetSdkVersion > 10.
As implementações de dispositivo PRECISAM disponibilizar uma parte da tela para
aplicativos que atendam aos requisitos definidos na seção 7.1.1.
7.2.4.Entrada de tela touch
As implementações de dispositivo PRECISAM ter um sistema de entrada de ponteiro de algum tipo (
semelhante a um mouse ou toque). No entanto, se uma implementação de dispositivo não oferecer suporte a um sistema de entrada
de ponteiro, ele NÃO PRECISA informar a constante de recurso android.hardware.touchscreen ou
android.hardware.faketouch. As implementações de dispositivo que

incluem um sistema de entrada de indicador:
DEVE oferecer suporte a indicadores rastreados independentemente, se o sistema de entrada do dispositivo
oferecer suporte a vários indicadores
DEVE informar o valor de android.content.res.Configuration.touchscreen
[Resources, 40] correspondendo ao tipo da tela touch específica no
dispositivo
O Android 4.0 oferece suporte a vários tipos de telas touch, touchpads e dispositivos de entrada
falsos. As implementações de dispositivo baseadas em tela sensível ao toque são associadas a uma
tela [Resources, 71] de forma que o usuário tenha a impressão de manipular diretamente os itens
na tela. Como o usuário toca diretamente na tela, o sistema não
requer nenhum affordance adicional para indicar os objetos que estão sendo manipulados. Em
contraste, uma interface de toque simulada oferece um sistema de entrada do usuário que aproxima-se de
um subconjunto de recursos de tela touch. Por exemplo, um mouse ou controle remoto que aciona
um cursor na tela se aproxima do toque, mas requer que o usuário primeiro aponte ou foco
e depois clique. Vários dispositivos de entrada como mouse, trackpad, mouse aéreo baseado em giroscópio,
ponteiro de giroscópio, joystick e trackpad multitoque podem oferecer interações de toque falso.
O Android 4.0 inclui a constante de recurso android.hardware.faketouch, que
corresponde a um dispositivo de entrada de alta fidelidade sem toque (ou seja, baseado em ponteiro) como um
mouse ou trackpad que pode emular adequadamente a entrada por toque (incluindo suporte a gesto
básico) e indica que o dispositivo oferece um subconjunto emulado de
funcionalidade de tela sensível ao toque. As implementações de dispositivo que declaram o recurso de toque falso
PRECISAM atender aos requisitos de toque falso na Seção 7.2.5.
As implementações de dispositivos precisam informar o recurso correto correspondente ao tipo de entrada
usada. As implementações de dispositivos que incluem uma tela touchscreen (single-touch ou melhor)
PRECISAM informar a constante do recurso da plataforma android.hardware.touchscreen. As implementações de
dispositivos que informam a constante de recurso da plataforma
android.hardware.touchscreen TAMBÉM PRECISAM informar a constante de recurso da plataforma
android.hardware.faketouch. As implementações de dispositivo que não incluem uma tela touchscreen
(e dependem apenas de um dispositivo de ponteiro) NÃO DEVEM relatar nenhum recurso
de tela touchscreen e DEVEM relatar apenas android.hardware.faketouch se atendem aos requisitos de toque
da seção 7.2.5.
7.2.5.Fake touch inp ut
As implementações de dispositivo que declaram suporte para android.hardware.faketouch
PRECISAM informar as posições absolutas X e Y da tela da localização do ponteiro e
exibir um ponteiro visual na tela[Resources, 70]
PRECISAM informar o evento de toque com o código de ação [Resources, 70] que especifica a
mudança de estado que ocorre no ponteiro going down ou up na tela
[Resources, 70]
PRECISAM oferecer suporte ao ponteiro para baixo e para cima em um objeto na tela, o que permite
que os usuários emulem o toque duplo em um objeto na tela
PRECISAM oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo
local em um objeto na tela dentro de um limite de tempo, o que permite
que os usuários emulem o toque duplo em um objeto na tela [Resources, 70]
PRECISAM oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo
local em um objeto na tela dentro de um limite de tempo, o que permite
que os usuários emulem o toque duplo em um objeto na tela [Resources, 70]
PRECISAM oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo
local em um objeto na tela dentro de um limite de tempo, o que permite
que os usuários emulem o toque duplo em um objeto na tela [Resources, 70]
PRECISAM oferecer suporte ao ponteiro para baixo, para cima, para baixo e para cima no mesmo
local em um objeto na tela dentro de um limite de tempo, o que permite
que os usuários emulem o toque duplo em um objeto na tela
Dispositivos que declaram suporte para android.hardware.faketouch.multitouch.distinct
PRECISAM atender aos requisitos para faketouch acima e também precisam oferecer suporte ao rastreamento
distinto de duas ou mais entradas de ponteiro independentes.
7.2.6. Microfone
As implementações do dispositivo podem omitir um microfone. No entanto, se uma implementação de dispositivo
omitir um microfone, ELA NÃO PRECISA informar a constante do recurso android.hardware.microphone
, e precisa implementar a API de gravação de áudio como no-ops, conforme a Seção 7.
Por outro lado, implementações de dispositivo que possuem um microfone:
PRECISAM informar a constante do recurso android.hardware.microphone
, E PRECISAM atender os requisitos de qualidade de áudio na Seção 5.4
, E PRECISAM atender os requisitos de latentez de áudio na Seção 5.5
7.3. Sensores

O Android 4.1 inclui APIs para acessar vários tipos de sensor. As implementações de
dispositivos podem omitir esses sensores, conforme descrito nas
subseções a seguir. Se um dispositivo incluir um tipo de sensor específico que tenha uma API
correspondente para desenvolvedores de terceiros, a implementação do dispositivo PRECISA implementar essa API conforme
descrito na documentação do SDK do Android. Por exemplo, implementações de dispositivo:
PRECISAM informar com precisão a presença ou ausência de sensores de acordo com a
classe android.content.pm.PackageManager. [Resources, 37]
PRECISA retornar uma lista precisa de sensores com suporte pelo
SensorManager.getSensorList() e métodos semelhantes
PRECISA se comportar razoavelmente para todas as outras APIs de sensor (por exemplo, retornando true
ou false conforme adequado quando os aplicativos tentarem registrar listeners, não cal ing
sensor listeners quando os sensores correspondentes não estiverem presentes; etc.)
PRECISA relatar todas as medições de sensor usando o Sistema Internacional de Unidades
(ou seja, métrica) relevante para cada tipo de sensor conforme definido na documentação do SDK Android
[Resources, 41]
A lista acima não é completa; o comportamento documentado do SDK Android é
considerado autorizado.
Alguns tipos de sensores são sintéticos, ou seja, podem ser derivados de dados fornecidos por
um ou mais outros sensores. (Exemplos incluem o sensor de orientação e o sensor de aceleração
linear.) As implementações de dispositivos DEVEM implementar esses tipos de sensor
quando incluem os sensores físicos necessários.
As APIs do Android 4.1 introduzem o conceito de um sensor de "streaming", que
retorna dados contínuos, 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.1 como um sensor de streaming.
7.3.1. Acelerômetro
As implementações do dispositivo DEVEM incluir um acelerômetro de três eixos. Se uma implementação
do dispositivo incluir um acelerômetro de três eixos, ela:
PRECISA ser capaz de enviar eventos a 120 Hz ou mais. A frequência do
sensor de aceleração
acima é definida como "SHOULD" para o Android 4.1. No entanto, 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.1, mas serão
necessários em versões futuras. É
recomendado que os dispositivos existentes e novos que executam o Android 4.1 atendem a esses requisitos no Android 4.1 para que eles possam ser atualizados para as versões futuras da plataforma
DEVE 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 medir de queda livre até o dobro da gravidade (2g) ou mais em
qualquer vetor tridimensionalal
DEVE ter 8 bits de precisão ou mais
DEVE ter uma desvio padrão não maior que 0,05 m/s^2
7.3.2.
Magnetômetro
As implementações do dispositivo DEVEM incluir um magnetômetro de três eixos (ou seja, uma bússola). Se um
dispositivo incluir um magnetômetro de 3 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]).
PRECISA ser capaz de amostrar um intervalo de intensidades de campo adequado para cobrir o
campo geomagnético
PRECISA ter 8 bits de precisão ou maise
PRECISA ter uma desvio padrão não maior que 0,5 µT
7.3.3. GPS
As implementações de dispositivos DEVEM incluir um receptor de GPS. Se uma implementação de dispositivo
incluir um receptor de GPS, ela DEVE 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 do dispositivo DEVEM 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 esteja incluído.
Se uma implementação de dispositivo incluir um giroscópio, ele:

PRECISA ser compensado pela temperatura
PRECISA ser capaz de medir mudanças de orientação até 5,5*Pi
radianos/segundo (ou aproximadamente 1.000 graus por segundo)
PRECISA ser capaz de enviar eventos a 200 Hz ou mais. A frequência do giroscópio
acima é definida como "SHOULD" para o Android 4.1, mas a definição de compatibilidade
para uma versão futura será alterada para
"MUST". Ou seja, esses padrões são opcionais no Android 4.1, mas serão
necessários em versões futuras. É
recomendado que os dispositivos existentes e novos que executam o Android 4.1 cumpram esses requisitos no Android 4.1 para
que possam fazer upgrade para as versões futuras da plataforma
PRECISAM ter 12 bits de precisão ou mais
PRECISAM ter uma variância não maior 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 variância do giroscópio
com uma taxa de amostragem de 1 Hz, ela não poderá ser maior do que 1e-7 rad^2/s^2.
PRECISA ter carimbos de data o mais próximos possível do evento de hardware que ocorreu
. A latência constante precisa ser removida.
7.3.5. Barômetro
As implementações do dispositivo PODEM incluir um barômetro (ou seja, um sensor de pressão atmosférica 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 da altitude
PRECISA ser compensado pela temperatura
7.3.7. Termômetro
As implementações do dispositivo PODEM, mas NÃO DEVEM incluir um termômetro (por exemplo,
sensor de temperatura). Se uma implementação de dispositivo incluir um termômetro, ela PRECISA
medir a temperatura da CPU do dispositivo. Ele NÃO DEVE medir nenhuma outra
temperatura. Observação: esse tipo de sensor foi descontinuado nas APIs do Android 4.1.
7.3.7. Fotometro
As implementações do dispositivo PODEM incluir um fotometro (ou seja, um sensor de luz ambiente).
7.3.8. Sensor de proximidade
As implementações do dispositivo podem incluir um sensor de proximidade. Se uma implementação de dispositivo
incluir um sensor de proximidade, ela 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 intent principal deste 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
do 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.1 e este documento se refere especificamente a
hardware relacionado a fazer chamadas de voz e enviar mensagens SMS por uma rede GSM ou
CDMA. Embora essas ligações de voz possam ou não ser comutadas por pacotes, elas são
para os fins do Android 4.1 consideradas independentes de qualquer conexão 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 dispositivo
que não podem fazer chamadas ou enviar/receber mensagens SMS NÃO DEVEM
relatar o recurso "android.hardware.telephony" ou qualquer subrecurso, independente de
se eles usam uma rede celular para conectividade de dados.
O Android 4.1 pode ser usado em dispositivos que não incluem hardware de telefonia. Ou seja,
o Android 4.1 é compatível com dispositivos que não são telefones. No entanto, se uma implementação
do dispositivo incluir telefonia GSM ou CDMA, ela PRECISA implementar o suporte
para a API dessa tecnologia. As implementações de dispositivo que não incluem hardware de telefonia
PRECISAM implementar as APIs como sem operações.
7.4.2. IEEE 802.11 (Wi-Fi)
As implementações de dispositivos Android 4.1 DEVEM incluir suporte a uma ou mais formas
de 802.11 (b/g/a/n, etc.) Se uma implementação de dispositivo incluir suporte ao 802.11, ela
PRECISA implementar a API Android correspondente.

As implementações de dispositivos PRECISAM implementar a API multicast conforme descrito na documentação do SDK
[Recursos, 62]. As implementações de dispositivos que incluem suporte a Wi-Fi
DEVEM oferecer suporte a DNS multicast (mDNS). As implementações de dispositivo NÃO PODEM filtrar pacotes mDNS
(224.0.0.251) a qualquer 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 DEVEM incluir suporte para Wi-Fi Direct (Wi-Fi peer-to-peer). 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 oferecer suporte ao Wi-Fi Direct, ela deve:
TER suporte à operação regular de Wi-Fi
DEVE oferecer suporte a operação simultânea de Wi-Fi e Wi-Fi Direct
7.4.3. Bluetooth
As implementações de dispositivos precisam incluir um transceptor Bluetooth. As implementações
do dispositivo que incluem um transmissor-receptor Bluetooth PRECISAM ativar a API Bluetooth baseada em RFCOMM-
, conforme descrito na documentação do SDK [Recursos, 42]. As implementações
do dispositivo DEVEM implementar os perfis Bluetooth relevantes, como A2DP,
AVRCP, OBEX, etc. conforme adequado para o dispositivo.
O pacote 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 testado completamente 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
manual descrito no Apêndice A.
7.4.4. Comunicação a curta distância
As implementações de dispositivos DEVEM incluir um transmissor-receptor e hardware relacionado para
Comunicação a curta distância (NFC). Se uma implementação de dispositivo incluir hardware
NFC, ela deve:
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 através dos seguintes padrões de NFC
standards:
PRECISA ser capaz de agir como um leitor/gravador do NFC Forum (conforme definido pela
especificação técnica do NFC Forum NFCForum-TS-DigitalProtocol-1.0)
através dos 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, 4 (definidos pelo NFC Forum)
PRECISA ser capaz de ler e gravar mensagens NDEF através dos seguintes
padrões de NFC. Observe que, embora os padrões de NFC abaixo sejam definidos como
"SHOULD" para o Android 4.1, a definição de compatibilidade para uma versão futura é
planejada para mudar para "MUST". Ou seja, esses padrões são opcionais no
Android 4.1 mas serão necessários em versões futuras. É recomendado que os dispositivos
existentes e novos que executam o Android 4.1 cumpram esses
requisitos no Android 4.1 para que possam fazer upgrade para as versões futuras da
plataforma.
O NfcV (ISO 15693)
PRECISA ser capaz de transmitir e receber dados através dos seguintes padrões e protocolos peer-to-
peer:
ISO 18092
LLCP 1.0 (definido pelo NFC Forum)
SDP 1.0 (definido pelo NFC Forum)
Protocolo de envio NDEF [Resources, 43]
SNEP 1.0 (definido pelo NFC Forum)
PRECISA incluir suporte ao Android Beam [Resources, 65]:
PRECISA implementar o servidor padrão SNEP. As mensagens NDEF válidas
recebidas pelo servidor SNEP padrão precisam ser enviadas aos aplicativos
usando a intent android.nfc.ACTION_NDEF_DISCOVERED. A desativação
do Android Beam nas configurações NÃO pode desabilitar o envio de mensagens NDEF
entrantes.
As implementações do dispositivo precisam respeitar a intent
android.settings.NFCSHARING_SETTINGS para mostrar o compartilhamento de NFC

configurações [Resources, 67].
PRECISA implementar o servidor NPP. As mensagens recebidas pelo servidor NPP
PRECISAMENTE precisam ser processadas da mesma forma que o servidor padrão do SNEP.
PRECISAMENTE precisa implementar um cliente SNEP e tentar enviar P2P NDEF
de saída para o servidor padrão do SNEP 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 atividades em primeiro plano definam a mensagem P2P NDEF de saída
usando android.nfc.NfcAdapter.setNdefPushMessage, e
android.nfc.NfcAdapter.setNdefPushMessageCal back, e
android.nfc.NfcAdapter.enableForegroundNdefPush.
É NECESSÁRIO usar um gesto ou uma confirmação na tela, como "Toque para
enviar", antes de enviar mensagens P2P NDEF de saída.
É NECESSÁRIO ativar o Android Beam por padrão
para suportar a transferência de conexão NFC para Bluetooth quando o dispositivo
oferecer 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 as especificações
"Transferência de conexão versão 1.2" [Resources, 60] e "Pareamento seguro
simples do Bluetooth usando NFC versão 1.0" [Resources, 61] do
Fórum NFC. Essa implementação de SCHOULD usa solicitações SNEP GET
para trocar o registro de solicitação de transferência / seleção por NFC. Além disso, ela
PRECISA usar o perfil de envio de objeto Bluetooth para a transferência real de dados por Bluetooth
.
É OBRIGATÓRIO usar pol para todas as tecnologias com suporte enquanto o dispositivo estiver 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 em MIFARE Classic (NXP AN1 30511 [Resources, 48], AN130411
[Resources, 49])
Observe que o Android 4.1 inclui APIs para esses tipos de MIFARE. Se uma implementação
do dispositivo oferecer suporte a MIFARE no papel de leitor/gravador, ela:
PRECISA implementar as APIs Android correspondentes, conforme documentado pelo
SDK Android
PRECISA informar o recurso com.nxp.mifare do
método android.content.pm.PackageManager.hasSystemFeature().
[Resources, 37] Observe que este não é um recurso padrão do Android e, como tal,
não aparece como uma constante na classe PackageManager.
NÃO É NECESSÁRIO implementar as APIs do Android correspondentes nem relatar o recurso
com.nxp.mifare, a menos que ele também implemente o suporte geral a NFC conforme
descrito nesta seção
Se uma implementação de dispositivo não incluir hardware NFC, ele NÃO PRECISA declarar o recurso
android.hardware.nfc do
método android.content.pm.hasSystemFeature() [Resources, 37].

Como as classes android.nfc.NdefMessage e android.nfc.NdefRecord r epresentam um formato de representação de dados independente do protocolo
, as implementações de dispositivo PRECISAM
implementar essas APIs, mesmo que elas não incluam suporte a NFC ou declarem 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 dispositivo PRECISAM incluir suporte a 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 DEVEM também incluir suporte a pelo menos um padrão de dados
sem fio comum, como 802.11 (WiFi).
Os dispositivos PODEM implementar mais de uma forma de conectividade de dados.

7.5. Câmeras
As implementações de dispositivos DEVEM 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 imagem do usuário, como para
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 ou foco automático de hardware, ou foco automático de software implementado
no driver da câmera (transparente para o software do aplicativo)
PODE ter foco fixo ou EDOF (profundidade de campo estendida) de hardware
PODE incluir um flash. Se a câmera incluir um flash, ele NÃO DEVE estar
aceso enquanto uma instância de android.hardware.Camera.PreviewCal for
registrada em uma superfície de visualização da câmera, a menos que o aplicativo tenha explicitamente
ativado 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
app 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 do dispositivo PODEM incluir uma câmera frontal. Se uma implementação de dispositivo
incluir uma câmera frontal, ela:
PRECISA ter uma resolução de pelo menos VGA (ou seja, 640x480 pixels)
NÃO PRECISA usar uma câmera frontal como padrão para a API Camera. Ou seja,
a API da câmera no Android 4.1 tem suporte específico para câmeras frontais, e
as implementações do dispositivo NÃO PRECISAM configurar a API para tratar uma câmera frontal
como a câmera traseira padrão, mesmo se ela for a única câmera no
dispositivo.
PODE incluir recursos (como foco automático, flash etc.) disponíveis para câmeras traseiras
conforme descrito na Seção 7.5.1.
PRECISA refletir horizontalmente (ou espelhar) o stream exibido por um app em uma
CameraPreview, conforme a seguir:
Se a implementação do dispositivo puder ser girando pelo usuário (como
automático y via um sensor de aceleração ou manual y via entrada do usuário), a visualização da câmera
PRECISA ser espelhada horizontalmente y em relação à orientação
atual do dispositivo.
Se o atual app pediu explicitamente que a exibição da câmera
fosse girando por um cal  para o
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
método, a visualização da câmera PRECISA ser espelhada horizontalmente y 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.A
PRECISA refletir a imagem exibida pela postview da mesma maneira que o
stream de imagem de visualização da câmera. (Se a implementação do dispositivo não oferecer suporte a
postview, este requisito não se aplica.)
NÃO É PERMITIDO espelhar a imagem ou o fluxo de vídeo final capturado retornado ao
aplicativo cal backs ou compactado no armazenamento de mídia
7.5.3. Comportamento da API da câmera
As implementações de dispositivos PRECISAM implementar os seguintes comportamentos para as APIs relacionadas à câmera
, tanto para câmeras frontais quanto para câmeras traseiras:
1.  Se um app nunca cal ed
android.hardware.Camera.Parameters.setPreviewFormat(int), o
dispositivo PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados
de pré-visualização fornecidos a calbacks do app.
2.  Se um app registrar uma instância android.hardware.Camera.PreviewCallback
e o sistema chama o método onPreviewFrame() quando o formato de prévia
é YCbCr_420_SP, os dados no byte[] transmitidos para onPreviewFrame()
precisam estar no formato de codificação NV21. Ou seja, NV21 PRECISA ser o padrão.
3.  As implementações de dispositivos precisam oferecer suporte ao formato YV12 (conforme indicado pela constante

android.graphics.ImageFormat.YV12) para visualizações de câmera para as câmeras
frontal e traseira. O decodificador de vídeo do hardware e a câmera podem
usar qualquer formato de pixel nativo, mas a implementação do dispositivo PRECISA oferecer suporte à
conversão para YV12.
As implementações de dispositivo PRECISAM implementar a API Camera completa incluída na documentação do SDK do Android
4.1 [Resources, 51]), independentemente de o dispositivo incluir autofoco
de hardware ou outros recursos. Por exemplo, câmeras que não têm foco automático
PRECISAM ainda 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. Observe
que isso não se aplica a câmeras frontais. Por exemplo, mesmo que a maioria das câmeras
frontais não ofereça suporte ao foco automático, as APIs precisam ser "falsas", conforme
descrito.
As implementações do dispositivo PRECISAM reconhecer e honrar cada nome de parâmetro definido como
uma constante na classe android.hardware.Camera.Parameters, se o hardware
de suporte 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 dispositivo
NÃO DEVEM
honrar ou reconhecer constantes de string transmitidas ao
método android.hardware.Camera.setParameters() diferentes daquelas documentadas como constantes
no android.hardware.Camera.Parameters. Ou seja, as implementações
do dispositivo PRECISAM oferecer suporte a todos os parâmetros padrão da câmera se o hardware
oferecer, e NÃO PRECISAM oferecer suporte a tipos de parâmetros personalizados da câmera.
As implementações de dispositivos precisam transmitir a intent Camera.ACTION_NEW_PICTURE
sempre que uma nova foto é tirada pela câmera e a entrada da foto foi
adicionada à loja de mídia.
As implementações de dispositivo 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 alinha à dimensão longa da tela. Ou seja, quando o
dispositivo é mantido 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, ele se aplica a dispositivos com paisagem principal e com retrato principal.
7.6. Memória e armazenamento
7.6.1. Memória mínima e armazenamento
As implementações do dispositivo 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 adicionais à 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 dispositivo 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 apps 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 "cache" padrão.
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 o armazenamento compartilhado montado por padrão,
"fora da caixa". Se o armazenamento compartilhado não for montado no caminho /sdcard do Linux,
o dispositivo PRECISA incluir um link simbólico do Linux de /sdcard ao 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
armazenamento interno (não removível) como armazenamento compartilhado para apps.

Independentemente da forma de armazenamento compartilhado usada, as implementações de dispositivos DEVEM
oferecer algum mecanismo para acessar o conteúdo do armazenamento compartilhado de um
computador host, como armazenamento em massa USB (UMS, na sigla em inglês) ou protocolo de transferência de mídia (MTP).
As implementações de dispositivos PODEM usar o armazenamento em massa USB, mas DEVEM 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 DEVE ser compatível com o host MTP de referência do Android
, a transferência de arquivos do Android [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
acesso ao conteúdo do armazenamento compartilhado por outros meios, como um sistema de arquivos
de rede.
É il ustrativo considerar dois exemplos comuns. Se uma implementação de dispositivo incluir
uma fenda para cartão SD para satisfazer o requisito de armazenamento compartilhado, um cartão SD formatado em 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 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 local).
As implementações de dispositivos que incluem vários caminhos de armazenamento compartilhado (como uma
fenda para cartão SD e armazenamento interno compartilhado) DEVEM modificar os aplicativos principais, como
o leitor de mídia e o ContentProvider, para oferecer suporte transparente a arquivos colocados em ambos os
locais.
7.7. USB
As implementações de dispositivos DEVEM 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 form factor micro USB no lado do dispositivo.É aconselhável
que os dispositivos existentes e novos que executam o Android 4.1 cumpram
esses requisitos no Android 4.1 para que eles possam fazer upgrade para as versões futuras da plataforma
.
O puerto DEVE estar centralizado no meio de uma borda. As implementações do dispositivo
DEVEM localizar a porta na parte inferior do dispositivo (de acordo com a orientação
natural) ou ativar a rotação da tela do software para todos os apps (incluindo a tela
inicial), para que a tela seja exibida corretamente quando o dispositivo estiver orientado com a
porta na parte inferior. É
recomendado
que os dispositivos atuais e novos que executam o Android 4.1 cumpram
esses requisitos no Android 4.1 para que
possam ser atualizados para versões futuras da plataforma
Se uma implementação de dispositivo inclui uma porta host USB:
ela PODE usar um fator de forma de porta não padrão, mas, se assim for, deve ser enviado com um cabo ou
cabos que adaptem a porta ao padrão USB-A
É OBRIGATÓRIO implementar a API host USB do Android conforme documentado na documentação do Android
SDK, e É OBRIGATÓRIO declarar suporte para o recurso de hardware
android.hardware.usb.host [Resources, 53]
As implementações de dispositivo PRECISAM implementar a ponte de depuração do Android.

Se uma implementação
do dispositivo omitir uma porta de cliente USB, ela PRECISA implementar a Android Debug Bridge
via rede de área local (como Ethernet ou 802.11)

8. Compatibilidade de desempenho
As implementações de dispositivos precisam atender às principais métricas de desempenho de um dispositivo
compatível com o Android 4.1 definido na tabela abaixo:
Métrica
Limite de desempenho
Comentários
Os aplicativos a seguir
precisam ser iniciados dentro do tempo
especificado.
O tempo de inicialização é medido como o
tempo total para concluir o carregamento do
Navegador: menos do que
atividade padrão para o aplicativo,
Aplicativo
1300ms
incluindo o tempo necessário para iniciar o
Tempo de inicialização
Contatos: menos do que
Processo Linux, carregue o pacote Android
700ms
na VM Dalvik e cal
Configurações: menos do que
onCreate.
700ms
Quando vários aplicativos
forem iniciados, re
iniciar um aplicativo
simultâneo
em execução após ele

for iniciado precisa
levar menos tempo do 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 do
dispositivo PRECISAM oferecer suporte à instalação de aplicativos autoassinados sem
requerer nenhuma outra permissão/certificado de terceiros/autoridades.
Especificamente, os dispositivos compatíveis PRECISAM oferecer suporte aos mecanismos de segurança descritos nas
subseções a seguir.
9.1. Permissões
As implementações de dispositivos precisam oferecer suporte ao modelo de permissões do Android, conforme definido na
documentação para desenvolvedores do Android [Resources, 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 permissões
adicionais, desde que as novas strings de ID de permissão não estejam no namespace android.*
.
9.2. UID e isolamento de processos
As implementações de dispositivos PRECISAM oferecer suporte ao modelo de sandbox de aplicativos Android,
em que cada aplicativo é executado como um UID exclusivo 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 do dispositivo 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 aplicativos
usando 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.
Não é permitido que ambientes de execução alternativos tenham 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 restritos 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 DEVEM instalar apps usando o PackageManager em sandboxes
Android separadas (ou seja, IDs de usuário do Linux, etc.)
Os ambientes de execução alternativos podem fornecer um único sandbox do Android compartilhado por
aplicativos usando o ambiente de execução alternativo
Os ambientes de execução alternativos e os aplicativos instalados usando um ambiente de execução alternativo NÃO DEVEM reutilizar o sandbox de nenhum outro app instalado no dispositivo, exceto pelos
mecanismos padrão do Android de ID de usuário compartilhado e certificado de assinatura
Os ambientes de execução alternativos NÃO DEVEM ser iniciados com, conceder ou receber acesso a nenhum
sandbox correspondente a outros aplicativos Android
Os ambientes de execução alternativos NÃO DEVEM ser iniciados com, conceder ou receber acesso a nenhum
aplicativo com nenhum privilégio do superusuário (raiz) ou de nenhum 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, as runtimes alternativas 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 há uma permissão do Android correspondente (como
a câmera, o 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 que use esse ambiente.
10. Testes 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 é completo. Por esse motivo,
os implementadores de dispositivos são fortemente incentivados a fazer o menor número de
mudanças possível na implementação de referência e preferencial do Android 4.1
disponível no Android Open Source Project. Isso minimiza 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 do dispositivo precisam ser aprovadas no conjunto de teste de compatibilidade do Android (CTS)
[Resources, 2] disponível no projeto de código aberto do Android, usando o software
final de envio no dispositivo. Além disso, os implementadores de dispositivos DEVEM usar a
referencialimplementação na árvore do Android Open Source o máximo possível e
PRECISAM garantir a compatibilidade em casos de ambiguidade no CTS e em qualquer
reimplementação de partes do código-fonte de referência.
O CTS é projetado para ser executado em um dispositivo real. Como qualquer software,
o CTS pode conter bugs. O CTS será versado independentemente desta definição
de compatibilidade, e várias revisões do CTS podem ser lançadas para o Android 4.1. As implementações
do dispositivo 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 verificador do CTS
. O verificador do CTS é 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 que
são opcionais. As implementações de dispositivo PRECISAM ser aprovadas em todos os testes de hardware que
possuem. Por exemplo, se um dispositivo tiver um acelerômetro, ele PRECISA executar corretamente
o caso de teste do acelerômetro no verificador do CTS. Os casos de teste para recursos indicados
como opcionais neste documento de definição de compatibilidade podem ser ignorados ou omitidos.
Todos os dispositivos e builds precisam executar corretamente o Verificador do CTS, conforme observado acima.
No entanto, como muitos builds são muito semelhantes, não é esperado que os implementadores de dispositivos
executem explicitamente o Verificador do CTS em builds que diferem apenas de maneiras triviais. Especificamente,
implementações de dispositivo que diferem de uma implementação que passou pelo 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 devem testar a compatibilidade da implementação usando os seguintes aplicativos de código aberto
:
Os aplicativos "Apps para Android" [Refontes, 55]
Replica Island (disponível no Android Market)
Cada aplicativo acima PRECISA ser iniciado e comportar-se corretamente na implementação para que a
implementação seja considerada compatível.
11. Software atuável
As implementações do dispositivo PRECISAM incluir um mecanismo para substituir o sistema
inteiro do software. O mecanismo não precisa realizar upgrades "ao vivo", ou seja, pode ser necessário reiniciar o dispositivo
.
Qualquer método pode ser usado, desde que substitua todo o software
pré-instalado no dispositivo. Por exemplo, qualquer uma das seguintes abordagens vai satisfazer
este 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 reinicialização e atualização de um arquivo em 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 da
vida útil razoável do produto determinada em consulta com a equipe de compatibilidade
do Android para afetar a compatibilidade de apps de terceiros, o implementador
do dispositivo PRECISA corrigir o erro usando uma atualização de software disponível que possa ser
aplicada de acordo com o mecanismo descrito.
12. Entre em contato com nós
Entre em contato com os autores do documento em compatibility@android.com para esclarecimentos
e para discutir qualquer problema que você acredite que o documento não abrange.

Apêndice A - Procedimento de teste de Bluetooth
O pacote de testes de compatibilidade inclui casos que abrangem a operação básica da API Bluetooth RFCOMM
. No entanto, como o Bluetooth é um protocolo de comunicações
entre dispositivos, ele não pode ser testado completamente por testes de unidade executados em um único dispositivo.
Consequentemente, as implementações de dispositivos PRECISAM também passar pelo procedimento de teste Bluetooth
operado por humanos descrito abaixo.
O procedimento de teste é baseado no app de exemplo BluetoothChat incluído na árvore de projetos de código aberto do Android
. O procedimento requer dois dispositivos:
uma implementação de dispositivo candidato que executa o build de software a ser testado
uma implementação de dispositivo separada que já é compatível e de um
modelo da implementação de dispositivo a ser testada - ou seja, uma implementação de dispositivo
"funcionando" corretamente
O procedimento de teste abaixo se refere a esses dispositivos como "candidato" e "
funcionando" corretamente, respectivamente.
Configuração e instalação
1.  Crie BluetoothChat.apk usando 'make samples' de uma árvore de código de fonte do Android
2.  Instale  BluetoothChat.apk no dispositivo conhecido como bom
3.  Instale  BluetoothChat.apk no dispositivo candidato
Teste o controle do Bluetooth por apps
1.  Inicie o BluetoothChat no dispositivo candidato enquanto o Bluetooth está desativado
2.  Verifique se o dispositivo candidato ativa o Bluetooth ou solicita ao usuário
uma caixa de diálogo para ativar o Bluetooth
Teste o pareamento e a comunicação
1.  Abra o app Chat por Bluetooth nos dois dispositivos
2.  Deixe o dispositivo conhecido como detectável no BluetoothChat (usando o
Menu)
3.  No dispositivo candidato, procure dispositivos Bluetooth no BluetoothChat
(usando o Menu) e pareie com o dispositivo confiável
4.  Envie 10 ou mais mensagens de cada dispositivo e verifique se o outro dispositivo
as recebe corretamente
5.  Feche o app BluetoothChat em ambos os dispositivos pressionando Home
6.  Desemparelhe cada dispositivo do outro, usando o app Configurações do dispositivo
Teste o emparelhamento e a comunicação na direção invertida
Direcional
1.  Abra o app Chat por Bluetooth nos dois dispositivos.
2.  Deixe o dispositivo candidato detectável em BluetoothChat (usando o
Menu).
3.  No dispositivo conhecido, procure dispositivos Bluetooth no BluetoothChat
(usando o Menu) e pareie com o dispositivo indicado.
4.  Envie 10 ou mensagens de cada dispositivo e verifique se o outro dispositivo
as recebe corretamente.
5.  Feche o app Bluetooth Chat em ambos os dispositivos pressionando "Voltar" repetidamente para
acessar a tela de início.
Teste de reinicializações
1.  Reinicie o app Chat por Bluetooth nos dois dispositivos.
2.  Envie 10 ou mensagens de cada dispositivo e verifique se o outro dispositivo
as recebe corretamente.
Observação: os testes acima têm alguns casos que terminam uma seção de teste usando "Início" e
alguns usando "Voltar". Esses testes não são redundantes e não são opcionais: o objetivo é
verificar se a API e a pilha Bluetooth funcionam corretamente tanto quando as atividades são
encerradas explicitamente (pelo usuário pressionando "Voltar", que é chamado de finish()) quanto enviados implicitamente
para segundo plano (pelo usuário pressionando "Início"). Cada sequência de teste PRECISA ser realizada
conforme descrito.