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 1.6
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

1. Introdução
Este documento enumera os requisitos que precisam ser atendidos para que os smartphones sejam
compatíveis com o Android 1.6. Esta definição pressupõe conhecimento do Programa de compatibilidade do Android
[Resources, 1].
O uso de "precisa", "não pode", "obrigatório", "deve", "não deve", "recomendado",
"pode" e "opcional" é conforme o padrão IETF definido na RFC2119 [Recursos, 2].
No presente documento, "implementador de dispositivo" ou "implementador" é uma pessoa ou organização que desenvolve
uma solução de hardware/software que usa o Android 1.6. Uma "implementação de dispositivo" ou "implementação" é a
solução de hardware/software desenvolvida.
Para serem consideradas compatíveis com o Android 1.6, as implementações de dispositivos:
1. PRECISAM atender aos requisitos apresentados nesta definição de compatibilidade, incluindo todos os documentos
incorporados por referência.
2. PRECISA ser aprovado no Teste de compatibilidade do Android (CTS, na sigla em inglês) disponível como parte do Android Open
Source Project [Resources, 3]. O CTS testa a maioria, mas não todos, os componentes descritos neste documento
.
Quando essa definição ou o CTS for silencioso, ambíguo ou incompleto, será responsabilidade do implementador do dispositivo
garantir a compatibilidade com as implementações atuais. Por esse motivo, o Android Open
Source Project [Resources, 4] é a implementação de referência e preferencial do Android. Recomendamos que os implementadores de dispositivos
baseiem as implementações no código-fonte "upstream"
disponível no Android Open Source Project. Embora alguns componentes possam ser hipoteticamente substituídos
por implementações alternativas, essa prática é desencorajada, porque passar nos testes do CTS vai ficar
substancialmente mais difícil. É responsabilidade do implementador garantir a compatibilidade comportamental total com
a implementação padrão do Android, incluindo e além do conjunto de testes de compatibilidade.
2. Recursos
Esta definição de compatibilidade faz referência a vários recursos que podem ser acessados aqui.
1. Visão geral do Programa de compatibilidade do Android: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. Níveis de requisito do IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Conjunto de teste de compatibilidade: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Android Open Source Project: 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-
summary.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/
Manifest.permission.html
10. Constantes de build: 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
de verificação; também disponível em http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
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 de ícones da barra de status: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Gerenciador de pesquisa: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Apps 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. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Serviço de monitoramento de depuração do Dalvik (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. Documentação sobre independência da tela:
25. Constantes de configuração: http://developer.android.com/reference/android/content/res/
Configuration.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/
security.html
Muitos desses recursos são derivados direta ou indiretamente do SDK do Android 1.6 e são
funcionalmente idênticos às informações na documentação desse SDK. Em qualquer caso em que esta definição de compatibilidade
não estiver de acordo com a documentação do SDK, a documentação do SDK será considerada
autoritária. Todos os detalhes técnicos fornecidos nas referências acima são considerados por inclusão
como parte desta definição de compatibilidade.
3. Software
A plataforma Android inclui um conjunto de APIs gerenciadas ("rígidas") e um conjunto de APIs chamadas de "flexíveis"
, como o sistema de intents, APIs de código nativo e APIs de aplicativos da Web. Esta seção detalha as APIs rígidas e
flexíveis que são essenciais para a compatibilidade, além de alguns outros comportamentos
técnicos e de interface do usuário relevantes. As implementações de dispositivos precisam obedecer a todos os requisitos desta seção.
3.1. Compatibilidade com a API gerenciada
O ambiente de execução gerenciado (baseado em Dalvik) é o principal veículo para aplicativos Android. A
interface de programação de aplicativos (API) do Android é o conjunto de interfaces da plataforma Android expostas a
aplicativos executados no ambiente de VM gerenciado. As implementações de dispositivos PRECISAM fornecer implementações
completas, incluindo todos os comportamentos documentados, de qualquer API documentada exposta pelo SDK
1.6 do Android, como:
1. APIs principais do Android em linguagem Java [Resources, 5].
2. Provedores de conteúdo [Resources, 6].
3. Recursos [Resources, 7].
4. Atributos e elementos do AndroidManifest.xml [Resources, 8].

As implementações de dispositivos NÃO PODEM omitir APIs gerenciadas, alterar interfaces ou assinaturas de API, desviar
do comportamento documentado ou incluir no-ops, exceto quando especificamente permitido por esta definição de
compatibilidade.
3.2. Compatibilidade com APIs flexíveis
Além das APIs gerenciadas da seção 3.1, o Android também inclui uma API
flexível significativa somente para execução, na forma de intents, permissões e aspectos semelhantes de aplicativos Android
que não podem ser aplicados no momento da compilação do aplicativo. Esta seção detalha as APIs "soft" e os comportamentos do sistema
necessários para a compatibilidade com o Android 1.6. As implementações de dispositivos PRECISAM atender a todos os
requisitos apresentados nesta seção.
3.2.1. Permissões
Os implementadores de dispositivos precisam oferecer suporte e aplicar todas as constantes de permissão, conforme documentado na
página de referência de permissões [Recursos, 9]. A seção 10 lista requisitos adicionais relacionados 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, 10] que
têm a finalidade de descrever o dispositivo atual. Para fornecer valores consistentes e significativos em todas as implementações de
dispositivos, a tabela abaixo inclui outras restrições sobre os formatos desses valores aos quais as implementações de
dispositivos PRECISAM se conformar.
Parâmetro
Comentários
A versão do sistema Android em execução no momento, em formato legível por humanos
android.os.Build.VERSION.RELEASE
. Para o Android 1.6, esse campo PRECISA ter o valor de string
"1.6".
A versão do sistema Android em execução no momento, em um formato
android.os.Build.VERSION.SDK
acessível para o código de aplicativos de terceiros. Para o Android 1.6, esse campo
PRECISA ter o valor inteiro 4.
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 enviados aos usuários
android.os.Build.VERSION.INCREMENTAL. 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 deste campo, exceto que ele
NÃO PODE ser nulo ou a 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
android.os.Build.BOARD
deste campo é indicar a revisão específica da placa que alimenta o
dispositivo. Não há requisitos para o formato específico deste campo,
exceto que ele NÃO PODE ser nulo ou a string vazia ("").
Um valor escolhido pelo implementador do dispositivo que identifica o nome da
android.os.Build.BRAND
empresa, organização, indivíduo etc. que produziu o dispositivo, em
formato legível por humanos. Um possível uso desse campo é indicar o OEM

e/ou a operadora que vendeu o dispositivo. Não há requisitos para o formato
específico desse campo, exceto que ele NÃO PODE ser nulo ou a string
vazia ("").
Um valor escolhido pelo implementador do dispositivo que identifica a configuração
específica ou a revisão do corpo (às vezes chamada de "design
android.os.Build.DEVICE
industrial") do dispositivo. Não há requisitos para o formato específico
deste campo, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
Uma string que identifica exclusivamente esse build. Ele DEVE ser razoavelmente
legível por humanos. Ele PRECISA 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/test-keys
A impressão digital PRECISA NÃO incluir espaços. Se outros campos incluídos no
modelo acima tiverem espaços, eles PRECISAM ser substituídos pelo caractere sublinhado ASCII
("_") na impressão digital.
Uma string que identifica de maneira exclusiva o host em que o build foi criado, no formato legível
android.os.Build.HOST
. Não há requisitos para o formato específico desse campo
, exceto que ele NÃO PODE ser nulo ou a string vazia ("").
Um identificador escolhido pelo implementador do dispositivo para se referir a uma versão
específica, em um formato legível por humanos. Esse campo pode ser o mesmo que
android.os.Build.VERSION.INCREMENTAL, mas DEVE ser um valor
android.os.Build.ID
com o objetivo de ser significativo para os usuários finais. Não há
requisitos para o formato específico desse campo, exceto que ele NÃO
pode 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. Ele DEVE ser o mesmo nome
android.os.Build.MODEL
com que o dispositivo é comercializado e vendido para usuários finais. Não há
requisitos para o formato específico desse campo, exceto que ele NÃO
pode 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 dispositivo. PRECISA ser legível por humanos, mas não
android.os.Build.PRODUCT
necessariamente destinado a ser visualizado pelos usuários finais. Não há requisitos
para o formato específico deste campo, exceto que ele NÃO PODE ser nulo ou a
string vazia ("").
Uma lista de tags separadas por vírgulas escolhidas pelo implementador do dispositivo que
diferenciam ainda mais o build. Por exemplo, "unsigned,debug". Esse campo
android.os.Build.TAGS
NÃO PODE ser nulo ou uma string vazia (""), mas uma única tag (como
"release") é válida.
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
android.os.Build.TYPE
correspondentes às três configurações típicas do ambiente de execução do Android: "user",
"userdebug" ou "eng".
Um nome ou ID do usuário (ou usuário automatizado) que gerou o build
android.os.Build.USER
. Não há requisitos para o formato específico deste campo,
exceto que ele NÃO PODE ser nulo ou a string vazia ("").

3.2.3. Compatibilidade com intents
O Android usa intents para conseguir uma integração frouxa entre os apps. Esta seção descreve
os requisitos relacionados aos padrões de intent que precisam ser atendidos pelas implementações de dispositivos. Por
"honrado", significa que o implementador do dispositivo PRECISA fornecer uma atividade do Android, um serviço ou outro componente
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 principais
O projeto upstream do Android define vários aplicativos principais, como discador de telefone, agenda,
livro de contatos, player de música e assim por diante. Os implementadores de dispositivos PODEM substituir esses aplicativos por
versões alternativas.
No entanto, todas essas versões alternativas precisam respeitar os mesmos padrões de intent fornecidos pelo projeto
upstream. Por exemplo, se um dispositivo tiver um player de música alternativo, ele ainda precisa respeitar o padrão de intent
emitido por aplicativos de terceiros para escolher uma música. As implementações de dispositivos precisam oferecer suporte a todos os padrões de intent
listados no Apêndice A.
3.2.3.2. Substituições de intent
Como o Android é uma plataforma extensível, os implementadores de dispositivos PRECISAM permitir que cada padrão de intent descrito no
Apêndice A seja substituído por aplicativos de terceiros. O projeto de código aberto do Android
permite isso por padrão. Os implementadores de dispositivos NÃO PODEM anexar privilégios especiais ao uso de
esses padrões de intent pelos aplicativos do sistema ou impedir que aplicativos de terceiros se associem a eles e assumam o controle
deles. Essa proibição inclui especificamente a desativação da interface do usuário "Chooser", que permite
ao usuário selecionar entre vários aplicativos que processam o mesmo padrão de intent.
3.2.3.3. Namespaces de intent
Os implementadores de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou
intent de transmissão usando uma string de chave ACTION, CATEGORY ou outra no namespace android.*.
Os implementadores de dispositivos NÃO PODEM incluir nenhum componente do Android que respeite novos padrões de intent ou
intent de transmissão usando uma string de chave ACTION, CATEGORY ou outra em um espaço de pacote
pertencente a outra organização. Os implementadores de dispositivos NÃO PODEM alterar ou estender nenhum dos padrões de intent
listados nos Apêndices A ou B.
Essa proibição é análoga à especificada para classes de linguagem Java na seção 3.6.

3.2.3.4. Intents de transmissão
Os aplicativos de terceiros dependem da plataforma para transmitir determinadas intents e receber notificações sobre mudanças no
ambiente de hardware ou software. Os dispositivos compatíveis com o Android precisam transmitir as intents
de transmissão pública em resposta a eventos do sistema adequados. Uma lista de intents de transmissão obrigatórias está disponível no
apêndice B. No entanto, o SDK pode definir intents de transmissão adicionais, que também precisam ser
atendidas.
3.3. Compatibilidade com a API nativa
O código gerenciado em execução no Dalvik pode chamar o código nativo fornecido no arquivo .apk do aplicativo como um arquivo ELF
.so compilado para a arquitetura de hardware do dispositivo. As implementações de dispositivos PRECISAM incluir
suporte para o código executado no ambiente gerenciado para chamar o código nativo, usando a semântica padrão da Java
Native Interface (JNI). As seguintes APIs precisam estar disponíveis para o 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 precisam ser compatíveis com a origem (ou seja, com o cabeçalho) e com o binário (para uma determinada
arquitetura de processador) com as versões fornecidas no Bionic pelo projeto Android Open Source. Como
as implementações do Bionic não são totalmente compatíveis com outras implementações, como a biblioteca GNU C
, os implementadores de dispositivos DEVEM usar a implementação do Android. Se os implementadores de dispositivos usarem uma
implementação diferente dessas bibliotecas, eles precisarão garantir a compatibilidade do cabeçalho e do binário.
A compatibilidade com o código nativo é desafiadora. Por esse motivo, queremos repetir que os implementadores de dispositivos
são MUITO encorajados a usar as implementações upstream das bibliotecas listadas acima para ajudar
a garantir a compatibilidade.
3.4. Compatibilidade com a API da Web
Muitos desenvolvedores e aplicativos dependem do comportamento da classe android.webkit.WebView [Resources,
11] para as interfaces do usuário. Portanto, a implementação da WebView precisa ser compatível com as implementações do Android
. A implementação do Android Open Source usa a versão do mecanismo de renderização do WebKit para
implementar a WebView.
Como não é viável desenvolver um conjunto de testes abrangente para um navegador da Web, os implementadores de dispositivos
PRECISAM usar o build upstream específico do WebKit na implementação da WebView. Especificamente:
• A WebView PRECISA usar o build 528.5+ do WebKit da árvore do Android Open Source upstream para
o Android 1.6. Esse build inclui um conjunto específico de correções de segurança e funcionalidade para a WebView.
• A string de user agent informada pela WebView PRECISA estar neste formato:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, like Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ A string "<device name>" PRECISA ser igual ao valor de
android.os.Build.MODEL
◦ A string "<build ID>" PRECISA ser igual ao valor de android.os.Build.ID.
◦ As strings "<language>" e "<country>" DEVEM seguir as convenções usuais para
código de país e idioma e DEVEM se referir à localidade atual do dispositivo no momento da solicitação.

As implementações podem enviar uma string de user agent personalizada no aplicativo de navegador independente. Além disso,
o navegador independente pode ser baseado em uma tecnologia de navegador alternativa (como o Firefox,
Opera etc.). No entanto, mesmo que um aplicativo de navegador alternativo seja enviado, o componente WebView
fornecido a aplicativos de terceiros PRECISA ser baseado no WebKit, como acima.
O aplicativo de navegador independente PRECISA incluir suporte a Gears [Resources, 12] e PODE
incluir suporte a parte ou a todos os recursos do HTML5.
3.5. Compatibilidade comportamental da API
Os comportamentos de cada um dos tipos de API (gerenciada, leve, nativa e da Web) precisam ser consistentes com a
implementação preferencial do Android disponível no Projeto Android Open Source.
Algumas áreas específicas de compatibilidade são:
• Os dispositivos NÃO PODEM mudar o comportamento ou o significado de uma intent padrão
• Os dispositivos NÃO PODEM alterar o ciclo de vida ou a semântica do ciclo de vida de um tipo específico de componente do sistema
(como Service, Activity, ContentProvider etc.)
• Os dispositivos NÃO PODEM mudar a semântica de uma permissão específica
A lista acima não é abrangente, e a responsabilidade é dos implementadores de dispositivos para garantir a compatibilidade
comportamental. Por esse motivo, os implementadores de dispositivos PRECISAM usar o código-fonte disponível no
Android Open Source Project sempre que possível, em vez de implementar novamente partes significativas do sistema.
O conjunto de teste de compatibilidade (CTS) testa partes significativas da plataforma para compatibilidade comportamental,
mas não todas. É responsabilidade do implementador garantir a compatibilidade comportamental com o Android
Open Source Project.
3.6. Namespaces de API
O Android segue as convenções de namespace de pacote e classe definidas pela linguagem de programação Java
. Para garantir a compatibilidade com aplicativos de terceiros, os implementadores de dispositivos NÃO PODEM
fazer modificações proibidas (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
mudando qualquer assinatura 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 qualquer
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" no
código-fonte do Android upstream. Em outras palavras, os implementadores de dispositivos NÃO PODEM expor novas APIs ou
alterar APIs existentes nos namespaces indicados acima. Os implementadores de dispositivos PODEM fazer modificações
somente 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
pertencente a outra organização ou que se refira a ela. Por exemplo, os implementadores de dispositivos NÃO PODEM adicionar APIs ao namespace
com.google.* ou semelhante. Somente o Google pode fazer isso. Da mesma forma, o Google NÃO PODE adicionar APIs aos namespaces
de outras empresas.
Se um implementador de dispositivo propor a melhoria de um dos namespaces de pacote acima (por exemplo, adicionando
novas funcionalidades úteis a uma API existente ou adicionando uma nova API), ele PRECISA acessar
source.android.com e iniciar o processo de contribuição de mudanças e código, de acordo com as
informações desse site.
As restrições acima correspondem a convenções padrão para nomear APIs na linguagem de programação Java
. O objetivo desta seção é simplesmente reforçar essas convenções e torná-las obrigatórias
com a inclusão nesta definição de compatibilidade.
3.7. Compatibilidade com máquinas virtuais
Um dispositivo Android compatível precisa oferecer suporte à especificação completa do bytecode do Dalvik Executable (DEX) e à
semântica da máquina virtual Dalvik [Resources, 13].
3.8. Compatibilidade com a interface do usuário
A plataforma Android inclui algumas APIs que permitem que os desenvolvedores se conectem à interface
do usuário do sistema. As implementações de dispositivos precisam incorporar essas APIs de interface padrão às interfaces do usuário personalizadas
que eles desenvolvem, conforme explicado abaixo.
3.8.1. Widgets
O Android define um tipo de componente e a API e o ciclo de vida correspondentes que permitem que os aplicativos exponham
um "AppWidget" ao usuário final [Resources, 14]. A versão de referência do Android Open Source inclui um aplicativo
Launcher que inclui elementos da interface do usuário que permitem adicionar, visualizar e remover widgets
App da tela inicial.
Os implementadores de dispositivos PODEM substituir uma alternativa ao iniciador de referência (ou seja, a tela inicial).
Os iniciadores alternativos PRECISAM incluir suporte integrado a widgets de apps e expor elementos da interface
do usuário para adicionar, visualizar e remover widgets de apps diretamente no iniciador. Os iniciadores alternativos PODEM
omitir esses elementos da interface do usuário. No entanto, se eles forem omitidos, o implementador do dispositivo PRECISA fornecer um
aplicativo separado acessível pelo iniciador que permita aos usuários adicionar, visualizar e remover
widgets de app.

3.8.2. Notificações
O Android inclui APIs que permitem que os desenvolvedores notifiquem os usuários sobre eventos importantes [Resources, 15]. Os implementadores de
dispositivos precisam oferecer suporte a cada classe de notificação definida, especificamente: sons,
vibração, luz e barra de status.
Além disso, a implementação PRECISA renderizar corretamente e todos os recursos (ícones, arquivos de som etc.)
fornecidos nas APIs [Resources, 7] ou no guia de estilo de ícones da barra de status [Resources, 16]. Os implementadores de
dispositivos podem oferecer uma experiência do usuário alternativa para notificações diferente da
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, como acima.
3.8.3. Pesquisa
O Android inclui APIs [Resources, 17] que permitem que os desenvolvedores incorporem a pesquisa aos apps
e exponham os dados do app à pesquisa global do sistema. Em geral, essa funcionalidade
consiste em uma única interface do usuário em todo o sistema que permite a entrada de consultas, mostra sugestões
à medida que os usuários digitam e exibe os resultados. As APIs do Android permitem que os desenvolvedores reutilizem essa interface para oferecer
a pesquisa nos próprios apps e fornecer resultados à interface
de usuário da pesquisa global comum.
As implementações de dispositivos precisam incluir uma interface do usuário de pesquisa única, compartilhada e em todo o sistema, capaz de
fazer sugestões em tempo real em resposta à entrada do usuário. As implementações de dispositivos precisam implementar as APIs que
permitem que os desenvolvedores reutilizem essa interface do usuário para oferecer pesquisa nos próprios aplicativos.
As implementações de dispositivos precisam implementar as APIs que permitem que aplicativos de terceiros adicionem sugestões
à caixa de pesquisa quando ela é executada no modo de pesquisa global. Se nenhum aplicativo de terceiros estiver instalado que
use essa funcionalidade, o comportamento padrão VAI SER mostrar os resultados do mecanismo de pesquisa da Web e as
sugestões.
As implementações de dispositivos PODEM enviar interfaces do usuário de pesquisa alternativas, mas PRECISAM incluir um botão de pesquisa dedicado
, rígido ou flexível, que possa ser usado a qualquer momento em qualquer app para invocar o framework de pesquisa,
com o comportamento fornecido na documentação da API.
3.8.4. Mensagens
Os aplicativos podem usar a API Toast (definida em [Resources, 18]) para mostrar strings não modais curtas ao
usuário final, que desaparecem após um breve período. As implementações de dispositivos precisam mostrar notificações
aos usuários finais de maneira bem visível.
4. Compatibilidade de referência do software
Os implementadores de dispositivos PRECISAM testar a compatibilidade da implementação usando os seguintes aplicativos
de código aberto:
• Calculadora (incluída no SDK)
• Lunar Lander (incluída no SDK)
• ApiDemos (incluída no SDK)
• Os aplicativos "Apps para Android" [Recursos, 19]
Cada app acima PRECISAM ser iniciado e se comportar corretamente na implementação para que ela seja

considerada compatível.
5. Compatibilidade de empacotamento de aplicativos
As implementações de dispositivos precisam instalar e executar arquivos ".apk" do Android conforme gerados pela ferramenta "aapt"
incluída no SDK oficial do Android [Resources, 20].
As implementações de dispositivos NÃO PODEM estender os formatos .apk, Manifest do Android ou bytecode Dalvik
de forma a impedir que esses arquivos sejam instalados e executados corretamente em outros dispositivos
compatíveis. Os implementadores de dispositivos precisam usar a implementação upstream de referência do Dalvik,
e o sistema de gerenciamento de pacotes da implementação de referência.
6. Compatibilidade com multimídia
Um dispositivo Android compatível precisa oferecer suporte aos seguintes codecs de multimídia. Todos esses codecs são
fornecidos como implementações de software na implementação preferida do Android do Android Open
Source Project [Resources, 4].
Nem o Google nem a Open Handset Alliance afirmam que esses
codecs não estão sujeitos a patentes de terceiros. Aqueles que pretendem usar esse código-fonte em produtos de hardware ou
software são informados de que as implementações desse código, incluindo em software de código aberto ou
shareware, podem exigir licenças de patente dos detentores de patente relevantes.
Áudio
Nome
Detalhes do codificador/decodificador
Arquivos compatíveis
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 de taxas de amostragem. Não há suporte para
raw entre 8 e 48 kHz
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 de taxas de amostragem. Não há suporte para
raw entre 8 e 48 kHz
AAC (.aac)
conteúdo mono/estéreo em qualquer
HE-AACv2
3GPP (.3gp) e
combinação de taxas de bits padrão
(MPEG-4
(.mp4, .m4a)
X
até 96 kbps e taxas de amostragem
AAC+)
arquivos. Não há suporte para
brutos entre 8 e 48 kHz
AAC (.aac)
AMR-NB
4,75 a 12,2 kbps amostrados em
arquivos 3GPP (.3gp)
X
X
8 kHz
AMR-WB
9 taxas de 6,60 kbit/s a 23,85
- arquivos 3GPP (.3gp)
X
kbit/s amostrados em 16 kHz
MP3
Arquivos MP3 (.mp3) de 8 a 320 kbps constantes
X
(CBR) ou taxa de bits variável (VBR)
Tipo 0 e 1 (.mid, .xmf,
MIDI tipo 0 e 1. DLS Version 1
MIDI
X
.mxmf). Também RTTTL/RTX
e 2. XMF e XMF para celular.
(.rtttl, .rtx), OTA (.ota),

Compatível com os formatos de toque
e iMelody (.imy)
RTTTL/RTX, OTA e iMelody
Ogg Vorbis
.ogg
X
PCM linear de 8 e 16 bits (taxas de até
PCM
X
WAVE
até o limite do hardware)
Imagem
Arquivos
Nome
Detalhes do decodificador/codificador
Compatível
JPEG
X
X
base+progressivo
GIF
X
PNG
X
X
BMP
X
Vídeo
Arquivos
Nome
Detalhes do decodificador/codificador
Compatível
3GPP (.3gp)
H.263
X
X
arquivos
3GPP (.3gp)
H.2064
X
e arquivos MPEG-4
(.mp4)
MPEG4
X
arquivo 3GPP (.3gp)
SP
7. 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 ou adb [Resources, 21]
As implementações de dispositivos precisam oferecer suporte a todas as funções do adb, conforme documentado no SDK do Android
. O daemon adb do dispositivo PRECISA estar inativo por padrão, mas PRECISA haver um mecanismo acessível ao
usuário para ativar a ponte de depuração do Android.
• Dalvik Debug Monitor Service ou ddms [Resources, 22]
As implementações de dispositivos precisam oferecer suporte a todos os recursos de ddms, conforme documentado no SDK do Android.
Como o ddms usa o adb, o suporte a ele precisa estar inativo por padrão, mas precisa ser oferecido quando o usuário ativar o Android Debug Bridge, como acima.

• Monkey [Resources, 23]
As implementações de dispositivos precisam incluir o framework Monkey e disponibilizá-lo para uso por
aplicativos.
8. Compatibilidade com hardware
O Android tem como objetivo oferecer suporte aos implementadores de dispositivos que criam formatos e configurações inovadores.
Ao mesmo tempo, os desenvolvedores do Android esperam que determinados hardwares, sensores e APIs sejam usados em todos os dispositivos
Android. Esta seção lista os recursos de hardware com que todos os dispositivos compatíveis com o Android 1.6 precisam ser compatíveis. No
Android 1.6, a maioria dos recursos de hardware (como Wi-Fi, bússola e acelerômetro) é obrigatória.
Se um dispositivo incluir um componente de hardware específico que tenha uma API correspondente para desenvolvedores
de terceiros, a implementação do dispositivo PRECISA implementar essa API conforme definido na documentação do SDK
do Android.
8.1. Exibição
O Android 1.6 inclui recursos que executam determinadas operações automáticas de escalonamento e transformação em
algumas circunstâncias, para garantir que os aplicativos de terceiros sejam executados de forma razoável em configurações de
hardware para as quais eles não foram necessariamente projetados explicitamente [Resources, 24]. Os dispositivos
PRECISAM implementar esses comportamentos corretamente, conforme detalhado nesta seção.
8.1.1. Configurações de tela 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 a 3,0
Pequeno
Baixo
WQVGA
240
400
3,2 a 3,5
Normal
Baixo
FWQVGA
240
432
3,5 a 3,8
Normal
Baixo
HVGA
320
480
3,0 a 3,5
Normal
Médio
WVGA
480
800
3,3 a 4,0
Normal
Alto
FWVGA
480
854
3,5 a 4,0
Normal
Alto
WVGA
480
800
4,8 a 5,5
Grande
Médio
FWVGA
480
854
5,0 a 5,8
Grande
Médio
As implementações de dispositivos correspondentes a uma das configurações padrão acima PRECISAM ser configuradas
para informar o tamanho da tela indicado aos aplicativos pela classe android.content.res.Configuration [Resources,
25].
Alguns pacotes .apk têm manifestos que não os identificam como compatíveis com um intervalo de densidade específico.
Ao executar esses apps, as seguintes restrições são aplicadas:

• As implementações de dispositivos PRECISAM interpretar todos os recursos presentes como padrão para
"medium" (conhecido como "mdpi" na documentação do SDK).
• Quando operados em uma tela de densidade "baixa", as implementações de dispositivos PRECISAM reduzir os recursos de mdpi médio/
em um fator de 0,75.
• Quando operar em uma tela de densidade "alta", as implementações de dispositivo PRECISAM aumentar os recursos de mdpi médio/
em um fator de 1,5.
• As implementações de dispositivos NÃO PODEM dimensionar recursos dentro de um intervalo de densidade e PRECISAM dimensionar
recursos exatamente por esses fatores entre intervalos de densidade.
8.1.2. Configurações de exibição não padrão
As configurações de exibição que não correspondem a uma das configurações padrão listadas na seção 8.2.1 exigem
consideração e trabalho adicionais para serem compatíveis. Os implementadores de dispositivos PRECISAM entrar em contato com a equipe de compatibilidade
do Android conforme descrito na Seção 12 para receber classificações de tamanho de tela, densidade
e fator de escalonamento. Quando essas informações são fornecidas, as implementações de dispositivo PRECISAM implementá-las
conforme especificado.
Observe que algumas configurações de tela (como telas muito grandes ou muito pequenas e algumas proporções)
são incompatíveis com o Android 1.6. Portanto, recomendamos que os implementadores de dispositivos
entrem em contato com a equipe de compatibilidade do Android o mais cedo possível no processo de desenvolvimento.
8.1.3. Métricas de tela
As implementações de dispositivos precisam informar os valores corretos para todas as métricas de tela definidas em
android.util.DisplayMetrics [Resources, 26].
8.2. Teclado
Implementações do dispositivo:
• PRECISA incluir suporte ao framework de gerenciamento de entrada, que permite que desenvolvedores
de terceiros criem mecanismos de gerenciamento de entrada, ou seja, teclados virtuais, conforme detalhado em
developer.android.com
• PRECISA fornecer pelo menos uma implementação de teclado virtual (independentemente de um teclado
físico estar presente)
• PODE incluir outras implementações de teclado virtual
• PODE incluir um teclado físico
• NÃO PODE incluir um teclado físico que não corresponda a um dos formatos especificados
em android.content.res.Configuration [Resources, 25] (ou seja, QWERTY ou 12 teclas)
8.3. Navegação sem toque
Implementações do dispositivo:
• PODE omitir opções de navegação sem toque (ou seja, pode omitir um trackball, um pad direcional de cinco posições ou
roda)
• PRECISA informar pelo android.content.res.Configuration [Resources, 25] o valor correto para o
hardware do dispositivo

8.4. Orientação da tela
Os dispositivos compatíveis precisam oferecer suporte à orientação dinâmica por aplicativos para orientação de tela
de 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 que forem consultados pela
android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou outras APIs.
8.5. Entrada de touchscreen
Implementações do dispositivo:
• PRECISA ter uma touchscreen
• PODE ter touchscreen resistiva ou capacitiva
• PRECISA informar o valor de android.content.res.Configuration [Resources, 25] refletindo
o tipo de touchscreen específico no dispositivo
8.6. USB
Implementações do dispositivo:
• É NECESSÁRIO implementar um cliente USB, conectável a um host USB com uma porta USB-A padrão
• É NECESSÁRIO implementar a ponte de depuração do Android por USB (conforme descrito na seção 7)
• É NECESSÁRIO implementar um cliente de armazenamento em massa USB para que o armazenamento removível/de mídia esteja presente no
dispositivo
• É NECESSÁRIO usar o formato micro USB no dispositivo
• É NECESSÁRIO implementar suporte para a especificação de armazenamento em massa USB (para que o armazenamento removível
ou fixo no dispositivo possa ser acessado de um PC host)
• É POSSÍVEL incluir uma porta não padrão no dispositivo, mas, se isso acontecer, é NECESSÁRIO enviar um cabo capaz de
conectar a pinagem personalizada à porta USB-A padrão
8.7. Teclas de navegação
As funções "Início", "Menu" e "Voltar" são essenciais para o paradigma de navegação do Android. As implementações do
dispositivo precisam disponibilizar essas funções ao usuário o tempo todo, independentemente do estado do
aplicativo. Essas funções precisam ser implementadas com botões dedicados. Elas PODEM ser implementadas
usando software, gestos, painel de toque etc., mas, se forem, PRECISAM estar sempre acessíveis e não obscurecer ou
interferir na área de exibição do aplicativo disponível.
Os implementadores de dispositivos também precisam fornecer uma chave de pesquisa dedicada. Os implementadores de dispositivos também podem
fornecer chaves de envio e encerramento para ligações.
8.8. Wi-Fi
As implementações de dispositivos precisam oferecer suporte a 802.11b e 802.11g e podem oferecer suporte a 802.11a.

8.9. Câmera
As implementações de dispositivos precisam incluir uma câmera. A câmera incluída:
• PRECISA ter uma resolução de pelo menos 2 megapixels
• PRECISA ter foco automático de hardware ou 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, a lâmpada de flash NÃO PODE ser acesa enquanto uma instância
android.hardware.Camera.PreviewCallback estiver registrada em uma superfície
de visualização da câmera.
As implementações de dispositivos precisam implementar os seguintes comportamentos para as APIs relacionadas à câmera
[Resources, 27]:
1. Se um app nunca chamou android.hardware.Camera.Parameters.setPreviewFormat(int),
o dispositivo PRECISA usar android.hardware.PixelFormat.YCbCr_420_SP para dados de visualização
fornecidos aos callbacks do app.
2. Se um aplicativo registrar uma instância android.hardware.Camera.PreviewCallback e o
sistema chamar o método onPreviewFrame() quando o formato de visualização for YCbCr_420_SP, os dados
no byte[] transmitido para onPreviewFrame() precisarão estar no formato de codificação NV21.
Esse é o formato usado de forma nativa pela família de hardware 7k. Ou seja, o NV21 PRECISA ser o padrão.
8.9.1. Câmeras sem autofoco
Se um dispositivo não tiver uma câmera com autofoco, o implementador do dispositivo PRECISA atender aos requisitos adicionais desta seção.
As implementações de dispositivos precisam implementar a API Camera completa incluída na documentação do SDK do Android 1.6
de maneira razoável, independentemente dos recursos reais do hardware da câmera.
No Android 1.6, se a câmera não tiver foco automático, a implementação do dispositivo PRECISA aderir ao seguinte:
1. O sistema PRECISA incluir uma propriedade do sistema somente leitura chamada "ro.workaround.noautofocus"
com o valor "1". Esse valor é destinado a ser usado por aplicativos como o Android Market para
identificar seletivamente os recursos do dispositivo e será substituído em uma versão futura do Android por uma API
robusta.
2. Se um aplicativo chamar android.hardware.Camera.autoFocus(), o sistema PRECISA chamar o método de callback
onAutoFocus() em qualquer instância registrada de
android.hardware.Camera.AutoFocusCallback, mesmo que nenhuma focagem tenha realmente
ocorrido. Isso evita que os aplicativos atuais sejam interrompidos ao esperar para sempre por um callback de
de autofoco que nunca vai chegar.
3. A chamada para o método AutoFocusCallback.onAutoFocus() PRECISA ser acionada pelo driver ou pelo framework
em um novo evento na linha de execução do looper do framework principal. Ou seja, o Camera.autoFocus()
NÃO PODE chamar diretamente o AutoFocusCallback.onAutoFocus(), porque isso viola o modelo de linha de execução do framework
do Android e quebra os apps.
8.10. Acelerômetro
As implementações de dispositivos precisam incluir um acelerômetro de 3 eixos e precisam ser capazes de enviar eventos a pelo menos
50 Hz. O sistema de coordenadas usado pelo acelerômetro precisa estar em conformidade com o sistema de coordenadas do sensor
do Android, conforme detalhado nas APIs do Android[Resources, 28].

8.11. Bússola
As implementações de dispositivos precisam incluir uma bússola de 3 eixos e precisam ser capazes de enviar eventos a pelo menos
10 Hz. O sistema de coordenadas usado pela bússola precisa estar em conformidade com o
sistema de coordenadas do sensor do Android, conforme definido na API do Android [Resources, 28].
8.12. GPS
As implementações de dispositivos PRECISAM incluir um GPS e DEVEM incluir alguma forma de técnica de
"GPS assistido" para minimizar o tempo de bloqueio do GPS.
8.13. Telefonia
Implementações de dispositivos:
• PRECISA incluir telefonia GSM ou CDMA
• PRECISA implementar as APIs apropriadas, conforme detalhado na documentação do SDK do Android em
developer.android.com
Esse requisito implica que dispositivos que não são smartphones não são compatíveis com o Android 1.6. Os dispositivos Android
1.6 PRECISAM incluir hardware de telefonia. Consulte o Apêndice C para informações sobre dispositivos que não são
smartphones.
8.14. Controles de volume
Os dispositivos compatíveis com Android precisam incluir um mecanismo que permita ao usuário aumentar e diminuir o
volume do áudio. As implementações de dispositivo precisam disponibilizar essas funções ao usuário o tempo todo,
independentemente do estado do aplicativo. Essas funções PODEM ser implementadas usando teclas físicas de hardware,
software, gestos, painel de toque etc., mas elas PRECISAM estar sempre acessíveis e não podem obscurecer ou interferir
na área de exibição do aplicativo disponível (consulte "Exibição" acima).
Quando esses botões são usados, os eventos de tecla correspondentes precisam ser gerados e enviados ao aplicativo
em primeiro plano. Se o evento não for interceptado e enviado pelo aplicativo, a implementação do dispositivo
PRECISA processar o evento como um controle de volume do sistema.
9. Compatibilidade de desempenho
Uma das metas do Programa de compatibilidade do Android é garantir uma experiência de aplicativo consistente para
os consumidores. As implementações compatíveis precisam garantir que os aplicativos sejam executados corretamente no
dispositivo, mas também que o façam com um desempenho razoável e uma boa experiência geral para o usuário.
As implementações de dispositivos PRECISAM atender às principais métricas de desempenho de um dispositivo compatível com o Android 1.6,
como na tabela abaixo:
Métrica
Limite de desempenho
Comentários

Isso é testado pelo CTS.
Os seguintes aplicativos
O tempo de inicialização é medido como o tempo total para
ser iniciado dentro do
de carregamento completo da atividade padrão para o
aplicativo
tempo especificado.
aplicativo, incluindo o tempo necessário para iniciar o
Tempo de inicialização
do navegador: menos de 1300ms
Processo do Linux, carregue o pacote Android no
MMS/SMS: menos de 700ms
VM Dalvik e chame onCreate.
AlarmClock: menos de 650ms
Vários aplicativos serão
testados pelo CTS.
lançado. A reabertura do
primeiro aplicativo simultâneo precisa
ser concluída em menos tempo do que o
original.

10. Compatibilidade do modelo de segurança
As implementações de dispositivos precisam implementar um modelo de segurança consistente com o modelo
de segurança da plataforma Android, conforme definido no documento de referência de segurança e permissões nas APIs [Resources, 29] na
documentação para desenvolvedores do Android. As implementações de dispositivos precisam oferecer suporte à instalação de aplicativos
autoassinados sem exigir permissões/certificados adicionais de terceiros/autoridades.
Especificamente, os dispositivos compatíveis precisam oferecer suporte aos seguintes mecanismos de segurança:
10.1. Permissões
As implementações de dispositivos PRECISAM oferecer suporte ao modelo de permissões do Android, conforme definido na documentação do desenvolvedor
do Android [Resources, 9]. Especificamente, as implementações precisam aplicar cada permissão
definida conforme descrito na documentação do SDK. Nenhuma permissão pode ser omitida, alterada ou ignorada.
As implementações podem adicionar outras permissões, desde que as novas strings de ID de permissão não estejam no namespace
android.*.
10.2. Isolamento de usuário e de processo
As implementações de dispositivos precisam oferecer suporte ao modelo de sandbox de aplicativos do 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
[Recursos, 29].

10.3. Permissões do sistema de arquivos
As implementações de dispositivos precisam oferecer suporte ao modelo de permissões de acesso a arquivos do Android, conforme definido na
referência de segurança e permissões [Resources, 29].
11. Conjunto de teste de compatibilidade
As implementações de dispositivos precisam ser aprovadas no Conjunto de teste de compatibilidade do Android (CTS) [Resources, 3] disponível
do Projeto Android Open Source, usando o software de envio final no dispositivo. Além disso,
os implementadores de dispositivos DEVEM usar a implementação de referência na árvore do Android Open Source o
mais possível e DEVEM garantir a compatibilidade em casos de ambiguidade no 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.
A versão do CTS será independente dessa definição de compatibilidade, e várias revisões do
CTS podem ser lançadas para o Android 1.6. No entanto, esses lançamentos só corrigirão bugs comportamentais nos testes CTS
e não vão impor novos testes, comportamentos ou APIs para uma determinada versão da plataforma.
12. Entre em contato
Entre em contato com a equipe de compatibilidade do Android em compatibility@android.com para esclarecer dúvidas relacionadas a
esta definição de compatibilidade e enviar feedback sobre ela.

Usou
EXTRA_CREATE_DESCRIPTION
com SHOW_OR_CREATE_CONTACT para
especificar uma descrição exata a ser

mostrada ao solicitar ao usuário a
criação de um novo contato.
Usar
com SHOW_OR_CREATE_CONTACT para
EXTRA_FORCE_CREATE
forçar a criação de um novo contato se nenhum
contato correspondente for encontrado.
Essa é a intent que é acionada quando uma
SEARCH_SUGGESTION_CLICKED
sugestão de pesquisa é clicada.
Essa é a intent que é acionada quando uma
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED sugestão de pesquisa para criar um
contato é clicada.
Essa é a intent que é disparada quando uma
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
sugestão de pesquisa para discar um número
é clicada.
Recebe como entrada um URI de dados com um esquema mailto:
SHOW_OR_CREATE_CONTACT
ou tel:.

Apêndice B: intents de transmissão obrigatóriasOBSERVAÇÃO: esta lista é provisória e será
atualizada no futuro.
Intent Action
Description
Broadcast Action: é transmitida uma vez, depois que o
ACTION_BOOT_COMPLETED
termina a inicialização.
Ação de transmissão: é transmitida uma vez, quando uma chamada
ACTION_CALL_BUTTON
é recebida.
Ação de transmissão: o "Botão da câmera" foi
ACTION_CAMERA_BUTTON
pressionado.
Ação de transmissão: a
ACTION_CONFIGURATION_CHANGED
Configuração do dispositivo atual(orientação, localidade etc.)
foi alterada.
ACTION_DATE_CHANGED
Ação de transmissão: a data foi alterada.
Ação de transmissão: indica a condição de pouca memória
ACTION_DEVICE_STORAGE_LOW
no dispositivo
Ação de transmissão: indica a condição de pouca 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 foi
ACTION_INPUT_METHOD_CHANGED
alterado.
Ação de transmissão: a mídia externa foi removida
ACTION_MEDIA_BAD_REMOVAL
do slot do cartão SD, mas o ponto de montagem não foi
desmontado.
Ação de transmissão: o "Botão de mídia" foi
ACTION_MEDIA_BUTTON
pressionado.
Ação de transmissão: a mídia externa está presente e
está sendo verificada pelo disco. O caminho para o ponto de montagem de
ACTION_MEDIA_CHECKING
a mídia de verificação está contida no campo
Intent.mData.
Ação de transmissão: o usuário expressou o desejo de
ACTION_MEDIA_EJECT
remover a mídia de armazenamento externo.
Ação de transmissão: a mídia externa está presente e
ACTION_MEDIA_MOUNTED
montada no ponto de montagem.
Ação de transmissão: a mídia externa está presente, mas
usa um fs incompatível (ou está em branco). O caminho para
ACTION_MEDIA_NOFS
o ponto de montagem para a mídia de verificação é
contido no campo Intent.mData.
Ação de transmissão: a mídia externa foi
ACTION_MEDIA_REMOVED
removida.
Ação de transmissão: o scanner de mídia terminou
ACTION_MEDIA_SCANNER_FINISHED
de digitalizar um diretório.
Ação de transmissão: solicite que o detector de mídia
ACTION_MEDIA_SCANNER_SCAN_FILE
verifique um arquivo e o adicione ao banco de dados de mídia.

Ação de transmissão: o scanner de mídia foi iniciado
ACTION_MEDIA_SCANNER_STARTED
fazendo a verificação de um diretório.
Ação de transmissão: a mídia externa foi desmontada
ACTION_MEDIA_SHARED
porque está sendo compartilhada pelo armazenamento em massa USB.
Ação de transmissão: a mídia externa está presente, mas
ACTION_MEDIA_UNMOUNTABLE
não pode ser montada.
Ação de transmissão: a mídia externa está presente, mas
ACTION_MEDIA_UNMOUNTED
não está montada no ponto de montagem.
Ação de transmissão: uma chamada será feita
ACTION_NEW_OUTGOING_CALL
no dispositivo.
Ação de transmissão: um novo pacote de aplicativo foi
ACTION_PACKAGE_ADDED
instalado no dispositivo.
Ação de transmissão: um pacote de aplicativo 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 dados persistentes são apagados e esta
transmissão é enviada. O pacote limpo
não recebe essa transmissão. Os dados contêm
o nome do pacote.
Ação de transmissão: um pacote de aplicativo
foi removido do dispositivo. Os dados
ACTION_PACKAGE_REMOVED
contêm o nome do pacote. O pacote
que está sendo instalado não recebe essa intent.
Ação de transmissão: uma nova versão de um aplicativo
ACTION_PACKAGE_REPLACED
foi instalada, substituindo uma versão
já instalada.
Ação de transmissão: o usuário reiniciou um
pacote, e todos os processos dele foram encerrados.
Todo o estado de execução associado a ele (processos,
ACTION_PACKAGE_RESTARTED
alarmes, notificações etc.) precisa ser removido. O pacote reiniciado não recebe essa
transmissão.
Os dados contêm o nome do pacote
.
Ação de transmissão: alguns provedores de conteúdo têm
partes do namespace em que publicam novos
eventos ACTION_PROVIDER_CHANGED
ou itens em que o usuário pode estar particularmente
interessado.
ACTION_SCREEN_OFF
Ação de transmissão: enviada depois que a tela é desligada.
ACTION_SCREEN_ON
Ação de transmissão: enviada depois que a tela é ligada.
Ação de transmissão: um ID do usuário foi removido
ACTION_UID_REMOVED
do sistema.
Ação de transmissão: o dispositivo entrou no modo de armazenamento em massa USB
ACTION_UMS_CONNECTED
.

Ação de transmissão: o dispositivo saiu do modo de armazenamento em massa USB
ACTION_UMS_DISCONNECTED
.
Ação de transmissão: enviada quando o usuário está presente
ACTION_USER_PRESENT
após o dispositivo ser ativado (por exemplo, quando a tela de bloqueio
é removida).
Ação de transmissão: o plano de fundo do sistema atual
ACTION_WALLPAPER_CHANGED
foi alterado.
ACTION_TIME_CHANGED
Ação de transmissão: o horário foi definido.
ACTION_TIME_TICK
Ação de transmissão: o horário atual mudou.
ACTION_TIMEZONE_CHANGED
Ação de transmissão: o fuso horário mudou.
Ação de transmissão: o estado de carregamento ou o nível de carga
ACTION_BATTERY_CHANGED
da bateria mudou.
Ação de transmissão: indica a condição de bateria fraca
ACTION_BATTERY_LOW
no dispositivo. Essa transmissão corresponde à caixa de diálogo do sistema
"Aviso de bateria fraca".
Ação de transmissão: indica que a bateria está
normal depois de estar fraca. Ela será enviada
ACTION_BATTERY_OKAY
depois de ACTION_BATTERY_LOW , quando a bateria
voltar a ter um estado normal.
Estado da rede
Ação da intent
Descrição
Ação de intent de transmissão que indica que o
NETWORK_STATE_CHANGED_ACTION
estado da conectividade Wi-Fi mudou.
Ação de intent de transmissão indicando que a
RSSI_CHANGED_ACTION
RSSI (intensidade do sinal) mudou.
Ação de intent de transmissão que indica que uma
SUPPLICANT_STATE_CHANGED_ACTION
conexão com o solicitante foi
estabelecida ou perdida.
Ação de intent de transmissão que indica que o Wi-Fi
WIFI_STATE_CHANGED_ACTION
foi ativado, desativado, ativado,
desativado ou desconhecido.
Os IDs de rede das redes configuradas
NETWORK_IDS_CHANGED_ACTION
podem ter mudado.
Ação de intent de transmissão indicando que a configuração
ACTION_BACKGROUND_DATA_SETTING_CHANGED para o uso de dados em segundo plano
mudou os valores.
Intent de transmissão indicando que ocorreu uma mudança na conectividade de rede
CONNECTIVITY_ACTION
.
Ação de transmissão: o usuário ativou ou desativou o
ACTION_AIRPLANE_MODE_CHANGED
no modo avião do smartphone.

Apêndice C: considerações futuras Este apêndice esclarece algumas partes desta definição de compatibilidade do
Android 1.6 e, em alguns casos, discute mudanças previstas ou planejadas para uma
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 telefones
O Android 1.6 é destinado exclusivamente a telefones. A funcionalidade de telefonia não é opcional. As versões futuras
da plataforma Android vão tornar a telefonia opcional, permitindo que dispositivos
Android não sejam smartphones, mas apenas smartphones são compatíveis com o Android 1.6.
2. Compatibilidade com Bluetooth
A versão 1.6 do Android não oferece suporte a APIs de Bluetooth. Portanto, do ponto de vista de compatibilidade,
o Bluetooth não impõe nenhuma consideração para essa versão da plataforma. No entanto, uma versão futura
do Android vai introduzir APIs Bluetooth. Nesse momento, o suporte a Bluetooth será obrigatório para
compatibilidade.
Por isso, recomendamos que os dispositivos Android 1.6 incluam Bluetooth para que sejam
compatíveis com as versões futuras do Android que exigem Bluetooth.
3. Componentes de hardware obrigatórios
Todos os componentes de hardware na Seção 8 (incluindo Wi-Fi, magnetômetro/bússola, acelerômetro etc.) são
obrigatórios e não podem ser omitidos. As versões futuras do Android vão tornar alguns (mas não todos)
esses componentes opcionais, em conjunto com as ferramentas correspondentes para que os desenvolvedores terceirizados processem essas
mudanças.
4. Exemplos de aplicativos
O documento de definição de compatibilidade de uma versão futura do Android vai incluir uma lista de aplicativos mais extensa e
representativa do que as listadas na Seção 4 acima. Para o Android 1.6, os aplicativos
listados na seção 4 precisam ser testados.
5. Telas touch
As versões futuras da Definição de compatibilidade podem ou não permitir que os dispositivos omitam telas touch.
No entanto, atualmente, grande parte da implementação do framework do Android pressupõe a existência de uma
tela touch. Omitir uma tela touch quebraria substancialmente todos os aplicativos Android de terceiros atuais.
Por isso, no Android 1.6, uma tela touch é necessária para a compatibilidade.

6. Desempenho
As próximas versões do CTS também vão medir a utilização da CPU e o desempenho dos seguintes
componentes de uma implementação:
• Gráficos 2D
• Gráficos 3D
• Reprodução de vídeo
• Reprodução de áudio
• Reprodução de Bluetooth A2DP

Definição de compatibilidade do Android 1.6 Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Estrutura do documento

Definição de compatibilidade do Android 1.6
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.