A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

Se usó la API de Cloud Translation para traducir esta página.

Definición de compatibilidad de Android 1.6
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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

1. Introducción
En este documento, se enumeran los requisitos que deben cumplirse para que los teléfonos celulares sean
compatibles con Android 1.6. Esta definición supone que conoces el Programa de compatibilidad de Android
[Recursos, 1].
El uso de “debes”, “no debes”, “obligatorio”, “deberás”, “no deberás”, “deberías”, “no deberías”, “recomendado”,
“puedes” y “opcional” se realiza de acuerdo con el estándar de IETF definido en RFC2119 [Recursos, 2].
Según se usa en este documento, un "implementador de dispositivos" o "implementador" es una persona o una organización que desarrolla
una solución de hardware o software que ejecuta Android 1.6. Una “implementación de dispositivos” o “implementación” es la
solución de hardware y software que se desarrolló.
Para que se consideren compatibles con Android 1.6, las implementaciones de dispositivos deben cumplir con los siguientes requisitos:
1. DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos
que se incorporan como referencia.
2. DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible como parte del Proyecto de código abierto de Android [Recursos, 3].
La CTS prueba la mayoría, pero no todos, los componentes que se describen en este
documento.
Cuando esta definición o el CTS no se mencionan, son ambiguos o están incompletos, es responsabilidad del implementador
del dispositivo garantizar la compatibilidad con las implementaciones existentes. Por este motivo, el Proyecto de código abierto de Android [Recursos, 4] es la implementación de referencia y preferida de Android.
Se recomienda encarecidamente a los implementadores de
dispositivos que basen sus implementaciones en el código fuente "upstream"
disponible en el Proyecto de código abierto de Android. Si bien, hipotéticamente, algunos componentes se pueden reemplazar
con implementaciones alternativas, no se recomienda esta práctica, ya que aprobar las pruebas de CTS se volverá
mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento total con
la implementación estándar de Android, incluido el conjunto de pruebas de compatibilidad y más allá de este.
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/
how-it-works
2. Niveles de requisitos de la RFC2119 del IETF: 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 la API: http://developer.android.com/reference/packages.html
6. Proveedores de contenido: http://code.google.com/android/reference/android/provider/package-
summary.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/
Manifest.permission.html
10. Constantes de compilación: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Extensiones del navegador de Gears: http://code.google.com/apis/gears/

13. Especificación de la máquina virtual de Dalvik, que se encuentra en el directorio dalvik/docs de una verificación de código fuente
. También está disponible en http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
. 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 íconos 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. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Apps 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. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Servicio de Dalvik Debug Monitor (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. Documentación de independencia de la pantalla:
25. Constantes de configuración: http://developer.android.com/reference/android/content/res/
Configuration.html
26. Métricas de pantalla: 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/
SensorEvent.html
29. Referencia de seguridad y permisos de Android: http://developer.android.com/guide/topics/security/
security.html
Muchos de estos recursos se derivan directa o indirectamente del SDK de Android 1.6 y serán
funcionalmente idénticos a la información de la documentación de ese SDK. En caso de que esta
Definición de Compatibilidad no coincida con la documentación del SDK, la documentación del SDK se considera
autorizada. Los detalles técnicos que se proporcionan en las referencias anteriores se consideran parte de esta Definición de Compatibilidad
.
3. Software
La plataforma de Android incluye un conjunto de APIs administradas ("hard") y un cuerpo de las llamadas APIs "soft"
, como el sistema de intents, las APIs de código nativo y las APIs de aplicaciones web. En esta sección, se detallan las APIs duras y
flexibles que son fundamentales para la compatibilidad, así como algunos otros comportamientos
técnicos y de la interfaz de usuario relevantes. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos de esta sección.
3.1. Compatibilidad con APIs administradas
El entorno de ejecución administrado (basado en Dalvik) es el vehículo principal para las aplicaciones para Android. La
interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma de Android expuestas a
aplicaciones que se ejecutan en el entorno de la VM administrada. Las implementaciones de dispositivos DEBEN proporcionar implementaciones
completas, incluidos todos los comportamientos documentados, de cualquier API documentada que exponga el SDK de Android
1.6, como los siguientes:
1. APIs principales de Android en lenguaje Java [Resources, 5].
2. Proveedores de contenido [Recursos, 6].
3. Recursos [Resources, 7].
4. Atributos y elementos de AndroidManifest.xml [Resources, 8].

Las implementaciones de dispositivos NO DEBEN omitir ninguna API administrada, alterar las interfaces o las firmas de la API, desviarse
del comportamiento documentado ni incluir no-ops, excepto cuando esta Definición de
Compatibilidad lo permita de forma específica.
3.2. Compatibilidad de API flexible
Además de las APIs administradas de la Sección 3.1, Android también incluye una API "flexible"
significativa solo para el tiempo de ejecución, en forma de intents, permisos y aspectos similares de las aplicaciones para Android
que no se pueden aplicar en el momento de la compilación de la aplicación. En esta sección, se detallan las APIs "flexibles" y los comportamientos del
sistema necesarios para la compatibilidad con Android 1.6. Las implementaciones de dispositivos DEBEN cumplir con todos los
requisitos que se presentan en esta sección.
3.2.1. Permisos
Los implementadores de dispositivos DEBEN admitir y aplicar todas las constantes de permisos como se documenta en la
página de referencia de permisos [Recursos, 9]. Ten en cuenta que en el artículo 10 se enumeran requisitos adicionales relacionados con
el modelo de seguridad de Android.
3.2.2. Parámetros de compilación
Las APIs de Android incluyen una serie de constantes en la clase android.os.Build [Resources, 10] que
se usan para describir el dispositivo actual. Para proporcionar valores coherentes y significativos en todas las implementaciones de
dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que
las implementaciones de dispositivos DEBEN cumplir.
Parámetro
Comentarios
Es la versión del sistema Android que se está ejecutando actualmente, en formato
android.os.Build.VERSION.RELEASE
legible por humanos. Para Android 1.6, este campo DEBE tener el valor de cadena
"1.6".
Es la versión del sistema Android que se está ejecutando actualmente, en un formato
android.os.Build.VERSION.SDK
al que puede acceder el código de la aplicación de terceros. Para Android 1.6, este campo
DEBE tener el valor de número entero 4.
Es un valor que elige el implementador del dispositivo y que designa la compilación específica
del sistema Android que se está ejecutando, en formato legible por humanos.
Este valor NO SE DEBE volver a usar para diferentes compilaciones enviadas a los usuarios
de android.os.Build.VERSION.INCREMENTAL. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de código fuente se usó para generar la compilación.
No
hay requisitos sobre el formato específico de este campo, excepto que
NO DEBE ser nulo ni una cadena vacía ("").
Es un valor que elige el implementador del dispositivo que identifica el hardware
interno específico que usa el dispositivo, en formato legible por humanos. Un posible uso
android.os.Build.BOARD
de este campo es 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 ni una cadena vacía ("").
Es un valor que elige el implementador del dispositivo que identifica el nombre de la
empresa, organización, persona, etcétera, que produjo el dispositivo, en
formato legible por humanos.
Un posible uso de este campo es indicar el OEM

o el operador que vendió el dispositivo. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
Es un valor que elige el implementador del dispositivo que identifica la configuración o revisión específica del cuerpo (a veces llamado "diseño industrial
android.os.Build.DEVICE
") del dispositivo.

No hay requisitos sobre el formato específico
de este campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
Es una cadena que identifica de forma exclusiva esta compilación. DEBE ser
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:userdebug/test-keys
La huella digital NO DEBE incluir espacios. Si otros campos incluidos en la
plantilla anterior tienen espacios, DEBEN reemplazarse por el carácter ASCII
guion bajo ("_") en la huella digital.
Es una cadena que identifica de forma exclusiva el host en el que se compiló la compilación, en formato legible
android.os.Build.HOST
por humanos. No hay requisitos sobre el formato específico de este
campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
Es un identificador que elige el implementador del dispositivo para hacer referencia a una versión
específica, en formato legible por humanos. Este campo puede ser el mismo que
android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor
android.os.Build.ID
que tenga algún significado para los usuarios finales. No hay
requisitos sobre el formato específico de este campo, excepto que NO
debe ser nulo ni una cadena vacía ("").
Es un valor que elige el implementador del dispositivo y que contiene el nombre del
dispositivo tal como lo conoce el usuario final. DEBE ser el mismo nombre
android.os.Build.MODEL
con el que se comercializa y vende el dispositivo a los usuarios finales. No hay
requisitos sobre el formato específico de este campo, excepto que NO
debe ser nulo ni una cadena vacía ("").
Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo
o el nombre de código del dispositivo. DEBE ser legible por humanos, pero no es necesariamente
android.os.Build.PRODUCT
para que los usuarios finales lo vean. No hay requisitos
sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni la
cadena vacía ("").
Es una lista de etiquetas separadas por comas que elige el implementador del dispositivo y que
distingue aún más la compilación. Por ejemplo, "unsigned,debug". Este campo
android.os.Build.TAGS
NO DEBE ser nulo ni una cadena vacía (""), pero una sola etiqueta (como
"release") es aceptable.
android.os.Build.TIME
Un valor que representa la marca de tiempo de cuándo se produjo la compilación.
Es un valor que elige el implementador del dispositivo y que especifica la configuración del entorno de ejecución
de la compilación. Este campo DEBE tener uno de los valores
android.os.Build.TYPE
correspondientes a las tres configuraciones típicas del entorno de ejecución de Android: "user",
"userdebug" o "eng".
Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación
android.os.Build.USER
. No hay requisitos sobre el formato específico de este campo,
excepto que NO DEBE ser nulo ni una cadena vacía ("").

3.2.3. Compatibilidad con intents
Android usa intents para lograr una integración de aplicaciones de acoplamiento flexible. En esta sección, se describen los
requisitos relacionados con los patrones de intents que las implementaciones de dispositivos DEBEN cumplir. Cuando se dice que se"respeta", se refiere a que el implementador del dispositivo DEBE proporcionar una actividad, un servicio o algún otro componente de Android que especifique un filtro de intents que coincida y que se vincule a cada patrón de intents especificado y que implemente el comportamiento correcto.

3.2.3.1. Intents de aplicación principales
El proyecto upstream de Android define varias aplicaciones principales, como un selector de llamadas, un calendario,
un libro de contactos, un reproductor de música, etcétera. Los implementadores de dispositivos PUEDEN reemplazar estas aplicaciones por
versiones alternativas.
Sin embargo, cualquier versión alternativa DEBE respetar los mismos patrones de Intent que proporciona el proyecto
upstream. (por ejemplo, si un dispositivo contiene un reproductor de música alternativo, aún debe respetar el patrón de Intent
que emiten las aplicaciones de terceros para elegir una canción). Las implementaciones de dispositivos DEBEN admitir todos los patrones de intents
que se indican en el Apéndice A.
3.2.3.2. Anulaciones de intents
Como Android es una plataforma extensible, los implementadores de dispositivos DEBEN permitir que las aplicaciones de terceros anulen cada patrón de intent descrito en el
Apéndice A. El proyecto de código abierto de Android upstream
lo permite de forma predeterminada. Los implementadores de dispositivos NO DEBEN adjuntar privilegios especiales al
uso de estos patrones de Intent por parte de las aplicaciones del sistema ni impedir que las aplicaciones de terceros se vinculen a estos patrones y asuman el control de
ellos. Esta prohibición incluye específicamente inhabilitar la interfaz de usuario "Selector", que permite
al usuario seleccionar entre varias aplicaciones que controlan el mismo patrón de intent.
3.2.3.3. Espacios de nombres de intents
Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete ningún intent nuevo o
patrón de intent de transmisión que use una ACTION, CATEGORY o alguna otra cadena clave en el espacio de nombres android.*.
Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete ningún intent nuevo o
patrón de intent de transmisión que use una ACTION, CATEGORY o alguna otra cadena clave en un espacio de paquete
que pertenezca a otra organización. Los implementadores de dispositivos NO DEBEN alterar ni extender ninguno de los patrones de Intent
que se enumeran en los Apéndices A o B.
Esta prohibición es análoga a la especificada para las clases del lenguaje Java en el artículo 3.6.

3.2.3.4. Intents 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 los intents de transmisión pública
en respuesta a los eventos del sistema adecuados. En el
Apéndice B, se proporciona una lista de intents de emisión obligatorios. Sin embargo, ten en cuenta que el SDK puede definir intents de emisión adicionales, que TAMBIÉN DEBEN cumplirse.

3.3. Compatibilidad con la 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 archivo ELF
.so compilado para la arquitectura de hardware del dispositivo adecuada. Las implementaciones de dispositivos DEBEN incluir
compatibilidad con el código que se ejecuta en el entorno administrado para llamar al código nativo con la semántica estándar de la
interfaz nativa de Java (JNI). Las siguientes APIs deben estar disponibles para el código nativo:
• libc (biblioteca C)
• libm (biblioteca matemática)
• Interfaz JNI
• libz (compresión Zlib)
• liblog (registro de Android)
• Compatibilidad mínima con C++
• OpenGL ES 1.1
Estas bibliotecas DEBEN ser compatibles con la fuente (es decir, con el encabezado) y con el código binario (para una arquitectura de procesador determinada) con las versiones que proporciona el proyecto de código abierto de Android en Bionic.
Dado que
las implementaciones de Bionic no son totalmente compatibles con otras implementaciones, como la biblioteca
de GNU C, los implementadores de dispositivos DEBEN usar la implementación de Android. Si los implementadores de dispositivos usan una
implementación diferente de estas bibliotecas, deben garantizar la compatibilidad de encabezados y objetos binarios.
La compatibilidad con el código nativo es un desafío. Por este motivo, queremos repetir que se
recomienda encarecidamente a los implementadores de dispositivos que usen las implementaciones upstream de las bibliotecas mencionadas anteriormente para ayudar a
garantizar la compatibilidad.
3.4. Compatibilidad con la API web
Muchos desarrolladores y aplicaciones dependen del 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 con todas las implementaciones de
Android. La implementación de código abierto de Android usa la versión del motor de renderización de WebKit para
implementar WebView.
Debido a que no es factible desarrollar un paquete de pruebas integral para un navegador web, los implementadores de dispositivos
DEBEN usar la compilación upstream específica de WebKit en la implementación de WebView. Específicamente:
• WebView DEBE usar la compilación de WebKit 528.5 o posterior del árbol de código abierto de Android upstream para
Android 1.6. Esta compilación incluye un conjunto específico de correcciones de funcionalidad y seguridad para WebView.
• La cadena de usuario-agente que informa WebView DEBE tener el siguiente 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

◦ La cadena "<device name>" DEBE ser igual al valor de
android.os.Build.MODEL
◦ La cadena "<build ID>" DEBE ser igual al valor de android.os.Build.ID.
◦ Las cadenas "<language>" y "<country>" DEBEN seguir las convenciones habituales para
el código de país y el idioma, y DEBEN hacer referencia a la configuración regional actual del dispositivo en el
momento de la solicitud.
Las implementaciones PUEDEN enviar una cadena de usuario-agente personalizada en la aplicación independiente del navegador. Además, el navegador independiente PUEDE basarse en una tecnología de navegador alternativa (como Firefox,
Opera, etcétera).
Sin embargo, incluso si se envía una aplicación de navegador alternativa, el componente WebView
que se proporciona a las aplicaciones de terceros DEBE basarse en WebKit, como se indicó anteriormente.
La aplicación de navegador independiente DEBE incluir compatibilidad con Gears [Recursos, 12] y PUEDE
incluir compatibilidad con parte o la totalidad de HTML5.
3.5. Compatibilidad de comportamiento de las APIs
Los comportamientos de cada uno de los tipos de API (administrados, de software, nativos y web) deben ser coherentes con la
implementación preferida de Android disponible en el Proyecto de código abierto de Android.
Algunas áreas específicas de compatibilidad son las siguientes:
• Los dispositivos NO DEBEN cambiar el comportamiento o el 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 componente del sistema
(como Service, Activity, ContentProvider, etcétera).
• Los dispositivos NO DEBEN cambiar la semántica de un permiso en particular.
La lista anterior no es exhaustiva, y los implementadores de dispositivos son responsables de garantizar la compatibilidad
conductual. Por este motivo, los implementadores de dispositivos DEBEN usar el código fuente disponible a través del
Proyecto de código abierto de Android siempre que sea posible, en lugar de volver a implementar partes significativas del sistema.
El Conjunto de pruebas de compatibilidad (CTS) prueba partes significativas de la plataforma para verificar la compatibilidad de comportamiento,
pero no todas. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento con el
Proyecto de código abierto de Android.
3.6. Espacios de nombres de la API
Android sigue las convenciones de espacio de nombres de paquetes y clases definidas por el lenguaje de programación
Java. Para garantizar la compatibilidad con aplicaciones de terceros, los implementadores de dispositivos NO DEBEN realizar
ningún tipo de modificación prohibida (consulta a continuación) en estos espacios de nombres de paquetes:
• java.*
• javax.*
• sun.*
• android.*
• com.android.*
Entre las modificaciones prohibidas, se incluyen las siguientes:
• Las implementaciones de dispositivos NO DEBEN modificar las APIs expuestas públicamente en la plataforma de Android
cambiando cualquier firma de método o clase, o quitando clases o campos de clase.

• Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero tales
modificaciones NO DEBEN afectar el comportamiento declarado ni la firma en lenguaje Java de ninguna
API expuesta públicamente.
• Los implementadores de dispositivos NO DEBEN agregar elementos expuestos públicamente (como clases o
interfaces, o campos o métodos a clases o interfaces existentes) a las APIs 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 APIs nuevas ni
alterar las APIs existentes en los espacios de nombres mencionados anteriormente. Los implementadores de dispositivos PUEDEN realizar modificaciones
solo para uso interno, pero esas modificaciones NO DEBEN promocionarse ni exponerse a los desarrolladores.
Los implementadores de dispositivos PUEDEN agregar APIs personalizadas, pero estas NO DEBEN estar en un espacio de nombres que sea propiedad
de otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres
com.google.* o a uno similar; solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a
los espacios de nombres de otras empresas.
Si un implementador de dispositivos propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando
una funcionalidad nueva y útil a una API existente o agregando una API nueva), el implementador DEBE visitar
source.android.com y comenzar el proceso para contribuir con cambios y código, según la
información de ese sitio.
Ten en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar APIs en el lenguaje de programación
Java. El objetivo de esta sección es reforzar esas convenciones y hacerlas vinculantes
mediante su inclusión en esta definición de compatibilidad.
3.7. Compatibilidad con máquinas virtuales
Un dispositivo Android compatible debe admitir la especificación completa del código de bytes ejecutable de Dalvik (DEX) y las
sintaxis de la máquina virtual de Dalvik [Recursos, 13].
3.8. Compatibilidad con la interfaz de usuario
La plataforma de Android incluye algunas APIs para desarrolladores que les permiten conectarse a la interfaz
de usuario del sistema. Las implementaciones de dispositivos DEBEN incorporar estas APIs de IU estándar en las interfaces de usuario personalizadas
que desarrollan, como se explica a continuación.
3.8.1. Widgets
Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan
un "AppWidget" al usuario final [Resources, 14]. La versión de referencia de código abierto de Android incluye una
aplicación de selector que incluye elementos de la interfaz de usuario que le permiten al usuario agregar, ver y quitar
widgets de la app de la pantalla principal.
Los implementadores de dispositivos PUEDEN sustituir una alternativa al selector de referencia (es decir, la pantalla principal).
Los selectores alternativos DEBEN incluir compatibilidad integrada con AppWidgets y exponer elementos de la interfaz de usuario
para agregar, ver y quitar AppWidgets directamente desde el selector. Los selectores alternativos PUEDEN
omitir estos elementos de la interfaz de usuario. Sin embargo, si se omiten, el implementador del dispositivo DEBE proporcionar una
aplicación independiente a la que se pueda acceder desde el selector que permita a los usuarios agregar, ver y quitar
widgets de la app.

3.8.2. Notificaciones
Android incluye APIs que permiten a los desarrolladores notificar a los usuarios sobre eventos importantes [Recursos, 15]. Los implementadores de
dispositivos DEBEN proporcionar compatibilidad con cada clase de notificación definida, específicamente: sonidos,
vibración, luz y barra de estado.
Además, la implementación DEBE renderizar correctamente todos los recursos (íconos, archivos de sonido, etc.)
que se proporcionan en las APIs [Recursos, 7] o en la guía de estilo de íconos de la barra de estado [Recursos, 16]. Los
implementadores de dispositivos PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la
implementación de código abierto de Android de referencia. Sin embargo, esos sistemas de notificaciones alternativos DEBEN
admitir los recursos de notificaciones existentes, como se indicó anteriormente.
3.8.3. Búsqueda
Android incluye APIs [Resources, 17] que permiten a los desarrolladores incorporar la búsqueda en sus aplicaciones,
y exponer los datos de su aplicación en la búsqueda global del sistema. En términos generales, esta funcionalidad
consiste en una única interfaz de usuario en todo el sistema que permite a los usuarios ingresar consultas, mostrar sugerencias
a medida que escriben y mostrar resultados. Las APIs de Android permiten a los desarrolladores reutilizar esta interfaz para proporcionar
búsquedas dentro de sus propias apps y proporcionar resultados a la interfaz
común del usuario de la búsqueda global.
Las implementaciones de dispositivos DEBEN incluir una interfaz de usuario de búsqueda única, compartida y en todo el sistema que sea capaz de
hacer sugerencias en tiempo real en respuesta a las entradas del usuario. Las implementaciones de dispositivos DEBEN implementar las APIs que
permiten a los desarrolladores reutilizar esta interfaz de usuario para proporcionar búsquedas en sus propias aplicaciones.
Las implementaciones de dispositivos DEBEN implementar las APIs que permiten que las aplicaciones de terceros agreguen sugerencias
al cuadro de búsqueda cuando se ejecuta en el modo de búsqueda global. Si no hay aplicaciones de terceros instaladas que
usen esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar resultados y
sugerencias del motor de búsqueda web.
Las implementaciones de dispositivos PUEDEN enviar interfaces de usuario de búsqueda alternativas, pero DEBEN incluir un botón de búsqueda dedicado
físico o virtual que se pueda usar en cualquier momento en cualquier app para invocar el framework de búsqueda,
con el comportamiento que se proporciona en la documentación de la API.
3.8.4. Avisos
Las aplicaciones pueden usar la API de "Toast" (definida en [Recursos, 18]) para mostrar cadenas breves no modales al
usuario final, que desaparecen después de un breve período de tiempo. Las implementaciones de dispositivos DEBEN mostrar notificaciones emergentes de
aplicaciones a los usuarios finales de una manera muy visible.
4. Compatibilidad de software de referencia
Los implementadores de dispositivos DEBEN probar la compatibilidad de la implementación con las siguientes aplicaciones
de código abierto:
• Calculadora (incluida en el SDK)
• Lunar Lander (incluida en el SDK)
• ApiDemos (incluida en el SDK)
• Las aplicaciones "Apps for Android" [Recursos, 19]
Cada una de las apps anteriores DEBE iniciarse y comportarse correctamente en la implementación para que esta se considere

compatible.
5. Compatibilidad de empaquetado de aplicaciones
Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android tal como los genera la herramienta "aapt"
incluida en el SDK oficial de Android [Recursos, 20].
Las implementaciones de dispositivos NO DEBEN extender los formatos .apk, Android Manifest ni Dalvik bytecode
de manera tal que impidan que esos archivos se instalen y ejecuten correctamente en otros
dispositivos compatibles. Los implementadores de dispositivos DEBEN usar la implementación ascendente de referencia de Dalvik,
y el sistema de administració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 se
proporcionan como implementaciones de software en la implementación preferida de Android del Proyecto de código
abierto de Android [Recursos, 4].
Ten en cuenta que ni Google ni la Open Handset Alliance hacen ninguna representación de que estos
códecs no estén sujetos a patentes de terceros. Se advierte a quienes deseen usar este código fuente en productos de hardware o
software que las implementaciones de este código, incluido en software de código abierto o
shareware, pueden requerir licencias de patente de los titulares de patentes relevantes.
Nombre
de audio
Detalles del codificador y decodificador
Archivos compatibles
Contenido mono/estéreo en cualquier
3GPP (.3gp) y
combinación de tasas de bits estándar
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
hasta 160 Kbps y tasas de muestreo. No se admite contenido mono/estéreo
entre 8 y 48 kHz
AAC (.aac)
sin procesar en ningún
3GPP (.3gp) y
HE-AACv1
combinación de tasas de bits estándar
MPEG-4 (.mp4, .m4a)
X
(AAC+)
hasta 96 Kbps y tasas de muestreo de archivos. No se admite contenido mono/estéreo
de AAC (.aac)
puro
de entre 8 y 48 kHz
en archivos
HE-AACv2
3GPP (.3gp) ni
combinaciones de tasas de bits estándar
(MPEG-4 mejorado
(.mp4, .m4a)
X
hasta 96 Kbps y tasas de muestreo
AAC+)
. No se admite el formato sin procesar
entre 8 y 48 kHz
AAC (.aac)
AMR-NB
De 4.75 a 12.2 Kbps muestreados a
Archivos 3GPP (.3gp)
X
X
8 kHz
AMR-WB
9 tasas de 6.60 Kbit/s a 23.85
- Archivos 3GPP (.3gp)
X
Kbit/s muestreados a 16 kHz
MP3
Archivos MP3 (.mp3) constantes de 8 a 320 Kbps
X
(CBR) o de tasa de bits variable (VBR)
Tipo 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 Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Compatibilidad con los formatos de tono
y iMelody (.imy)
RTTTL/RTX, OTA y iMelody
Ogg Vorbis
.ogg
X
PCM lineal de 8 y 16 bits (frecuencias de hasta
PCM
X
WAVE
hasta el límite del hardware)
Archivos
de imagen
Nombre
Detalles del codificador decodificador
Compatibilidad
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Archivos
de video
Nombre
Detalles del codificador decodificador
Compatibilidad
3GPP (.3gp)
H.263
X
X
archivos
3GPP (.3gp)
H.264
X
y MPEG-4
(.mp4)
MPEG4
X
archivo 3GPP (.3gp)
SP
7. Compatibilidad con herramientas para desarrolladores
Las implementaciones de dispositivos DEBEN admitir las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.
Específicamente, los dispositivos compatibles con Android DEBEN ser compatibles con lo siguiente:
• Android Debug Bridge o adb [Resources, 21]
Las implementaciones de dispositivos DEBEN admitir todas las funciones de adb como se documenta en el SDK de
Android. El daemon adb del dispositivo DEBE estar inactivo de forma predeterminada, pero DEBE haber un mecanismo accesible para el usuario
para activar el puente de depuración de Android.
• Dalvik Debug Monitor Service o ddms [Resources, 22]
Las implementaciones de dispositivos DEBEN admitir todas las funciones de ddms como se documenta en el SDK de Android.
Como ddms usa adb, la compatibilidad con ddms DEBERIA estar inactiva de forma predeterminada, pero DEBE ser compatible
siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.

• Monkey [Resources, 23]
Las implementaciones de dispositivos DEBEN incluir el framework de Monkey y ponerlo a disposición de las
aplicaciones para que lo usen.
8. Compatibilidad de hardware
Android está diseñado para admitir implementadores de dispositivos que crean factores de forma y configuraciones innovadores.
Al mismo tiempo, los desarrolladores de Android esperan que todos los dispositivos
Android tengan cierto hardware, sensores y APIs. En esta sección, se enumeran las funciones de hardware que deben admitir todos los dispositivos compatibles con Android 1.6. En
Android 1.6, la mayoría de las funciones de hardware (como Wi-Fi, brújula y acelerómetro) son obligatorias.
Si un dispositivo incluye un componente de hardware en particular que tiene una API correspondiente para desarrolladores
externos, la implementación del dispositivo DEBE implementar esa API como se define en la documentación del SDK
de Android.
8.1. Pantalla
Android 1.6 incluye funciones que realizan ciertas operaciones de escalamiento y transformación automáticas en
algunas circunstancias para garantizar que las aplicaciones de terceros se ejecuten bastante bien en configuraciones de
hardware para las que no necesariamente se diseñaron de forma explícita [Resources, 24]. Los dispositivos DEBEN
implementar estos comportamientos de forma correcta, como se detalla en esta sección.
8.1.1. Configuraciones de pantalla estándar
En esta tabla, se enumeran las configuraciones de pantalla estándar que se consideran 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
Mediano
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
Mediano
FWVGA
480
854
5.0 - 5.8
Grande
Mediano
Las implementaciones de dispositivos que correspondan 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 la clase android.content.res.Configuration [Resources,
25].
Algunos paquetes .apk tienen manifiestos que no los identifican como compatibles con un rango de densidad específico.
Cuando se ejecutan esas aplicaciones, se aplican las siguientes restricciones:

• Las implementaciones de dispositivos DEBEN interpretar cualquier recurso que esté presente como predeterminado en
"mediano" (conocido como "mdpi" en la documentación del SDK).
• Cuando se operan en una pantalla de densidad "baja", las implementaciones de dispositivos DEBEN reducir los recursos de mdpi medios o
por un factor de 0.75.
• Cuando se operan en una pantalla de densidad "alta", las implementaciones de dispositivos DEBEN escalar los recursos de mdpi medios o
medianos por un factor de 1.5.
• Las implementaciones de dispositivos NO DEBEN escalar los recursos dentro de un rango de densidad y DEBEN escalar los recursos
exactamente con estos factores entre los rangos de densidad.
8.1.2. Parámetros de configuración de pantalla no estándar
Los parámetros de configuración de pantalla que no coinciden con uno de los parámetros de configuración estándar que se indican en el artículo 8.2.1 requieren
consideración y trabajo adicionales para ser compatibles. Los implementadores de dispositivos DEBEN comunicarse con el equipo de compatibilidad de Android
como se indica en el artículo 12 para obtener clasificaciones de bucket de tamaño de pantalla, densidad
y factor de escalamiento. Cuando se proporciona esta información, las implementaciones de dispositivos DEBEN implementarlas
como se especifica.
Ten en cuenta que algunas configuraciones de pantalla (como pantallas muy grandes o muy pequeñas, y algunas relaciones de aspecto)
son incompatibles de forma fundamental con Android 1.6. Por lo tanto, se recomienda que los implementadores de dispositivos
se comuniquen con el equipo de compatibilidad de Android lo antes posible en el proceso de desarrollo.
8.1.3. Métricas de visualización
Las implementaciones de dispositivos DEBEN informar valores correctos para todas las métricas de visualización definidas en
android.util.DisplayMetrics [Resources, 26].
8.2. Teclado
Implementaciones de dispositivos:
• DEBEN incluir compatibilidad con el Framework de administración de entradas (que permite a los desarrolladores
externos crear motores de administración de entradas, es decir, teclados en pantalla), como se detalla en
developer.android.com
• DEBEN proporcionar al menos una implementación de teclado en pantalla (independientemente de si hay un
teclado físico)
• PUEDEN incluir implementaciones adicionales de teclado en pantalla
• PUEDEN incluir un teclado físico
• NO DEBEN incluir un teclado físico que no coincida con uno de los formatos especificados
en android.content.res.Configuration [Resources, 25] (es decir, QWERTY o 12 teclas)
8.3. Navegación sin tacto
Implementaciones de dispositivos:
• SE PUEDEN omitir las opciones de navegación sin tacto (es decir, se puede omitir una bola de seguimiento, un pad direccional de 5 vías o una
rueda)
• SE DEBEN informar a través de android.content.res.Configuration [Resources, 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 de las aplicaciones a la orientación de la pantalla
vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación para una orientación
específica de la pantalla. Las implementaciones de dispositivos PUEDEN seleccionar la orientación vertical u horizontal como predeterminada.
Los dispositivos DEBEN informar el valor correcto de la orientación actual del dispositivo, cada vez que se consulte a través de
android.content.res.Configuration.orientation, android.view.Display.getOrientation() o alguna otra API.
8.5. Entrada de pantalla táctil
Implementaciones de dispositivos:
• DEBEN tener una pantalla táctil
• PUEDEN tener una pantalla táctil resistiva o capacitiva
• DEBEN informar el valor de android.content.res.Configuration [Resources, 25] que refleja
el tipo de pantalla táctil específica del dispositivo
8.6. Implementaciones de dispositivos USB
:
• SE DEBE implementar un cliente USB que se pueda conectar a un host USB con un puerto USB-A estándar
• SE DEBE implementar el puente de depuración de Android a través de USB (como se describe en el artículo 7)
• SE DEBE implementar un cliente de almacenamiento masivo en USB para que el almacenamiento extraíble o multimedia esté presente en el
dispositivo
• SE DEBE usar el factor de forma micro-USB en el dispositivo
• SE DEBE implementar la compatibilidad con la especificación de almacenamiento masivo en USB (para que se pueda acceder al almacenamiento
extraíble o fijo del dispositivo desde una PC host)
• SE PUEDE incluir un puerto no estándar en el dispositivo, pero, de ser así, DEBE enviarse con un cable capaz de
conectar el pinout personalizado al puerto USB-A estándar
8.7. Teclas de navegación
Las funciones de Inicio, Menú y Atrás son esenciales para el paradigma de navegación de Android. Las implementaciones de
dispositivos DEBEN poner estas funciones a disposición del usuario en todo momento, independientemente del estado de la
aplicación. Estas funciones DEBEN implementarse a través de botones dedicados. PUEDEN implementarse
con software, gestos, panel táctil, etc., pero, de ser así, DEBEN ser accesibles en todo momento y no deben ocultar ni
interferir con el área de visualización disponible de la aplicación.
Los implementadores de dispositivos también DEBEN proporcionar una tecla de búsqueda dedicada. Los implementadores de dispositivos TAMBIÉN PUEDEN
proporcionar teclas de envío y finalización para las llamadas telefónicas.
8.8. Wi-Fi
Las implementaciones de dispositivos DEBEN ser compatibles con 802.11b y 802.11g, y PUEDEN ser compatibles con 802.11a.

8.9. Cámara
Las implementaciones de dispositivos DEBEN incluir una cámara. La cámara incluida debe cumplir con los siguientes requisitos:
• DEBE tener una resolución de al menos 2 megapíxeles
• DEBE tener enfoque automático de hardware o software implementado en el controlador de la cámara
(transparente para el software de la 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 del flash NO DEBE estar encendida mientras se haya registrado una instancia de
android.hardware.Camera.PreviewCallback en una superficie de vista previa de la cámara
.
Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara
[Resources, 27]:
1. Si una aplicación nunca llamó a android.hardware.Camera.Parameters.setPreviewFormat(int),
entonces el dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para los datos de vista previa
que se proporcionan a las devoluciones de llamada de la aplicación.
2. Si una aplicación registra una instancia de android.hardware.Camera.PreviewCallback y el sistema
llama al método onPreviewFrame() cuando el formato de vista previa es YCbCr_420_SP, los
datos en el byte[] que se pasa a onPreviewFrame() deben estar en el formato de codificación NV21.
(Este es el formato que usa de forma nativa la familia de hardware 7K). Es decir, NV21 DEBE ser el valor predeterminado.
8.9.1. Cámaras sin enfoque automático
Si un dispositivo no tiene una cámara con enfoque automático, el implementador del dispositivo DEBE cumplir con los requisitos adicionales de
esta sección. Las implementaciones de dispositivos DEBEN implementar la API de cámara completa incluida en la documentación del SDK de Android 1.6
de alguna manera razonable, independientemente de las capacidades reales del hardware de la cámara.
En Android 1.6, si la cámara no tiene 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 "1". Este valor está destinado a que lo usen aplicaciones como Android Market para
identificar de forma selectiva las capacidades del dispositivo y se reemplazará en una versión futura de Android por una
API sólida.
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 instancia registrada de
android.hardware.Camera.AutoFocusCallback, aunque no se haya realizado ningún enfoque
. Esto se hace para evitar que las aplicaciones existentes se interrumpan esperando para siempre una devolución de llamada de enfoque automático
que nunca llegará.
3. El controlador o el framework de
deben activar la llamada al método AutoFocusCallback.onAutoFocus() en un evento nuevo en el subproceso de Looper del framework principal. Es decir, Camera.autoFocus()
NO DEBE llamar directamente a AutoFocusCallback.onAutoFocus(), ya que esto infringe el modelo de subprocesos del framework de Android
y dañará las apps.
8.10. Acelerómetro
Las implementaciones de dispositivos DEBEN incluir un acelerómetro de 3 ejes y DEBEN poder entregar eventos a al
menos 50 Hz. El sistema de coordenadas que usa el acelerómetro DEBE cumplir con el sistema de coordenadas del sensor
de Android, como se detalla en la 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 a al menos
10 Hz. El sistema de coordenadas que usa la brújula DEBE cumplir con el sistema de coordenadas del sensor
de Android, como se define en la API de Android [Recursos, 28].
8.12. GPS
Las implementaciones de dispositivos DEBEN incluir un GPS y DEBEN incluir algún tipo de técnica de "GPS asistido"
para minimizar el tiempo de bloqueo del GPS.
8.13. Telefonía
Implementaciones de dispositivos:
• DEBEN incluir telefonía GSM o CDMA
• DEBEN implementar las APIs adecuadas, como se detalla en la documentación del SDK de Android en
developer.android.com
Ten en cuenta que este requisito implica que los dispositivos que no son teléfonos no son compatibles con Android 1.6. Los dispositivos
1.6 de Android DEBEN incluir hardware de telefonía. Consulta el Apéndice C para obtener información sobre dispositivos
que no sean teléfonos.
8.14. Controles de volumen
Los dispositivos compatibles con Android DEBEN incluir un mecanismo que permita al usuario aumentar y disminuir el
volumen de audio. Las implementaciones de dispositivos DEBEN poner estas funciones a disposición del usuario en todo momento,
independientemente del estado de la aplicación. Estas funciones PUEDEN implementarse con teclas físicas,
software, gestos, panel táctil, etc., pero DEBEN ser accesibles en todo momento y no deben ocultar ni interferir
con el área de visualización disponible de la aplicación (consulta la sección Pantalla más arriba).
Cuando se usan estos botones, SE DEBEN generar los eventos de teclas correspondientes y enviarlos a la
aplicación en primer plano. Si la aplicación no intercepta ni descarta el evento, la implementación de
del dispositivo DEBE controlar 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 coherente para los
consumidores. Las implementaciones compatibles deben garantizar no solo que las aplicaciones se ejecuten correctamente en
el dispositivo, sino que lo hagan con un rendimiento razonable y una buena experiencia general del usuario.
Las implementaciones de dispositivos DEBEN cumplir con las métricas de rendimiento clave de un dispositivo compatible con Android 1.6,
como se muestra en la siguiente tabla:
Métrica
Umbral de rendimiento
Comentarios

CTS realiza pruebas de esto.
Las siguientes aplicaciones
El tiempo de inicio se mide como el tiempo total para
deben iniciarse dentro del
completar la carga de la actividad predeterminada para la
aplicación
hora especificada.
aplicación, incluido el tiempo que tarda en iniciarse el
Tiempo de inicio
Navegador: menos de 1300 ms
proceso de Linux, cargar el paquete de Android en la
MMS/SMS: menos de 700 ms
VM de Dalvik y llamar a onCreate.
AlarmClock: Menos de 650 ms
Se lanzarán varias aplicaciones.
CTS realiza esta prueba.
Si vuelves a iniciar la
primera aplicación simultánea,
las aplicaciones
deberían completarse en menos tiempo que el
tiempo de inicio original.
10. Compatibilidad del modelo de seguridad
Las implementaciones de dispositivos DEBEN implementar un modelo de seguridad coherente con el modelo de seguridad
de la plataforma de Android, como se define en el documento de referencia Seguridad y permisos de las APIs [Recursos, 29] en la
documentación para desarrolladores de Android. Las implementaciones de dispositivos DEBEN admitir la instalación de aplicaciones
con firma propia sin requerir permisos ni certificados adicionales de terceros o autoridades.
En particular, los dispositivos compatibles DEBEN admitir los siguientes mecanismos de seguridad:
10.1. Permisos
Las implementaciones de dispositivos DEBEN admitir el modelo de permisos de Android, como se define en la documentación para desarrolladores de
Android [Recursos, 9]. Específicamente, las implementaciones DEBEN aplicar cada permiso
definido como se describe en la documentación del SDK. No se pueden omitir, alterar ni ignorar los permisos.
Las implementaciones PUEDEN agregar permisos adicionales, siempre y cuando las nuevas cadenas de ID de permiso no estén en el espacio de nombres
android.*.
10.2. Aislamiento de usuarios y procesos
Las implementaciones de dispositivos DEBEN admitir el modelo de zona de pruebas de aplicaciones de Android, en el que cada aplicación
se ejecuta como un UID único de estilo Unix y en un proceso independiente.
Las implementaciones de dispositivos DEBEN admitir la ejecución de varias aplicaciones como el mismo ID de usuario de Linux, siempre
que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de Seguridad y Permisos
[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 la referencia de Seguridad y Permisos [Resources, 29].

11. Conjunto de pruebas de compatibilidad
Las implementaciones de dispositivos DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android [Recursos, 3] disponible
en el Proyecto de código abierto de Android con 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 lo
más posible y DEBEN garantizar la compatibilidad en caso de ambigüedad en CTS y para cualquier
reimplementación de partes del código fuente de referencia.
El CTS está diseñado para ejecutarse en un dispositivo real. Al igual que cualquier software, el CTS puede contener errores.
El CTS tendrá control de versiones independientemente de esta definición de compatibilidad, y es posible que se lancen varias revisiones del
CTS para Android 1.6. Sin embargo, esas versiones solo corregirán errores de comportamiento en las pruebas de CTS
y no impondrán ninguna prueba, comportamiento o API nuevos para una versión determinada de la plataforma.
12. Comunícate con nosotros
Puedes comunicarte con el equipo de compatibilidad de Android en compatibility@android.com para obtener aclaraciones relacionadas con
esta Definición de Compatibilidad y enviar comentarios sobre ella.

Se usa
EXTRA_CREATE_DESCRIPTION
con SHOW_OR_CREATE_CONTACT para
especificar una descripción exacta que se

mostrará cuando se le solicite al usuario que
cree un contacto nuevo.
Se usa
con SHOW_OR_CREATE_CONTACT para
EXTRA_FORCE_CREATE
forzar la creación de un contacto nuevo si no se encuentra
un contacto coincidente.
Este es el intent que se activa cuando se hace clic en una
SUGGESTION_SEARCH_CLICKED
sugerencia de búsqueda.
Este es el intent que se activa cuando se hace clic en una
SUGGESTION_CREATE_CONTACT_CLICKED sugerencia de búsqueda para crear un
contacto.
Este es el intent que se activa cuando se hace clic en una
SUGGESTION_SEARCH_DIAL_NUMBER_CLICKED
sugerencia de búsqueda para marcar un número
.
Toma como entrada un URI de datos con un esquema mailto:
SHOW_OR_CREATE_CONTACT
o tel:.

Apéndice B: Intents de transmisión obligatoriosNOTA: Esta lista es provisional y se
actualizará en el futuro.
Acción de intent
Descripción
Acción de emisión: Se transmite una vez, después de que el sistema
ACTION_BOOT_COMPLETED
termina de iniciarse.
Acción de transmisión: Se transmite una vez, cuando se recibe una llamada
ACTION_CALL_BUTTON
.
Acción de transmisión: Se presionó el "botón de la cámara"
ACTION_CAMERA_BUTTON
.
Acción de emisión: La configuración (orientación, configuración regional, etc.)
del dispositivo
ACTION_CONFIGURATION_CHANGED actual
cambió.
ACTION_DATE_CHANGED
Acción de emisión: La fecha cambió.
Acción de transmisión: Indica que el dispositivo
ACTION_DEVICE_STORAGE_LOW
tiene poca memoria.
Acción de transmisión: Indica que el dispositivo
ACTION_DEVICE_STORAGE_OK
ya no tiene poca memoria.
Acción de transmisión: Auriculares con cable conectados o
ACTION_HEADSET_PLUG
desconectados.
Acción de emisión: Se cambió un método de entrada
ACTION_INPUT_METHOD_CHANGED
.
Acción de transmisión: Se quitó el contenido multimedia externo
ACTION_MEDIA_BAD_REMOVAL
de la ranura de la tarjeta SD, pero no se desactivó
el punto de activación.
Acción de transmisión: Se presionó el "Botón de medios"
ACTION_MEDIA_BUTTON
.
Acción de transmisión: Hay contenido multimedia externo y
se está verificando en el disco. La ruta de acceso al punto de activación para
ACTION_MEDIA_CHECKING
el contenido multimedia de verificación se encuentra en el campo
Intent.mData.
Acción de transmisión: El usuario expresó su deseo de
ACTION_MEDIA_EJECT
quitar el medio de almacenamiento externo.
Acción de transmisión: Hay un medio externo y
ACTION_MEDIA_MOUNTED
se activa en su punto de activación.
Acción de transmisión: Hay contenido multimedia externo, pero
usa un sistema de archivos incompatible (o está en blanco). La ruta de acceso a
ACTION_MEDIA_NOFS
el punto de activación para el contenido multimedia de verificación se
contiene en el campo Intent.mData.
Acción de transmisión: Se quitó
ACTION_MEDIA_REMOVED
el contenido multimedia externo.
Acción de transmisión: El escáner de contenido multimedia finalizó
ACTION_MEDIA_SCANNER_FINISHED
el análisis de un directorio.
Acción de transmisión: Solicita al escáner multimedia que
ACTION_MEDIA_SCANNER_SCAN_FILE
analice un archivo y lo agregue a la base de datos de contenido multimedia.

Acción de transmisión: El escáner de contenido multimedia comenzó
ACTION_MEDIA_SCANNER_STARTED
a analizar un directorio.
Acción de transmisión: Se desmontó el contenido multimedia externo
ACTION_MEDIA_SHARED
porque se comparte a través del almacenamiento masivo USB.
Acción de transmisión: Hay un medio externo, pero
ACTION_MEDIA_UNMOUNTABLE
no se puede activar.
Acción de transmisión: Hay medios externos, pero
ACTION_MEDIA_UNMOUNTED
no está activado en su punto de activación.
Acción de transmisión: Se está a punto de realizar una llamada saliente
ACTION_NEW_OUTGOING_CALL
.
Acción de emisión: Se instaló un nuevo paquete de aplicación
ACTION_PACKAGE_ADDED
en el dispositivo.
Acción de emisión: Se cambió un paquete de aplicación existente
ACTION_PACKAGE_CHANGED
(p.ej., se habilitó o inhabilitó un componente).

Acción de transmisión: El usuario borró los datos de
un paquete. Debe precederse
por ACTION_PACKAGE_RESTARTED, después de lo cual
ACTION_PACKAGE_DATA_CLEARED
se borran todos sus datos persistentes y se envía esta
transmisión. Ten en cuenta que el paquete borrado
no recibe esta transmisión. Los datos contienen
el nombre del paquete.
Acción de transmisión: Se quitó del dispositivo un paquete de aplicación existente
. Los datos
ACTION_PACKAGE_REMOVED
contienen el nombre del paquete. El paquete
que se está instalando no recibe este Intent.
Acción de emisión: Se instaló una versión nueva de un paquete de aplicación
ACTION_PACKAGE_REPLACED
que reemplaza una versión
existente que se instaló anteriormente.
Acción de transmisión: El usuario reinició un
paquete y se finalizaron todos sus procesos.
Se debe quitar todo el estado del entorno de ejecución asociado con él (procesos,
ACTION_PACKAGE_RESTARTED
alarmas, notificaciones, etcétera). Ten en cuenta
que el paquete reiniciado no recibe esta
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 en las que publican nuevos
eventos o elementos ACTION_PROVIDER_CHANGED
que pueden ser de especial interés para el usuario.

ACTION_SCREEN_OFF
Acción de transmisión: Se envía después de que se apaga la pantalla.
ACTION_SCREEN_ON
Acción de transmisión: Se envía después de que se enciende la pantalla.
Acción de transmisión: Se quitó un ID de usuario
ACTION_UID_REMOVED
del sistema.
Acción de transmisión: El dispositivo entró en el modo de almacenamiento masivo
ACTION_UMS_CONNECTED
USB.

Acción de emisión: El dispositivo salió del modo de almacenamiento masivo
ACTION_UMS_DISCONNECTED
USB.
Acción de transmisión: Se envía cuando el usuario está presente
ACTION_USER_PRESENT
después de que el dispositivo se activa (p. ej., cuando desaparece el

protector de pantalla).
Acción de transmisión: Cambió el fondo de pantalla actual del sistema
ACTION_WALLPAPER_CHANGED
.
ACTION_TIME_CHANGED
Acción de emisión: Se estableció la hora.
ACTION_TIME_TICK
Acción de emisión: Cambió la hora actual.
ACTION_TIMEZONE_CHANGED
Acción de transmisión: Se cambió la zona horaria.
Acción de transmisión: Cambió el estado de carga o el nivel de carga
ACTION_BATTERY_CHANGED
de la batería.
Acción de transmisión: Indica la condición de batería baja
ACTION_BATTERY_LOW
en el dispositivo. Esta transmisión corresponde al diálogo del sistema
"Advertencia de batería baja".
Acción de transmisión: Indica que la batería ahora está bien
después de estar baja. Se enviará
ACTION_BATTERY_OKAY
después de ACTION_BATTERY_LOW una vez que la batería
haya vuelto a un estado normal.
Estado de la red
Acción de intent
Descripción
Acción de intent de emisión que indica que cambió el estado
NETWORK_STATE_CHANGED_ACTION
de la conectividad Wi-Fi.
Acción de intent de transmisión que indica que cambió el RSSI (intensidad de la señal) de
RSSI_CHANGED_ACTION
.
Acción de intent de transmisión que indica que se estableció o se perdió una
SUPPLICANT_STATE_CHANGED_ACTION
conexión con el solicitante.

Acción de intent de transmisión que indica que la conexión Wi-Fi
WIFI_STATE_CHANGED_ACTION
se habilitó, inhabilitó, habilitó
inhabilitó o es desconocida.
Los IDs de red de las redes configuradas
NETWORK_IDS_CHANGED_ACTION
podrían haber cambiado.
Acción de intent de transmisión que indica que el parámetro de configuración
ACTION_BACKGROUND_DATA_SETTING_CHANGED para el uso de datos en segundo plano
cambió de valor.
Intento de transmisión que indica que se produjo un cambio en la conectividad de la red
CONNECTIVITY_ACTION
.
Acción de transmisión: El usuario activó o desactivó el
ACTION_AIRPLANE_MODE_CHANGED
modo de avión del teléfono.

Apéndice C: Consideraciones futuras En este apéndice, se aclaran ciertas partes de esta Definición de compatibilidad de Android
1.6 y, en algunos casos, se analizan los cambios previstos o planificados para una
versión futura de la plataforma de Android. Este apéndice es solo para fines informativos y de planificación, y
no forma parte de la Definición de Compatibilidad para Android 1.6.
1. Dispositivos que no son teléfonos
Android 1.6 está diseñado exclusivamente para teléfonos, y la funcionalidad de telefonía no es opcional. Se espera que las versiones futuras
de la plataforma de Android hagan que la telefonía sea opcional (y, por lo tanto, permitan dispositivos
Android que no sean teléfonos), pero solo los teléfonos son compatibles con Android 1.6.
2. Compatibilidad con Bluetooth
La versión 1.6 de Android no admite APIs de 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 incluirá las APIs de Bluetooth. En ese momento, la compatibilidad con Bluetooth será obligatoria para la
compatibilidad.
Por lo tanto, te recomendamos que los dispositivos con Android 1.6 incluyan Bluetooth para que sean
compatibles con las versiones futuras de Android que lo requieran.
3. Componentes de hardware obligatorios
Todos los componentes de hardware de la Sección 8 (incluidos Wi-Fi, magnetómetro/brújula, acelerómetro, etc.) son
obligatorios y no se pueden omitir. Se espera que las versiones futuras de Android hagan que algunos (pero no todos)
de estos componentes sean opcionales, junto con las herramientas correspondientes para que los desarrolladores de terceros manejen estos
cambios.
4. Aplicaciones de ejemplo
El documento de definición de compatibilidad de una versión futura de Android incluirá una lista de aplicaciones más extensa y
representativa que las que se enumeran en la Sección 4 anterior. En el caso de Android 1.6, se deben probar las
aplicaciones que se indican en la Sección 4.
5. Pantallas táctiles
Es posible que las versiones futuras de la Definición de compatibilidad permitan o no que los dispositivos omitan las pantallas táctiles.
Sin embargo, actualmente, gran parte de la implementación del framework de Android supone la existencia de una
pantalla táctil. Si se omite una pantalla táctil, se romperían todas las aplicaciones de Android de terceros actuales,
por lo que en Android 1.6 se requiere una pantalla táctil para la compatibilidad.

6. Rendimiento
Las versiones futuras de CTS también medirán el uso de la CPU y el rendimiento de los siguientes
componentes de una implementación:
• Gráficos 2D
• Gráficos 3D
• Reproducción de video
• Reproducción de audio
• Reproducción de A2DP de Bluetooth

Definición de compatibilidad de Android 1.6 Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Esquema del documento

Definición de compatibilidad de Android 1.6
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.