Esta página se ha traducido con Cloud Translation API.

Definición de compatibilidad con Android 1.6

Definición de compatibilidad de Android: Android 1.6
Android 1.6 r2
Corporación Google.
compatibilidad@android.com

1. Introducción
Este documento enumera los requisitos que se deben cumplir para que los teléfonos móviles sean
Compatible con Android 1.6. Esta definición asume familiaridad con el Programa de compatibilidad de Android.
[Recursos, 1].
El uso de "debe", "no debe", "obligatorio", "deberá", "no deberá", "debería", "no debería", "recomendado",
"puede" y "opcional" se ajustan al estándar IETF definido en RFC2119 [ Recursos , 2].
Tal como se utiliza en este documento, un "implementador de dispositivos" o "implementador" es una persona u organización que desarrolla
una solución de hardware/software que ejecuta Android 1.6. Una "implementación de dispositivo" o "implementación" es la
solución de hardware/software así desarrollada.
Para ser considerado compatible con Android 1.6, las implementaciones del dispositivo:
1. DEBE cumplir con los requisitos presentados en esta Definición de compatibilidad, incluido cualquier documento
incorporado mediante referencia.
2. DEBE aprobar el conjunto de pruebas de compatibilidad de Android (CTS) disponible como parte del Android Open
Proyecto fuente [ Recursos , 3]. El CTS prueba la mayoría, pero no todos , los componentes descritos en este
documento.
Cuando esta definición o la CTS no dicen nada, son ambiguas o están incompletas, es responsabilidad del dispositivo.
implementador para garantizar la compatibilidad con las implementaciones existentes. Por este motivo, el Android Open
Source Project [ Recursos , 4] es la implementación de referencia y preferida de Android. Dispositivo
Se recomienda encarecidamente a los implementadores que basen sus implementaciones en el código fuente "ascendente".
disponible en el Proyecto de código abierto de Android. Si bien algunos componentes pueden hipotéticamente reemplazarse
Con implementaciones alternativas, se desaconseja encarecidamente esta práctica, ya que pasar las pruebas CTS se convertirá en un problema.
sustancialmente más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con
la implementación estándar de Android, incluido y más allá del Compatibility Test Suite.
2. Recursos
Esta Definición de compatibilidad hace referencia a una serie de recursos que se pueden obtener aquí.
1. Descripción general del programa de compatibilidad de Android: https://sites.google.com/a/android.com/compatibility/
cómo funciona
2. Niveles de requisitos IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Conjunto de pruebas de compatibilidad: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Proyecto de código abierto de Android: http://source.android.com/
5. Definiciones y documentación de API: http://developer.android.com/reference/packages.html
6. Proveedores de contenido: http://code.google.com/android/reference/android/provider/package-
resumen.html
7. Recursos disponibles: http://code.google.com/android/reference/available-resources.html
8. Archivos de manifiesto de Android: http://code.google.com/android/devel/bblocks-manifest.html
9. Referencia de permisos de Android: http://developer.android.com/reference/android/
manifiesto.permiso.html
10. Construir constantes: http://developer.android.com/reference/android/os/Build.html
11. Vista web: http://developer.android.com/reference/android/webkit/WebView.html
12. Extensiones del navegador Gears: http://code.google.com/apis/gears/

13. Especificación de la máquina virtual Dalvik, que se encuentra en el directorio dalvik/docs de un código fuente
verificar; también disponible en http://android.git.kernel.org/?p=platform/
dalvik.git;a=árbol;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=CABEZA
14. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Notificaciones: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Guía de estilo de iconos de la barra de estado: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Administrador de búsqueda: http://developer.android.com/reference/android/app/SearchManager.html
18. Brindis: http://developer.android.com/reference/android/widget/Toast.html
19. Aplicaciones para Android: http://code.google.com/p/apps-for-android
20. Descripción del archivo apk de Android: http://developer.android.com/guide/topics/fundamentals.html
21. Puente de depuración de Android (adb): http://code.google.com/android/reference/adb.html
22. Servicio de monitorización de depuración de Dalvik (ddms): http://code.google.com/android/reference/ddms.html
23. Mono: http://developer.android.com/guide/developing/tools/monkey.html
24. Documentación de independencia de visualización:
25. Constantes de configuración: http://developer.android.com/reference/android/content/res/
Configuración.html
26. Mostrar métricas: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Cámara: http://developer.android.com/reference/android/hardware/Camera.html
28. Espacio de coordenadas del sensor: http://developer.android.com/reference/android/hardware/
SensorEvento.html
29. Referencia de permisos y seguridad de Android: http://developer.android.com/guide/topics/security/
seguridad.html
Muchos de estos recursos se derivan directa o indirectamente del SDK de Android 1.6 y serán
funcionalmente idéntico a la información contenida en la documentación de ese SDK. En cualquier caso donde esto
La definición de compatibilidad no está de acuerdo con la documentación del SDK, se considera la documentación del SDK
autoritario. Cualquier detalle técnico proporcionado en las referencias incluidas anteriormente se considera por inclusión.
para ser parte de esta Definición de Compatibilidad.
3.software
La plataforma Android incluye un conjunto de API administradas ("duras") y un conjunto de API denominadas "blandas".
como el sistema Intent, las API de código nativo y las API de aplicaciones web. Esta sección detalla los duros y
API suaves que son parte integral de la compatibilidad, así como otras interfaces técnicas y de usuario relevantes
comportamientos. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos de esta sección.
3.1. Compatibilidad de API administrada
El entorno de ejecución administrado (basado en Dalvik) es el vehículo principal para las aplicaciones de Android. El
La interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma Android expuestas a
aplicaciones que se ejecutan en el entorno de VM administrado. Las implementaciones de dispositivos DEBEN proporcionar información completa
implementaciones, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por Android
1.6 SDK, como por ejemplo:
1. API principales del lenguaje Java de Android [Recursos, 5].
2. Proveedores de contenido [Recursos , 6].
3. Recursos [Recursos, 7].
4. Atributos y elementos de AndroidManifest.xml [Recursos, 8].

Las implementaciones de dispositivos NO DEBEN omitir ninguna API administrada, alterar las interfaces o firmas de API, desviarse
del comportamiento documentado, o incluir no operaciones, excepto donde lo permita específicamente esta Compatibilidad
Definición.
3.2. Compatibilidad de API suave
Además de las API administradas de la Sección 3.1, Android también incluye una importante versión "soft" de solo tiempo de ejecución.
API, en forma de elementos como intenciones, permisos y aspectos similares de las aplicaciones de Android.
que no se puede aplicar en el momento de la compilación de la aplicación. Esta sección detalla las API y el sistema "blandos".
comportamientos necesarios para la compatibilidad con Android 1.6. Las implementaciones de dispositivos DEBEN cumplir con todos los
requisitos presentados en esta sección.
3.2.1. Permisos
Los implementadores de dispositivos DEBEN admitir y hacer cumplir todas las constantes de permisos según lo documentado por el
Página de referencia de permisos [ Recursos , 9]. Tenga en cuenta que la Sección 10 enumera requisitos adicionales relacionados con
El modelo de seguridad de Android.
3.2.2. Parámetros de construcción
Las API de Android incluyen una serie de constantes en la clase android.os.Build [Recursos, 10] que son
destinado a describir el dispositivo actual. Proporcionar valores coherentes y significativos en todos los dispositivos
implementaciones, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que
las implementaciones de dispositivos DEBEN cumplir.
Parámetro
Comentarios
La versión del sistema Android que se está ejecutando actualmente, en términos humanos.
android.os.Build.VERSION.RELEASE
formato legible. Para Android 1.6, este campo DEBE tener el valor de cadena
"1,6".
La versión del sistema Android que se está ejecutando actualmente, en un formato
android.os.Build.VERSIÓN.SDK
accesible al código de aplicación de terceros. Para Android 1.6, este campo
DEBE tener el valor entero 4.
Un valor elegido por el implementador del dispositivo que designa la compilación específica.
del sistema Android que se está ejecutando actualmente, en formato legible por humanos.
Este valor NO DEBE reutilizarse para diferentes compilaciones enviadas al final
usuarios de android.os.Build.VERSION.INCREMENTAL. Un uso típico de este campo es indicar qué número de compilación o
Se utilizó el identificador de cambio de control de fuente para generar la compilación. Allá
No hay requisitos sobre el formato específico de este campo, excepto que
NO DEBE ser nulo o una cadena vacía ("").
Un valor elegido por el implementador del dispositivo que identifica el interno específico
hardware utilizado por el dispositivo, en formato legible por humanos. Un posible uso
android.os.Build.BOARD
de este campo es para indicar la revisión específica de la placa que alimenta el
dispositivo. No hay requisitos sobre el formato específico de este campo,
excepto que NO DEBE ser nulo o una cadena vacía ("").
Un valor elegido por el implementador del dispositivo que identifica el nombre del
android.os.Build.BRAND
empresa, organización, individuo, etc. que produjo el dispositivo, en
formato legible por humanos. Un posible uso de este campo es indicar el OEM

y/o proveedor que vendió el dispositivo. No hay requisitos sobre el
formato específico de este campo, excepto que NO DEBE ser nulo o estar vacío
cadena ("").
Un valor elegido por el implementador del dispositivo que identifica el
configuración o revisión de la carrocería (a veces llamada "industrial
android.os.Build.DEVICE
diseño") del dispositivo. No existen requisitos sobre el formato específico
de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
Una cadena que identifica de forma única esta compilación. DEBE ser razonablemente
legible por humanos. DEBE seguir esta plantilla:
$(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 ejemplo: acme/mydevicel/generic/generic:Donut/ERC77/
3359: depuración de usuario/claves de prueba
La huella digital NO DEBE incluir espacios. Si otros campos incluidos en el
La plantilla anterior tiene espacios, DEBEN reemplazarse con el formato ASCII.
carácter de guión bajo ("_") en la huella digital.
Una cadena que identifica de forma única el host en el que se creó la compilación, en términos humanos.
android.os.Build.HOST
formato legible. No existen requisitos sobre el formato específico de este
campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
Un identificador elegido por el implementador del dispositivo para referirse a un elemento específico.
lanzamiento, en formato legible por humanos. Este campo puede ser igual que
android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor
android.os.Build.ID
pretende ser algo significativo para los usuarios finales. No existen
requisitos sobre el formato específico de este campo, excepto que NO DEBE
ser nulo o la cadena vacía ("").
Un valor elegido por el implementador del dispositivo que contiene el nombre del
dispositivo tal como lo conoce el usuario final. Este DEBE ser el mismo nombre.
android.os.Build.MODEL
bajo el cual el dispositivo se comercializa y vende a los usuarios finales. No existen
requisitos sobre el formato específico de este campo, excepto que NO DEBE
ser nulo o la cadena vacía ("").
Un valor elegido por el implementador del dispositivo que contiene el desarrollo.
nombre o nombre en clave del dispositivo. DEBE ser legible por humanos, pero no lo es
android.os.Build.PRODUCTO
necesariamente destinado a ser visto por los usuarios finales. No hay requisitos
en el formato específico de este campo, excepto que NO DEBE ser nulo o el
cuerda vacía ("").
Una lista separada por comas de etiquetas elegidas por el implementador del dispositivo que
distinguir aún más la construcción. Por ejemplo, "sin firmar, depurar". Este campo
android.os.Build.TAGS
NO DEBE ser nulo o una cadena vacía (""), sino una sola etiqueta (como
"liberar") está bien.
android.os.Build.TIME
Un valor que representa la marca de tiempo de cuando ocurrió la compilación.
Un valor elegido por el implementador del dispositivo que especifica el tiempo de ejecución.
configuración de la construcción. Este campo DEBE tener uno de los valores
android.os.Build.TYPE
correspondiente a las tres configuraciones típicas de tiempo de ejecución de Android: "usuario",
"userdebug" o "eng".
Un nombre o ID de usuario del usuario (o usuario automatizado) que generó el
android.os.Build.USER
construir. No hay requisitos sobre el formato específico de este campo,
excepto que NO DEBE ser nulo o una cadena vacía ("").

3.2.3. Compatibilidad de intenciones
Android usa Intents para lograr una integración débil entre aplicaciones. Esta sección describe
requisitos relacionados con los patrones de intención que DEBEN ser respetados por las implementaciones de dispositivos. Por
"honrado", significa que el implementador del dispositivo DEBE proporcionar una Actividad, Servicio u otro
Componente que especifica un filtro de intención coincidente y se vincula e implementa el comportamiento correcto para cada uno.
patrón de intención especificado.
3.2.3.1. Intenciones principales de la aplicación
El proyecto upstream de Android define una serie de aplicaciones principales, como un marcador telefónico, un calendario,
libreta de contactos, reproductor de música, etc. Los implementadores de dispositivos PUEDEN reemplazar estas aplicaciones con
versiones alternativas.
Sin embargo, cualquiera de estas versiones alternativas DEBE respetar los mismos patrones de intención proporcionados por el software ascendente.
proyecto. (Por ejemplo, si un dispositivo contiene un reproductor de música alternativo, aún debe respetar el patrón de intención
emitido por aplicaciones de terceros para elegir una canción). Las implementaciones de dispositivos DEBEN admitir todos los patrones de intención.
enumerados en el Apéndice A.
3.2.3.2. Anulaciones de intención
Como Android es una plataforma extensible, los implementadores de dispositivos DEBEN permitir cada patrón de Intención descrito en
El Apéndice A será anulado por aplicaciones de terceros. El proyecto de código abierto de Android
permite esto de forma predeterminada; Los implementadores de dispositivos NO DEBEN otorgar privilegios especiales a las aplicaciones del sistema.
uso de estos patrones de Intent, o evitar que aplicaciones de terceros se vinculen y asuman el control de
estos patrones. Esta prohibición incluye específicamente la desactivación de la interfaz de usuario "Chooser" que permite
el usuario puede seleccionar entre múltiples aplicaciones que manejan el mismo patrón de intención.
3.2.3.3. Espacios de nombres de intención
Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier nueva intención o
Transmitir patrones de intención usando una ACCIÓN, CATEGORÍA u otra cadena clave en el espacio de nombres android.*.
Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier nueva intención o
Patrones de intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete
perteneciente a otra organización. Los implementadores de dispositivos NO DEBEN alterar ni ampliar ninguna de las intenciones.
patrones enumerados en los Apéndices A o B.
Esta prohibición es análoga a la especificada para las clases de lenguaje Java en la Sección 3.6.

3.2.3.4. Intenciones de transmisión
Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos Intents y notificarles sobre cambios en el
entorno de hardware o software. Los dispositivos compatibles con Android DEBEN transmitir la transmisión pública
Intenciones en respuesta a eventos apropiados del sistema. Se proporciona una lista de intenciones de transmisión requeridas en
Apéndice B; sin embargo, tenga en cuenta que el SDK puede definir intenciones de transmisión adicionales, que también DEBEN ser
honrado.
3.3. Compatibilidad API nativa
El código administrado que se ejecuta en Dalvik puede llamar al código nativo proporcionado en el archivo .apk de la aplicación como un ELF.
Archivo .so compilado para la arquitectura de hardware del dispositivo adecuada. Las implementaciones de dispositivos DEBEN incluir
soporte para código que se ejecuta en el entorno administrado para llamar a código nativo, utilizando el estándar Java
Semántica de la interfaz nativa (JNI). Las siguientes API deben estar disponibles para el código nativo:
• libc (biblioteca C)
• libm (biblioteca de matemáticas)
• Interfaz JNI
• libz (compresión Zlib)
• liblog (registro de Android)
• Soporte mínimo para C++
• OpenGL ES 1.1
Estas bibliotecas DEBEN ser compatibles con el código fuente (es decir, con el encabezado) y con el sistema binario (para un determinado
arquitectura del procesador) con las versiones proporcionadas en Bionic por el proyecto Android Open Source. Desde
Las implementaciones de Bionic no son totalmente compatibles con otras implementaciones como GNU C.
biblioteca, los implementadores de dispositivos DEBEN usar la implementación de Android. Si los implementadores de dispositivos utilizan un
Para diferentes implementaciones de estas bibliotecas, deben garantizar la compatibilidad binaria y de encabezado.
La compatibilidad del código nativo es un desafío. Por esta razón, deseamos repetir que los implementadores de dispositivos son
Se recomienda MUY encarecidamente el uso de implementaciones ascendentes de las bibliotecas enumeradas anteriormente, para ayudar
garantizar la compatibilidad.
3.4. Compatibilidad de API web
Muchos desarrolladores y aplicaciones confían en el comportamiento de la clase android.webkit.WebView [ Recursos ,
11] para sus interfaces de usuario, por lo que la implementación de WebView debe ser compatible en Android
implementaciones. La implementación de Android Open Source utiliza la versión del motor de renderizado WebKit para
implementar el WebView.
Debido a que no es factible desarrollar un conjunto de pruebas integral para un navegador web, los implementadores de dispositivos
DEBE utilizar la compilación ascendente específica de WebKit en la implementación de WebView. Específicamente:
• WebView DEBE utilizar la compilación WebKit 528.5+ del árbol de código abierto de Android para
Android 1.6. Esta compilación incluye un conjunto específico de funcionalidades y correcciones de seguridad para WebView.
• La cadena del agente de usuario reportada por WebView DEBE tener este formato:
Mozilla/5.0 (Linux; U; Android 1.6; <idioma>-<país>; <dispositivo
nombre>; Compilación/<ID de compilación>) AppleWebKit/528.5+ (KHTML, como Gecko)
Versión/3.1.2 Safari Móvil/525.20.1

◦ La cadena "<nombre del dispositivo>" DEBE ser la misma que el valor de
android.os.Build.MODEL
◦ La cadena "<build ID>" DEBE ser la misma que el valor de android.os.Build.ID.
◦ Las cadenas "<idioma>" y "<país>" DEBEN seguir las convenciones habituales para
código de país e idioma, y DEBE hacer referencia a la configuración regional actual del dispositivo en el
momento de la solicitud.
Las implementaciones PUEDEN incluir una cadena de agente de usuario personalizada en la aplicación de navegador independiente. Qué
Además, el navegador independiente PUEDE basarse en una tecnología de navegador alternativa (como Firefox,
Opera, etc.) Sin embargo, incluso si se envía una aplicación de navegador alternativa, el componente WebView
proporcionado a aplicaciones de terceros DEBE basarse en WebKit, como se indicó anteriormente.
La aplicación de navegador independiente DEBE incluir soporte para Gears [ Recursos, 12] y MAYO
incluyen soporte para parte o todo HTML5.
3.5. Compatibilidad de comportamiento de API
Los comportamientos de cada uno de los tipos de API (administrada, suave, nativa y web) deben ser consistentes con el
Implementación preferida de Android disponible en el Proyecto de código abierto de Android.
Algunas áreas específicas de compatibilidad son:
• Los dispositivos NO DEBEN cambiar el comportamiento o significado de un Intent estándar
• Los dispositivos NO DEBEN alterar el ciclo de vida o la semántica del ciclo de vida de un tipo particular de sistema
componente (como servicio, actividad, proveedor de contenido, etc.)
• Los dispositivos NO DEBEN cambiar la semántica de un permiso en particular
La lista anterior no es exhaustiva y la responsabilidad de garantizar el comportamiento recae en los implementadores del dispositivo.
compatibilidad. Por esta razón, los implementadores de dispositivos DEBEN utilizar el código fuente disponible a través de
Proyecto de código abierto de Android siempre que sea posible, en lugar de volver a implementar partes importantes del sistema.
El Compatibility Test Suite (CTS) prueba partes importantes de la plataforma para determinar la compatibilidad de comportamiento,
pero no todos. Es responsabilidad del implementador garantizar la compatibilidad del comportamiento con Android.
Proyecto de código abierto.
3.6. Espacios de nombres API
Android sigue las convenciones de espacio de nombres de paquetes y clases definidas por la programación Java.
idioma. Para garantizar la compatibilidad con aplicaciones de terceros, los implementadores de dispositivos NO DEBEN realizar
cualquier modificación prohibida (ver a continuación) a estos espacios de nombres de paquetes:
• java.*
• javax.*
• sol.*
• androide.*
• com.android.*
Las modificaciones prohibidas incluyen:
• Las implementaciones de dispositivos NO DEBEN modificar las API expuestas públicamente en la plataforma Android.
cambiando cualquier método o firma de clase, o eliminando clases o campos de clase.

• Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las API, pero dichas
Las modificaciones NO DEBEN afectar el comportamiento indicado y la firma en lenguaje Java de cualquier
API expuestas públicamente.
• Los implementadores de dispositivos NO DEBEN agregar ningún elemento expuesto públicamente (como clases o
interfaces, o campos o métodos para clases o interfaces existentes) a las API anteriores.
Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide" en el
Código fuente de Android ascendente. En otras palabras, los implementadores de dispositivos NO DEBEN exponer nuevas API o
alterar las API existentes en los espacios de nombres indicados anteriormente. Los implementadores de dispositivos PUEDEN hacer que sean solo internos
modificaciones, pero esas modificaciones NO DEBEN publicitarse ni exponerse de otro modo a los desarrolladores.
Los implementadores de dispositivos PUEDEN agregar API personalizadas, pero dichas API NO DEBEN estar en un espacio de nombres de propiedad
por o refiriéndose a otra organización. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar API al
com.google.* o espacio de nombres similar; sólo Google puede hacerlo. De manera similar, Google NO DEBE agregar API a
espacios de nombres de otras empresas.
Si un implementador de dispositivo propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando
nueva funcionalidad útil a una API existente, o agregar una nueva API), el implementador DEBE visitar
source.android.com y comenzar el proceso para contribuir con cambios y código, de acuerdo con las
información en ese sitio.
Tenga en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar API en Java.
lenguaje de programación; Esta sección simplemente tiene como objetivo reforzar esas convenciones y hacerlas vinculantes.
mediante su inclusión en esta definición de compatibilidad.
3.7. Compatibilidad de máquinas virtuales
Un dispositivo Android compatible debe admitir la especificación completa del código de bytes Dalvik Executable (DEX) y
Semántica de la máquina virtual Dalvik [Recursos, 13].
3.8. Compatibilidad de la interfaz de usuario
La plataforma Android incluye algunas API de desarrollador que permiten a los desarrolladores conectarse al usuario del sistema.
interfaz. Las implementaciones de dispositivos DEBEN incorporar estas API de UI estándar en interfaces de usuario personalizadas
se desarrollan, como se explica a continuación.
3.8.1. widgets
Android define un tipo de componente y su API y ciclo de vida correspondientes que permiten que las aplicaciones expongan
un "AppWidget" para el usuario final [Recursos , 14] . La versión de referencia de código abierto de Android incluye una
Aplicación de inicio que incluye elementos de interfaz de usuario que permiten al usuario agregar, ver y eliminar
AppWidgets desde la pantalla de inicio.
Los implementadores de dispositivos PUEDEN sustituir una alternativa al Iniciador de referencia (es decir, la pantalla de inicio).
Los lanzadores alternativos DEBEN incluir soporte integrado para AppWidgets y exponer la interfaz de usuario
elementos para agregar, ver y eliminar AppWidgets directamente dentro del Iniciador. Lanzadores alternativos MAYO
omitir estos elementos de la interfaz de usuario; sin embargo, si se omiten, el implementador del dispositivo DEBE proporcionar una
aplicación separada accesible desde el Iniciador que permite a los usuarios agregar, ver y eliminar
Widgets de aplicaciones.

3.8.2. Notificaciones
Android incluye API que permiten a los desarrolladores notificar a los usuarios sobre eventos notables [Recursos, 15]. Dispositivo
los implementadores DEBEN brindar soporte para cada clase de notificación así definida; específicamente: sonidos,
vibración, luz y barra de estado.
Además, la implementación DEBE renderizarse correctamente y todos los recursos (iconos, archivos de sonido, etc.)
proporcionado en las API [Recursos, 7], o en la guía de estilo del icono de la barra de estado [Recursos , 16]. Dispositivo
Los implementadores PUEDEN proporcionar una experiencia de usuario alternativa para las notificaciones a la proporcionada por el
hacer referencia a la implementación de código abierto de Android; sin embargo, dichos sistemas de notificación alternativos DEBEN
admitir recursos de notificación existentes, como se indicó anteriormente.
3.8.3. Buscar
Android incluye API [Recursos, 17] que permiten a los desarrolladores incorporar búsquedas en sus aplicaciones,
y exponer los datos de su aplicación en la búsqueda del sistema global. En términos generales, esta funcionalidad
Consiste en una única interfaz de usuario para todo el sistema que permite a los usuarios ingresar consultas, muestra sugerencias
a medida que los usuarios escriben y muestra los resultados. Las API de Android permiten a los desarrolladores reutilizar esta interfaz para proporcionar
buscar dentro de sus propias aplicaciones y permitir a los desarrolladores proporcionar resultados al usuario común de búsqueda global
interfaz.
Las implementaciones de dispositivos DEBEN incluir una interfaz de usuario de búsqueda única, compartida y en todo el sistema capaz de
sugerencias en tiempo real en respuesta a las aportaciones del usuario. Las implementaciones de dispositivos DEBEN implementar las API que
Permitir a los desarrolladores reutilizar esta interfaz de usuario para realizar búsquedas dentro de sus propias aplicaciones.
Las implementaciones de dispositivos DEBEN implementar las API que permiten que las aplicaciones de terceros agreguen sugerencias
al cuadro de búsqueda cuando se ejecuta en modo de búsqueda global. Si no hay aplicaciones de terceros instaladas que
hacer uso de esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar los resultados del motor de búsqueda web y
sugerencias.
Las implementaciones de dispositivos PUEDEN incluir interfaces de usuario de búsqueda alternativas, pero DEBEN incluir una interfaz dura o blanda.
botón de búsqueda dedicado, que se puede utilizar en cualquier momento dentro de cualquier aplicación para invocar el marco de búsqueda,
con el comportamiento previsto en la documentación de la API.
3.8.4. Brindis
Las aplicaciones pueden usar la API "Toast" (definida en [ Recursos, 18]) para mostrar cadenas cortas no modales en el
usuario final, que desaparecen al cabo de un breve periodo de tiempo. Las implementaciones de dispositivos DEBEN mostrar Tostadas de
aplicaciones a los usuarios finales de alguna manera de alta visibilidad.
4. Compatibilidad del software de referencia
Los implementadores de dispositivos DEBEN probar la compatibilidad de la implementación utilizando el siguiente código abierto
aplicaciones:
• Calculadora (incluida en SDK)
• Lunar Lander (incluido en SDK)
• ApiDemos (incluido en SDK)
• Las aplicaciones "Aplicaciones para Android" [ Recursos, 19]
Cada aplicación anterior DEBE iniciarse y comportarse correctamente en la implementación, para que la implementación sea

considerados compatibles.
5. Compatibilidad del embalaje de la aplicación
Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android generados por la herramienta "aapt"
incluido en el SDK oficial de Android [ Recursos , 20].
Las implementaciones de dispositivos NO DEBEN extender el código de bytes .apk, Android Manifest o Dalvik
formatos de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros
dispositivos compatibles. Los implementadores de dispositivos DEBEN utilizar la implementación ascendente de referencia de Dalvik,
y el sistema de gestión de paquetes de la implementación de referencia.
6. Compatibilidad multimedia
Un dispositivo Android compatible debe admitir los siguientes códecs multimedia. Todos estos códecs son
proporcionados como implementaciones de software en la implementación de Android preferida desde Android Open
Proyecto fuente [ Recursos , 4].
Tenga en cuenta que ni Google ni Open Handset Alliance hacen ninguna declaración de que estos
Los códecs no están afectados por patentes de terceros. Aquellos que tengan la intención de utilizar este código fuente en hardware o
Se recomienda a los productos de software que las implementaciones de este código, incluso en software de código abierto o
shareware, puede requerir licencias de patentes de los titulares de patentes pertinentes.
Audio
Nombre
Detalles del codificador y decodificador
Archivos compatibles
Contenido mono/estéreo en cualquier
3GPP (.3gp) y
combinación de velocidades de bits estándar
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
archivos de hasta 160 kbps y velocidades de muestreo. No hay soporte para raw
entre 8 y 48kHz
AAC (.aac)
Contenido mono/estéreo en cualquier
3GPP (.3gp) y
HE-AACv1
combinación de velocidades de bits estándar
MPEG-4 (.mp4, .m4a)
X
(CAA+)
archivos de hasta 96 kbps y velocidades de muestreo. No hay soporte para raw
entre 8 y 48kHz
AAC (.aac)
Contenido mono/estéreo en cualquier
HE-AACv2
3GPP (.3gp) y
combinación de velocidades de bits estándar
(mejorado
MPEG-4 (.mp4, .m4a)
X
hasta 96 kbps y tasas de muestreo
CAA+)
archivos. No hay soporte para raw
entre 8 y 48kHz
AAC (.aac)
AMR-NB
4,75 a 12,2 kbps muestreados @
Archivos 3GPP (.3gp)
X
X
8kHz
AMR-WB
9 velocidades desde 6,60 kbit/s hasta 23,85
-Archivos 3GPP (.3gp)
X
kbit/s muestreado a 16 kHz
MP3
Archivos MP3 (.mp3) constantes mono/estéreo de 8 a 320 Kbps
X
(CBR) o velocidad de bits variable (VBR)
Escriba 0 y 1 (.mid, .xmf,
MIDI Tipo 0 y 1. DLS Versión 1
midi
X
.mxmf). También RTTTL/RTX
y 2. XMF y XMF móvil.
(.rtttl, .rtx), OTA (.ota),

Soporte para formatos de tonos de llamada
y iMelody (.imy)
RTTTL/RTX, OTA e iMelody
Ogg Vorbis
.ogg
X
PCM lineal de 8 y 16 bits (velocidad hasta
PCM
X
OLA
al límite del hardware)
Imagen
Archivos
Nombre
Detalles del codificador y decodificador
Soportado
JPEG
X
X
base+progresiva
GIF
X
PNG
X
X
BMP
X
Video
Archivos
Nombre
Detalles del codificador y decodificador
Soportado
3GPP (.3gp)
H.263
X
X
archivos
3GPP (.3gp)
H.264
X
y MPEG-4
(.mp4) archivos
MPEG4
X
Archivo 3GPP (.3gp)
SP
7. Compatibilidad de herramientas de desarrollo
Las implementaciones de dispositivos DEBEN ser compatibles con las herramientas de desarrollo de Android proporcionadas en el SDK de Android.
Específicamente, los dispositivos compatibles con Android deben ser compatibles con:
• Android Depug Bridge o ADB [Recursos , 21]
Las implementaciones de dispositivos deben admitir todas las funciones ADB como se documenta en el Android
SDK. El demonio ADB del lado del dispositivo debe estar inactivo de forma predeterminada, pero debe haber un usuario
Mecanismo accesible para encender el puente de depuración de Android.
• Servicio de monitor de depuración de Dalvik o DDMS [recursos , 22]
Las implementaciones de dispositivos deben admitir todas las características DDMS según lo documentado en el SDK de Android.
Como DDMS usa ADB, el soporte para DDMS debe estar inactivo de forma predeterminada, pero debe ser compatible
Cada vez que el usuario ha activado el puente de depuración de Android, como arriba.

• Mono [Recursos, 23]
Las implementaciones de dispositivos deben incluir el marco de mono y hacerlo disponible para
aplicaciones para usar.
8. Compatibilidad de hardware
Android está destinado a admitir implementadores de dispositivos que crean factores y configuraciones de forma innovadores.
Al mismo tiempo, los desarrolladores de Android esperan ciertos hardware, sensores y API en todos los Android
dispositivo. Esta sección enumera las características de hardware que todos los dispositivos compatibles de Android 1.6 deben admitir. En
Android 1.6, se requiere la mayoría de las características de hardware (como WiFi, brújula y acelerómetro).
Si un dispositivo incluye un componente de hardware particular que tiene una API correspondiente para un tercero.
Desarrolladores, la implementación del dispositivo debe implementar esa API como se define en el SDK de Android
documentación.
8.1. Mostrar
Android 1.6 incluye instalaciones que realizan ciertas operaciones automáticas de escala y transformación en
algunas circunstancias, para garantizar que las aplicaciones de terceros funcionen razonablemente bien en el hardware
configuraciones para las cuales no fueron necesariamente diseñados explícitamente [recursos, 24] . Los dispositivos deben
Implemente correctamente estos comportamientos, como se detalla en esta sección.
8.1.1. Configuraciones de visualización estándar
Esta tabla enumera las configuraciones de pantalla estándar consideradas compatibles con Android:
Diagonal
Tamaño de pantalla
Densidad de pantalla
Tipo de pantalla
Ancho (píxeles)
Altura (píxeles)
Rango de longitud
Grupo
Grupo
(pulgadas)
Qvga
240
320
2.6 - 3.0
Pequeño
Bajo
WQVGA
240
400
3.2 - 3.5
Normal
Bajo
Fwqvga
240
432
3.5 - 3.8
Normal
Bajo
HVGA
320
480
3.0 - 3.5
Normal
Medio
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
Medio
Fwvga
480
854
5.0 - 5.8
Grande
Medio
Las implementaciones del dispositivo correspondientes a una de las configuraciones estándar anteriores deben configurarse
Para informar el tamaño de pantalla indicado a las aplicaciones a través de android.content.res.Configuration [ Recursos,
25] Clase.
Algunos paquetes .APK tienen manifiestos que no los identifican como admitir un rango de densidad específico.
Al ejecutar tales aplicaciones, se aplican las siguientes restricciones:

• Las implementaciones de dispositivos deben interpretar cualquier recurso que esté presente como un valor predeterminado a
"Medio" (conocido como "MDPI" en la documentación SDK).
• Al operar en una pantalla de densidad "baja", las implementaciones de dispositivos deben escalar el medio/
Activos MDPI por un factor de 0.75.
• Al operar en una pantalla de densidad "alta", las implementaciones del dispositivo deben ampliar el medio/
Activos MDPI por un factor de 1.5.
• Las implementaciones de dispositivos no deben escalar activos dentro de un rango de densidad, y deben escalar
Activos por exactamente estos factores entre los rangos de densidad.
8.1.2. Configuraciones de visualización no estándar
Las configuraciones de visualización que no coinciden con una de las configuraciones estándar enumeradas en la Sección 8.2.1 requieren
Consideración adicional y trabajo para ser compatible. Los implementadores de dispositivos deben contactar a Android
Equipo de compatibilidad según lo dispuesto en la sección 12 para obtener clasificaciones para cubo de tamaño de pantalla, densidad,
y factor de escala. Cuando se proporciona esta información, las implementaciones de dispositivos deben implementarlas
Como se especificó.
Tenga en cuenta que algunas configuraciones de visualización (como pantallas muy grandes o muy pequeñas y algunas relaciones de aspecto)
son fundamentalmente incompatibles con Android 1.6; por lo tanto, se alienta a los implementadores de dispositivos a
Póngase en contacto con el equipo de compatibilidad de Android lo antes posible en el proceso de desarrollo.
8.1.3. Muestra métricas
Las implementaciones del dispositivo deben informar los valores correctos para todas las métricas de visualización definidas en
android.util.displaymetrics [Recursos , 26].
8.2. Teclado
Implementaciones de dispositivos:
• Debe incluir soporte para el marco de gestión de insumos (que permite a un tercero
desarrolladores para crear motores de gestión de entrada, es decir, teclado suave) como se detalla en
desarrollador.android.com
• Debe proporcionar al menos una implementación de teclado suave (independientemente de si una difícil
El teclado está presente)
• Puede incluir implementaciones adicionales de teclado suave
• Puede incluir un teclado de hardware
• No debe incluir un teclado de hardware que no coincida con uno de los formatos especificados
en android.content.res.configuration [ recursos, 25] (es decir, Qwerty, o 12 teclas)
8.3. Navegación no táctil
Implementaciones de dispositivos:
• Puede omitir las opciones de navegación no táctiles (es decir, puede omitir una bola de seguimiento, una almohadilla direccional de 5 vías o
rueda)
• Debe informar a través de android.content.res.Configuration [recursos , 25] El valor correcto para el
hardware del dispositivo

8.4. Orientación de la pantalla
Los dispositivos compatibles deben admitir la orientación dinámica mediante aplicaciones al retrato o al paisaje
orientación de la pantalla. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una pantalla específica
orientación. Las implementaciones de dispositivos pueden seleccionar la orientación de retrato o paisaje como predeterminado.
Los dispositivos deben informar el valor correcto para la orientación actual del dispositivo, siempre que se consulte a través del
android.content.res.configuration.orientation, android.view.display.getorientation () u otras API.
8.5. Entrada de pantalla táctil
Implementaciones de dispositivos:
• Debe tener una pantalla táctil
• Puede tener una pantalla táctil de capacitación o resistiva
• Debe informar el valor de android.content.res.Configuration [ recursos, 25] reflejando
correspondiente al tipo de pantalla táctil específica en el dispositivo
8.6. USB
Implementaciones de dispositivos:
• Debe implementar un cliente USB, conectable a un host USB con un puerto USB-A estándar
• Debe implementar el puente de depuración de Android sobre USB (como se describe en la Sección 7)
• Debe implementar un cliente de almacenamiento masivo USB para el almacenamiento extraíble/de medios está presente en el
dispositivo
• Debe usar el factor de forma micro USB en el lado del dispositivo
• Debe implementar soporte para la especificación de almacenamiento masivo USB (de modo que sea extraíble
o se puede acceder al almacenamiento fijo en el dispositivo desde una PC host)
• Puede incluir un puerto no estándar en el lado del dispositivo, pero si es así, debe enviarse con un cable capaz de
Conectando el Pinout personalizado al puerto USB-A estándar
8.7. Teclas de navegación
El hogar, el menú y las funciones posteriores son esenciales para el paradigma de navegación de Android. Dispositivo
Las implementaciones deben hacer que estas funciones estén disponibles para el usuario en todo momento, independientemente de la aplicación
estado. Estas funciones deben implementarse a través de botones dedicados. Se pueden implementar
Uso de software, gestos, panel táctil, etc., pero si es así, siempre deben ser accesibles y no oscuros o oscuras o
Interferir con el área de visualización de aplicaciones disponible.
Los implementadores de dispositivos también deben proporcionar una clave de búsqueda dedicada. Los implementadores de dispositivos también pueden
Proporcione claves de envío y finalización para llamadas telefónicas.
8.8. Wifi
Las implementaciones del dispositivo deben admitir 802.11b y 802.11g, y pueden admitir 802.11a.

8.9. Cámara
Las implementaciones del dispositivo deben incluir una cámara. La cámara incluida:
• Debe tener una resolución de al menos 2 megapíxeles
• Debería tener autos de hardware o enfoque automático de software implementado en la cámara
Conductor (transparente al software de aplicación)
• Puede tener hardware de enfoque fijo o EDOF (profundidad de campo extendida)
• Puede incluir un flash. Si la cámara incluye un flash, la lámpara de flash no debe encenderse mientras una
android.hardware.camera.previewCallback La instancia se ha registrado en una vista previa de la cámara
superficie.
Las implementaciones del dispositivo deben implementar los siguientes comportamientos para las API relacionadas con la cámara
[Recursos, 27] :
1. Si una aplicación nunca ha llamado android.hardware.camera.parameters.setPreviewFormat (int),
entonces el dispositivo debe usar android.hardware.pixelformat.ycbcr_420_sp para los datos de vista previa
Proporcionado a las devoluciones de llamada de la aplicación.
2. Si una aplicación registra un android.hardware.camera.previewcallback instancia y la
El sistema llama al método onPreviewFrame () cuando el formato de vista previa es YCBCR_420_SP, el
Los datos en el byte [] pasados a OnPreviewFrame () deben estar en el formato de codificación NV21.
(Este es el formato utilizado de forma nativa por la familia de hardware 7K). Es decir, NV21 debe ser el valor predeterminado.
8.9.1. Cámaras que no son de autos
Si un dispositivo carece de una cámara de enfoque automático, el implementador del dispositivo debe cumplir con los requisitos adicionales en
esta sección. Las implementaciones de dispositivos deben implementar la API de cámara completa incluida en el Android 1.6
Documentación de SDK de alguna manera razonable, independientemente de las capacidades reales de hardware de la cámara.
Para Android 1.6, si la cámara carece de enfoque automático, la implementación del dispositivo debe cumplir con lo siguiente:
1. El sistema debe incluir una propiedad del sistema de solo lectura llamada "Ro.Workaround.NoAUTOFOCUS"
con el valor de "1". Este valor está destinado a ser utilizado por aplicaciones como Android Market para
identificar selectivamente las capacidades del dispositivo y se reemplazará en una versión futura de Android con un
API robusta.
2. Si una aplicación llama a android.hardware.camera.autofocus (), el sistema debe llamar al
Método de devolución de llamada onautofocus () en cualquier registro
android.hardware.camera.autofocuscallback instancias, aunque no se enfoque en realidad
sucedió. Esto es para evitar que las aplicaciones existentes se rompan esperando para siempre un enfoque automático.
devolución de llamada que nunca vendrá.
3. La llamada al método de autofocuscallback.autofocus () debe ser activado por el controlador o
Marco en un nuevo evento en el hilo Looper de marco principal. Es decir, cámara.autofocus ()
No debe llamar directamente a Autofocuscallback.AUTOFOCUS () ya que esto viola el Android
Modelo de roscado marco y romperá aplicaciones.
8.10. Acelerómetro
Las implementaciones de dispositivos deben incluir un acelerómetro de 3 ejes y deben poder entregar eventos a AT
menos 50 Hz. El sistema de coordenadas utilizado por el acelerómetro debe cumplir con el sensor de Android
Coordinar el sistema como se detalla en las API de Android [Recursos , 28].

8.11. Brújula
Las implementaciones de dispositivos deben incluir una brújula de 3 ejes y deben poder entregar eventos al menos
10 Hz. El sistema de coordenadas utilizado por la brújula debe cumplir con la coordenada del sensor de Android
Sistema como se define en la API de Android [recursos , 28].
8.12. GPS
Las implementaciones de dispositivos deben incluir un GPS, y deben incluir alguna forma de "GPS asistido"
técnica para minimizar el tiempo de bloqueo del GPS.
8.13. Telefonía
Implementaciones de dispositivos:
• Debe incluir telefonía GSM o CDMA
• Debe implementar las API apropiadas como se detalla en la documentación SDK de Android en
desarrollador.android.com
Tenga en cuenta que este requisito implica que los dispositivos que no son de teléfonos no son compatibles con Android 1.6; Androide
1.6 Los dispositivos deben incluir hardware de telefonía. Consulte el Apéndice C para obtener información sobre un teléfono sin teléfono.
dispositivos.
8.14. Controles de volumen
Los dispositivos compatibles con Android deben incluir un mecanismo para permitir que el usuario aumente y disminuya el
Volumen de audio. Las implementaciones de dispositivos deben hacer que estas funciones estén disponibles para el usuario en todo momento,
independientemente del estado de aplicación. Estas funciones pueden implementarse utilizando claves de hardware físico,
software, gestos, panel táctil, etc., pero siempre deben ser accesibles y no oscuras o interferir
con el área de visualización de aplicaciones disponible (consulte la pantalla arriba).
Cuando se utilizan estos botones, los eventos clave correspondientes deben generarse y enviar al
Aplicación de primer plano. Si el evento no es interceptado y hundido por la aplicación, entonces el dispositivo
La implementación debe manejar el evento como un control de volumen del sistema.
9. Compatibilidad de rendimiento
Uno de los objetivos del programa de compatibilidad de Android es garantizar una experiencia de aplicación consistente para
consumidores. Las implementaciones compatibles deben garantizar no solo que las aplicaciones simplemente se ejecuten correctamente en
El dispositivo, pero que lo hacen con un rendimiento razonable y una buena experiencia de usuario en general.
Las implementaciones de dispositivos deben cumplir con las métricas clave de rendimiento de un dispositivo compatible con Android 1.6,
Como en la tabla a continuación:
Métrico
Umbral de rendimiento
Comentarios

Esto es probado por CTS.
Las siguientes aplicaciones
El tiempo de lanzamiento se mide como el tiempo total para
Debería lanzarse dentro del
Complete la carga de la actividad predeterminada para el
Solicitud
tiempo especificado.
aplicación, incluido el tiempo que lleva iniciar el
Hora de almuerzo
Navegador: menos de 1300 ms
Proceso de Linux, cargue el paquete de Android en el
MMS/SMS: menos de 700 ms
Dalvik VM, y llame a OnCreate.
ALARMCLOCK: Menos de 650 ms
Múltiples aplicaciones serán
Esto es probado por CTS.
lanzado. Relanzando el
La primera aplicación simultánea debe
Aplicaciones
Complete tomando menos que el
Tiempo de lanzamiento original.
10. Compatibilidad del modelo de seguridad
Las implementaciones de dispositivos deben implementar un modelo de seguridad consistente con la seguridad de la plataforma Android
modelo según se define en el documento de referencia de seguridad y permisos en las API [recursos, 29] en el
Documentación del desarrollador de Android. Las implementaciones de dispositivos deben admitir la instalación de autofirmado
solicitudes sin requerir permisos/certificados adicionales de terceros/autoridades.
Específicamente, los dispositivos compatibles deben admitir los siguientes mecanismos de seguridad:
10.1. Permisos
Las implementaciones del dispositivo deben admitir el modelo de permisos de Android como se define en el Android
Documentación del desarrollador [ Recursos , 9]. Específicamente, las implementaciones deben hacer cumplir cada permiso
definido como se describe en la documentación SDK; No se pueden omitir, alterar o ignorar los permisos.
Las implementaciones pueden agregar permisos adicionales, siempre que las nuevas cadenas de identificación de permiso no estén en el
Android.* Espacio de nombres.
10.2. Aislamiento de usuarios y procesos
Las implementaciones del dispositivo deben admitir el modelo de Sandbox de la aplicación Android, en el que cada aplicación
se ejecuta como un UID de estilo UNIX único y en un proceso separado.
Las implementaciones del dispositivo deben admitir la ejecución de múltiples aplicaciones como la misma ID de usuario de Linux, proporcionada
que las aplicaciones están firmadas y construidas correctamente, como se define en la seguridad y los permisos
Referencia [ Recursos , 29].

10.3. Permisos del sistema de archivos
Las implementaciones de dispositivos deben admitir el modelo de permisos de acceso a archivos de Android como se define en
definido en la referencia de seguridad y permisos [recursos , 29].
11. Suite de prueba de compatibilidad
Las implementaciones de dispositivos deben aprobar el Android Compatity Test Suite (CTS) [ recursos, 3] disponibles
Desde el proyecto de código abierto de Android, utilizando el software de envío final en el dispositivo. Además,
Los implementadores de dispositivos deben usar la implementación de referencia en el árbol de código abierto de Android como
lo más posible, y debe garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier
Reimplementos de partes del código fuente de referencia.
El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, el CTS puede contener errores.
El CTS se verá a la versión independientemente de esta definición de compatibilidad y múltiples revisiones del
CTS se puede lanzar para Android 1.6. Sin embargo, tales versiones solo solucionarán errores de comportamiento en el CTS
pruebas y no impondrá ninguna nueva prueba, comportamiento o API para una versión de plataforma dada.
12. Contáctenos
Puede comunicarse con el equipo de compatibilidad de Android en compatibilidad@android.com para aclaraciones relacionadas con
Esta definición compatible y para proporcionar comentarios sobre esta definición.

Apéndice A: Intentos de aplicación requeridos
Nota: Esta lista es provisional y se actualizará en el futuro.
Acciones de aplicación
Esquemas Tipos de mimo
(ninguno)
Texto sin formato
http
texto/html
Navegador
android.intent.action.view
https
aplicación/xhtml+xml
solicitud/
vnd.wap.xhtml+xml
(ninguno)
android.intent.action.web_search
http
(ninguno)
https
android.media.action.image_capture
android.media.action.still_image_camera
Cámara
android.media.action.video_camera
android.media.action.video_capture
vnd.android.cursor.dir/
android.intent.action.view
imagen
android.intent.action.get_content
vnd.android.cursor.dir/
android.intent.action.pick
video
android.intent.action.attach_data
imagen/*
video/*
android.intent.action.view
rtsp
vídeo/mp4
Video/3GP
android.intent.action.view
http
Video/3GPP
Video/3GPP2
android.intent.action.dial
Teléfono /
android.intent.action.view
teléfono
Contactos
android.intent.action.call
android.intent.action.dial
vnd.android.cursor.dir/
android.intent.action.view
persona

vnd.android.cursor.dir/
persona
vnd.android.cursor.dir/
android.intent.action.pick
teléfono
vnd.android.cursor.dir/
direccion postal
vnd.android.cursor.item/
persona
vnd.android.cursor.item/
android.intent.action.get_content
teléfono
vnd.android.cursor.item/
direccion postal
Texto sin formato
Correo electrónico
android.intent.action.send
imagen/*
video/*
android.intent.action.view
enviar por correo
android.intent.action.sendto
SMS
android.intent.action.view
smsto
Sms / mms android.intent.action.sendto
mms
mmsto
audio/*
Aplicación/OGG
Música
android.intent.action.view
archivo
Aplicación/X-OGG
aplicación/iTunes
audio/mp3
audio/X-MP3
android.intent.action.view
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
artista
vnd.android.cursor.dir/
álbum
vnd.android.cursor.dir/
android.intent.action.pick
Jugando ahora
vnd.android.cursor.dir/
pista
nd.android.cursor.dir/
lista de reproducción
vnd.android.cursor.dir/
video
medios de comunicación/*
audio/*
android.intent.action.get_content
Aplicación/OGG
Aplicación/X-OGG
video/*

contenido
Paquete
android.intent.action.view
archivo
Instalador
paquete
archivo
android.intent.action.package_install
http
https
android.intent.action.all_apps
android.settings.settings
android.settings.wireless_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
Ajustes
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
Buscar
android.intent.action.search
consulta
android.intent.action.search_long_press
Voz
android.intent.action.voice_command
Gestión de contactos
Acción de intención
Descripción
Inicia una actividad que le permite al usuario elegir
Adjunte_image
Un contacto para adjuntar una imagen.
Usado
Extra_create_description
con show_or_create_contact a
especificar una descripción exacta para ser

se muestra al solicitar al usuario
creando un nuevo contacto.
Usado
con show_or_create_contact a
Extra_force_create
forzar creando un nuevo contacto si no
Contacto coincidente encontrado.
Esta es la intención que se dispara cuando un
Search_suggestion_clicked
Se hace clic en la sugerencia de búsqueda.
Esta es la intención que se dispara cuando un
Search_suggestion_create_contact_clicked sugerencia de búsqueda para crear un
Se hace clic en el contacto.
Esta es la intención que se dispara cuando un
Search_suggestion_dial_number_clicked
Sugerencia de búsqueda para marcar un número
se hace clic en.
Toma como entrada un URI de datos con un mailto:
Show_or_create_contact
o Tel: esquema.

Apéndice B: Intentos de transmisión requeridos Nota: Esta lista es provisional y será
actualizado en el futuro.
Acción de intención
Descripción
Acción de transmisión: esto se transmite una vez, después del
Action_boot_completed
El sistema ha terminado de arranque.
Acción de transmisión: esto se transmite una vez, cuando un
Action_Call_Button
se recibe la llamada.
Acción de transmisión: el "botón de la cámara" fue
Action_Camera_Button
presionado.
Acción de transmisión: la corriente
Action_Configuration_Changed
La configuración del dispositivo (orientación, localidad, etc.) tiene
cambió.
Action_Date_Changed
Acción de transmisión: la fecha ha cambiado.
Acción de transmisión: indica una condición de memoria baja
Action_device_storage_low
en el dispositivo
Acción de transmisión: indica una condición de memoria baja
Action_Device_Storage_ok
en el dispositivo ya no existe
Acción de transmisión: auriculares con cable enchufados o
Action_headset_plug
desenchufado.
Acción de transmisión: ha sido un método de entrada
Action_input_method_changed
cambió.
Acción de transmisión: se eliminaron los medios externos
Action_media_bad_removal
desde la ranura de la tarjeta SD, pero el punto de montaje no era
desmontado.
Acción de transmisión: el "botón de medios" fue
Action_Media_Button
presionado.
Acción de transmisión: los medios externos están presentes y
estar revisado en disco el camino hacia el punto de montaje para
Action_media_checking
Los medios de comunicación están contenidos en el
Campo intento.mdata.
Acción de transmisión: el usuario ha expresado el deseo de
Action_Media_Eject
Elimine los medios de almacenamiento externos.
Acción de transmisión: los medios externos están presentes y
Action_media_mounted
montado en su punto de montaje.
Acción de transmisión: los medios externos están presentes, pero están
usando un FS incompatible (o está en blanco) el camino a
Action_media_nofs
El punto de montaje para los medios de comunicación es
contenido en el campo intento.mdata.
Acción de transmisión: los medios externos han sido
Action_Media_Removed
remoto.
Acción de transmisión: el escáner de medios ha terminado
Action_Media_Scanner_Finished
escanear un directorio.
Acción de transmisión: solicite el escáner de medios a
Action_Media_Scanner_Scan_File
Escanee un archivo y agréguelo a la base de datos de medios.

Acción de transmisión: el escáner de medios ha comenzado
Action_media_scanner_started
escanear un directorio.
Acción de transmisión: los medios externos están desmontados
Action_Media_Shared
Porque se está compartiendo a través del almacenamiento masivo USB.
Acción de transmisión: los medios externos están presentes pero
Action_media_unmountable
no se puede montar.
Acción de transmisión: los medios externos están presentes, pero
Action_media_unmounted
No montado en su punto de montaje.
Acción de transmisión: una llamada saliente está a punto de estar
Action_New_Outurging_Call
metido.
Acción de transmisión: un nuevo paquete de aplicaciones tiene
Action_package_added
se ha instalado en el dispositivo.
Acción de transmisión: un paquete de aplicaciones existente
Action_package_changed
ha sido cambiado (por ejemplo, un componente ha sido
habilitado o deshabilitado.
Acción de transmisión: el usuario ha borrado los datos de
un paquete. Esto debe precedirse
por action_package_restarted, después de lo cual
Action_package_data_clared
Todos sus datos persistentes se borran y esto
transmisión enviada. Tenga en cuenta que el paquete borrado
no recibe esta transmisión. Los datos contienen
El nombre del paquete.
Acción de transmisión: un paquete de aplicaciones existente
se ha eliminado del dispositivo. Los datos
Action_Package_Removed
contiene el nombre del paquete. El paquete
Eso se está instalando no recibe esta intención.
Acción de transmisión: una nueva versión de una aplicación
Action_package_replaced
Se ha instalado el paquete, reemplazando un
versión que se instaló anteriormente.
Acción de transmisión: el usuario ha reiniciado un
Paquete, y todos sus procesos han sido asesinados.
Todo el estado de tiempo de ejecución asociado con él (procesos,
Action_Package_Restarted
Se deben eliminar las alarmas, notificaciones, etc.). Nota
que el paquete reiniciado no recibe esto
transmisión. Los datos contienen el nombre del
paquete.
Acción de transmisión: algunos proveedores de contenido tienen
partes de su espacio de nombres donde publican nuevos
Action_Provider_Changed
eventos o elementos que el usuario puede ser especialmente
interesado en.
Action_Screen_off
Acción de transmisión: enviado después de que la pantalla se apaga.
Action_Screen_on
Acción de transmisión: enviado después de que se enciende la pantalla.
Acción de transmisión: se ha eliminado una ID de usuario
Action_uid_Removed
del sistema.
Acción de transmisión: el dispositivo ha ingresado a USB
Action_ums_connected
Modo de almacenamiento de masa.

Acción de transmisión: el dispositivo ha salido de USB
Action_ums_disconnected
Modo de almacenamiento de masa.
Acción de transmisión: enviado cuando el usuario está presente
Action_user_present
Después de que el dispositivo se despierta (por ejemplo, cuando el KeyGuard está
desaparecido).
Acción de transmisión: el fondo de pantalla del sistema actual
Action_wallpaper_changed
ha cambiado.
Action_time_changed
Acción de transmisión: se estableció el tiempo.
Action_time_tick
Acción de transmisión: la hora actual ha cambiado.
Action_Timezone_Changed
Acción de transmisión: la zona horaria ha cambiado.
Acción de transmisión: el estado de carga o el cargo
Action_Battery_Changed
El nivel de la batería ha cambiado.
Acción de transmisión: indica una baja condición de batería
Action_Battery_Low
en el dispositivo. Esta transmisión corresponde al
Diálogo del sistema de "ADVERTENCIA DE BATERÍA BAJA".
Acción de transmisión: indica que la batería ahora está bien
después de estar bajo. Esto será enviado
Action_Battery_okay
Después de Action_Battery_Low una vez la batería
ha vuelto a un estado bien.
Estado de red
Acción de intención
Descripción
Transmisión de acción de intención que indica que el
Network_state_changed_action
El estado de conectividad Wi-Fi ha cambiado.
Transmisión de acción de intención que indica que el
Rssi_changed_action
RSSI (resistencia a la señal) ha cambiado.
Transmitir acción de intención que indica que un
Suplicant_state_changed_action
La conexión con el suplicante ha sido
establecido o perdido.
Acción de intención de transmisión que indica que Wi-Fi
Wifi_state_changed_action
ha sido habilitado, deshabilitado, habilitado,
deshabilitante o desconocido.
Los ID de red de las redes configuradas
Network_ids_changed_action
podría haber cambiado.
Transmisión de acción de intención que indica que el
Action_background_data_setting_changed La configuración para el uso de datos de fondo tiene
valores cambiados.
Intención de transmisión que indica que un cambio en
Conectividad_accion
Se ha producido conectividad de red.
Acción de transmisión: el usuario ha cambiado el
Action_airplane_mode_changed
teléfono dentro o fuera del modo avión.

Apéndice C: Consideraciones futuras Este apéndice aclara ciertas partes de este Android
1.6 Definición de compatibilidad, y en algunos casos discute los cambios anticipados o planificados destinados a un
Versión futura de la plataforma Android. Este apéndice es solo para fines informativos y de planificación, y
no es parte de la definición de compatibilidad para Android 1.6.
1. Dispositivos que no son telefonas
Android 1.6 está destinado exclusivamente a teléfonos; La funcionalidad de telefonía no es opcional. Versiones futuras
de la plataforma Android se espera que haga que la telefonía sea opcional (y, por lo tanto, permiten Android sin teléfono
dispositivos), pero solo los teléfonos son compatibles con Android 1.6.
2. Compatibilidad de Bluetooth
La versión de Android 1.6 de Android no admite las API Bluetooth, por lo que desde una perspectiva de compatibilidad
Bluetooth no impone ninguna consideración para esta versión de la plataforma. Sin embargo, una versión futura
de Android introducirá API Bluetooth. En ese momento, el soporte de Bluetooth se volverá obligatorio para
compatibilidad.
En consecuencia, recomendamos encarecidamente que los dispositivos Android 1.6 incluyan Bluetooth, de modo que sean
Compatible con futuras versiones de Android que requieren Bluetooth.
3. Componentes de hardware requeridos
Todos los componentes de hardware en la Sección 8 (incluyendo WiFi, magnetómetro/brújula, acelerómetro, etc.) son
requerido y no se puede omitir. Se espera que las versiones futuras de Android hagan algunas (pero no todas) de
Estos componentes opcionales, en conjunto con las herramientas correspondientes para que los desarrolladores de terceros manejen estos
cambios.
4. Aplicaciones de muestra
El documento de definición de compatibilidad para una versión futura de Android incluirá un
Lista representativa de aplicaciones que las enumeradas en la Sección 4, arriba. Para Android 1.6, el
Las aplicaciones enumeradas en la Sección 4 deben ser probadas.
5. Pantallas táctiles
Las versiones futuras de la definición de compatibilidad pueden o no permitir que los dispositivos omitan las pantallas táctiles.
Sin embargo, actualmente gran parte de la implementación del marco de Android asume la existencia de un
pantalla táctil; omitir una pantalla táctil rompería sustancialmente todas las aplicaciones de Android de terceros actuales,
Entonces, en Android 1.6 se requiere una pantalla táctil para la compatibilidad.

6. rendimiento
Las versiones futuras de CTS también medirán la utilización y el rendimiento de la CPU de lo siguiente
Componentes de una implementación:
• Gráficos 2D
• Gráficos 3D
• Reproducción de vídeo
• Reproducción de audio
• Bluetooth A2DP Reproducción

Definición de compatibilidad con Android 1.6

Esquema del documento