Definición de compatibilidad de Android 2.1

Copyright © 2010, Google Inc. Todos los derechos reservados.
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 2.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 la IETF definido en RFC2119 [Recursos, 1].

En el uso que se hace de este documento, un "implementador de dispositivos" o "implementador" es una persona o una organización que desarrolla una solución de hardware y software que ejecuta Android 2.1. 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 2.1, las implementaciones de dispositivos deben cumplir con los siguientes requisitos:

  • DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos que se incorporan como referencia.
  • DEBEN aprobar la versión más reciente del Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el momento en que se completa el software de la implementación 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 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, 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 "upstream" disponible en el Proyecto de código abierto de Android. Si bien, hipotéticamente, algunos componentes se pueden reemplazar con implementaciones alternativas, se desaconseja 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. Por último, ten en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

2. Recursos

  1. Niveles de requisitos de la RFC2119 de IETF: http://www.ietf.org/rfc/rfc2119.txt
  2. Descripción general del programa de compatibilidad con Android: http://source.android.com/compatibility/index.html
  3. Proyecto de código abierto de Android: http://source.android.com/
  4. Definiciones y documentación de la API: http://developer.android.com/reference/packages.html
  5. Referencia de permisos de Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. Referencia de android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. Cadena de versiones permitidas de Android 2.1: http://source.android.com/docs/compatibility/2.1/versions.html
  8. Clase android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Especificación de la máquina virtual de Dalvik: Disponible en el código fuente de Android, en dalvik/docs
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Notificaciones: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Recursos de la aplicación: http://code.google.com/android/reference/available-resources.html
  14. Guía de estilo de íconos de la barra de estado: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Administrador de búsqueda: http://developer.android.com/reference/android/app/SearchManager.html
  16. Toasts: http://developer.android.com/reference/android/widget/Toast.html
  17. Fondos de pantalla en vivo: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. Apps para Android: http://code.google.com/p/apps-for-android
  19. Documentación de herramientas de referencia (para adb, aapt y ddms): http://developer.android.com/guide/developing/tools/index.html
  20. Descripción del archivo APK de Android: http://developer.android.com/guide/topics/fundamentals.html
  21. Archivos de manifiesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Herramienta de prueba de Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Compatibilidad con varias pantallas: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. Espacio de coordenadas del sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Referencia de seguridad y permisos de Android: http://developer.android.com/guide/topics/security/security.html
  29. API de Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Muchos de estos recursos se derivan directamente o indirectamente del SDK de Android 2.1 y serán funcionalmente idénticos a la información de 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 coincidan con la documentación del SDK, esta última se considerará como fuente de autoridad. Cualquier detalle técnico que se proporcione en las referencias anteriores se considera parte de esta definición de compatibilidad.

3. Software

La plataforma de Android incluye un conjunto de APIs administradas, un conjunto de APIs nativas y un cuerpo de las llamadas APIs "soft", como el sistema de intents y las APIs de aplicaciones web. En esta sección, se detallan las APIs duras y blandas que son fundamentales para la compatibilidad, así como 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 de 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 las 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 2.1 [Recursos, 4].

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 "soft" 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 2.1. 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, 5]. 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, 6] que tienen como objetivo 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 cumplir las implementaciones de dispositivos.

Parámetro Comentarios
android.os.Build.VERSION.RELEASE Es 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.VERSION.SDK Es la versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. Para Android 2.1, este campo DEBE tener el valor de número entero 7.
android.os.Build.VERSION.INCREMENTAL Es un valor que elige el implementador del dispositivo y que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO DEBE reutilizarse para diferentes compilaciones enviadas a 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 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 ("").
android.os.Build.BOARD 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 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 ("").
android.os.Build.BRAND Es un valor que elige el implementador del dispositivo que identifica el nombre de la empresa, la organización, la 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 ("").
android.os.Build.DEVICE Es un valor que elige el implementador del dispositivo y 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 ni una cadena vacía ("").
android.os.Build.FINGERPRINT Es una cadena que identifica de forma inequívoca esta compilación. DEBE ser 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.1-update1/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 de guion bajo ASCII ("_") en la huella digital.
android.os.Build.HOST Es una cadena que identifica de forma exclusiva el host en el que se compiló 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 ni una cadena vacía ("").
android.os.Build.ID 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 lo 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 ni una cadena vacía ("").
android.os.Build.MODEL Es un valor que elige el implementador del dispositivo y que contiene el nombre del dispositivo como lo conoce el usuario final. 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 ni una cadena vacía ("").
android.os.Build.PRODUCT Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código del dispositivo. DEBEN ser legibles por humanos, pero no necesariamente están destinados a que los usuarios finales los vean. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
android.os.Build.TAGS 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 NO DEBE ser nulo ni una cadena vacía (""), pero una sola etiqueta (como "release") es adecuada.
android.os.Build.TIME Es un valor que representa la marca de tiempo de la compilación.
android.os.Build.TYPE 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 correspondientes a las tres configuraciones típicas del entorno 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 ni una cadena vacía ("").

3.2.3. Compatibilidad con intents

Android usa intents para lograr una integración de acoplamiento flexible entre las aplicaciones. En esta sección, se describen los requisitos relacionados con los patrones de Intent que las implementaciones de dispositivos DEBEN respetar. Cuando se dice que se "respeta", se hace referencia a que el implementador del dispositivo DEBE proporcionar una actividad o un servicio de Android que especifique un filtro de intents que coincida y se vincule a cada patrón de intents especificado y, además, implemente el comportamiento correcto.

3.2.3.1. Intents de la aplicación principales

El proyecto upstream de Android define varias aplicaciones principales, como un marcador de teléfono, 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 intents 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 siguientes aplicaciones se consideran aplicaciones principales del sistema Android:

  • Reloj de escritorio
  • Navegador
  • Calendario
  • Calculadora
  • Cámara
  • Contactos
  • Correo electrónico
  • Galería
  • GlobalSearch
  • Selector
  • LivePicker (es decir, la aplicación del selector de fondo de pantalla animado; se PUEDE omitir si el dispositivo no admite fondos de pantalla animados, según el artículo 3.8.5).
  • Mensajería (también conocida como “MMS”)
  • Música
  • Teléfono
  • Configuración
  • Grabadora 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:exported" puede estar ausente o tener el valor "true".

Para cada actividad o servicio definido en una de las apps principales del sistema Android que no esté marcada como no pública a través de un atributo android:exported con el valor "false", las implementaciones de dispositivos DEBEN incluir un componente del mismo tipo que implemente los mismos patrones de filtro de intents que la app principal del sistema Android.

En otras palabras, una implementación de dispositivo PUEDE reemplazar las apps principales del sistema Android. Sin embargo, si lo hace, la implementación del dispositivo DEBE admitir todos los patrones de intents definidos por cada app principal del sistema Android que se reemplaza.

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 definido en las apps del sistema principal. 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, de forma específica, pero no se limita a inhabilitar la interfaz de usuario "Selector", que permite al usuario elegir entre varias aplicaciones que controlan el mismo patrón de intent.

Nota: Esta sección se modificó con la errata EX6580.

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 patrón de intent nuevo o intent de transmisión con 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 patrones nuevos de intents o intents de emisión con 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 intents que usan las apps principales que se indican en el artículo 3.2.3.1.

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 para 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. Los intents de transmisión se describen en la documentación del SDK.

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 .so ELF 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 de JNI
  • libz (compresión zlib)
  • liblog (registro de Android)
  • Compatibilidad mínima con C++
  • Compatibilidad con OpenGL, como se describe a continuación

Las implementaciones de dispositivos DEBEN ser compatibles con OpenGL ES 1.0. Los dispositivos que no tienen aceleración de hardware DEBEN implementar OpenGL ES 1.0 con un renderizador de software. Las implementaciones de dispositivos DEBEN implementar la mayor cantidad posible de OpenGL ES 1.1 que 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 obtener un rendimiento razonable en esas APIs.

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 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 C de GNU, 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 encabezado, binario y comportamiento.

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

La compatibilidad con el código nativo es un desafío. Por este motivo, se debe repetir que se recomienda encarecidamente a los implementadores de dispositivos que usen las implementaciones upstream de las bibliotecas mencionadas anteriormente para garantizar la compatibilidad.

3.4. Compatibilidad con la API web

Muchos desarrolladores y aplicaciones dependen del comportamiento de la clase android.webkit.WebView [Resources, 8] 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 el 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. Más precisamente:

  • WebView DEBE usar la compilación 530.17 de WebKit del árbol de código abierto de Android upstream para Android 2.1. Esta compilación incluye un conjunto específico de funciones y correcciones de seguridad para WebView.
  • La cadena de usuario-agente que informa WebView DEBE tener este formato:
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    • 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 de ISO para el código de país y el idioma, y DEBE hacer referencia a la configuración regional configurada actualmente 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.

Las implementaciones PUEDEN enviar una cadena de usuario-agente personalizada en la aplicación del navegador independiente. 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 proporcionado a las aplicaciones de terceros DEBE basarse en WebKit, como se indicó anteriormente.

La configuración de WebView DEBE incluir compatibilidad con la base de datos HTML5, la caché de la aplicación y las APIs de geolocalización [Recursos, 9]. WebView DEBE incluir compatibilidad con la etiqueta <video> de HTML5 de alguna forma. La aplicación de navegador independiente (ya sea que se base en la aplicación de navegador WebKit upstream o en un reemplazo de terceros) DEBE incluir compatibilidad con las mismas funciones de HTML5 que se enumeraron para WebView.

3.5. Compatibilidad de comportamiento de la API

Los comportamientos de cada uno de los tipos de API (administrados, flexibles, nativos y web) deben ser coherentes con la implementación preferida del proyecto de código abierto de Android upstream [Recursos, 3]. Estas son algunas áreas específicas de compatibilidad:

  • Los dispositivos NO DEBEN cambiar el comportamiento ni el significado de un intent estándar.
  • Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etc.).
  • 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 de comportamiento. 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 modificaciones prohibidas (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 las firmas de métodos o clases, o quitando clases o campos de clase.
  • Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero esas 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 ningún elemento expuesto 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 upstream. 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 internas, pero estas modificaciones NO DEBEN anunciarse ni exponerse de otra manera a los desarrolladores.

Los implementadores de dispositivos PUEDEN agregar APIs personalizadas, pero estas NO DEBEN estar en un espacio de nombres que pertenezca a 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 a través de 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 ejecutable de Dalvik (DEX) y la semántica de la máquina virtual de Dalvik [Recursos, 10].

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

3.8. Compatibilidad de 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 [Recursos, 11]. 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 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, configurar, 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 y que permita a los usuarios agregar, configurar, ver y quitar widgets de app.

3.8.2. Notificaciones

Android incluye APIs que permiten a los desarrolladores notificar a los usuarios sobre eventos notables [Recursos, 12]. 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, 13] o en la guía de estilo de íconos de la barra de estado [Recursos, 14]. Los implementadores de dispositivos PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que no sea la que proporciona la implementación de referencia de Android de código abierto. Sin embargo, esos sistemas de notificaciones alternativos DEBEN admitir los recursos de notificaciones existentes, como se indicó anteriormente.

Android incluye APIs [Recursos, 15] 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 interfaz de usuario única 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 de usuario común 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 pueda realizar 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 sugerencias y resultados de motores 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, 16]) para mostrarle al usuario final cadenas cortas no modales que desaparecen después de un breve período de tiempo. Las implementaciones de dispositivos DEBEN mostrar notificaciones emergentes de las aplicaciones a los usuarios finales de una manera muy visible.

3.8.5. Fondos de pantalla animados

Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan uno o más "Fondos de pantalla en vivo" 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.

El hardware se considera capaz de ejecutar fondos de pantalla en vivo de forma confiable si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones en la funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware hacen que los fondos de pantalla o las aplicaciones fallan, funcionan mal, consumen energía de la CPU o de la batería de forma excesiva, o se ejecutan a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware no es capaz de ejecutar fondos de pantalla en vivo. A modo de ejemplo, algunos fondos de pantalla en vivo pueden usar un contexto de Open GL 1.0 o 2.0 para renderizar su contenido. El fondo de pantalla en vivo no se ejecutará de forma confiable en hardware que no admita varios contextos de OpenGL, ya que el uso de un contexto de OpenGL en el fondo de pantalla en vivo puede entrar en conflicto con otras aplicaciones que también usan un contexto de OpenGL.

Las implementaciones de dispositivos que pueden ejecutar fondos de pantalla de forma confiable como se describió anteriormente DEBEN implementar fondos de pantalla. Las implementaciones de dispositivos que se determine que no ejecutan fondos de pantalla de forma confiable, como se describió anteriormente, NO DEBEN implementar fondos de pantalla.

4. Compatibilidad con 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 (incluido en el SDK)
  • Las aplicaciones "Apps para Android" [Recursos, 18].

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

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

  • ApiDemos (incluida en el SDK)
  • ManualSmokeTests (incluido en CTS)

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

5. Compatibilidad de empaquetado de aplicaciones

Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android como los genera 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] ni Dalvik bytecode [Recursos, 10] 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 upstream de referencia de Dalvik y el sistema de administración de paquetes de la implementación de referencia.

6. Compatibilidad multimedia

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

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 recomienda a quienes deseen usar este código fuente en productos de hardware o software que las implementaciones de este código, incluido el software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes relevantes.

Audio
Nombre Codificador Decodificador Detalles Formato de archivo o contenedor
AAC LC/LTP   X Contenido mono/estéreo en cualquier combinación de tasas de bits estándar de hasta 160 Kbps y tasas de muestreo de 8 a 48 kHz 3GPP (.3gp) y MPEG-4 (.mp4, .m4a) No es compatible con AAC sin procesar (.aac).
HE-AACv1 (AAC+)   X
HE-AACv2 (AAC+ mejorado)   X
AMR-NB X X 4.75 a 12.2 kbps con muestreo a 8 kHz 3GPP (.3gp)
AMR-WB   X 9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz 3GPP (.3gp)
MP3   X Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps. MP3 (.mp3)
MIDI   X MIDI tipo 0 y 1. Versión 1 y 2 de DLS. XMF y Mobile XMF. Compatibilidad con los formatos de tono RTTTL/RTX, OTA y iMelody. Tipo 0 y 1 (.mid, .xmf, .mxmf). También RTTTL/RTX (.rtttl, .rtx), OTA (.ota) y iMelody (.imy)
Ogg Vorbis   X   Ogg (.ogg)
PCM   X PCM lineal de 8 y 16 bits (el límite de las tasas depende del hardware) WAVE (.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)

Ten en cuenta que la tabla anterior no incluye los requisitos de tasa de bits específicos para la mayoría de los códecs de video. El motivo es que, en la práctica, el hardware de los dispositivos actuales no necesariamente admite tasas de bits que se asignen exactamente a las tasas de bits requeridas que especifican los estándares relevantes. En cambio, las implementaciones de dispositivos DEBEN admitir la tasa de bits más alta posible en el hardware, hasta los límites definidos por las especificaciones.

7. Compatibilidad de las 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 (conocido como adb) [Recursos, 19]
    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.
  • Servicio de monitor de depuración de Dalvik (conocido como ddms) [Recursos, 19]
    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 DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario haya activado el puente de depuración de Android, como se indicó anteriormente.
  • Monkey [Recursos, 22]
    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

El objetivo de Android es admitir a los implementadores de dispositivos que crean configuraciones y factores de forma 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 2.1.

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. Si una API del SDK interactúa con un componente de hardware que se indica como opcional y la implementación del dispositivo no tiene ese componente, haz lo siguiente:

  • Las definiciones de clases para las APIs del componente DEBEN estar presentes.
  • Los comportamientos de la API DEBEN implementarse como no-ops de alguna manera razonable.
  • Los métodos de la API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
  • Los métodos de la API DEBEN mostrar implementaciones de no operación de clases en las que la documentación del SDK no permite valores nulos.

Un ejemplo típico de una situación en la que se aplican estos requisitos es la API de telefonía: incluso en dispositivos que no son teléfonos, estas APIs deben implementarse como no operaciones razonables.

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

8.1. Pantalla

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

En Android 2.1, 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 a 3.0 Pequeño Bajo
WQVGA 240 400 3.2 a 3.5 Normal Bajo
FWQVGA 240 432 3.5 a 3.8 Normal Bajo
HVGA 320 480 3.0 a 3.5 Normal Medio
WVGA 480 800 3.3 - 4.0 Normal Alto
FWVGA 480 854 3.5 a 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 [Resources, 24].

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 los recursos en un .apk que no tenga un calificador de densidad como "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 o medios en un factor de 0.75.
  • Cuando se operan en una pantalla de densidad "alta", las implementaciones de dispositivos DEBEN escalar los recursos de mdpi o de densidad media por un factor de 1.5.
  • Las implementaciones de dispositivos NO DEBEN escalar recursos dentro de un rango de densidad y DEBEN escalar recursos exactamente con 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 que se enumeran en el artículo 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 indica en el artículo 12 para obtener clasificaciones para el bucket de tamaño de pantalla, la densidad y el factor de escala. 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 2.1. 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 Display

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

8.2. Teclado

Implementaciones de dispositivos:

  • DEBEN incluir compatibilidad con el framework de administración de entradas (que permite que los desarrolladores externos creen motores de administración de entradas, es decir, teclados en pantalla), como se detalla en developer.android.com.
  • DEBE proporcionar al menos una implementación de teclado en pantalla (independientemente de si hay un teclado físico)
  • PUEDE incluir implementaciones adicionales de teclado en pantalla
  • 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, 24] (es decir, QWERTY o 12 teclas).

8.3. Navegación no táctil

Implementaciones de dispositivos:

  • PUEDE omitir las opciones de navegación no táctil (es decir, puede omitir una bola de seguimiento, un pad direccional o una rueda)
  • DEBE informar el valor correcto para android.content.res.Configuration.navigation [Resources, 24].

8.4. Orientación de pantalla

Los dispositivos compatibles DEBEN admitir la orientación dinámica de las aplicaciones para 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 de pantalla específica. Las implementaciones de dispositivos PUEDEN seleccionar la orientación vertical u horizontal como la predeterminada.

Los dispositivos DEBEN informar el valor correcto de la orientación actual del dispositivo cada vez que se consulta a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() o de otras APIs.

8.5. Entrada táctil

Implementaciones de dispositivos:

  • DEBE tener una pantalla táctil
  • PUEDE tener una pantalla táctil capacitiva o resistiva.
  • DEBE informar el valor de android.content.res.Configuration [Resources, 24] que refleja el tipo de pantalla táctil específica en el dispositivo.

8.6. USB

Implementaciones de dispositivos:

  • DEBE implementar un cliente USB que se pueda conectar a un host USB con un puerto USB-A estándar.
  • DEBEN 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 usar el factor de forma micro-USB en el lado del dispositivo
  • PUEDE incluir un puerto no estándar en el lado del 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. Redes de datos inalámbricas

Las implementaciones de dispositivos DEBEN incluir compatibilidad con redes de datos inalámbricas de alta velocidad. Específicamente, las implementaciones de dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos inalámbricos capaz de alcanzar 200 Kbit/s o más. Algunos ejemplos de tecnologías que satisfacen este requisito son EDGE, HSPA, EV-DO, 802.11g, etcétera.

Si una implementación de dispositivo incluye una modalidad particular para la que el SDK de Android incluye una API (es decir, Wi-Fi, 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. La cámara incluida:

  • DEBEN tener una resolución de al menos 2 megapíxeles.
  • DEBE tener el enfoque automático de hardware o software implementado en el controlador de la cámara (transparente para el software de la aplicación).
  • PUEDEN 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 el flash de forma explícita habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un objeto Camera.Parameters. Ten en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema integrada del dispositivo, sino solo a las aplicaciones de terceros que usan Camera.PreviewCallback.

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

  1. Si una aplicación nunca llamó a android.hardware.Camera.Parameters.setPreviewFormat(int), el dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para los datos de vista previa proporcionados 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.

Las implementaciones de dispositivos DEBEN implementar la API de Camera completa incluida en la documentación del SDK de Android 2.1 [Recursos, 26], independientemente de si el dispositivo incluye enfoque automático de hardware o alguna otra función. Por ejemplo, las cámaras que no tienen enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no sea relevante para una cámara sin enfoque automático).

Las implementaciones de dispositivos DEBEN reconocer y respetar 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 respetar ni reconocer constantes de cadenas que se pasen al método android.hardware.Camera.setParameters(), excepto las que se documenten como constantes en android.hardware.Camera.Parameters, a menos que las constantes tengan un prefijo con una cadena que indique el nombre del implementador del dispositivo. Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de cámara estándar si el hardware lo permite y NO DEBEN admitir tipos de parámetros de cámara personalizados, a menos que los nombres de los parámetros se indiquen claramente a través de un prefijo de cadena para que no sean estándar.

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 que usa el acelerómetro DEBE cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android (consulta [Recursos, 27]).

8.11. Brújula

Las implementaciones de dispositivos DEBEN incluir un compás de 3 ejes y DEBEN poder entregar eventos de 10 Hz o más. 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 (consulta [Recursos, 27]).

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

Android 2.1 SE PUEDE usar en dispositivos que no incluyen hardware de telefonía. Es decir, Android 2.1 es compatible con dispositivos que no son teléfonos. Sin embargo, si una implementación de dispositivo incluye telefonía GSM o CDMA, debe implementar la compatibilidad total con la API de esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía DEBEN implementar las APIs completas como no-ops.

Consulta también la sección 8.8, Redes de datos inalámbricas.

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. Los 92 MB DEBEN ser adicionales a cualquier memoria dedicada a los componentes de hardware, como la radio, la memoria, etcétera, que no estén bajo el control del kernel.

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 tener al menos 150 MB.

Nota: Esta sección se modificó con la errata EX6580.

8.15. Almacenamiento compartido de la aplicación

Las implementaciones de dispositivos DEBEN ofrecer almacenamiento compartido para las aplicaciones. El almacenamiento compartido proporcionado DEBE tener un tamaño de al menos 2 GB.

Las implementaciones de dispositivos DEBEN configurarse con el almacenamiento compartido activado de forma predeterminada. Si el almacenamiento compartido no está activado en la ruta de acceso /sdcard de Linux, el dispositivo DEBE incluir un vínculo simbólico de Linux desde /sdcard hasta el punto de activación real.

Las implementaciones de dispositivos DEBEN aplicar, como se documenta, el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido. De lo contrario, cualquier aplicación que obtenga ese permiso DEBE poder escribir en el almacenamiento compartido.

Las implementaciones de dispositivos PUEDEN tener hardware para el almacenamiento extraíble al que el usuario puede acceder, como una tarjeta Secure Digital. Como alternativa, las implementaciones de dispositivos PUEDEN asignar almacenamiento interno (no extraíble) como almacenamiento compartido para apps.

Independientemente del tipo de almacenamiento compartido que se use, este DEBE implementar el almacenamiento masivo USB, como se describe en el artículo 8.6. Tal como se envía, el almacenamiento compartido DEBE estar activado con el sistema de archivos FAT.

Para ilustrarlo, consideremos dos ejemplos comunes. Si la 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 formato FAT de 2 GB de tamaño o superior con el dispositivo tal como se vende a los usuarios y DEBE estar activada de forma predeterminada. Como alternativa, si una implementación de dispositivo usa almacenamiento fijo interno para satisfacer este requisito, ese almacenamiento DEBE tener un tamaño de 2 GB o superior y estar activado en /sdcard (o /sdcard DEBE ser un vínculo simbólico a la ubicación física si está activado en otro lugar).

Nota: Esta sección se agregó con la errata EX6580.

8.16. Bluetooth

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

Nota: Esta sección se agregó con la errata EX6580.

9. Compatibilidad de rendimiento

Uno de los objetivos del Programa de compatibilidad de Android es ofrecer a los consumidores una experiencia de aplicación coherente. 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 del usuario en general. Las implementaciones de dispositivos DEBEN cumplir con las métricas de rendimiento clave de un dispositivo compatible con Android 2.1 que se definen en la siguiente tabla:

Métrica Umbral de rendimiento Comentarios
Hora de inicio de la aplicación Las siguientes aplicaciones deberían iniciarse dentro del tiempo especificado.
  • Navegador: Menos de 1,300 ms
  • MMS/SMS: Menos de 700 ms
  • AlarmClock: Menos de 650 ms
 El tiempo de inicio se mide como el tiempo total para completar la carga de la actividad predeterminada de la aplicación, incluido el tiempo que tarda en iniciarse el proceso de Linux, cargar el paquete de Android en la VM de Dalvik y llamar a onCreate.
Aplicaciones simultáneas Cuando se inician varias aplicaciones, reiniciar una aplicación que ya se está ejecutando después de que se inició debe tardar menos que el tiempo de inicio original.  

10. Compatibilidad de modelos 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 de seguridad y permisos de las APIs [Recursos, 28] 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. Específicamente, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad que se describen en las siguientes sub secciones.

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, 28]. 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 permisos. Las implementaciones PUEDEN agregar permisos adicionales, siempre que las cadenas de ID de permiso nuevas no estén en el espacio de nombres android.*.

10.2. Aislamiento de UID 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 compiladas correctamente, como se define en la referencia de seguridad y permisos [Recursos, 28].

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, 28].

11. Conjunto de pruebas de compatibilidad (CTS)

Las implementaciones de dispositivos DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android [Recursos, 2] 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 tanto como sea posible y DEBEN garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier nueva implementació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 2.1. Las implementaciones de dispositivos DEBEN aprobar la versión más reciente de CTS disponible en el momento en que se completa el software del dispositivo.

12. Software actualizable

Las implementaciones de dispositivos DEBEN incluir un mecanismo para reemplazar todo el software del sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, es POSIBLE que se requiera un reinicio del dispositivo.

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

  • Descargas inalámbricas (OTA) con actualización sin conexión mediante el reinicio
  • Actualizaciones "con conexión" por USB desde una PC host
  • Actualizaciones "sin conexión" mediante un reinicio y una actualización desde un archivo en el almacenamiento extraíble

El mecanismo de actualización que se usa DEBE admitir actualizaciones sin borrar los datos del usuario. Ten en cuenta que el software de Android upstream 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 su lanzamiento, pero dentro de su vida útil razonable del producto que se determina en consulta con el equipo de compatibilidad de Android para afectar la compatibilidad de las aplicaciones de terceros, el implementador del dispositivo DEBE corregir el error mediante una actualización de software disponible que se pueda aplicar según el mecanismo que se acaba de describir.

13. Comunícate con nosotros

Puedes comunicarte con los autores del documento en compatibility@android.com para obtener aclaraciones y plantear cualquier problema que creas que no se aborda en el documento.