El uso de "debe", "no debe", "obligatorio", "deberá", "no deberá", "debería", "no debería", "recomendado", "puede" y "opcional" se ajusta al estándar del IETF. definido en RFC2119 [ Recursos, 1 ].

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 2.2. Una "implementación de dispositivo" o "implementación" es la solución de hardware/software así desarrollada.

Para ser considerado compatible con Android 2.2, las implementaciones del dispositivo:

DEBE cumplir con los requisitos presentados en esta Definición de compatibilidad, incluido cualquier documento incorporado mediante referencia.
DEBE aprobar la versión más reciente del conjunto de pruebas de compatibilidad de Android (CTS) disponible en el momento en que se completa la implementación del software del dispositivo. (El CTS está disponible como parte del Proyecto de código abierto de Android [ Recursos, 2 ]). El CTS prueba muchos, pero no todos, los componentes descritos en este documento.

Cuando esta definición o el CTS no dice nada, es ambiguo o está incompleto, es responsabilidad del implementador del dispositivo garantizar la compatibilidad con las implementaciones existentes. Por esta razón, el Proyecto de código abierto de Android [ Recursos, 3 ] 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 "ascendente" disponible en el Proyecto de código abierto de Android. Si bien hipotéticamente algunos componentes pueden reemplazarse con implementaciones alternativas, se desaconseja encarecidamente esta práctica, ya que pasar las pruebas CTS será 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. Finalmente, tenga en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

2. Recursos

Niveles de requisitos IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

Descripción general del programa de compatibilidad de Android: http://source.android.com/docs/compatibility/index.html

Proyecto de código abierto de Android: http://source.android.com/

Definiciones y documentación de API: http://developer.android.com/reference/packages.html

Referencia de permisos de Android: http://developer.android.com/reference/android/Manifest.permission.html

Referencia de android.os.Build: http://developer.android.com/reference/android/os/Build.html

Cadenas de versión permitidas de Android 2.2: http://source.android.com/docs/compatibility/2.2/versions.html

Clase android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Especificación de la máquina virtual Dalvik: disponible en el código fuente de Android, en dalvik/docs

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

Notificaciones: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

Recursos de la aplicación: http://code.google.com/android/reference/available-resources.html

Guía de estilo de iconos de la barra de estado: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

Administrador de búsqueda: http://developer.android.com/reference/android/app/SearchManager.html

Brindis: http://developer.android.com/reference/android/widget/Toast.html

Fondos de pantalla en vivo: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Aplicaciones para Android: http://code.google.com/p/apps-for-android

Documentación de la herramienta de referencia (para adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html

Descripción del archivo apk de Android: http://developer.android.com/guide/topics/fundamentals.html

Archivos de manifiesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html

Herramienta de prueba de monos: https://developer.android.com/studio/test/other-testing-tools/monkey

Lista de funciones de hardware de Android: http://developer.android.com/reference/android/content/pm/PackageManager.html

Compatible con varias pantallas: http://developer.android.com/guide/practices/screens_support.html

android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html

Espacio de coordenadas del sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html

Referencia de permisos y seguridad de Android: http://developer.android.com/guide/topics/security/security.html

API de Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Muchos de estos recursos se derivan directa o indirectamente del SDK de Android 2.2 y serán funcionalmente idénticos a la información contenida en la documentación de ese SDK. En cualquier caso en el que esta Definición de compatibilidad o el Conjunto de pruebas de compatibilidad no estén de acuerdo con la documentación del SDK, la documentación del SDK se considera autorizada. Cualquier detalle técnico proporcionado en las referencias incluidas anteriormente se considera por inclusión parte de esta Definición de compatibilidad.

3.software

La plataforma Android incluye un conjunto de API administradas, un conjunto de API nativas y un conjunto de API denominadas "blandas", como el sistema Intent y las API de aplicaciones web. Esta sección detalla las API físicas y blandas que son parte integral de la compatibilidad, así como otros comportamientos técnicos y de interfaz de usuario relevantes. 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. 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 implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android 2.2 [ Recursos, 4 ].

Las implementaciones de dispositivos NO DEBEN omitir ninguna API administrada, alterar las interfaces o firmas de API, desviarse del comportamiento documentado ni incluir operaciones no operativas, excepto donde lo permita específicamente esta Definición de compatibilidad.

3.2. Compatibilidad de API suave

Además de las API administradas de la Sección 3.1, Android también incluye una importante API "suave" solo en tiempo de ejecución, en forma de elementos como intenciones, permisos y aspectos similares de las aplicaciones de Android que no se pueden aplicar en el momento de la compilación de la aplicación. Esta sección detalla las API "soft" y los comportamientos del sistema necesarios para la compatibilidad con Android 2.2. 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 en la página de referencia de permisos [ Recursos, 5 ]. 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, 6 ] que están destinadas a 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 DEBEN ajustarse las implementaciones de dispositivos.

Parámetro	Comentarios
android.os.Build.VERSION.RELEASE	La versión del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en [ Recursos, 7 ].
android.os.Build.VERSIÓN.SDK	La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 2.2, este campo DEBE tener el valor entero 8.
android.os.Build.VERSIÓN.INCREMENTAL	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 disponibles para los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de fuente se utilizó para generar la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.BOARD	Un valor elegido por el implementador del dispositivo que identifica el hardware interno específico utilizado por el dispositivo, en formato legible por humanos. Un posible uso 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 o una cadena vacía ("").
android.os.Build.BRAND	Un valor elegido por el implementador del dispositivo que identifica el nombre de la 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 el proveedor que vendió el dispositivo. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.DEVICE	Un valor elegido por el implementador del dispositivo que identifica la configuración o revisión específica del cuerpo (a veces llamado "diseño industrial") del dispositivo. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.FINGERPRINT	Una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla: `$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Por ejemplo: `acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys` La huella digital NO DEBE incluir espacios en blanco. Si otros campos incluidos en la plantilla anterior tienen espacios en blanco, DEBEN reemplazarse en la huella digital de compilación con otro carácter, como el carácter de guión bajo ("_").
android.os.Build.HOST	Una cadena que identifica de forma única el host en el que se creó la compilación, en formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.ID	Un identificador elegido por 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 suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.MODEL	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 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 o una cadena vacía ("").
android.os.Build.PRODUCTO	Un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre en código del dispositivo. DEBE ser legible por humanos, pero no necesariamente está destinado a ser visto por usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.TAGS	Una lista de etiquetas separadas por comas elegidas por el implementador del dispositivo que distinguen aún más la compilación. Por ejemplo, "sin firmar, depurar". Este campo NO DEBE ser nulo o una cadena vacía (""), pero una sola etiqueta (como "liberación") está bien.
android.os.Build.TIME	Un valor que representa la marca de tiempo de cuando ocurrió la compilación.
android.os.Build.TYPE	Un valor elegido por el implementador del dispositivo que especifica la configuración de tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: "user", "userdebug" o "eng".
android.os.Build.USER	Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. 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 los requisitos relacionados con los patrones de intención que DEBEN ser respetados por las implementaciones de dispositivos. Por "honrado" se entiende que el implementador del dispositivo DEBE proporcionar una Actividad o Servicio de Android que especifique un filtro de Intención coincidente y se vincule e implemente el comportamiento correcto para cada 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, una libreta de contactos, un 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 proyecto inicial. 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 siguientes aplicaciones se consideran aplicaciones principales del sistema Android:

Reloj de escritorio
Navegador
Calendario
Calculadora
Cámara
Contactos
Correo electrónico
Galería
Búsqueda global
Lanzacohetes
LivePicker (es decir, la aplicación de selección de Live Wallpaper; PUEDE omitirse si el dispositivo no es compatible con Live Wallpapers, según la Sección 3.8.5).
Mensajería (también conocida como "Mms")
Música
Teléfono
Ajustes
Grabador de sonido

Las aplicaciones principales del sistema Android incluyen varios componentes de Actividad o Servicio que se consideran "públicos". Es decir, el atributo "android:exportado" puede estar ausente o puede tener el valor "verdadero".

Para cada Actividad o Servicio definido en una de las aplicaciones principales del sistema Android que no esté marcado como no público mediante un atributo android:exportado con el valor "falso", las implementaciones del dispositivo DEBEN incluir un componente del mismo tipo que implemente el mismo filtro de Intención. patrones como la aplicación principal del sistema Android.

En otras palabras, la implementación de un dispositivo PUEDE reemplazar las aplicaciones principales del sistema Android; sin embargo, si es así, la implementación del dispositivo DEBE admitir todos los patrones de intención definidos por cada aplicación principal del sistema Android que se reemplaza.

3.2.3.2. Anulaciones de intención

Como Android es una plataforma extensible, los implementadores de dispositivos DEBEN permitir que cada patrón de Intención al que se hace referencia en la Sección 3.2.3.1 sea 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 al uso de estos patrones de Intent por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros se vinculen y asuman el control de estos patrones. Esta prohibición incluye específicamente, entre otras, la desactivación de la interfaz de usuario "Selector", que permite al usuario 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 nuevo patrón de Intención o Intención de transmisión utilizando 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 nuevo patrón de Intención o Intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete que pertenece a otra organización. Los implementadores de dispositivos NO DEBEN alterar ni ampliar ninguno de los patrones de Intención utilizados por las aplicaciones principales enumeradas en la Sección 3.2.3.1.

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 los Intents de transmisión pública en respuesta a los eventos apropiados del sistema. Las intenciones de transmisión se describen en la documentación del SDK.

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 archivo ELF .so compilado para la arquitectura de hardware del dispositivo adecuada. Las implementaciones de dispositivos DEBEN incluir soporte para el código que se ejecuta en el entorno administrado para llamar al código nativo, utilizando la semántica estándar de la interfaz nativa de Java (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++
Soporte para OpenGL, como se describe a continuación

Las implementaciones de dispositivos DEBEN ser compatibles con OpenGL ES 1.0. Los dispositivos que carecen de aceleración de hardware DEBEN implementar OpenGL ES 1.0 mediante un renderizador de software. Las implementaciones de dispositivos DEBEN implementar tanto OpenGL ES 1.1 como admita el hardware del dispositivo. Las implementaciones de dispositivos DEBEN proporcionar una implementación para OpenGL ES 2.0, si el hardware es capaz de ofrecer un rendimiento razonable en esas API.

Estas bibliotecas DEBEN ser compatibles con el código fuente (es decir, con el encabezado) y con el código binario (para una arquitectura de procesador determinada) con las versiones proporcionadas en Bionic por el proyecto de código abierto de Android. Dado que las implementaciones de Bionic no son totalmente compatibles con otras implementaciones como la biblioteca GNU C, los implementadores de dispositivos DEBEN usar la implementación de Android. Si los implementadores de dispositivos utilizan una implementación diferente de estas bibliotecas, DEBEN garantizar la compatibilidad de encabezado, binaria y de comportamiento.

Las implementaciones de dispositivos DEBEN informar con precisión la interfaz binaria de aplicación (ABI) nativa admitida por el dispositivo, a través de la API android.os.Build.CPU_ABI . La ABI DEBE ser una de las entradas documentadas en la última versión del NDK de Android, en el archivo docs/CPU-ARCH-ABIS.txt . Tenga en cuenta que las versiones adicionales del NDK de Android pueden introducir compatibilidad con ABI adicionales.

La compatibilidad del código nativo es un desafío. Por esta razón, se debe repetir que se recomienda MUY fuertemente a los implementadores de dispositivos que utilicen las implementaciones ascendentes de las bibliotecas enumeradas anteriormente para ayudar a garantizar la compatibilidad.

3.4. Compatibilidad web

Muchos desarrolladores y aplicaciones dependen del comportamiento de la clase android.webkit.WebView [ Recursos, 8 ] para sus interfaces de usuario, por lo que la implementación de WebView debe ser compatible con todas las implementaciones de Android. De manera similar, una experiencia web completa es fundamental para la experiencia del usuario de Android. Las implementaciones de dispositivos DEBEN incluir una versión de android.webkit.WebView coherente con el software de Android anterior y DEBEN incluir un navegador moderno compatible con HTML5, como se describe a continuación.

3.4.1. Compatibilidad con WebView

La implementación de Android Open Source utiliza el motor de renderizado WebKit para implementar android.webkit.WebView . Debido a que no es factible desarrollar un conjunto de pruebas integral para un sistema de renderizado web, los implementadores de dispositivos DEBEN usar la compilación ascendente específica de WebKit en la implementación de WebView. Específicamente:

Las implementaciones de android.webkit.WebView de las implementaciones de dispositivos DEBEN basarse en la compilación WebKit 533.1 del árbol de código abierto de Android ascendente para Android 2.2. Esta compilación incluye un conjunto específico de funcionalidades y correcciones de seguridad para WebView. Los implementadores de dispositivos PUEDEN incluir personalizaciones en la implementación de WebKit; sin embargo, dichas personalizaciones NO DEBEN alterar el comportamiento de WebView, incluido el comportamiento de representación.
La cadena del agente de usuario informada por WebView DEBE tener este formato:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- El valor de la cadena $(VERSION) DEBE ser el mismo que el valor de android.os.Build.VERSION.RELEASE
- El valor de la cadena $(LOCALE) DEBE seguir las convenciones ISO para el código de país y el idioma, y DEBE hacer referencia a la configuración regional actual del dispositivo.
- El valor de la cadena $(MODEL) DEBE ser el mismo que el valor de android.os.Build.MODEL
- El valor de la cadena $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID

La configuración de WebView DEBE incluir soporte para la base de datos HTML5, caché de aplicaciones y API de geolocalización [ Recursos, 9 ]. WebView DEBE incluir soporte para la etiqueta HTML5 <video> . Las API HTML5, como todas las API de JavaScript, DEBEN estar deshabilitadas de forma predeterminada en un WebView, a menos que el desarrollador las habilite explícitamente a través de las API habituales de Android.

3.4.2. Compatibilidad del navegador

Las implementaciones de dispositivos DEBEN incluir una aplicación de navegador independiente para la navegación web del usuario general. El navegador independiente PUEDE basarse en una tecnología de navegador distinta de WebKit. Sin embargo, incluso si se envía una aplicación de navegador alternativa, el componente android.webkit.WebView proporcionado a aplicaciones de terceros DEBE estar basado en WebKit, como se describe en la Sección 3.4.1.

Las implementaciones PUEDEN incluir una cadena de agente de usuario personalizada en la aplicación de navegador independiente.

La aplicación de navegador independiente (ya sea basada en la aplicación de navegador WebKit anterior o en un reemplazo de terceros) DEBE incluir soporte para la mayor cantidad de HTML5 [ Recursos, 9 ] posible. Como mínimo, las implementaciones de dispositivos DEBEN admitir la geolocalización HTML5, la caché de aplicaciones y las API de bases de datos y la etiqueta <video> en la aplicación del navegador independiente.

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 la implementación preferida del proyecto de código abierto de Android [ Recursos, 3 ]. 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 componente del sistema (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 la compatibilidad del comportamiento recae en los implementadores del dispositivo. Por esta razón, los implementadores de dispositivos DEBEN utilizar 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 importantes del sistema.

El Compatibility Test Suite (CTS) prueba partes importantes de la plataforma para determinar la compatibilidad del comportamiento, pero no todas. Es responsabilidad del implementador garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android.

3.6. Espacios de nombres 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 modificaciones prohibidas (ver a continuación) en 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 modificaciones NO DEBEN afectar el comportamiento declarado ni la firma en lenguaje Java de las 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 a 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. En otras palabras, los implementadores de dispositivos NO DEBEN exponer nuevas API ni alterar las API existentes en los espacios de nombres mencionados anteriormente. Los implementadores de dispositivos PUEDEN realizar modificaciones solo internas, 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 que sea propiedad de otra organización o que haga referencia a ella. 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 los 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 nuevas funciones útiles a una API existente o agregando una nueva API), 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.

Tenga en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar API en el lenguaje de programación Java; 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

Las implementaciones de dispositivos DEBEN admitir la especificación completa del código de bytes Dalvik Executable (DEX) y la semántica de la máquina virtual Dalvik [ Recursos, 10 ].

Las implementaciones de dispositivos con pantallas clasificadas como de densidad media o baja DEBEN configurar Dalvik para asignar al menos 16 MB de memoria a cada aplicación. Las implementaciones de dispositivos con pantallas clasificadas como de alta densidad DEBEN configurar Dalvik para asignar al menos 24 MB de memoria a cada aplicación. Tenga en cuenta que las implementaciones de dispositivos PUEDEN asignar más memoria que estas cifras.

3.8. Compatibilidad de la interfaz de usuario

La plataforma Android incluye algunas API para desarrolladores que les permiten conectarse a la interfaz de usuario del sistema. Las implementaciones de dispositivos DEBEN incorporar estas API de UI estándar en interfaces de usuario personalizadas que desarrollen, 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 a las aplicaciones exponer un "AppWidget" al usuario final [ Recursos, 11 ]. 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 de 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 elementos de la interfaz de usuario para agregar, configurar, ver y eliminar AppWidgets directamente dentro del Lanzador. Los lanzadores alternativos PUEDEN 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 permita a los usuarios agregar, configurar, ver y eliminar AppWidgets.

3.8.2. Notificaciones

Android incluye API que permiten a los desarrolladores notificar a los usuarios sobre eventos notables [ Recursos, 12 ]. Los implementadores de dispositivos DEBEN brindar soporte para cada clase de notificación así definida; en concreto: sonidos, vibración, luz y barra de estado.

Además, la implementación DEBE representar correctamente todos los recursos (iconos, archivos de sonido, etc.) proporcionados en las API [ Recursos, 13 ], o en la guía de estilo de iconos de la barra de estado [ Recursos, 14 ]. Los implementadores de dispositivos PUEDEN proporcionar una experiencia de usuario alternativa para las notificaciones a la proporcionada por la implementación de código abierto de Android de referencia; sin embargo, dichos sistemas de notificación alternativos DEBEN respaldar los recursos de notificación existentes, como se indicó anteriormente.

3.8.3. Buscar

Android incluye API [ Recursos, 15 ] que permiten a los desarrolladores incorporar búsquedas en sus aplicaciones y exponer los datos de sus aplicaciones en la búsqueda global del sistema. En términos generales, esta funcionalidad consta de 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 resultados. Las API de Android permiten a los desarrolladores reutilizar esta interfaz para realizar búsquedas dentro de sus propias aplicaciones y les permiten proporcionar resultados a la interfaz de usuario de búsqueda global común.

Las implementaciones de dispositivos DEBEN incluir una interfaz de usuario de búsqueda única, compartida y en todo el sistema capaz de realizar sugerencias en tiempo real en respuesta a las entradas del usuario. Las implementaciones de dispositivos DEBEN implementar las API que permitan 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 utilicen esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar resultados y sugerencias del motor de búsqueda web.

Las implementaciones de dispositivos PUEDEN incluir interfaces de usuario de búsqueda alternativas, pero DEBEN incluir un botón de búsqueda dedicado físico o virtual, que se puede usar 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, 16 ]) para mostrar cadenas cortas no modales al usuario final, que desaparecen después de un breve período de tiempo. Las implementaciones de dispositivos DEBEN mostrar los brindis de las aplicaciones a los usuarios finales de alguna manera de alta visibilidad.

3.8.5. Fondos de pantalla vivos

Android define un tipo de componente y su correspondiente API y ciclo de vida que permite a las aplicaciones exponer uno o más "Live Wallpapers" al usuario final [ Recursos, 17 ]. Los fondos de pantalla animados son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como fondo de pantalla, detrás de otras aplicaciones.

Se considera que el hardware es capaz de ejecutar de manera confiable fondos de pantalla en vivo si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones de funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware provocan que los fondos de pantalla y/o las aplicaciones fallen, funcionen mal, consuman demasiada energía de la CPU o de la batería, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware es incapaz de ejecutar fondos de pantalla en vivo. Por ejemplo, algunos fondos de pantalla animados pueden utilizar un contexto Open GL 1.0 o 2.0 para representar su contenido. El fondo de pantalla en vivo no se ejecutará de manera confiable en hardware que no admita múltiples contextos OpenGL porque el uso del fondo de pantalla en vivo de un contexto OpenGL puede entrar en conflicto con otras aplicaciones que también usan un contexto OpenGL.

Las implementaciones de dispositivos capaces de ejecutar fondos de pantalla en vivo de manera confiable, como se describe anteriormente, DEBEN implementar fondos de pantalla en vivo. Las implementaciones de dispositivos que se determine que no ejecutan fondos de pantalla en vivo de manera confiable, como se describe anteriormente, NO DEBEN implementar fondos de pantalla en vivo.

4. Compatibilidad del software de referencia

Los implementadores de dispositivos DEBEN probar la compatibilidad de la implementación utilizando las siguientes aplicaciones de código abierto:

Calculadora (incluida en SDK)
Módulo de aterrizaje lunar (incluido en SDK)
Las aplicaciones "Aplicaciones para Android" [ Recursos, 18 ].
Replica Island (disponible en Android Market; solo se requiere para implementaciones de dispositivos compatibles con OpenGL ES 2.0)

Cada aplicación anterior DEBE iniciarse y comportarse correctamente en la implementación, para que la implementación se considere compatible.

Además, las implementaciones de dispositivos DEBEN probar cada elemento del menú (incluidos todos los submenús) de cada una de estas aplicaciones de prueba de humo:

ApiDemos (incluido en SDK)
Pruebas de humo manuales (incluidas en CTS)

Cada caso de prueba en las aplicaciones anteriores DEBE ejecutarse correctamente en la implementación del dispositivo.

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" incluida en el SDK oficial de Android [ Recursos, 19 ].

Las implementaciones de dispositivos NO DEBEN extender los formatos .apk [ Recursos, 20 ], Android Manifest [ Recursos, 21 ] o Dalvik bytecode [ Recursos, 10 ] 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

Las implementaciones de dispositivos DEBEN implementar completamente todas las API multimedia. Las implementaciones de dispositivos DEBEN incluir soporte para todos los códecs multimedia que se describen a continuación y DEBEN cumplir con las pautas de procesamiento de sonido que se describen a continuación.

6.1. Códecs multimedia

Las implementaciones de dispositivos DEBEN admitir los siguientes códecs multimedia. Todos estos códecs se proporcionan como implementaciones de software en la implementación de Android preferida del Proyecto de código abierto de Android.

Tenga en cuenta que ni Google ni Open Handset Alliance hacen ninguna declaración de que estos códecs no estén gravados por patentes de terceros. Se advierte a quienes deseen utilizar este código fuente en productos de hardware o software que las implementaciones de este código, incluso en software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes correspondientes.

Audio
	Nombre	Codificador	Descifrador	Detalles	Formato de archivo/contenedor
	AAC LC/LTP		X	Contenido mono/estéreo en cualquier combinación de velocidades de bits estándar de hasta 160 kbps y velocidades de muestreo de entre 8 y 48 kHz	3GPP (.3gp) y MPEG-4 (.mp4, .m4a). No hay soporte para AAC sin formato (.aac)
	HE-AACv1 (AAC+)		X
	HE-AACv2 (AAC+ mejorado)		X
	AMR-NB	X	X	4,75 a 12,2 kbps muestreados a 8 kHz	3GPP (.3gp)
	AMR-WB		X	9 velocidades de 6,60 kbit/s a 23,85 kbit/s muestreadas a 16 kHz	3GPP (.3gp)
	MP3		X	Mono/estéreo 8-320 Kbps constante (CBR) o velocidad de bits variable (VBR)	MP3 (.mp3)
	midi		X	MIDI Tipo 0 y 1. DLS Versión 1 y 2. XMF y XMF móvil. Compatibilidad con formatos de tonos de llamada RTTTL/RTX, OTA e iMelody	Escriba 0 y 1 (.mid, .xmf, .mxmf). También RTTTL/RTX (.rtttl, .rtx), OTA (.ota) e iMelody (.imy)
	Ogg Vorbis		X		Ogg (.ogg)
	PCM		X	PCM lineal de 8 y 16 bits (velocidades hasta el límite del hardware)	ONDA (.wav)
Imagen
	JPEG	X	X	base+progresiva
	GIF		X
	PNG	X	X
	BMP		X
Video
	H.263	X	X		Archivos 3GPP (.3gp)
	H.264		X		Archivos 3GPP (.3gp) y MPEG-4 (.mp4)
	Perfil simple MPEG4		X		Archivo 3GPP (.3gp)

Tenga en cuenta que la tabla anterior no enumera los requisitos de velocidad de bits específicos para la mayoría de los códecs de vídeo. La razón de esto es que, en la práctica, el hardware de los dispositivos actuales no necesariamente admite velocidades de bits que se correspondan exactamente con las velocidades de bits requeridas y especificadas por los estándares pertinentes. En cambio, las implementaciones de dispositivos DEBEN admitir la tasa de bits más alta práctica en el hardware, hasta los límites definidos por las especificaciones.

6.2. Grabación de audio

Cuando una aplicación ha utilizado la API android.media.AudioRecord para comenzar a grabar una transmisión de audio, las implementaciones del dispositivo DEBEN muestrear y grabar audio con cada uno de estos comportamientos:

El procesamiento de reducción de ruido, si está presente, DEBE desactivarse.
El control automático de ganancia, si está presente, DEBE desactivarse.
El dispositivo DEBE exhibir características de amplitud versus frecuencia aproximadamente planas; específicamente, ±3 dB, de 100 Hz a 4000 Hz
La sensibilidad de entrada de audio DEBE configurarse de modo que una fuente de nivel de potencia sonora (SPL) de 90 dB a 1000 Hz produzca un RMS de 5000 para muestras de 16 bits.
Los niveles de amplitud PCM DEBEN seguir linealmente los cambios de SPL de entrada en al menos un rango de 30 dB, desde -18 dB a +12 dB con respecto a 90 dB SPL en el micrófono.
La distorsión armónica total DEBE ser inferior al 1% de 100 Hz a 4000 Hz a un nivel de entrada de 90 dB SPL.

Nota: si bien los requisitos descritos anteriormente se indican como "DEBERÍAN" para Android 2.2, se prevé que la definición de compatibilidad para una versión futura los cambie a "DEBE". Es decir, estos requisitos son opcionales en Android 2.2 pero serán requeridos en una versión futura. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan Android 2.2 Android cumplan con estos requisitos en Android 2.2 , o no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

6.3. Latencia de audio

La latencia de audio se define ampliamente como el intervalo entre el momento en que una aplicación solicita una operación de reproducción o grabación de audio y el momento en que la implementación del dispositivo realmente comienza la operación. Muchas clases de aplicaciones se basan en latencias cortas para lograr efectos en tiempo real, como efectos de sonido o comunicación VOIP. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos de latencia de audio descritos en esta sección.

Para los efectos de esta sección:

La "latencia de salida en frío" se define como el intervalo entre el momento en que una aplicación solicita la reproducción de audio y el momento en que el sonido comienza a reproducirse, cuando el sistema de audio ha estado inactivo y apagado antes de la solicitud.
La "latencia de salida cálida" se define como el intervalo entre el momento en que una aplicación solicita la reproducción de audio y el momento en que comienza a reproducirse el sonido, cuando el sistema de audio se ha utilizado recientemente pero actualmente está inactivo (es decir, en silencio).
La "latencia de salida continua" se define como el intervalo entre el momento en que una aplicación emite una muestra para reproducir y el momento en que el altavoz reproduce físicamente el sonido correspondiente, mientras el dispositivo está reproduciendo audio actualmente.
La "latencia de entrada en frío" se define como el intervalo entre el momento en que una aplicación solicita una grabación de audio y el momento en que la primera muestra se entrega a la aplicación a través de su devolución de llamada, cuando el sistema de audio y el micrófono han estado inactivos y apagados antes de la solicitud.
La "latencia de entrada continua" se define como cuando se produce un sonido ambiental y cuando la muestra correspondiente a ese sonido se entrega a una aplicación de grabación a través de su devolución de llamada, mientras el dispositivo está en modo de grabación.

Utilizando las definiciones anteriores, las implementaciones de dispositivos DEBEN exhibir cada una de estas propiedades:

Latencia de salida en frío de 100 milisegundos o menos.
Latencia de salida cálida de 10 milisegundos o menos.
Latencia de salida continua de 45 milisegundos o menos.
Latencia de entrada en frío de 100 milisegundos o menos.
Latencia de entrada continua de 50 milisegundos o menos.

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:

Puente de depuración de Android (conocido como adb) [ Recursos, 19 ]
Las implementaciones de dispositivos DEBEN admitir todas las funciones adb como se documenta en el SDK de Android. El demonio adb del lado 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.
Servicio Dalvik Debug Monitor (conocido como ddms) [ Recursos, 19 ]
Las implementaciones de dispositivos DEBEN admitir todas las funciones ddms como se documenta en el SDK de Android. Como ddms usa adb , la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.
Mono [ Recursos, 22 ]
Las implementaciones de dispositivos DEBEN incluir el marco Monkey y ponerlo a disposición de las aplicaciones.

8. Compatibilidad de hardware

Android está destinado a ayudar a los implementadores de dispositivos a crear configuraciones y factores de forma innovadores. Al mismo tiempo, los desarrolladores de Android esperan cierto hardware, sensores y API en todos los dispositivos Android. Esta sección enumera las funciones de hardware que deben admitir todos los dispositivos compatibles con Android 2.2.

Si un dispositivo incluye un componente de hardware 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. Si una API en el SDK interactúa con un componente de hardware que se declara opcional y la implementación del dispositivo no posee ese componente:

Las definiciones de clase para las API del componente DEBEN estar presentes.
Los comportamientos de la API DEBEN implementarse como no operativos de alguna manera razonable.
Los métodos API DEBEN devolver valores nulos cuando lo permita la documentación del SDK
Los métodos API DEBEN devolver implementaciones no operativas de clases donde la documentación del SDK no permite valores nulos

Un ejemplo típico de un escenario en el que se aplican estos requisitos es la API de telefonía: incluso en dispositivos que no son teléfonos, estas API deben implementarse como operaciones no operativas razonables.

Las implementaciones de dispositivos DEBEN informar con precisión información precisa de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager . [ Recursos, 23 ]

8.1. Mostrar

Android 2.2 incluye funciones que realizan ciertas operaciones automáticas de escalado y transformación en algunas circunstancias, para garantizar que las aplicaciones de terceros se ejecuten razonablemente bien en una variedad de configuraciones de hardware [ Recursos, 24 ]. Los dispositivos DEBEN implementar correctamente estos comportamientos, como se detalla en esta sección.

Para Android 2.2, estas son las configuraciones de pantalla más comunes:

Tipo de pantalla	Ancho (píxeles)	Altura (píxeles)	Rango de longitud diagonal (pulgadas)	Grupo de tamaño de pantalla	Grupo de densidad de pantalla
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 de dispositivos 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 la clase android.content.res.Configuration [ Recursos, 24 ].

Algunos paquetes .apk tienen manifiestos que no los identifican como compatibles con un rango de densidad específico. Al ejecutar dichas aplicaciones, se aplican las siguientes restricciones:

Las implementaciones de dispositivos DEBEN interpretar los recursos en un .apk que carecen de un calificador de densidad como predeterminados en "medio" (conocido como "mdpi" en la documentación del SDK).
Cuando se opera en una pantalla de densidad "baja", las implementaciones de dispositivos DEBEN reducir los activos medios/mdpi en un factor de 0,75.
Cuando se opera en una pantalla de "alta" densidad, las implementaciones de dispositivos DEBEN ampliar los activos medios/mdpi en un factor de 1,5.
Las implementaciones de dispositivos NO DEBEN escalar los activos dentro de un rango de densidad y DEBEN escalar los activos exactamente según estos factores entre rangos de densidad.

8.1.2. Configuraciones de pantalla no estándar

Las configuraciones de pantalla que no coinciden con una de las configuraciones estándar enumeradas en la Sección 8.1.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 describe en la Sección 13 para obtener clasificaciones por tamaño de pantalla, densidad y factor de escala. Cuando se les proporciona esta información, las implementaciones de dispositivos DEBEN implementarlas según lo especificado.

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 2.2; por lo tanto, se recomienda a los implementadores de dispositivos que se comuniquen con el equipo de compatibilidad de Android lo antes posible en el proceso de desarrollo.

8.1.3. Mostrar métricas

Las implementaciones de dispositivos DEBEN informar valores correctos para todas las métricas de visualización definidas en android.util.DisplayMetrics [ Recursos, 26 ].

8.1.4. Soporte de pantalla declarado

Las aplicaciones pueden indicar qué tamaños de pantalla admiten a través del atributo <supports-screens> en el archivo AndroidManifest.xml. Las implementaciones de dispositivos DEBEN respetar correctamente la compatibilidad declarada de las aplicaciones para pantallas pequeñas, medianas y grandes, como se describe en la documentación del SDK de Android.

8.2. Teclado

Implementaciones de dispositivos:

DEBE incluir soporte para el marco de administración de entrada (que permite a los desarrolladores externos crear motores de administración de entrada, es decir, teclado virtual) como se detalla en desarrollador.android.com
DEBE proporcionar al menos una implementación de teclado virtual (independientemente de si hay un teclado físico presente)
PUEDE incluir implementaciones adicionales de teclado virtual
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.keyboard [ Recursos, 25 ] (es decir, QWERTY o 12 teclas).

Implementaciones de dispositivos:

PUEDE omitir opciones de navegación no táctiles (es decir, puede omitir una trackball, un d-pad o una rueda)
DEBE informar el valor correcto para android.content.res.Configuration.navigation [ Recursos, 25 ]

8.4. Orientación de la pantalla

Los dispositivos compatibles DEBEN admitir la orientación dinámica de las aplicaciones en orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una orientación de pantalla específica. Las implementaciones de dispositivos PUEDEN seleccionar la orientación vertical u horizontal como opción predeterminada.

Los dispositivos DEBEN informar el valor correcto para la orientación actual del dispositivo, siempre que se realice una consulta a través de 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 capacativa o resistiva
DEBE informar el valor de android.content.res.Configuration [ Recursos, 25 ] que refleja el tipo de pantalla táctil específica del dispositivo
DEBE admitir punteros con seguimiento totalmente independiente, si la pantalla táctil admite múltiples punteros

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 Android Debug Bridge a través de USB (como se describe en la Sección 7)
DEBE implementar la especificación de almacenamiento masivo USB, para permitir que un host conectado al dispositivo acceda al contenido del volumen /sdcard
DEBE utilizar el factor de forma micro USB en el lado del dispositivo
PUEDE incluir un puerto no estándar en el lado del dispositivo, pero si es así DEBE enviarse con un cable capaz de conectar el pinout personalizado al puerto USB-A estándar
DEBE implementar soporte para la especificación de almacenamiento masivo USB (para que se pueda acceder al almacenamiento fijo o extraíble en el dispositivo desde una PC host)

Las funciones 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 mediante botones dedicados. PUEDEN implementarse mediante software, gestos, panel táctil, etc., pero de ser así DEBEN estar siempre accesibles y no oscurecer ni interferir con el área de visualización de la aplicación disponible.

Los implementadores de dispositivos DEBEN también proporcionar una clave de búsqueda dedicada. Los implementadores de dispositivos PUEDEN también proporcionar claves de envío y finalización para llamadas telefónicas.

8.8. Redes de datos inalámbricas

Las implementaciones de dispositivos DEBEN incluir soporte para redes de datos inalámbricas de alta velocidad. Específicamente, las implementaciones de dispositivos DEBEN incluir soporte para al menos un estándar de datos inalámbricos capaz de alcanzar 200 Kbit/seg o más. Ejemplos de tecnologías que satisfacen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, etc.

Si la implementación de un dispositivo incluye una modalidad particular para la cual el SDK de Android incluye una API (es decir, WiFi, GSM o CDMA), la implementación DEBE admitir la API.

Los dispositivos PUEDEN implementar más de una forma de conectividad de datos inalámbrica. Los dispositivos PUEDEN implementar conectividad de datos por cable (como Ethernet), pero DEBEN incluir al menos una forma de conectividad inalámbrica, como se indicó anteriormente.

8.9. Cámara

Las implementaciones de dispositivos DEBEN incluir una cámara orientada hacia atrás. La cámara trasera incluida:

DEBE tener una resolución de al menos 2 megapíxeles
DEBE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara (transparente al 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, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un Objeto Camera.Parameters . Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara integrada del sistema del dispositivo, sino solo a aplicaciones de terceros que utilizan Camera.PreviewCallback .

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las API relacionadas con la cámara:

Si una aplicación nunca ha llamado a android.hardware.Camera.Parameters.setPreviewFormat(int), entonces el dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para obtener una vista previa de los datos proporcionados a las devoluciones de llamada de la aplicación.
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[] pasados a onPreviewFrame() deben estar además 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 predeterminado.

Las implementaciones de dispositivos deben implementar la API de cámara completa incluida en la documentación SDK de Android 2.2 [ recursos, 27 ]), independientemente de si el dispositivo incluye enfoque automático de hardware u otras capacidades. Por ejemplo, las cámaras que carecen de enfoque automático aún deben llamar a cualquier android.hardware.Camera.AutoFocusCallback registrado.camera.autofocuscallback instancias (a pesar de que esto no tiene relevancia para una cámara no autocubierta).

Las implementaciones del dispositivo deben reconocer y honrar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters , si el hardware subyacente admite la función. Si el hardware del dispositivo no admite una función, la API debe comportarse como se documenta. Por el contrario, las implementaciones de dispositivos no deben honrar ni reconocer las constantes de cadena pasadas al método android.hardware.Camera.setParameters() que no sean las documentadas como constantes en android.hardware.Camera.Parameters . Es decir, las implementaciones del dispositivo deben admitir todos los parámetros de cámara estándar si el hardware lo permite, y no debe admitir tipos de parámetros de cámara personalizados.

Las implementaciones de dispositivos pueden incluir una cámara frontal. Sin embargo, si una implementación de un dispositivo incluye una cámara frontal, la API de la cámara implementada en el dispositivo no debe usar la cámara frontal de forma predeterminada. Es decir, la API de la cámara en Android 2.2 es solo para cámaras traseras, y las implementaciones de dispositivos no deben reutilizar ni sobrecargar la API para actuar en una cámara frontal, si uno está presente. Tenga en cuenta que cualquier API personalizada agregada por los implementadores del dispositivo para admitir cámaras frontales debe cumplir con las Secciones 3.5 y 3.6; Por ejemplo, si se proporciona un android.hardware.Camera o Camera.Parameters La subclase de parámetros. Tenga en cuenta que la inclusión de una cámara frontal no cumple con el requisito de que los dispositivos incluyan una cámara trasera.

8.10. Acelerómetro

Las implementaciones de dispositivos deben incluir un acelerómetro de 3 ejes y deben poder entregar eventos a 50 Hz o más. El sistema de coordenadas utilizado por el acelerómetro debe cumplir con el sistema de coordenadas del sensor Android como se detalla en las API de Android (ver [ Recursos, 28 ]).

8.11. Brújula

Las implementaciones de dispositivos deben incluir una brújula de 3 ejes y deben poder entregar eventos de 10 Hz o más. El sistema de coordenadas utilizado por la brújula debe cumplir con el sistema de coordenadas del sensor Android como se define en la API de Android (ver [ Recursos, 28 ]).

8.12. GPS

Las implementaciones de dispositivos deben incluir un receptor GPS, y deben incluir alguna forma de técnica de "GPS asistido" para minimizar el tiempo de bloqueo del GPS.

8.13. Telefonía

Android 2.2 se puede usar en dispositivos que no incluyen hardware de telefonía. Es decir, Android 2.2 es compatible con dispositivos que no son teléfonos. Sin embargo, si una implementación de un dispositivo incluye la telefonía GSM o CDMA, debe implementar el soporte completo para la API para esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía deben implementar las API completas como NO-OPS.

Consulte también la Sección 8.8, redes de datos inalámbricos.

8.14. Memoria y almacenamiento

Las implementaciones de dispositivos deben tener al menos 92 MB de memoria disponible para el kernel y el espacio de usuario. El 92 MB debe ser además de cualquier memoria dedicada a componentes de hardware como radio, memoria, etc., eso no está bajo el control del núcleo.

Las implementaciones de dispositivos deben tener al menos 150 MB de almacenamiento no volátil disponible para los datos del usuario. Es decir, la partición /data debe ser de al menos 150 MB.

Más allá de los requisitos anteriores, las implementaciones de dispositivos deben tener al menos 128 MB de memoria disponible para el kernel y el espacio de usuarios, además de cualquier memoria dedicada a componentes de hardware que no estén bajo el control del kernel. Las implementaciones de dispositivos deben tener al menos 1 GB de almacenamiento no volátil disponible para los datos del usuario. Tenga en cuenta que estos requisitos más altos se planean para convertirse en mínimos difíciles en una versión futura de Android. Se recomienda encarecidamente a las implementaciones de dispositivos a cumplir con estos requisitos ahora, o de lo contrario pueden no ser elegibles para la compatibilidad para una versión futura de Android.

8.15. Aplicación Almacenamiento compartido

Las implementaciones de dispositivos deben ofrecer almacenamiento compartido para aplicaciones. El almacenamiento compartido proporcionado debe tener al menos 2 GB de tamaño.

Las implementaciones de dispositivos deben configurarse con almacenamiento compartido montado de forma predeterminada, "fuera de la caja". Si el almacenamiento compartido no está montado en la ruta de Linux /sdcard , entonces el dispositivo debe incluir un enlace simbólico de Linux desde /sdcard al punto de montaje real.

Las implementaciones de dispositivos deben aplicar como se documenta el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido. El almacenamiento compartido debe ser redactado por cualquier aplicación que obtenga ese permiso.

Las implementaciones de dispositivos pueden tener hardware para el almacenamiento extraíble accesible para el usuario, como una tarjeta digital segura. Alternativamente, las implementaciones de dispositivos pueden asignar el almacenamiento interno (no removible) como almacenamiento compartido para aplicaciones.

Independientemente de la forma de almacenamiento compartido utilizado, el almacenamiento compartido debe implementar el almacenamiento en masa USB, como se describe en la Sección 8.6. Como se envía fuera de la caja, el almacenamiento compartido debe montarse con el sistema de archivos FAT.

Es ilustrativo considerar dos ejemplos comunes. Si una implementación de un dispositivo incluye una ranura para tarjeta SD para satisfacer el requisito de almacenamiento compartido, se debe incluir una tarjeta SD con forma de grasa de 2GB o más grande con el dispositivo como se vende a los usuarios, y debe montarse de manera predeterminada. Alternativamente, si una implementación de un dispositivo utiliza almacenamiento fijo interno para satisfacer este requisito, ese almacenamiento debe tener un tamaño de 2 GB o más grande, formateado como grasa y montado en /sdcard (o /sdcard debe ser un enlace simbólico a la ubicación física si es así. montado en otro lugar.)

Las implementaciones de dispositivos que incluyen múltiples rutas de almacenamiento compartidas (como una ranura de tarjeta SD y almacenamiento interno compartido) deben modificar las aplicaciones principales, como el escáner de medios y ContentProvider, para admitir transparentemente archivos colocados en ambas ubicaciones.

8.16. Bluetooth

Las implementaciones del dispositivo deben incluir un transceptor Bluetooth. Las implementaciones del dispositivo deben habilitar la API Bluetooth basada en RFCOMM como se describe en la documentación SDK [ recursos, 30 ]. Las implementaciones de dispositivos deben implementar perfiles Bluetooth relevantes, como A2DP, AVRCP, OBEX, etc., según corresponda para el dispositivo.

El conjunto de pruebas de compatibilidad incluye casos que cubren la operación básica de la API Bluetooth de Android RFCOMM. Sin embargo, dado que Bluetooth es un protocolo de comunicación entre los dispositivos, no se puede probar completamente mediante pruebas unitarias que se ejecutan en un solo dispositivo. En consecuencia, las implementaciones de dispositivos también deben aprobar el procedimiento de prueba Bluetooth impulsado por los humanos descrito en el Apéndice A.

9. Compatibilidad de rendimiento

Uno de los objetivos del programa de compatibilidad de Android es permitir una experiencia de aplicación constante para los consumidores. Las implementaciones compatibles deben garantizar no solo que las aplicaciones simplemente se ejecuten correctamente en el dispositivo, sino 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 de Android 2.2 definido en la tabla a continuación:

Métrico	Umbral de rendimiento	Comentarios
Tiempo de lanzamiento de la aplicación	Las siguientes aplicaciones deben lanzarse dentro del tiempo especificado. Navegador: menos de 1300 ms MMS/SMS: menos de 700 ms ALARMCLOCK: Menos de 650 ms	El tiempo de lanzamiento se mide como el tiempo total para completar la carga de la actividad predeterminada para la aplicación, incluido el tiempo que lleva iniciar el proceso de Linux, cargar el paquete de Android en la VM Dalvik y llamar a OnCreate.
Aplicaciones simultáneas	Cuando se han lanzado múltiples aplicaciones, el relanzamiento de una aplicación que ya está en funcionamiento después de que se haya lanzado debe tomar 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 el modelo de seguridad de la plataforma Android como se define en el documento de referencia de seguridad y permisos en las API [ recursos, 29 ] en la documentación del desarrollador de Android. Las implementaciones de dispositivos deben admitir la instalación de aplicaciones autofirmadas sin requerir ningún permiso/certificado adicionales de terceros/autoridades. Específicamente, los dispositivos compatibles deben admitir los mecanismos de seguridad descritos en las siguientes subsecciones.

10.1. Permisos

Las implementaciones de dispositivos deben admitir el modelo de permisos de Android como se define en la documentación del desarrollador de Android [ recursos, 29 ]. 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 ID de permiso no estén en el espacio de nombres de Android.*

10.2. Aislamiento de uid y proceso

Las implementaciones de dispositivos deben admitir el modelo 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, siempre que las aplicaciones estén correctamente firmadas y construidas, 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 [ recursos, 29 ].

10.4. Entornos de ejecución alternativos

Las implementaciones de dispositivos pueden incluir entornos de tiempo de ejecución que ejecutan aplicaciones utilizando algún otro software o tecnología que la máquina virtual Dalvik o el código nativo. Sin embargo, tales entornos de ejecución alternativos no deben comprometer el modelo de seguridad de Android o la seguridad de las aplicaciones de Android instaladas, como se describe en esta sección.

Los tiempos de ejecución alternativos deben ser aplicaciones de Android, y cumplir con el modelo de seguridad de Android estándar, como se describe en otra parte de la Sección 10.

Los tiempos de ejecución alternativos no se deben otorgar acceso a recursos protegidos por permisos no solicitados en el archivo AndroidManifest.xml del tiempo de ejecución a través del mecanismo <uses-permission> .

Los tiempos de ejecución alternativos no deben permitir que las solicitudes utilicen características protegidas por los permisos de Android restringidos a las aplicaciones del sistema.

Los tiempos de ejecución alternativos deben cumplir con el modelo Android Sandbox. Específicamente:

Los tiempos de ejecución alternativos deben instalar aplicaciones a través del PackageManager en Android Sandboxes separados (es decir, ID de usuario de Linux, etc.)
Los tiempos de ejecución alternativos pueden proporcionar una sola caja de arena de Android compartida por todas las aplicaciones utilizando el tiempo de ejecución alternativo.
Los tiempos de ejecución alternativos y las aplicaciones instaladas que utilizan un tiempo de ejecución alternativo no deben reutilizar el sandbox de ninguna otra aplicación instalada en el dispositivo, excepto a través de los mecanismos estándar de Android de ID de usuario compartido y certificado de firma
Los tiempos de ejecución alternativos no deben lanzarse, otorgar o tener acceso a los sandboxes correspondientes a otras aplicaciones de Android.

Los tiempos de ejecución alternativos no deben lanzarse, otorgarse o otorgar a otras aplicaciones ningún privilegio del superusor (root) o de cualquier otra identificación de usuario.

Los archivos .APK de tiempos de ejecución alternativos pueden incluirse en la imagen del sistema de la implementación de un dispositivo, pero deben firmarse con una clave distinta de la clave utilizada para firmar otras aplicaciones incluidas con la implementación del dispositivo.

Al instalar aplicaciones, los tiempos de ejecución alternativos deben obtener el consentimiento del usuario para los permisos de Android utilizados por la aplicación. Es decir, si una aplicación necesita utilizar un recurso de dispositivo para el cual hay un permiso de Android correspondiente (como cámara, GPS, etc.), el tiempo de ejecución alternativo debe informar al usuario que la aplicación podrá acceder a ese recurso . Si el entorno de tiempo de ejecución no registra las capacidades de aplicación de esta manera, el entorno de tiempo de ejecución debe enumerar todos los permisos que se realizan en sí al instalar cualquier aplicación utilizando ese tiempo de ejecución.

11. Suite de prueba de compatibilidad

Las implementaciones de dispositivos deben pasar el Suite de prueba de compatibilidad de Android (CTS) [ recursos, 2 ] disponible en 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 tanto como sea posible, y deben garantizar la compatibilidad en casos 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. Como cualquier software, el CTS puede contener errores. El CTS se verificará independientemente de esta definición de compatibilidad, y se pueden publicar múltiples revisiones del CTS para Android 2.2. Las implementaciones de dispositivos deben pasar la última versión CTS disponible en el momento en que se completa el software del dispositivo.

12. Software actualizado

Las implementaciones de dispositivos deben incluir un mecanismo para reemplazar la totalidad del software del sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, se puede requerir un reinicio de un dispositivo.

Se puede utilizar cualquier método, siempre que pueda reemplazar la totalidad del software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques satisfará este requisito:

Descargas sobre el aire (OTA) con actualización fuera de línea a través de reinicio
Actualizaciones "atadas" a través de USB desde una PC host
Actualizaciones de "fuera de línea" a través de un reinicio y actualización desde un archivo en almacenamiento extraíble

El mecanismo de actualización utilizado debe admitir actualizaciones sin limpiar los datos del usuario. Tenga en cuenta que el software Android ascendente incluye un mecanismo de actualización que satisface este requisito.

Si se encuentra un error en la implementación de un dispositivo después de que se haya lanzado, pero dentro de su vida de producto razonable que se determina en consulta con el equipo de compatibilidad de Android para afectar la compatibilidad de las aplicaciones de los partidos, el implementador del dispositivo debe corregir el error a través de un software Actualización disponible que se puede aplicar según el mecanismo que se acaba de describir.

13. Contáctenos

Puede comunicarse con los autores del documento en compatibilidad@android.com para obtener aclaraciones y para presentar cualquier problema que crea que el documento no cubre.

Apéndice A - Procedimiento de prueba Bluetooth

El procedimiento de prueba se basa en la aplicación de muestra BluetoothChat incluida en el árbol de proyecto de código abierto de Android. El procedimiento requiere dos dispositivos:

Una implementación de dispositivos candidatos que ejecuta la compilación de software para ser probado
Una implementación de dispositivo separada ya se sabe que es compatible y de un modelo de la implementación del dispositivo que se está probando, es decir, una implementación del dispositivo "conocida" de un dispositivo "conocida"

El procedimiento de prueba a continuación se refiere a estos dispositivos como los dispositivos "candidatos" y "buenos", respectivamente.

Configuración e instalación

Construya bluetoothchat.apk a través de 'hacer muestras' a partir de un árbol de código fuente de Android.
Instale bluetoothchat.apk en el dispositivo bien conocido.
Instale bluetoothchat.apk en el dispositivo candidato.

Pruebe el control de Bluetooth por aplicaciones

Inicie BluetoothChat en el dispositivo candidato, mientras que Bluetooth está deshabilitado.
Verifique que el dispositivo candidato encienda Bluetooth o solicite al usuario con un cuadro de diálogo que encienda Bluetooth.

Emparejamiento de pruebas y comunicación

Inicie la aplicación Bluetooth Chat en ambos dispositivos.
Haga que el dispositivo bien conocido se pueda descubrir desde BluetoothChat (usando el menú).
En el dispositivo candidato, escanee los dispositivos Bluetooth desde BluetoothChat (usando el menú) y combínele con el dispositivo bien conocido.
Envíe 10 o más mensajes desde cada dispositivo y verifique que el otro dispositivo los reciba correctamente.
Cierre la aplicación BluetoothChat en ambos dispositivos presionando a casa .
Desvuelva cada dispositivo del otro, utilizando la aplicación Configuración del dispositivo.

Emparejamiento de pruebas y comunicación en la dirección inversa

Inicie la aplicación Bluetooth Chat en ambos dispositivos.
Haga que el dispositivo candidato se pueda descubrir desde BluetoothChat (usando el menú).
En el dispositivo bien conocido, escanee los dispositivos Bluetooth desde BluetoothChat (usando el menú) y combínele con el dispositivo candidato.
Envíe 10 o mensajes de cada dispositivo y verifique que el otro dispositivo los reciba correctamente.
Cierre la aplicación Bluetooth Chat en ambos dispositivos presionando nuevamente repetidamente para llegar al lanzador.

Realicias de prueba

Vuelva a lanzar la aplicación Bluetooth Chat en ambos dispositivos.
Envíe 10 o mensajes de cada dispositivo y verifique que el otro dispositivo los reciba correctamente.

Nota: Las pruebas anteriores tienen algunos casos que terminan una sección de prueba usando Home, y otras usando Back. Estas pruebas no son redundantes y no son opcionales: el objetivo es verificar que la API y la pila Bluetooth funcionen correctamente tanto cuando las actividades se terminan explícitamente (a través del usuario presionando hacia atrás, que llama a Final el usuario presionando el hogar.) Cada secuencia de prueba debe realizarse como se describe.