Esta página foi traduzida pela API Cloud Translation.

Definição de compatibilidade do Android 1.6

Definição de compatibilidade do Android: Android 1.6
Android 1.6 r2
Google Inc.
compatibilidade@android.com

1. Introdução
Este documento enumera os requisitos que devem ser atendidos para que os telefones celulares possam ser
compatível com Android 1.6. Esta definição pressupõe familiaridade com o Programa de Compatibilidade do Android
[Recursos, 1].
O uso de "deve", "não deve", "obrigatório", "deve", "não deve", "deveria", "não deveria", "recomendado",
"pode" e "opcional" são de acordo com o padrão IETF definido em RFC2119 [ Recursos , 2].
Conforme utilizado neste documento, um "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve
uma solução de hardware/software rodando Android 1.6. Uma "implementação de dispositivo" ou "implementação" é o
solução de hardware/software assim desenvolvida.
Para serem considerados compatíveis com Android 1.6, as implementações de dispositivos:
1. DEVE atender aos requisitos apresentados nesta Definição de Compatibilidade, incluindo quaisquer documentos
incorporado via referência.
2. DEVE passar no Android Compatibility Test Suite (CTS) disponível como parte do Android Open
Projeto Fonte [ Recursos , 3]. O CTS testa a maioria, mas não todos , os componentes descritos neste
documento.
Quando esta definição ou o CTS for omisso, ambíguo ou incompleto, é de responsabilidade do dispositivo
implementador para garantir compatibilidade com implementações existentes. Por esta razão, o Android Open
O Projeto Fonte [ Resources , 4] é a referência e a implementação preferida do Android. Dispositivo
os implementadores são fortemente encorajados a basear suas implementações no código-fonte "upstream"
disponível no Android Open Source Project. Embora alguns componentes possam hipoteticamente ser substituídos
com implementações alternativas esta prática é fortemente desencorajada, pois passar nos testes CTS se tornará
substancialmente mais difícil. É responsabilidade do implementador garantir total compatibilidade comportamental com
a implementação padrão do Android, incluindo e além do conjunto de testes de compatibilidade.
2. Recursos
Esta Definição de Compatibilidade faz referência a vários recursos que podem ser obtidos aqui.
1. Visão geral do programa de compatibilidade Android: https://sites.google.com/a/android.com/compatibility/
como funciona
2. Níveis de requisitos IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Conjunto de testes de compatibilidade: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suíte--cts
4. Projeto de código aberto Android: http://source.android.com/
5. Definições e documentação da API: http://developer.android.com/reference/packages.html
6. Provedores de conteúdo: http://code.google.com/android/reference/android/provider/package-
resumo.html
7. Recursos disponíveis: http://code.google.com/android/reference/available-resources.html
8. Arquivos de manifesto do Android: http://code.google.com/android/devel/bblocks-manifest.html
9. Referência de permissões do Android: http://developer.android.com/reference/android/
Manifesto.permissão.html
10. Constantes de construção: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Extensões do navegador Gears: http://code.google.com/apis/gears/

13. Especificação da Máquina Virtual Dalvik, encontrada no diretório dalvik/docs de um código-fonte
Confira; também disponível em http://android.git.kernel.org/?p=platform/
dalvik.git;a=árvore;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=CABEÇA
14. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Notificações: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Guia de estilo do ícone da barra de status: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarestrutura
17. Gerenciador de pesquisa: http://developer.android.com/reference/android/app/SearchManager.html
18. Brinde: http://developer.android.com/reference/android/widget/Toast.html
19. Aplicativos para Android: http://code.google.com/p/apps-for-android
20. Descrição do arquivo apk do Android: http://developer.android.com/guide/topics/fundamentals.html
21. Ponte de depuração do Android (adb): http://code.google.com/android/reference/adb.html
22. Serviço Dalvik Debug Monitor (ddms): http://code.google.com/android/reference/ddms.html
23. Macaco: http://developer.android.com/guide/developing/tools/monkey.html
24. Documentação de independência de exibição:
25. Constantes de configuração: http://developer.android.com/reference/android/content/res/
Configuração.html
26. Métricas de exibição: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Câmera: http://developer.android.com/reference/android/hardware/Camera.html
28. Espaço de coordenadas do sensor: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Referência de segurança e permissões do Android: http://developer.android.com/guide/topics/security/
segurança.html
Muitos desses recursos são derivados direta ou indiretamente do Android 1.6 SDK e serão
funcionalmente idêntico às informações na documentação desse SDK. Em qualquer caso em que isso
A definição de compatibilidade não concorda com a documentação do SDK, a documentação do SDK é considerada
autoritário. Quaisquer detalhes técnicos fornecidos nas referências incluídas acima são considerados por inclusão
fazer parte desta Definição de Compatibilidade.
3. Programas
A plataforma Android inclui um conjunto de APIs gerenciadas ("duras") e um conjunto de APIs chamadas "soft"
como o sistema Intent, APIs de código nativo e APIs de aplicativos da web. Esta seção detalha os aspectos difíceis e
soft APIs que são essenciais para a compatibilidade, bem como outras interfaces técnicas e de usuário relevantes
comportamentos. As implementações de dispositivos DEVEM cumprir todos os requisitos desta seção.
3.1. Compatibilidade de API gerenciada
O ambiente de execução gerenciado (baseado em Dalvik) é o principal veículo para aplicativos Android. O
A interface de programação de aplicativos (API) Android é o conjunto de interfaces da plataforma Android expostas a
aplicativos em execução no ambiente de VM gerenciado. As implementações de dispositivos DEVEM fornecer
implementações, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo Android
1.6 SDK, como:
1. APIs principais da linguagem Java Android [Recursos, 5].
2. Provedores de conteúdo [Recursos , 6].
3. Recursos [Recursos, 7].
4. Atributos e elementos AndroidManifest.xml [Recursos, 8].

As implementações de dispositivos NÃO DEVEM omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar
do comportamento documentado ou incluir ambientes autônomos, exceto quando especificamente permitido por esta Compatibilidade
Definição.
3.2. Compatibilidade de API suave
Além das APIs gerenciadas da Seção 3.1, o Android também inclui um recurso "soft" significativo somente em tempo de execução.
API, na forma de coisas como intenções, permissões e aspectos semelhantes de aplicativos Android
que não pode ser aplicado em tempo de compilação do aplicativo. Esta seção detalha as APIs "soft" e o sistema
comportamentos necessários para compatibilidade com Android 1.6. As implementações de dispositivos DEVEM atender a todos os
requisitos apresentados nesta seção.
3.2.1. Permissões
Os implementadores de dispositivos DEVEM apoiar e impor todas as constantes de permissão, conforme documentado pelo
Página de referência de permissão [ Recursos , 9]. Observe que a Seção 10 lista requisitos adicionais relacionados a
o modelo de segurança do Android.
3.2.2. Parâmetros de construção
As APIs do Android incluem uma série de constantes na classe android.os.Build [Resources, 10] que são
destina-se a descrever o dispositivo atual. Para fornecer valores consistentes e significativos em todos os dispositivos
implementações, a tabela abaixo inclui restrições adicionais sobre os formatos desses valores aos quais
implementações de dispositivos DEVEM estar em conformidade.
Parâmetro
Comentários
A versão do sistema Android atualmente em execução, em humanos
android.os.Build.VERSION.RELEASE
formato legível. Para Android 1.6, este campo DEVE ter o valor da string
"1,6".
A versão do sistema Android atualmente em execução, em formato
android.os.Build.VERSION.SDK
acessível ao código do aplicativo de terceiros. Para Android 1.6, este campo
DEVE ter o valor inteiro 4.
Um valor escolhido pelo implementador do dispositivo que designa a compilação específica
do sistema Android atualmente em execução, em formato legível por humanos.
Este valor NÃO DEVE ser reutilizado para diferentes compilações enviadas para o final
Usuários android.os.Build.VERSION.INCREMENTAL. Um uso típico deste campo é indicar qual número de compilação ou
O identificador de alteração de controle de origem foi usado para gerar a compilação. Lá
não há requisitos quanto ao formato específico deste campo, exceto que ele
NÃO DEVE ser nulo ou a string vazia ("").
Um valor escolhido pelo implementador do dispositivo que identifica o interno específico
hardware usado pelo dispositivo, em formato legível por humanos. Um possível uso
android.os.Build.BOARD
deste campo é indicar a revisão específica da placa que alimenta o
dispositivo. Não há requisitos quanto ao formato específico deste campo,
exceto que NÃO DEVE ser nulo ou uma string vazia ("").
Um valor escolhido pelo implementador do dispositivo que identifica o nome do
android.os.Build.BRAND
empresa, organização, indivíduo, etc. que produziu o dispositivo, em
formato legível por humanos. Uma possível utilização deste campo é indicar o OEM

e/ou operadora que vendeu o dispositivo. Não há requisitos sobre
formato específico deste campo, exceto que NÃO DEVE ser nulo ou vazio
corda ("").
Um valor escolhido pelo implementador do dispositivo que identifica o específico
configuração ou revisão do corpo (às vezes chamado de "industrial
android.os.Build.DEVICE
design") do dispositivo. Não há requisitos sobre o formato específico
deste campo, exceto que NÃO DEVE ser nulo ou a string vazia ("").
Uma string que identifica exclusivamente esta compilação. DEVE ser razoavelmente
legível por humanos. DEVE seguir este modelo:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Por exemplo: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/chaves de teste
A impressão digital NÃO DEVE incluir espaços. Se outros campos incluídos no
modelo acima contém espaços, eles DEVEM ser substituídos pelo ASCII
caractere de sublinhado ("_") na impressão digital.
Uma string que identifica exclusivamente o host no qual o build foi construído, em humano
android.os.Build.HOST
formato legível. Não há requisitos sobre o formato específico deste
campo, exceto que NÃO DEVE ser nulo ou a string vazia ("").
Um identificador escolhido pelo implementador do dispositivo para se referir a um determinado
lançamento, em formato legível por humanos. Este campo pode ser o mesmo que
android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor
android.os.Build.ID
pretende ser algo significativo para os usuários finais. Não há
requisitos sobre o formato específico deste campo, exceto que NÃO DEVE
seja nulo ou a string vazia ("").
Um valor escolhido pelo implementador do dispositivo contendo o nome do
dispositivo conforme conhecido pelo usuário final. Este DEVE ser o mesmo nome
android.os.Build.MODEL
sob o qual o dispositivo é comercializado e vendido aos usuários finais. Não há
requisitos sobre o formato específico deste campo, exceto que NÃO DEVE
seja nulo ou a string vazia ("").
Um valor escolhido pelo implementador do dispositivo contendo o desenvolvimento
nome ou nome de código do dispositivo. DEVE ser legível por humanos, mas não é
android.os.Build.PRODUCT
necessariamente destinado à visualização pelos usuários finais. Não há requisitos
no formato específico deste campo, exceto que NÃO DEVE ser nulo ou o
string vazia ("").
Uma lista separada por vírgulas de tags escolhidas pelo implementador do dispositivo que
distinguir ainda mais a construção. Por exemplo, "não assinado, depuração". Este campo
android.os.Build.TAGS
NÃO DEVE ser nulo ou uma string vazia (""), mas uma única tag (como
"liberação") está bem.
android.os.Build.TIME
Um valor que representa o carimbo de data/hora de quando o build ocorreu.
Um valor escolhido pelo implementador do dispositivo especificando o tempo de execução
configuração da compilação. Este campo DEVE ter um dos valores
android.os.Build.TYPE
correspondendo às três configurações típicas de tempo de execução do Android: "usuário",
"userdebug" ou "eng".
Um nome ou ID do usuário (ou usuário automatizado) que gerou o
android.os.Build.USER
construir. Não há requisitos quanto ao formato específico deste campo,
exceto que NÃO DEVE ser nulo ou uma string vazia ("").

3.2.3. Compatibilidade de intenções
O Android usa Intents para obter integração fraca entre aplicativos. Esta seção descreve
requisitos relacionados aos padrões de intenção que DEVEM ser respeitados pelas implementações de dispositivos. Por
"honrado", significa que o implementador do dispositivo DEVE fornecer uma atividade, serviço Android ou outro
componente que especifica um filtro de intenção correspondente e se vincula e implementa o comportamento correto para cada
padrão de intenção especificado.
3.2.3.1. Principais intenções do aplicativo
O projeto upstream do Android define uma série de aplicativos principais, como discador telefônico, calendário,
livro de contatos, reprodutor de música e assim por diante. Os implementadores de dispositivos PODEM substituir esses aplicativos por
versões alternativas.
No entanto, quaisquer versões alternativas DEVEM respeitar os mesmos padrões de Intent fornecidos pelo upstream
projeto. (Por exemplo, se um dispositivo contiver um reprodutor de música alternativo, ele ainda deverá respeitar o padrão Intent
emitido por aplicativos de terceiros para escolher uma música.) As implementações de dispositivos DEVEM suportar todos os padrões de Intenção
listado no Apêndice A.
3.2.3.2. Substituições de intenção
Como o Android é uma plataforma extensível, os implementadores de dispositivos DEVEM permitir cada padrão de Intent descrito em
Apêndice A deve ser substituído por aplicativos de terceiros. O projeto upstream de código aberto Android
permite isso por padrão; implementadores de dispositivos NÃO DEVEM atribuir privilégios especiais aos aplicativos do sistema
uso desses padrões de intenção ou impedir que aplicativos de terceiros se vinculem e assumam o controle de
esses padrões. Esta proibição inclui especificamente a desativação da interface de usuário "Seletor", que permite
o usuário pode selecionar entre vários aplicativos que lidam com o mesmo padrão de intenção.
3.2.3.3. Namespaces de intenção
Os implementadores de dispositivos NÃO DEVEM incluir nenhum componente Android que honre qualquer nova intenção ou
Padrões de intenção de transmissão usando ACTION, CATEGORY ou outra sequência de chaves no namespace android.*.
Os implementadores de dispositivos NÃO DEVEM incluir nenhum componente Android que honre qualquer nova intenção ou
Padrões de intenção de transmissão usando ACTION, CATEGORY ou outra sequência de chaves em um espaço de pacote
pertencente a outra organização. Os implementadores de dispositivos NÃO DEVEM alterar ou estender qualquer intenção
padrões listados nos Apêndices A ou B.
Esta proibição é análoga àquela especificada para classes de linguagem Java na Seção 3.6.

3.2.3.4. Intenções de transmissão
Aplicativos de terceiros dependem da plataforma para transmitir certas intenções para notificá-los sobre mudanças no
ambiente de hardware ou software. Dispositivos compatíveis com Android DEVEM transmitir a transmissão pública
Intenções em resposta a eventos apropriados do sistema. Uma lista de Broadcast Intents necessários é fornecida em
Apêndice B; no entanto, observe que o SDK pode definir intenções de transmissão adicionais, que também DEVEM ser
honrado.
3.3. Compatibilidade de API nativa
O código gerenciado em execução no Dalvik pode chamar o código nativo fornecido no arquivo .apk do aplicativo como um ELF
Arquivo .so compilado para a arquitetura de hardware do dispositivo apropriada. As implementações de dispositivos DEVEM incluir
suporte para código em execução no ambiente gerenciado para chamar código nativo, usando o padrão Java
Semântica da Interface Nativa (JNI). As seguintes APIs devem estar disponíveis para código nativo:
• libc (biblioteca C)
• libm (biblioteca matemática)
• Interface JNI
• libz (compressão Zlib)
• liblog (registro do Android)
• Suporte mínimo para C++
• OpenGL ES 1.1
Essas bibliotecas DEVEM ser compatíveis com a fonte (ou seja, com o cabeçalho) e com o binário (para um determinado
arquitetura do processador) com as versões fornecidas em Bionic pelo projeto Android Open Source. Desde
as implementações Bionic não são totalmente compatíveis com outras implementações, como o GNU C
biblioteca, os implementadores de dispositivos DEVEM usar a implementação do Android. Se os implementadores de dispositivos usarem um
implementação diferente dessas bibliotecas, elas devem garantir compatibilidade de cabeçalho e binário.
A compatibilidade do código nativo é um desafio. Por esta razão, desejamos repetir que os implementadores de dispositivos são
MUITO fortemente encorajado a usar as implementações upstream das bibliotecas listadas acima, para ajudar
garantir a compatibilidade.
3.4. Compatibilidade com API Web
Muitos desenvolvedores e aplicativos dependem do comportamento da classe android.webkit.WebView [ Recursos ,
11] para suas interfaces de usuário, portanto a implementação do WebView deve ser compatível com Android
implementações. A implementação do Android Open Source usa a versão do mecanismo de renderização WebKit para
implementar o WebView.
Como não é viável desenvolver um conjunto de testes abrangente para um navegador web, os implementadores de dispositivos
DEVE usar a construção upstream específica do WebKit na implementação do WebView. Especificamente:
• O WebView DEVE usar a versão 528.5+ WebKit da árvore upstream de código aberto do Android para
Andróide 1.6. Esta compilação inclui um conjunto específico de funcionalidades e correções de segurança para o WebView.
• A string do agente do usuário informada pelo WebView DEVE estar neste formato:
Mozilla/5.0 (Linux; U; Android 1.6; <idioma>-<país>; <dispositivo
nome>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, como Gecko)
Versão/3.1.2 Mobile Safari/525.20.1

◦ A string "<nome do dispositivo>" DEVE ser igual ao valor de
android.os.Build.MODEL
◦ A string "<build ID>" DEVE ser igual ao valor de android.os.Build.ID.
◦ As strings "<idioma>" e "<país>" DEVEM seguir as convenções usuais para
código do país e idioma, e DEVE referir-se à localidade atual do dispositivo no
momento da solicitação.
As implementações PODEM enviar uma string de agente de usuário personalizada no aplicativo de navegador independente. O que é
além disso, o navegador independente PODE ser baseado em uma tecnologia de navegador alternativa (como Firefox,
Opera, etc.) No entanto, mesmo que um aplicativo de navegador alternativo seja enviado, o componente WebView
fornecidos a aplicativos de terceiros DEVEM ser baseados no WebKit, conforme acima.
O aplicativo de navegador independente DEVE incluir suporte para Gears [ Recursos, 12] e MAIO
incluem suporte para parte ou todo o HTML5.
3.5. Compatibilidade comportamental da API
Os comportamentos de cada um dos tipos de API (gerenciada, flexível, nativa e web) devem ser consistentes com o
implementação preferencial do Android disponível no Android Open Source Project.
Algumas áreas específicas de compatibilidade são:
• Os dispositivos NÃO DEVEM alterar o comportamento ou o significado de uma intenção padrão
• Os dispositivos NÃO DEVEM alterar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de sistema
componente (como Serviço, Atividade, ContentProvider, etc.)
• Os dispositivos NÃO DEVEM alterar a semântica de uma permissão específica
A lista acima não é abrangente e a responsabilidade recai sobre os implementadores de dispositivos para garantir
compatibilidade. Por esta razão, os implementadores de dispositivos DEVEM usar o código-fonte disponível através do
Android Open Source Project sempre que possível, em vez de reimplementar partes significativas do sistema.
O Compatibility Test Suite (CTS) testa partes significativas da plataforma quanto à compatibilidade comportamental,
mas nem todos. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android
Projeto de código aberto.
3.6. Namespaces de API
O Android segue as convenções de namespace de pacote e classe definidas pela programação Java
linguagem. Para garantir a compatibilidade com aplicativos de terceiros, os implementadores de dispositivos NÃO DEVEM fazer
quaisquer modificações proibidas (veja abaixo) nestes namespaces de pacotes:
• java.*
• javax.*
• sol.*
• andróide.*
• com.android.*
As modificações proibidas incluem:
• As implementações de dispositivos NÃO DEVEM modificar as APIs expostas publicamente na plataforma Android
alterando qualquer método ou assinatura de classe ou removendo classes ou campos de classe.

• Os implementadores de dispositivos PODEM modificar a implementação subjacente das APIs, mas tal
modificações NÃO DEVEM impactar o comportamento declarado e a assinatura da linguagem Java de qualquer
APIs expostas publicamente.
• Os implementadores de dispositivos NÃO DEVEM adicionar quaisquer elementos expostos publicamente (como classes ou
interfaces, ou campos ou métodos para classes ou interfaces existentes) para as APIs acima.
Um "elemento exposto publicamente" é qualquer construção que não esteja decorada com o marcador "@hide" no
código-fonte original do Android. Em outras palavras, os implementadores de dispositivos NÃO DEVEM expor novas APIs ou
alterar APIs existentes nos namespaces mencionados acima. Os implementadores de dispositivos PODEM fazer apenas
modificações, mas essas modificações NÃO DEVEM ser anunciadas ou expostas de outra forma aos desenvolvedores.
Os implementadores de dispositivos PODEM adicionar APIs personalizadas, mas essas APIs NÃO DEVEM estar em um namespace de propriedade
por ou referindo-se a outra organização. Por exemplo, os implementadores de dispositivos NÃO DEVEM adicionar APIs ao
com.google.* ou namespace semelhante; somente o Google pode fazer isso. Da mesma forma, o Google NÃO DEVE adicionar APIs a
namespaces de outras empresas.
Se um implementador de dispositivo propor melhorar um dos namespaces de pacote acima (como adicionando
nova funcionalidade útil para uma API existente ou adicionando uma nova API), o implementador DEVE visitar
source.android.com e inicie o processo de contribuição de alterações e código, de acordo com o
informações nesse site.
Observe que as restrições acima correspondem às convenções padrão para nomenclatura de APIs no Java
linguagem de programação; esta seção visa simplesmente reforçar essas convenções e torná-las vinculativas
através da inclusão nesta definição de compatibilidade.
3.7. Compatibilidade de Máquina Virtual
Um dispositivo Android compatível deve suportar a especificação completa de bytecode Dalvik Executable (DEX) e
Semântica da Máquina Virtual Dalvik [Recursos, 13].
3.8. Compatibilidade da interface do usuário
A plataforma Android inclui algumas APIs de desenvolvedor que permitem que os desenvolvedores se conectem ao usuário do sistema
interface. As implementações de dispositivos DEVEM incorporar essas APIs de UI padrão em interfaces de usuário personalizadas
eles se desenvolvem, conforme explicado abaixo.
3.8.1. Widgets
O Android define um tipo de componente e uma API e um ciclo de vida correspondentes que permitem que os aplicativos exponham
um "AppWidget" para o usuário final [Recursos , 14] . A versão de referência do Android Open Source inclui um
Aplicativo inicializador que inclui elementos da interface do usuário que permitem ao usuário adicionar, visualizar e remover
AppWidgets na tela inicial.
Os implementadores de dispositivos PODEM substituir uma alternativa ao Launcher de referência (ou seja, tela inicial).
Lançadores alternativos DEVEM incluir suporte integrado para AppWidgets e expor a interface do usuário
elementos para adicionar, visualizar e remover AppWidgets diretamente no Launcher. Lançadores alternativos PODEM
omita esses elementos da interface do usuário; no entanto, se forem omitidos, o implementador do dispositivo DEVE fornecer um
aplicativo separado acessível a partir do Launcher que permite aos usuários adicionar, visualizar e remover
AppWidgets.

3.8.2. Notificações
O Android inclui APIs que permitem aos desenvolvedores notificar os usuários sobre eventos notáveis [Recursos, 15]. Dispositivo
os implementadores DEVEM fornecer suporte para cada classe de notificação assim definida; especificamente: sons,
vibração, luz e barra de status.
Além disso, a implementação DEVE ser renderizada corretamente e todos os recursos (ícones, arquivos de som, etc.)
fornecido nas APIs [Recursos, 7] ou no guia de estilo de ícones da barra de status [Recursos , 16]. Dispositivo
os implementadores PODEM fornecer uma experiência de usuário alternativa para notificações do que aquela fornecida pelo
referência à implementação de código aberto do Android; no entanto, esses sistemas de notificação alternativos DEVEM
apoiar recursos de notificação existentes, como acima.
3.8.3. Procurar
O Android inclui APIs [Recursos, 17] que permitem aos desenvolvedores incorporar pesquisas em seus aplicativos,
e expor os dados de seus aplicativos na pesquisa global do sistema. De um modo geral, esta funcionalidade
consiste em uma interface de usuário única para todo o sistema que permite aos usuários inserir consultas, exibe sugestões
conforme os usuários digitam e exibe os resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para fornecer
pesquise em seus próprios aplicativos e permita que os desenvolvedores forneçam resultados ao usuário comum de pesquisa global
interface.
As implementações de dispositivos DEVEM incluir uma interface de usuário de pesquisa única e compartilhada em todo o sistema, capaz de
sugestões em tempo real em resposta à entrada do usuário. As implementações de dispositivos DEVEM implementar as APIs que
permitir que os desenvolvedores reutilizem essa interface de usuário para fornecer pesquisa em seus próprios aplicativos.
As implementações de dispositivos DEVEM implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões
para a caixa de pesquisa quando é executado no modo de pesquisa global. Se nenhum aplicativo de terceiros estiver instalado
fazer uso desta funcionalidade, o comportamento padrão DEVE ser exibir resultados de mecanismos de pesquisa na web e
sugestões.
As implementações de dispositivos PODEM fornecer interfaces de usuário de pesquisa alternativas, mas DEVEM incluir um hard ou soft
botão de pesquisa dedicado, que pode ser usado a qualquer momento em qualquer aplicativo para invocar a estrutura de pesquisa,
com o comportamento previsto na documentação da API.
3.8.4. Torradas
Os aplicativos podem usar a API "Toast" (definida em [ Recursos, 18]) para exibir strings curtas não modais para o
usuário final, que desaparecem após um breve período de tempo. As implementações de dispositivos DEVEM exibir brindes de
aplicativos para usuários finais de alguma maneira de alta visibilidade.
4. Referência de compatibilidade de software
Os implementadores de dispositivos DEVEM testar a compatibilidade da implementação usando o seguinte código aberto
formulários:
• Calculadora (incluída no SDK)
• Módulo Lunar (incluído no SDK)
• ApiDemos (incluído no SDK)
• Os aplicativos "Apps para Android" [ Recursos, 19]
Cada aplicativo acima DEVE ser iniciado e se comportar corretamente na implementação, para que a implementação seja

considerado compatível.
5. Compatibilidade de pacotes de aplicativos
As implementações de dispositivos DEVEM instalar e executar arquivos ".apk" do Android gerados pela ferramenta "aapt"
incluído no Android SDK oficial [ Recursos , 20].
As implementações de dispositivos NÃO DEVEM estender o bytecode .apk, Android Manifest ou Dalvik
formatos de forma que impeça que esses arquivos sejam instalados e executados corretamente em outros
dispositivos compatíveis. Os implementadores de dispositivos DEVEM usar a implementação upstream de referência da Dalvik,
e o sistema de gerenciamento de pacotes da implementação de referência.
6. Compatibilidade multimídia
Um dispositivo Android compatível deve suportar os seguintes codecs multimídia. Todos esses codecs são
fornecidos como implementações de software na implementação Android preferida do Android Open
Projeto Fonte [ Recursos , 4].
Observe que nem o Google nem a Open Handset Alliance fazem qualquer declaração de que estes
os codecs não estão onerados por patentes de terceiros. Aqueles que pretendem usar este código fonte em hardware ou
produtos de software são avisados de que implementações deste código, inclusive em software de código aberto ou
shareware, pode exigir licenças de patentes dos detentores de patentes relevantes.
Áudio
Nome
Detalhes do decodificador do codificador
Arquivos suportados
Conteúdo mono/estéreo em qualquer
3GPP (.3gp) e
combinação de taxas de bits padrão
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
até 160 kbps e arquivos com taxas de amostragem. Não há suporte para raw
entre 8 a 48kHz
AAC (.aac)
Conteúdo mono/estéreo em qualquer
3GPP (.3gp) e
HE-AACv1
combinação de taxas de bits padrão
MPEG-4 (.mp4, .m4a)
X
(AAC+)
até 96 kbps e arquivos com taxas de amostragem. Não há suporte para raw
entre 8 a 48kHz
AAC (.aac)
Conteúdo mono/estéreo em qualquer
HE-AACv2
3GPP (.3gp) e
combinação de taxas de bits padrão
(aprimorado
MPEG-4 (.mp4, .m4a)
X
até 96 kbps e taxas de amostragem
AAC+)
arquivos. Não há suporte para raw
entre 8 a 48kHz
AAC (.aac)
AMR-NB
4,75 a 12,2 kbps amostrados @
Arquivos 3GPP (.3gp)
X
X
8kHz
AMR-WB
9 taxas de 6,60 kbit/s a 23,85
-Arquivos 3GPP (.3gp)
X
kbit/s amostrados a 16kHz
MP3
Arquivos MP3 (.mp3) constantes mono/estéreo de 8-320 Kbps
X
(CBR) ou taxa de bits variável (VBR)
Digite 0 e 1 (.mid, .xmf,
MIDI Tipo 0 e 1. DLS Versão 1
MIDI
X
.mxmf). Também RTTTL/RTX
e 2. XMF e XMF Móvel.
(.rtttl, .rtx), ota (.ota),

Suporte para formatos de toque
e iMelody (.imy)
Rtttl/rtx, OTA e iMelody
Ogg Vorbis
.ogg
X
PCM linear de 8 e 16 bits
PCM
X
ACENO
para limitar o hardware)
Imagem
arquivos
Nome
Detalhes do decodificador do codificador
Suportado
JPEG
X
X
base+progressiva
GIFs
X
png
X
X
Veículo de combate de infantaria
X
Vídeo
arquivos
Nome
Detalhes do decodificador do codificador
Suportado
3GPP (.3GP)
H.263
X
X
arquivos
3GPP (.3GP)
H.264
X
e MPEG-4
(.mp4) arquivos
MPEG4
X
Arquivo 3GPP (.3GP)
SP
7. Compatibilidade da ferramenta de desenvolvedor
As implementações do dispositivo devem suportar as ferramentas de desenvolvedor Android fornecidas no Android SDK.
Especificamente, os dispositivos compatíveis com Android devem ser compatíveis com:
• Android Debug Bridge ou Adb [Recursos , 21]
As implementações de dispositivos devem suportar todas as funções do ADB, conforme documentado no Android
SDK. O daemon adb do lado do dispositivo deve estar inativo por padrão, mas deve haver um usuário-
Mecanismo acessível para ativar a ponte de depuração do Android.
• Dalvik Debug Monitor Service ou DDMS [Recursos , 22]
As implementações do dispositivo devem suportar todos os recursos do DDMS, conforme documentado no Android SDK.
Como o DDMS usa o ADB, o suporte para o DDMS deve estar inativo por padrão, mas deve ser suportado
Sempre que o usuário ativou a ponte de depuração do Android, como acima.

• Macaco [Recursos, 23]
As implementações de dispositivos devem incluir a estrutura do macaco e disponibilizá -lo para
Aplicativos para usar.
8. Compatibilidade de hardware
O Android destina -se a apoiar os implementadores de dispositivos, criando fatores e configurações inovadores de forma.
Ao mesmo tempo, os desenvolvedores do Android esperam certos hardware, sensores e APIs em todo o Android
dispositivo. Esta seção lista os recursos de hardware que todos os dispositivos compatíveis com Android 1.6 devem suportar. Em
Android 1.6, a maioria dos recursos de hardware (como WiFi, Compass e Acceleromômetro) é necessária.
Se um dispositivo incluir um componente de hardware específico que possui uma API correspondente para terceiros
Desenvolvedores, a implementação do dispositivo deve implementar essa API conforme definido no Android SDK
documentação.
8.1. Mostrar
Android 1.6 inclui instalações que executam certas operações automáticas de escala e transformação em
Algumas circunstâncias, para garantir que os aplicativos de terceiros funcionem razoavelmente bem em hardware
As configurações para as quais não foram necessariamente projetadas explicitamente [Recursos, 24] . Dispositivos devem
Implemente adequadamente esses comportamentos, conforme detalhado nesta seção.
8.1.1. Configurações de exibição padrão
Esta tabela lista as configurações de tela padrão consideradas compatíveis com o Android:
Diagonal
Tamanho da tela
Densidade da tela
Tipo de tela
Largura (pixels)
Altura (pixels)
Faixa de comprimento
Grupo
Grupo
(polegadas)
Qvga
240
320
2.6 - 3.0
Pequeno
Baixo
WQVGA
240
400
3.2 - 3.5
Normal
Baixo
FWQVGA
240
432
3.5 - 3.8
Normal
Baixo
HVGA
320
480
3.0 - 3.5
Normal
Médio
WVGA
480
800
3.3 - 4.0
Normal
Alto
FWVGA
480
854
3.5 - 4.0
Normal
Alto
WVGA
480
800
4.8 - 5.5
Grande
Médio
FWVGA
480
854
5.0 - 5.8
Grande
Médio
As implementações do dispositivo correspondentes a uma das configurações padrão acima devem ser configuradas
Para relatar o tamanho da tela indicado aos aplicativos via Android.content.res.configuration [ Recursos,
25] classe.
Alguns pacotes .APK têm manifestos que não os identificam como apoiando uma faixa de densidade específica.
Ao executar esses aplicativos, as seguintes restrições se aplicam:

• As implementações do dispositivo devem interpretar os recursos presentes como inadimplentes para
"Médio" (conhecido como "MDPI" na documentação do SDK.)
• Ao operar em uma tela de densidade "baixa", as implementações do dispositivo devem diminuir o meio/
Ativos MDPI por um fator de 0,75.
• Ao operar em uma tela de densidade "alta", as implementações de dispositivos devem escalar médio/
Ativos MDPI por um fator de 1,5.
• As implementações do dispositivo não devem escalar ativos dentro de uma faixa de densidade e devem escalar
ativos exatamente por esses fatores entre as faixas de densidade.
8.1.2. Configurações de exibição não padrão
Exibir configurações que não correspondem a uma das configurações padrão listadas na Seção 8.2.1 requerem
consideração e trabalho adicionais para serem compatíveis. Os implementadores de dispositivos devem entrar em contato com o Android
Equipe de compatibilidade conforme previsto na Seção 12 para obter classificações para o balde de tamanho de tela, densidade,
e fator de escala. Quando fornecido com essas informações, as implementações do dispositivo devem implementá -las
como especificado.
Observe que algumas configurações de exibição (como telas muito grandes ou muito pequenas e algumas proporções de aspecto)
são fundamentalmente incompatíveis com o Android 1.6; Portanto, os implementadores de dispositivos são incentivados a
Entre em contato com a equipe de compatibilidade do Android o mais cedo possível no processo de desenvolvimento.
8.1.3. Exibir métricas
As implementações do dispositivo devem relatar valores corretos para todas as métricas de exibição definidas em
Android.util.DisplayMetrics [Recursos , 26].
8.2. Teclado
Implementações de dispositivos:
• Deve incluir suporte para a estrutura de gerenciamento de entrada (que permite terceiros
desenvolvedores para criar mecanismos de gerenciamento de entrada - ou seja, teclado suave) conforme detalhado em
desenvolvedor.android.com
• Deve fornecer pelo menos uma implementação de teclado suave (independentemente de um difícil
teclado está presente)
• Pode incluir implementações adicionais de teclado suave
• Pode incluir um teclado de hardware
• Não deve incluir um teclado de hardware que não corresponda a um dos formatos especificados
in Android.content.res.configuration [ Recursos, 25] (isto é, qwerty ou 12 teclas)
8.3. Navegação não-touch
Implementações de dispositivos:
• Pode omitir opções de navegação não-touch (ou seja, podem omitir um trackball, bloco direcional de 5 vias, ou
roda)
• Deve reportar via Android.content.res.configuration [Recursos , 25] O valor correto para o
hardware do dispositivo

8.4. Orientação da tela
Dispositivos compatíveis devem apoiar a orientação dinâmica por aplicações para retratos ou paisagem
orientação da tela. Ou seja, o dispositivo deve respeitar a solicitação do aplicativo para uma tela específica
orientação. As implementações do dispositivo podem selecionar a orientação de retrato ou paisagem como padrão.
Os dispositivos devem relatar o valor correto para a orientação atual do dispositivo, sempre que consultado através do
Android.content.res.configuration.orientation, android.view.display.getorientation () ou outras APIs.
8.5. Entrada de tela sensível ao toque
Implementações de dispositivos:
• Deve ter uma tela sensível ao toque
• Pode ter tela sensível ao toque capacativa ou resistiva
• Deve relatar o valor de Android.content.res.configuration [ Recursos, 25] refletindo
correspondente ao tipo de tela sensível ao toque específica no dispositivo
8.6. USB
Implementações de dispositivos:
• Deve implementar um cliente USB, conectado a um host USB com uma porta USB-A padrão
• Deve implementar a ponte de depuração do Android sobre USB (conforme descrito na Seção 7)
• Deve implementar um cliente de armazenamento em massa USB para o armazenamento removível/de mídia está presente no
dispositivo
• Deve usar o fator de forma micro USB no lado do dispositivo
• Deve implementar o suporte para a especificação de armazenamento em massa USB (para que seja removível
ou armazenamento fixo no dispositivo pode ser acessado de um PC hospedeiro)
• Pode incluir uma porta fora do padrão no lado do dispositivo, mas se assim deve ser enviado com um cabo capaz de
Conectando a pinagem personalizada à porta USB-A padrão
8.7. Teclas de navegação
As funções domésticas, menus e costas são essenciais para o paradigma de navegação Android. Dispositivo
As implementações devem disponibilizar essas funções para o usuário o tempo todo, independentemente do aplicativo
estado. Essas funções devem ser implementadas através de botões dedicados. Eles podem ser implementados
Usando software, gestos, painel de toque, etc., mas se assim for, eles devem estar sempre acessíveis e não obscuros ou
interferir na área de exibição do aplicativo disponível.
Os implementadores do dispositivo também devem fornecer uma chave de pesquisa dedicada. Os implementadores de dispositivos também podem
Forneça as chaves de envio e final para telefonemas.
8.8. Wi-fi
As implementações do dispositivo devem suportar 802.11b e 802.11g e podem suportar 802.11a.

8.9. Câmera
As implementações do dispositivo devem incluir uma câmera. A câmera incluída:
• Deve ter uma resolução de pelo menos 2 megapixels
• Deve ter foco automático de hardware ou foco automático de software implementado na câmera
Driver (transparente ao software de aplicativo)
• Pode ter foco fixo ou hardware EDOF (profundidade de campo prolongada)
• Pode incluir um flash. Se a câmera incluir um flash, a lâmpada flash não deve ser acesa enquanto um
Android.hardware.camera.previewCallback A instância foi registrada em uma prévia da câmera
superfície.
As implementações do dispositivo devem implementar os seguintes comportamentos para as APIs relacionadas à câmera
[Recursos, 27] :
1. Se um aplicativo nunca ligou para Android.hardware.camera.parameters.setPreviewFormat (int),
Em seguida, o dispositivo deve usar Android.hardware.pixelformat.ycbcr_420_sp para dados de visualização
Fornecido para retornos de chamada do aplicativo.
2. Se um aplicativo registrar um Android.hardware.camera.previewCallback e o
O sistema chama o método onpreviewframe () quando o formato de visualização é ycbcr_420_sp, o
Os dados no byte [] transmitidos para o OnPreviewFrame () devem estar ainda no formato de codificação NV21.
(Este é o formato usado nativamente pela família 7K de hardware.) Ou seja, o NV21 deve ser o padrão.
8.9.1. Câmeras não automáticas
Se um dispositivo não possui uma câmera de foco automático, o implementador do dispositivo deve atender aos requisitos adicionais em
esta seção. As implementações do dispositivo devem implementar a API de câmera completa incluída no Android 1.6
A documentação do SDK de alguma maneira razoável, independentemente dos recursos reais do hardware da câmera.
Para o Android 1.6, se a câmera não tiver foco automático, a implementação do dispositivo deve aderir ao seguinte:
1. O sistema deve incluir uma propriedade do sistema somente leitura chamada "ro.workAlound.noautoFocus"
com o valor de "1". Este valor deve ser usado por aplicativos como o mercado Android para
identificar seletivamente os recursos do dispositivo e serão substituídos em uma versão futura do Android com um
API robusta.
2. Se um aplicativo chamar Android.hardware.camera.autoFocus (), o sistema deve chamar o
Método de retorno de chamada em OnautoFocus () em qualquer
Android.hardware.camera.autoFocusCallback Instâncias, mesmo que não focalize na verdade
ocorrido. Isso é para evitar que os aplicativos existentes quebrem esperando para sempre por um foco automático
retorno de chamada que nunca virá.
3. A chamada para o método AutoFocusCallback.onaUtoFocus () deve ser desencadeada pelo driver ou
estrutura em um novo evento no encadeamento Looper principal da estrutura. Isto é, câmera.autoFocus ()
Não deve chamar diretamente de AutoFocusCallback.onaUtoFocus (), pois isso viola o Android
Modelo de encadeamento da estrutura e quebrará aplicativos.
8.10. Acelerômetro
As implementações de dispositivos devem incluir um acelerômetro de 3 eixos e devem ser capazes de entregar eventos em AT
pelo menos 50 Hz. O sistema de coordenadas usado pelo acelerômetro deve cumprir o sensor Android
Coordenar o sistema detalhado nas APIs Android [Recursos , 28].

8.11. Bússola
As implementações de dispositivos devem incluir uma bússola de 3 eixos e devem ser capazes de entregar eventos pelo menos
10 Hz. O sistema de coordenadas usado pela bússola deve cumprir com a coordenada do sensor Android
sistema conforme definido na API Android [Recursos , 28].
8.12. GPS
As implementações de dispositivos devem incluir um GPS e devem incluir alguma forma de "GPS assistido"
Técnica para minimizar o tempo de bloqueio do GPS.
8.13. Telefonia
Implementações de dispositivos:
• Deve incluir a telefonia GSM ou CDMA
• Deve implementar as APIs apropriadas conforme detalhado na documentação do Android SDK em
desenvolvedor.android.com
Observe que esse requisito implica que os dispositivos que não são de telefone não são compatíveis com o Android 1.6; Android
1.6 Os dispositivos devem incluir hardware de telefonia. Consulte o Apêndice C para obter informações sobre não-telefone
dispositivos.
8.14. Controles de volume
Os dispositivos compatíveis com Android devem incluir um mecanismo para permitir que o usuário aumente e diminua o
Volume de áudio. As implementações do dispositivo devem disponibilizar essas funções para o usuário o tempo todo,
independentemente do estado de aplicação. Essas funções podem ser implementadas usando chaves físicas de hardware,
software, gestos, painel de toque, etc., mas eles devem estar sempre acessíveis e não obscurecer ou interferir
com a área de exibição de aplicativos disponível (consulte a exibição acima).
Quando esses botões são usados, os principais eventos correspondentes devem ser gerados e enviados para o
Aplicação em primeiro plano. Se o evento não for interceptado e afundado pelo aplicativo, então o dispositivo
A implementação deve lidar com o evento como controle de volume do sistema.
9. Compatibilidade de desempenho
Um dos objetivos do programa de compatibilidade do Android é garantir uma experiência de aplicação consistente para
consumidores. As implementações compatíveis devem garantir não apenas que os aplicativos simplesmente sejam executados corretamente
O dispositivo, mas que o fazem com desempenho razoável e boa experiência geral do usuário.
As implementações do dispositivo devem atender às principais métricas de desempenho de um dispositivo compatível com Android 1.6,
Como na tabela abaixo:
Métrica
Limiar de desempenho
Comentários

Isso é testado pelo CTS.
As seguintes aplicações
O tempo de lançamento é medido como o tempo total para
deve ser lançado dentro do
carregamento completo da atividade padrão para o
Aplicativo
tempo especificado.
aplicação, incluindo o tempo necessário para iniciar o
Hora do almoço
Navegador: menos de 1300ms
Processo Linux, carregue o pacote Android no
MMS/SMS: menos de 700ms
Dalvik VM e ligue para o OnCreate.
AlarmClock: menos de 650ms
Vários aplicativos serão
Isso é testado pelo CTS.
lançado. Reavaliação do
A primeira aplicação simultânea deve
Formulários
completo tomando menos do que o
Tempo de lançamento original.
10. Compatibilidade do modelo de segurança
As implementações do dispositivo devem implementar um modelo de segurança consistente com a segurança da plataforma Android
Modelo conforme definido no documento de referência de segurança e permissões nas APIs [Recursos, 29] no
Documentação do desenvolvedor do Android. As implementações de dispositivos devem suportar a instalação de auto-autentação
Aplicativos sem exigir quaisquer permissões/certificados adicionais de terceiros/autoridades.
Especificamente, os dispositivos compatíveis devem suportar os seguintes mecanismos de segurança:
10.1. Permissões
As implementações de dispositivos devem suportar o modelo de permissões Android, conforme definido no Android
Documentação do desenvolvedor [ Recursos , 9]. Especificamente, as implementações devem aplicar cada permissão
definido conforme descrito na documentação do SDK; Nenhuma permissões pode ser omitida, alterada ou ignorada.
As implementações podem adicionar permissões adicionais, desde que as novas seqüências de identificação de permissão não estejam no
Android.* Namespace.
10.2. Isolamento de usuário e processo
As implementações de dispositivos devem suportar o modelo de sandbox de aplicativo Android, no qual cada aplicativo
é executado como um UID exclusivo no estilo UNIX e em um processo separado.
As implementações do dispositivo devem suportar a execução de vários aplicativos como o mesmo ID do usuário do Linux, fornecido
que os aplicativos são devidamente assinados e construídos, conforme definido na segurança e permissões
Referência [ Recursos , 29].

10.3. Permissões de sistema de arquivos
As implementações de dispositivos devem suportar o modelo de permissões de acesso ao arquivo Android, conforme definido em AS
definido na referência de segurança e permissões [Recursos , 29].
11. Suíte de teste de compatibilidade
As implementações do dispositivo devem passar no Android Compatibility Test Suite (CTS) [ Recursos, 3] Disponível
No projeto de código aberto Android, usando o software de remessa final no dispositivo. Adicionalmente,
Os implementadores de dispositivos devem usar a implementação de referência na árvore de código aberto Android como
tanto quanto possível, e deve garantir a compatibilidade em casos de ambiguidade em CTs e para qualquer
Reimplementação de partes do código -fonte de referência.
O CTS foi projetado para ser executado em um dispositivo real. Como qualquer software, o CTS pode conter bugs.
O CTS será versionada independentemente desta definição de compatibilidade e múltiplas revisões do
Os CTs podem ser lançados para o Android 1.6. No entanto, esses lançamentos só corrigirão bugs comportamentais no CTS
testes e não imporá novos testes, comportamentos ou APIs para uma determinada lançamento da plataforma.
12. Entre em contato conosco
Você pode entrar em contato com a equipe de compatibilidade do Android em compatibility@android.com para esclarecimentos relacionados a
Esta definição compatível e para fornecer feedback sobre essa definição.

Apêndice A: Intenos de aplicação necessários
Nota: Esta lista é provisória e será atualizada no futuro.
Ações de aplicação
Esquemas MIMES TIPOS
(nenhum)
texto/simples
http
texto/html
Navegador
Android.intent.action.View
https
APLICAÇÃO/XHTML+XML
aplicativo/
vnd.wap.xhtml+xml
(nenhum)
Android.intent.action.web_search
http
(nenhum)
https
Android.media.action.image_capture
Android.media.action.still_image_camera
Câmera
Android.media.action.video_camera
Android.media.action.video_capture
vnd.android.cursor.dir/
Android.intent.action.View
imagem
Android.intent.action.get_content
vnd.android.cursor.dir/
Android.Intent.action.pick
vídeo
android.intent.action.attach_data
imagem/*
vídeo/*
Android.intent.action.View
RTSP
vídeo/mp4
vídeo/3gp
Android.intent.action.View
http
Vídeo/3GPP
Vídeo/3GPP2
Android.Intent.action.dial
Telefone /
Android.intent.action.View
telefone
Contatos
Android.Intent.action.Call
Android.Intent.action.dial
vnd.android.cursor.dir/
Android.intent.action.View
pessoa

vnd.android.cursor.dir/
pessoa
vnd.android.cursor.dir/
Android.Intent.action.pick
telefone
vnd.android.cursor.dir/
endereço postal
vnd.android.cursor.item/
pessoa
vnd.android.cursor.item/
Android.intent.action.get_content
telefone
vnd.android.cursor.item/
endereço postal
texto/simples
E-mail
Android.intent.action.send
imagem/*
vídeo/*
Android.intent.action.View
mailto
Android.Intent.action.sendto
SMS
Android.intent.action.View
smsto
SMS / MMS Android.intent.action.sendto
mms
mmsto
áudio/*
APLICAÇÃO/OGG
Música
Android.intent.action.View
arquivo
APLICAÇÃO/X-OGG
Aplicação/iTunes
áudio/mp3
áudio/x-mp3
Android.intent.action.View
http
áudio/mpeg
Áudio/MP4
Áudio/MP4A-LATM
vnd.android.cursor.dir/
Artistalbum
vnd.android.cursor.dir/
álbum
vnd.android.cursor.dir/
Android.Intent.action.pick
Nowplaying
vnd.android.cursor.dir/
acompanhar
nd.android.cursor.dir/
lista de reprodução
vnd.android.cursor.dir/
vídeo
meios de comunicação/*
áudio/*
Android.intent.action.get_content
APLICAÇÃO/OGG
APLICAÇÃO/X-OGG
vídeo/*

contente
Pacote
Android.intent.action.View
arquivo
instalador
pacote
arquivo
Android.intent.action.package_install
http
https
Android.intent.action.all_apps
Android.Settings.Settings
Android.Settings.WIRESS_SETTINGS
Android.settings.airplane_mode_settings
Android.settings.wifi_settings
Android.settings.apn_settings
Android.settings.bluetooth_settings
Android.settings.date_settings
Android.settings.locale_settings
Configurações
Android.settings.input_method_settings
com.android.settings.sound_settings
com.android.settings.display_settings
Android.settings.security_setting
Android.Settings.Location_Source_Settings
Android.settings.internal_storage_settings
Android.settings.memory_card_settings
Android.intent.action.set_wallpaper
Procurar
Android.intent.action.search
consulta
Android.intent.action.search_long_press
Voz
Android.intent.action.voice_Command
Gerenciamento de contatos
Ação intenção
Descrição
Inicia uma atividade que permite que o usuário escolha
APCT_IMAGE
um contato para anexar uma imagem a.
Usado
Extra_create_description
com show_or_create_contact para
Especifique uma descrição exata a ser

mostrado ao solicitar o usuário sobre
criando um novo contato.
Usado
com show_or_create_contact para
Extra_force_create
forçar a criação de um novo contato se não
Contato correspondente encontrado.
Esta é a intenção que é disparada quando um
Search_Suggestion_Clicked
A sugestão de pesquisa está clicada.
Esta é a intenção que é disparada quando um
Search_suggestion_create_contact_clicked sugestão de pesquisa para criar um
O contato é clicado.
Esta é a intenção que é disparada quando um
Search_suggestion_dial_number_clicked
Pesquise sugestão para discar um número
é clicado.
Toma como entrada um URI de dados com um correio:
Show_or_create_contact
ou tel: esquema.

Apêndice B: Intentros de transmissão necessários Nota: Esta lista é provisória e será
atualizado no futuro.
Ação intenção
Descrição
Ação de transmissão: isso é transmitido uma vez, depois do
Action_Boot_Completed
O sistema terminou de inicializar.
Ação de transmissão: isso é transmitido uma vez, quando um
Action_Call_Button
Chamada é recebida.
Ação de transmissão: o "botão da câmera" foi
Action_camera_button
pressionado.
Ação de transmissão: o atual
Action_configuration_changed
Configuração do dispositivo (orientação, localidade, etc) tem
mudado.
Action_date_changed
Ação de transmissão: a data mudou.
Ação de transmissão: indica baixa condição de memória
Action_Device_Storage_Low
no dispositivo
Ação de transmissão: indica baixa condição de memória
Action_device_storage_ok
no dispositivo não existe mais
Ação de transmissão: fone de ouvido com fio conectado ou
Action_headset_plug
desconectado.
Ação de transmissão: um método de entrada tem sido
Action_input_method_changed
mudado.
Ação de transmissão: a mídia externa foi removida
Action_media_bad_removal
do slot do cartão SD, mas o Mount Point não foi
não montado.
Ação de transmissão: o "botão de mídia" era
Action_media_button
pressionado.
Ação de transmissão: a mídia externa está presente e
sendo verificou o caminho para o ponto de montagem para
Action_media_checking
a mídia corrente está contida no
Campo intent.mdata.
Ação de transmissão: o usuário expressou o desejo de
Action_media_eject
Remova o mídia de armazenamento externo.
Ação de transmissão: a mídia externa está presente e
Action_media_mounted
montado em seu ponto de montagem.
Ação de transmissão: a mídia externa está presente, mas é
usando um FS incompatível (ou está em branco) o caminho para
Action_media_nofs
O ponto de montagem para a mídia corrente é
contido no campo Intent.mdata.
Ação de transmissão: a mídia externa tem sido
Action_media_removed
removido.
Ação de transmissão: o scanner de mídia terminou
Action_media_scanner_finished
Examinando um diretório.
Ação de transmissão: solicite ao scanner de mídia para
Action_media_scanner_scan_file
Digitalize um arquivo e adicione -o ao banco de dados de mídia.

Ação de transmissão: o scanner de mídia começou
Action_media_scanner_started
Examinando um diretório.
Ação de transmissão: a mídia externa não é montada
Action_media_shared
Porque está sendo compartilhado via armazenamento em massa USB.
Ação de transmissão: a mídia externa está presente, mas
Action_media_unmountable
não pode ser montado.
Ação de transmissão: mídia externa está presente, mas
Action_media_unmouged
não montado em seu ponto de montagem.
Ação de transmissão: uma chamada de saída está prestes a ser
Action_new_outwer_call
colocada.
Ação de transmissão: um novo pacote de aplicativos tem
Action_package_added
foi instalado no dispositivo.
Ação de transmissão: um pacote de aplicativos existente
Action_package_changed
foi alterado (por exemplo, um componente foi
ativado ou desativado.
Ação de transmissão: o usuário limpou os dados de
um pacote. Isso deve ser precedido
por action_package_restarted, após o que
Action_package_data_cleared
Todos os seus dados persistentes são apagados e este
transmissão enviada. Observe que o pacote limpo
não recebe esta transmissão. Os dados contêm
o nome do pacote.
Ação de transmissão: um pacote de aplicativos existente
foi removido do dispositivo. Os dados
Action_Package_Removed
Contém o nome do pacote. O pacote
Isso está sendo instalado não recebe essa intenção.
Ação de transmissão: uma nova versão de um aplicativo
Action_package_replaced
o pacote foi instalado, substituindo um existente
versão que foi instalada anteriormente.
Ação de transmissão: o usuário reiniciou um
pacote e todos os seus processos foram mortos.
Todo o estado de tempo de execução associado a ele (processos,
Action_package_restarted
Alarmes, notificações, etc) devem ser removidos. Observação
que o pacote reiniciado não recebe isso
transmissão. Os dados contêm o nome do
pacote.
Ação de transmissão: alguns provedores de conteúdo têm
partes de seu espaço para nome onde eles publicam novos
Action_provider_changed
eventos ou itens que o usuário pode ser especialmente
interessado em.
Action_screen_off
Ação de transmissão: enviado após a tela desligar.
Action_screen_on
Ação de transmissão: enviado após a tela ligar.
Ação de transmissão: um ID de usuário foi removido
Action_uid_removed
do sistema.
Ação de transmissão: o dispositivo entrou USB
Action_ums_connected
Modo de armazenamento em massa.

Ação de transmissão: o dispositivo saiu do USB
Action_ums_disconnected
Modo de armazenamento em massa.
Ação de transmissão: enviado quando o usuário estiver presente
Action_User_Present
depois que o dispositivo acorda (por exemplo, quando o guard
perdido).
Ação de transmissão: o papel de parede do sistema atual
Action_wallpaper_changed
mudou.
Action_time_changed
Ação de transmissão: a hora foi definida.
Action_time_tick
Ação de transmissão: a hora atual mudou.
Action_timezone_changed
Ação de transmissão: o fuso horário mudou.
Ação de transmissão: o estado de cobrança, ou cobrança
Action_battery_changed
O nível da bateria mudou.
Ação de transmissão: indica baixa condição da bateria
Action_battery_low
no dispositivo. Esta transmissão corresponde ao
Caixa de diálogo do sistema "Baixa bateria".
Ação de transmissão: indica que a bateria agora está bem
depois de estar baixo. Isso será enviado
Action_battery_okay
depois de action_battery_low uma vez a bateria
voltou a um bom estado.
Estado de rede
Ação intenção
Descrição
Ação de intenção de transmissão indicando que o
Network_state_changed_action
O estado de conectividade Wi-Fi mudou.
Ação de intenção de transmissão indicando que o
Rssi_changed_action
O RSSI (força do sinal) mudou.
Ação de intenção de transmissão indicando que um
Supplicant_state_changed_action
A conexão com o suplicante tem sido
estabelecido ou perdido.
Ação de intenção de transmissão indicando que Wi-Fi
Wifi_state_changed_action
foi ativado, desativado, habilitando,
incapacitante, ou desconhecido.
Os IDs de rede das redes configuradas
Network_Ids_Changed_Action
poderia ter mudado.
Ação de intenção de transmissão indicando que o
Action_background_data_setting_changed para uso de dados em segundo plano
valores alterados.
Transmitir intenção indicando que uma mudança em
Conectividade_action
A conectividade de rede ocorreu.
Ação de transmissão: o usuário mudou o
Action_airplane_mode_changed
Telefone para dentro ou fora do modo de avião.

Apêndice C: Considerações futuras Este apêndice esclarece certas partes deste Android
1.6 Definição de compatibilidade e, em alguns casos
Versão futura da plataforma Android. Este apêndice é apenas para fins informativos e de planejamento, e
não faz parte da definição de compatibilidade do Android 1.6.
1. Dispositivos que não são de telefonia
O Android 1.6 é destinado exclusivamente para telefones; A funcionalidade de telefonia não é opcional. Versões futuras
da plataforma Android deve tornar a telefonia opcional (e, assim, permitir o Android não-telefone
dispositivos), mas apenas os telefones são compatíveis com o Android 1.6.
2. Compatibilidade do Bluetooth
A liberação do Android 1.6 do Android não suporta APIs Bluetooth, portanto, de uma perspectiva de compatibilidade
O Bluetooth não impõe nenhuma consideração a esta versão da plataforma. No entanto, uma versão futura
do Android apresentará APIs Bluetooth. Nesse ponto, apoiar o Bluetooth se tornará obrigatório para
compatibilidade.
Consequentemente, recomendamos fortemente que os dispositivos Android 1.6 incluam Bluetooth, para que sejam
Compatível com versões futuras do Android que requerem o Bluetooth.
3. Componentes de hardware necessários
Todos os componentes de hardware na Seção 8 (incluindo Wi -Fi, magnetômetro/bússola, acelerômetro, etc.) são
necessário e não pode ser omitido. Espera -se que as versões futuras do Android façam alguns (mas não todos) de
Esses componentes opcionais, em conjunto com as ferramentas correspondentes para desenvolvedores de terceiros para lidar com esses
mudanças.
4. Aplicações de amostra
O documento de definição de compatibilidade para uma versão futura do Android incluirá um mais extenso e
Lista representativa de aplicativos do que os listados na Seção 4, acima. Para Android 1.6, o
Os aplicativos listados na Seção 4 devem ser testados.
5. Toque em telas
Versões futuras da definição de compatibilidade podem ou não permitir que os dispositivos omitam as telas sensíveis ao toque.
No entanto, atualmente grande parte da implementação da estrutura do Android assume a existência de um
tela sensível ao toque; omitir uma tela sensível ao toque quebraria substancialmente todos os aplicativos Android de terceiros atuais,
Portanto, no Android 1.6, é necessária uma tela sensível ao toque para a compatibilidade.

6. Desempenho
Versões futuras do CTS também medirão a utilização e o desempenho da CPU do seguinte
Componentes de uma implementação:
• Gráficos 2D
• gráficos 3D
• Reprodução de vídeo
• Reprodução de áudio
• Playback A2DP Bluetooth

Definição de compatibilidade do Android 1.6

Esboço do documento