Definición de compatibilidad de Android 2.3

Copyright © 2010, Google Inc. Todos los derechos reservados.
compatibility@android.com

Índice

1. Introducción
2. Recursos
3. Software
4. Compatibilidad de empaquetado de aplicaciones
5. Compatibilidad multimedia
6. Compatibilidad de herramientas para desarrolladores
7. Compatibilidad de hardware
7.1. Pantalla y gráficos
7.2. Dispositivos de entrada
7.3. Sensores
7.4. Conectividad de datos
7.5. Cámaras
7.6. Memoria y almacenamiento
7.7. USB
8. Compatibilidad de rendimiento
9. Compatibilidad de modelos de seguridad
10. Pruebas de compatibilidad de software
11. Software actualizable
12. Comunícate con nosotros
Apéndice A: Procedimiento de prueba de Bluetooth

1. Introducción

En este documento, se enumeran los requisitos que deben cumplirse para que los teléfonos celulares sean compatibles con Android 2.3.

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.3. 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.3, las implementaciones del dispositivo DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos que se incorporan como referencia.

Cuando esta definición o las pruebas de software que se describen en la Sección 10 no se mencionan, son ambiguas o están incompletas, 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 la mayor medida posible en el código fuente "upstream" disponible en el Proyecto de código abierto de Android. Si bien, en teoría, algunos componentes se pueden reemplazar por implementaciones alternativas, se desaconseja esta práctica, ya que aprobar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento completa 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.

Ten en cuenta que esta definición de compatibilidad se emite para que coincida con la actualización 2.3.3 de Android, que es el nivel de API 10. Esta definición deja obsoleta y reemplaza la definición de compatibilidad para las versiones de Android 2.3 anteriores a la 2.3.3. (es decir, las versiones 2.3.1 y 2.3.2 están obsoletas). Los futuros dispositivos compatibles con Android que ejecuten Android 2.3 DEBEN enviarse con la versión 2.3.3 o una posterior.

2. Recursos

  1. Niveles de requisitos de la RFC2119 del IETF: http://www.ietf.org/rfc/rfc2119.txt
  2. Descripción general del programa de compatibilidad de Android: http://source.android.com/docs/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. Cadenas de versión permitidas de Android 2.3: http://source.android.com/docs/compatibility/2.3/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. Funciones sin conexión de HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
  11. Etiqueta de video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
  12. API de Geolocation de HTML5/W3C: http://www.w3.org/TR/geolocation-API/
  13. API de la base de datos web HTML5/W3C: http://www.w3.org/TR/webdatabase/
  14. API de IndexedDB de HTML5/W3C: http://www.w3.org/TR/IndexedDB/
  15. Especificación de la máquina virtual de Dalvik: Disponible en el código fuente de Android, en dalvik/docs
  16. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  17. Notificaciones: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  18. Recursos de la aplicación: http://code.google.com/android/reference/available-resources.html
  19. Guía de estilo de íconos de la barra de estado: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  20. Administrador de búsqueda: http://developer.android.com/reference/android/app/SearchManager.html
  21. Toasts: http://developer.android.com/reference/android/widget/Toast.html
  22. Fondos de pantalla animados: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  23. Documentación de herramientas de referencia (para adb, aapt y ddms): http://developer.android.com/guide/developing/tools/index.html
  24. Descripción del archivo APK de Android: http://developer.android.com/guide/topics/fundamentals.html
  25. Archivos de manifiesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  26. Herramienta de prueba de Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  27. Lista de funciones de hardware de Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
  28. Compatibilidad con varias pantallas: http://developer.android.com/guide/practices/screens_support.html
  29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  31. Espacio de coordenadas del sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
  32. API de Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
  33. Protocolo de envío de NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  40. API de orientación de la cámara: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  42. Referencia de seguridad y permisos de Android: http://developer.android.com/guide/topics/security/security.html
  43. Apps para Android: http://code.google.com/p/apps-for-android

Muchos de estos recursos se derivan de forma directa o indirecta del SDK de Android 2.3 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.3 [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.

Esta definición de compatibilidad permite que las implementaciones de dispositivos omitan algunos tipos de hardware para los que Android incluye APIs. En esos casos, las APIs DEBEN seguir presentes y comportarse de manera razonable. Consulta la sección 7 para conocer los requisitos específicos de esta situación.

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.3. 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.3, este campo DEBE tener el valor de número entero 9.
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 que se ponen a disposición de 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. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Por ejemplo:
acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys
La huella digital NO DEBE incluir caracteres de espacio en blanco. Si otros campos incluidos en la plantilla anterior tienen caracteres de espacio en blanco, DEBEN reemplazarse en la huella digital de compilación por otro carácter, como el guion bajo ("_"). El valor de este campo DEBE poder codificarse como ASCII de 7 bits.
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. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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". El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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". El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
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
  • Contactos
  • Correo electrónico
  • Galería
  • GlobalSearch
  • Selector
  • Música
  • Configuración

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 al que se hace referencia en la Sección 3.2.3.1. 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.

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. Como el código nativo depende en gran medida de la tecnología del procesador subyacente, Android define una serie de interfaces binarias de la aplicación (ABI) en el NDK de Android, en el archivo docs/CPU-ARCH-ABIS.txt. Si la implementación de un dispositivo es compatible con una o más ABI definidas, DEBE implementar la compatibilidad con el NDK de Android, como se indica a continuación.

Si una implementación de dispositivo incluye compatibilidad con una ABI de Android, hace lo siguiente:

  • 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).
  • DEBEN ser compatibles con el código fuente (es decir, compatibles con el encabezado) y con el código binario (para la ABI) con cada biblioteca requerida de la siguiente lista.
  • DEBE 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.
  • DEBEN informar solo las ABI documentadas en la versión más reciente del NDK de Android, en el archivo docs/CPU-ARCH-ABIS.txt.
  • DEBE compilarse con el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android upstream.

Las siguientes APIs de código nativo DEBEN estar disponibles para las apps que incluyen código nativo:

  • libc (biblioteca C)
  • libm (biblioteca matemática)
  • Compatibilidad mínima con C++
  • Interfaz de JNI
  • liblog (registro de Android)
  • libz (compresión zlib)
  • libdl (vinculador dinámico)
  • libGLESv1_CM.so (OpenGL ES 1.0)
  • libGLESv2.so (OpenGL ES 2.0)
  • libEGL.so (administración nativa de la superficie de OpenGL)
  • libjnigraphics.so
  • libOpenSLES.so (Compatibilidad con audio de la biblioteca de sonido abierta)
  • libandroid.so (compatibilidad con actividades nativas de Android)
  • Compatibilidad con OpenGL, como se describe a continuación

Ten en cuenta que las versiones futuras del NDK de Android pueden admitir ABI adicionales. Si una implementación de dispositivo no es compatible con una ABI predefinida existente, NO DEBE informar la compatibilidad con ninguna ABI.

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 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. Del mismo modo, un navegador web completo y moderno 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 upstream 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 código abierto de Android usa el motor de renderización de WebKit para implementar android.webkit.WebView. Debido a que no es factible desarrollar un paquete de pruebas integral para un sistema de renderización web, los implementadores de dispositivos DEBEN usar la compilación upstream específica de WebKit en la implementación de WebView. Más precisamente:

  • Las implementaciones de android.webkit.WebView de las implementaciones de dispositivos DEBEN basarse en la compilación de WebKit 533.1 del árbol de código abierto de Android upstream para Android 2.3. Esta compilación incluye un conjunto específico de correcciones de funcionalidad y seguridad para WebView. Los implementadores de dispositivos PUEDEN incluir personalizaciones en la implementación de WebKit. Sin embargo, estas personalizaciones NO DEBEN alterar el comportamiento de WebView, incluido el comportamiento de renderización.
  • La cadena de usuario-agente que informa 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 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.

El componente WebView DEBE incluir compatibilidad con la mayor cantidad posible de HTML5 [Recursos, 9]. Como mínimo, las implementaciones de dispositivos DEBEN admitir cada una de estas APIs asociadas con HTML5 en WebView:

Además, las implementaciones de dispositivos DEBEN ser compatibles con la API de HTML5/W3C WebStorage [Recursos, 13] y DEBEN ser compatibles con la API de IndexedDB de HTML5/W3C [Recursos, 14]. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer IndexedDB sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.

Las APIs de HTML5, como todas las APIs de JavaScript, DEBEN estar inhabilitadas de forma predeterminada en un WebView, a menos que el desarrollador las habilite de forma explícita a través de las APIs 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 general del usuario. El navegador independiente PUEDE basarse en una tecnología de navegador distinta de WebKit. Sin embargo, incluso si se usa una aplicación de navegador alternativa, el componente android.webkit.WebView que se proporciona a las aplicaciones de terceros DEBE basarse en WebKit, como se describe en la sección 3.4.1.

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

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 la mayor cantidad posible de HTML5 [Recursos, 9]. Como mínimo, las implementaciones de dispositivos DEBEN admitir cada una de estas APIs asociadas con HTML5:

Además, las implementaciones de dispositivos DEBEN ser compatibles con la API de HTML5/W3C WebStorage [Recursos, 13] y DEBEN ser compatibles con la API de IndexedDB de HTML5/W3C [Recursos, 14]. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer IndexedDB sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.

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 la semántica 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étera).
  • Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.

La lista anterior no es exhaustiva. 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. 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.

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" como se usa en el código fuente de Android ascendente. En otras palabras, los implementadores de dispositivos NO DEBEN exponer APIs nuevas ni alterar las existentes en los espacios de nombres mencionados anteriormente. Los implementadores de dispositivos PUEDEN realizar modificaciones solo para uso interno, pero esas 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. Además, si una implementación de dispositivo incluye APIs personalizadas fuera del espacio de nombres estándar de Android, esas APIs DEBEN empaquetarse en una biblioteca compartida de Android para que solo las apps que las usen de forma explícita (a través del mecanismo <uses-library>) se vean afectadas por el aumento del uso de memoria de esas APIs.

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

Las implementaciones de dispositivos con pantallas clasificadas como de densidad media o baja DEBEN configurar Dalvik para que asigne al menos 16 MB de memoria a cada aplicación. Las implementaciones de dispositivos con pantallas clasificadas como de alta densidad o extra alta densidad DEBEN configurar Dalvik para que asigne al menos 24 MB de memoria a cada aplicación. Ten 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 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, 16]. 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, 17]. 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, 18] o en la guía de estilo de íconos de la barra de estado [Recursos, 19]. 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, 20] 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, 21]) para mostrarle al usuario final cadenas breves 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, 22]. 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 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, 23].

Las implementaciones de dispositivos NO DEBEN extender los formatos .apk [Recursos, 24], manifiesto de Android [Recursos, 25] ni código de bytes de Dalvik [Recursos, 15] de manera 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.

5. Compatibilidad multimedia

Las implementaciones de dispositivos DEBEN implementar todas las APIs multimedia. Las implementaciones de dispositivos DEBEN incluir compatibilidad con todos los códecs multimedia que se describen a continuación y DEBEN cumplir con los lineamientos de procesamiento de sonido que se describen a continuación. Las implementaciones de dispositivos DEBEN incluir al menos una forma de salida de audio, como bocinas, conector para auriculares, conexión de bocina externa, etcétera.

5.1. Códecs multimedia

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

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.

En las siguientes tablas, no se indican 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.

5.1.1. Decodificadores multimedia

Las implementaciones de dispositivos DEBEN incluir una implementación de un decodificador para cada códec y formato que se describe en la siguiente tabla. Ten en cuenta que el Proyecto de código abierto de Android proporciona los decodificadores para cada uno de estos tipos de contenido multimedia.

Audio
Nombre Detalles Formato de archivo o contenedor
AAC LC/LTP 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+)
HE-AACv2 (AAC+ mejorado)
AMR-NB 4.75 a 12.2 kbps con muestreo a 8 kHz 3GPP (.3gp)
AMR-WB 9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz 3GPP (.3gp)
MP3 Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps. MP3 (.mp3)
MIDI 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   Ogg (.ogg)
PCM PCM lineal de 8 y 16 bits (el límite de las tasas depende del hardware) WAVE (.wav)
Imagen
JPEG base+progresiva  
GIF    
PNG    
BMP    
Video
H.263   Archivos 3GPP (.3gp)
H.264   Archivos 3GPP (.3gp) y MPEG-4 (.mp4)
Perfil simple MPEG4   Archivo 3GPP (.3gp)

5.1.2. Codificadores multimedia

Las implementaciones de dispositivos DEBEN incluir codificadores para la mayor cantidad posible de los formatos de contenido multimedia que se enumeran en el artículo 5.1.1. Sin embargo, algunos codificadores no tienen sentido para dispositivos que carecen de cierto hardware opcional. Por ejemplo, un codificador para el video H.263 no tiene sentido si el dispositivo no tiene cámaras. Por lo tanto, las implementaciones de dispositivos DEBEN implementar codificadores de contenido multimedia según las condiciones que se describen en la siguiente tabla.

Consulta el artículo 7 para obtener detalles sobre las condiciones en las que las implementaciones de dispositivos pueden omitir el hardware.

Audio
Nombre Detalles Formato de archivo o contenedor Condiciones
AMR-NB 4.75 a 12.2 kbps con muestreo a 8 kHz 3GPP (.3gp) Las implementaciones de dispositivos que incluyen hardware de micrófono y definen android.hardware.microphone DEBEN incluir codificadores para estos formatos de audio.
AMR-WB 9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz 3GPP (.3gp)
AAC LC/LTP 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)
Imagen JPEG base+progresiva   Todas las implementaciones de dispositivos DEBEN incluir codificadores para estos formatos de imagen, ya que Android 2.3 incluye APIs que las aplicaciones pueden usar para generar archivos de estos tipos de forma programática.
PNG    
Video H.263   Archivos 3GPP (.3gp) Las implementaciones de dispositivos que incluyen hardware de cámara y definen android.hardware.camera o android.hardware.camera.front DEBEN incluir codificadores para estos formatos de video.

Además de los codificadores mencionados anteriormente, las implementaciones de dispositivos DEBEN incluir un codificador H.264. Ten en cuenta que se planea cambiar este requisito a "DEBEN" en la definición de compatibilidad de una versión futura. Es decir, la codificación H.264 es opcional en Android 2.3, pero una versión futura la exigirá. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan Android 2.3 cumplan con este requisito en Android 2.3, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.

5.2. Grabación de audio

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

  • El procesamiento de reducción de ruido, si está presente, DEBE estar inhabilitado.
  • El control automático de ganancia, si está presente, DEBE estar inhabilitado.
  • El dispositivo DEBE mostrar características de amplitud aproximadamente planas en comparación con la frecuencia, específicamente, ±3 dB, de 100 Hz a 4000 Hz.
  • La sensibilidad de entrada de audio DEBE establecerse de modo que una fuente de nivel de potencia de sonido (SPL) de 90 dB a 1,000 Hz genere un RMS de 5,000 para muestras de 16 bits.
  • Los niveles de amplitud de PCM DEBEN hacer un seguimiento lineal de los cambios de SPL de entrada en un rango de al menos 30 dB, de -18 dB a +12 dB en relación con 90 dB SPL en el micrófono.
  • La distorsión armónica total DEBE ser inferior al 1% de 100 Hz a 4,000 Hz a un nivel de entrada de SPL de 90 dB.

Nota: Si bien los requisitos descritos anteriormente se indican como "DEBEN" para Android 2.3, se planea que la definición de compatibilidad de una versión futura los cambie a "DEBEN". Es decir, estos requisitos son opcionales en Android 2.3, pero una versión futura los exigirá. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan Android 2.3 cumplan con estos requisitos en Android 2.3, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.

5.3. Latencia de audio

La latencia de audio se define de manera general como el intervalo entre el momento en que una aplicación solicita una operación de grabación o reproducción de audio y el momento en que la implementación del dispositivo comienza realmente la operación. Muchas clases de aplicaciones dependen de latencias cortas para lograr efectos en tiempo real, como efectos de sonido o comunicación de VOIP. Las implementaciones de dispositivos que incluyen hardware de micrófono y declaran android.hardware.microphone DEBEN cumplir con todos los requisitos de latencia de audio que se describen en esta sección. Consulta el artículo 7 para obtener detalles sobre las condiciones en las que las implementaciones de dispositivos pueden omitir el hardware del micrófono.

A los efectos de esta sección, se entenderá lo siguiente:

  • 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 comienza a reproducirse el sonido, cuando el sistema de audio estuvo inactivo y apagado antes de la solicitud.
  • La "latencia de salida activada" 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 usó recientemente, pero actualmente está inactivo (es decir, silencioso).
  • La "latencia de salida continua" se define como el intervalo entre el momento en que una aplicación emite una muestra para que se reproduzca y el momento en que la bocina reproduce físicamente el sonido correspondiente, mientras el dispositivo está reproduciendo audio.
  • La "latencia de entrada en frío" se define como el intervalo entre el momento en que una aplicación solicita la grabación de audio y el momento en que se entrega la primera muestra a la aplicación a través de su devolución de llamada, cuando el sistema de audio y el micrófono estuvieron 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.

Con las definiciones anteriores, las implementaciones de dispositivos DEBEN mostrar cada una de estas propiedades:

  • Latencia de salida en frío de 100 milisegundos o menos
  • Latencia de salida semicaliente 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

Nota: Si bien los requisitos descritos anteriormente se indican como "DEBEN" para Android 2.3, se planea que la definición de compatibilidad de una versión futura los cambie a "DEBEN". Es decir, estos requisitos son opcionales en Android 2.3, pero una versión futura los requerirá. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan Android 2.3 cumplan con estos requisitos en Android 2.3, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.

Si la implementación de un dispositivo cumple con los requisitos de esta sección, PUEDE informar la compatibilidad con audio de baja latencia a través de la función "android.hardware.audio.low-latency" mediante la clase android.content.pm.PackageManager. [Recursos, 27] Por el contrario, si la implementación del dispositivo no cumple con estos requisitos, NO DEBE informar la compatibilidad con audio de baja latencia.

6. 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, 23]
    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, 23]
    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, 26]
    Las implementaciones de dispositivos DEBEN incluir el framework de Monkey y ponerlo a disposición de las aplicaciones para que lo usen.

La mayoría de los sistemas basados en Linux y los sistemas Apple Macintosh reconocen dispositivos Android con las herramientas estándar del SDK de Android, sin compatibilidad adicional. Sin embargo, los sistemas Microsoft Windows suelen requerir un controlador para dispositivos Android nuevos. (por ejemplo, los IDs de proveedores nuevos y, a veces, los IDs de dispositivos nuevos requieren controladores USB personalizados para sistemas Windows). Si la herramienta adb no reconoce una implementación de dispositivo como se proporciona en el SDK estándar de Android, los implementadores de dispositivos DEBEN proporcionar controladores de Windows que permitan a los desarrolladores conectarse al dispositivo con el protocolo adb. Estos controladores DEBEN proporcionarse para Windows XP, Windows Vista y Windows 7, en versiones de 32 y 64 bits.

7. Compatibilidad de hardware

El objetivo de Android es permitir que los implementadores de dispositivos creen configuraciones y factores de forma innovadores. Al mismo tiempo, los desarrolladores de Android escriben aplicaciones innovadoras que dependen de los diversos hardware y funciones disponibles a través de las APIs de Android. Los requisitos de esta sección establecen un equilibrio entre las innovaciones disponibles para los implementadores de dispositivos y las necesidades de los desarrolladores para garantizar que sus apps solo estén disponibles para los dispositivos en los que se ejecutarán correctamente.

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 describe 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 completas (como se documenta en el SDK) 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.
  • Los métodos de la API NO DEBEN generar excepciones que no estén documentadas en la documentación del SDK.

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 con precisión la información de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager. [Recursos, 27]

7.1. Pantalla y gráficos

Android 2.3 incluye funciones que ajustan automáticamente los recursos de la aplicación y los diseños de la IU de forma adecuada para el dispositivo, a fin de garantizar que las aplicaciones de terceros se ejecuten bien en una variedad de configuraciones de hardware [Recursos, 28]. Los dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

7.1.1. Configuraciones de pantalla

Las implementaciones de dispositivos PUEDEN usar pantallas de cualquier dimensión de píxeles, siempre que cumplan con los siguientes requisitos:

  • Las pantallas DEBEN tener un tamaño diagonal físico de al menos 6.35 cm (2.5 pulgadas).
  • La densidad DEBE ser de al menos 100 dpi.
  • La relación de aspecto DEBE ser de entre 1.333 (4:3) y 1.779 (16:9).
  • la tecnología de pantalla utilizada consta de píxeles cuadrados

Las implementaciones de dispositivos con una pantalla que cumpla con los requisitos anteriores se consideran compatibles y no es necesario realizar ninguna acción adicional. La implementación del framework de Android calcula automáticamente las características de la pantalla, como el bucket de tamaño de pantalla y el bucket de densidad. En la mayoría de los casos, las decisiones del framework son las correctas. Si se usan las operaciones del framework predeterminadas, no es necesario que realices ninguna acción adicional. Los implementadores de dispositivos que deseen cambiar los valores predeterminados o usar una pantalla que no cumpla con los requisitos anteriores DEBEN comunicarse con el equipo de compatibilidad de Android para obtener orientación, como se indica en el artículo 12.

Las unidades que usan los requisitos anteriores se definen de la siguiente manera:

  • El “tamaño diagonal físico” es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
  • “dpi” (que significa “puntos por pulgada”) es la cantidad de píxeles que abarca un tramo lineal horizontal o vertical de 1". Cuando se enumeran los valores de dpi, los dpi horizontales y verticales deben estar dentro del rango.
  • "Relación de aspecto" es la proporción entre la dimensión más larga de la pantalla y la más corta. Por ejemplo, una pantalla de 480 x 854 píxeles sería 854 / 480 = 1.779, o aproximadamente "16:9".

Las implementaciones de dispositivos DEBEN usar solo pantallas con una sola configuración estática. Es decir, las implementaciones de dispositivos NO DEBEN habilitar configuraciones de varias pantallas. Por ejemplo, como una televisión típica admite varias resoluciones, como 1080p, 720p, etcétera, esta configuración no es compatible con Android 2.3. (Sin embargo, la compatibilidad con esas configuraciones está en proceso de investigación y se planea para una versión futura de Android).

7.1.2. 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, 29].

7.1.3. Compatibilidad de pantalla declarada

De manera opcional, las aplicaciones indican 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.

7.1.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 que no se pueden rotar físicamente PUEDEN cumplir con este requisito mediante aplicaciones de formato letterbox que soliciten el modo vertical y usen solo una parte de la pantalla disponible.

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.

7.1.5. Aceleración de gráficos 3D

Las implementaciones de dispositivos DEBEN admitir OpenGL ES 1.0, como lo requieren las APIs de Android 2.3. En el caso de los dispositivos que no tienen hardware de aceleración 3D, el proyecto de código abierto de Android proporciona una implementación de software de OpenGL ES 1.0. Las implementaciones de dispositivos DEBEN admitir OpenGL ES 2.0.

Las implementaciones PUEDEN omitir la compatibilidad con OpenGL ES 2.0. Sin embargo, si se omite la compatibilidad, las implementaciones de dispositivos NO DEBEN informar que son compatibles con OpenGL ES 2.0. Específicamente, si las implementaciones de un dispositivo no son compatibles con OpenGL ES 2.0, ocurre lo siguiente:

  • Las APIs administradas (como a través del método GLES10.getString()) NO DEBEN informar compatibilidad con OpenGL ES 2.0.
  • Las APIs nativas de OpenGL C/C++ (es decir, las que están disponibles para las apps a través de libGLES_v1CM.so, libGLES_v2.so o libEGL.so) NO DEBEN informar compatibilidad con OpenGL ES 2.0.

Por el contrario, si una implementación de dispositivo sí es compatible con OpenGL ES 2.0, DEBE informar esa compatibilidad con precisión a través de las rutas que se acaban de enumerar.

Ten en cuenta que Android 2.3 incluye compatibilidad con aplicaciones que, de manera opcional, pueden especificar que requieren formatos de compresión de texturas OpenGL específicos. Por lo general, estos formatos son específicos de cada proveedor. Android 2.3 no requiere implementaciones de dispositivos para implementar ningún formato de compresión de texturas específico. Sin embargo, DEBEN informar con precisión los formatos de compresión de texturas que sí admiten, a través del método getString() en la API de OpenGL.

7.2. Dispositivos de entrada

Android 2.3 admite varias modalidades de entrada del usuario. Las implementaciones de dispositivos DEBEN admitir dispositivos de entrada del usuario como se indica en esta sección.

7.2.1. 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, 30] (es decir, QWERTY o 12 teclas).

7.2.2. Navegación no táctil

Implementaciones de dispositivos:

  • PUEDE omitir una opción 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, 30].
  • DEBEN proporcionar un mecanismo alternativo razonable de interfaz de usuario para la selección y edición de texto, compatible con los motores de administración de entradas. El código fuente abierto de Android upstream incluye un mecanismo de selección adecuado para su uso con dispositivos que no tienen entradas de navegación no táctiles.

7.2.3. 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.

7.2.4. Entrada táctil

Implementaciones de dispositivos:

  • DEBE tener una pantalla táctil
  • PUEDE tener una pantalla táctil resistiva o capacitiva.
  • DEBE informar el valor de android.content.res.Configuration [Resources, 30] que refleja el tipo de pantalla táctil específica del dispositivo.
  • DEBE admitir punteros con seguimiento completamente independiente, si la pantalla táctil admite varios punteros

7.3. Sensores

Android 2.3 incluye APIs para acceder a una variedad de tipos de sensores. Por lo general, las implementaciones de dispositivos PUEDEN omitir estos sensores, como se indica en las siguientes sub secciones. Si un dispositivo incluye un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos, la implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android. Por ejemplo, las siguientes implementaciones de dispositivos:

  • DEBEN informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager. [Recursos, 27]
  • DEBE mostrar una lista precisa de los sensores compatibles a través de SensorManager.getSensorList() y métodos similares.
  • DEBEN comportarse de manera razonable para todas las demás APIs de sensores (por ejemplo, devolviendo verdadero o falso según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamando a objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etcétera).

La lista anterior no es exhaustiva. El comportamiento documentado del SDK de Android se debe considerar como fuente de autoridad.

Algunos tipos de sensores son sintéticos, lo que significa que se pueden obtener a partir de datos que proporcionan uno o más sensores. (entre los ejemplos, se incluyen el sensor de orientación y el sensor de aceleración lineal). Las implementaciones de dispositivos DEBEN implementar estos tipos de sensores, cuando incluyen los sensores físicos previos.

Las APIs de Android 2.3 presentan el concepto de un sensor de "transmisión", que es uno que muestra datos de forma continua, en lugar de solo cuando los datos cambian. Las implementaciones de dispositivos DEBEN proporcionar muestras de datos periódicas de forma continua para cualquier API que indique la documentación del SDK de Android 2.3 para ser un sensor de transmisión.

7.3.1. Acelerómetro

Las implementaciones de dispositivos DEBEN incluir un acelerómetro de 3 ejes. Si la implementación de un dispositivo incluye un acelerómetro de 3 ejes, hace lo siguiente:

  • DEBE poder entregar eventos a 50 Hz o más
  • DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android (consulta [Recursos, 31]).
  • DEBEN ser capaces de medir desde la caída libre hasta el doble de la gravedad (2 g) o más en cualquier vector tridimensional.
  • DEBEN tener 8 bits de precisión o más
  • DEBE tener una desviación estándar no superior a 0.05 m/s².

7.3.2. Magnetómetro

Las implementaciones de dispositivos DEBEN incluir un magnetómetro de 3 ejes (es decir, una brújula). Si un dispositivo incluye un magnetómetro de 3 ejes, tiene las siguientes características:

  • DEBEN poder entregar eventos a 10 Hz o más.
  • DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android (consulta [Recursos, 31]).
  • DEBEN ser capaces de muestrear un rango de intensidades de campo adecuadas para cubrir el campo geomagnético.
  • DEBEN tener 8 bits de precisión o más
  • DEBE tener una desviación estándar no superior a 0.5 µT.

7.3.3. GPS

Las implementaciones de dispositivos DEBEN incluir un receptor GPS. Si la implementación de un dispositivo incluye un receptor GPS, DEBE incluir algún tipo de técnica de "GPS asistido" para minimizar el tiempo de bloqueo del GPS.

7.3.4. Giroscopio

Las implementaciones de dispositivos DEBEN incluir un giroscopio (es decir, un sensor de cambio angular). Los dispositivos NO DEBEN incluir un sensor de giroscopio, a menos que también se incluya un acelerómetro de 3 ejes. Si una implementación de dispositivo incluye un giroscopio, hace lo siguiente:

  • DEBEN ser capaces de medir cambios de orientación de hasta 5.5*Pi radianes por segundo (es decir, aproximadamente 1,000 grados por segundo).
  • DEBEN poder entregar eventos a 100 Hz o más.
  • DEBEN tener 8 bits de precisión o más

7.3.5. Barómetro

Las implementaciones de dispositivos PUEDEN incluir un barómetro (es decir, un sensor de presión del aire ambiente). Si una implementación de dispositivo incluye un barómetro, hace lo siguiente:

  • DEBE poder entregar eventos a 5 Hz o más.
  • DEBEN tener una precisión adecuada para permitir la estimación de la altitud.

7.3.7. Termómetro

Las implementaciones de dispositivos PUEDEN, pero NO DEBEN, incluir un termómetro (es decir, un sensor de temperatura). Si una implementación de dispositivo incluye un termómetro, este DEBE medir la temperatura de la CPU del dispositivo. NO DEBE medir ninguna otra temperatura. (Ten en cuenta que este tipo de sensor dejó de estar disponible en las APIs de Android 2.3).

7.3.7. Fotómetro

Las implementaciones de dispositivos PUEDEN incluir un fotómetro (es decir, un sensor de luz ambiental).

7.3.8. Sensor de proximidad

Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad. Si la implementación de un dispositivo incluye un sensor de proximidad, DEBE medir la proximidad de un objeto en la misma dirección que la pantalla. Es decir, el sensor de proximidad DEBE estar orientado para detectar objetos cerca de la pantalla, ya que el objetivo principal de este tipo de sensor es detectar un teléfono en uso por el usuario. Si la implementación de un dispositivo incluye un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API. Si la implementación de un dispositivo tiene un sensor de proximidad, DEBE tener 1 bit de precisión o más.

7.4. Conectividad de datos

La conectividad de red y el acceso a Internet son funciones vitales de Android. Mientras tanto, la interacción entre dispositivos agrega un valor significativo a los dispositivos y las aplicaciones para Android. Las implementaciones de dispositivos DEBEN cumplir con los requisitos de conectividad de datos que se indican en esta sección.

7.4.1. Telefonía

El término “telefonía”, tal como lo usan las APIs de Android 2.3 y este documento, hace referencia de forma específica al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes, para los fines de Android 2.3, se consideran independientes de cualquier conectividad de datos que se pueda implementar con la misma red. En otras palabras, las APIs y la funcionalidad de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS NO DEBEN informar la función "android.hardware.telephony" ni ninguna subfunción, independientemente de si usan una red celular para la conectividad de datos.

SE PUEDE usar Android 2.3 en dispositivos que no incluyen hardware de telefonía. Es decir, Android 2.3 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.

7.4.2. IEEE 802.11 (Wi-Fi)

Las implementaciones de dispositivos Android 2.3 DEBEN incluir compatibilidad con una o más formas de 802.11 (b/g/a/n, etcétera). Si una implementación de dispositivo incluye compatibilidad con 802.11, DEBE implementar la API de Android correspondiente.

7.4.3. Bluetooth

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

El conjunto de pruebas de compatibilidad incluye casos que abarcan el funcionamiento básico de la API de Bluetooth RFCOMM de Android. Sin embargo, como Bluetooth es un protocolo de comunicación entre dispositivos, no se puede probar por completo con pruebas de unidades que se ejecutan en un solo dispositivo. En consecuencia, las implementaciones de dispositivos TAMBIÉN DEBEN aprobar el procedimiento de prueba de Bluetooth manual que se describe en el Apéndice A.

7.4.4. Comunicación de campo cercano

Las implementaciones de dispositivos DEBEN incluir un transceptor y el hardware relacionado para la comunicación de campo cercano (NFC). Si una implementación de dispositivo incluye hardware NFC, hace lo siguiente:

  • DEBE informar la función android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature(). [Recursos, 27]
  • DEBEN ser capaces de leer y escribir mensajes NDEF a través de los siguientes estándares de NFC:
    • DEBEN ser capaces de actuar como lectores o escritores de NFC Forum (según se define en la especificación técnica NFC Forum NFCForum-TS-DigitalProtocol-1.0) a través de los siguientes estándares de NFC:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • NFCv (ISO 15693)
      • IsoDep (ISO 14443-4)
      • Tipos de etiquetas del NFC Forum 1, 2, 3 y 4 (definidos por el NFC Forum)
    • DEBEN ser capaces de transmitir y recibir datos a través de los siguientes protocolos y estándares de peer-to-peer:
      • ISO 18092
      • LLCP 1.0 (definido por el NFC Forum)
      • SDP 1.0 (definido por NFC Forum)
      • Protocolo de envío de NDEF [Recursos, 33]
    • DEBE buscar todas las tecnologías compatibles mientras está en el modo de descubrimiento de NFC.
    • DEBE estar en modo de descubrimiento de NFC mientras el dispositivo está activo con la pantalla activa.

    (Ten en cuenta que los vínculos disponibles públicamente no están disponibles para las especificaciones de JIS, ISO y NFC Forum mencionadas anteriormente).

    Además, las implementaciones de dispositivos DEBEN admitir las siguientes tecnologías MIFARE ampliamente implementadas.

    Ten en cuenta que Android 2.3.3 incluye APIs para estos tipos de MIFARE. Si una implementación de dispositivo admite MIFARE, hace lo siguiente:

    • DEBEN implementar las APIs de Android correspondientes, como se documenta en el SDK de Android.
    • DEBE informar la función com.nxp.mifare desde el método android.content.pm.PackageManager.hasSystemFeature(). [Resources, 27] Ten en cuenta que esta no es una función estándar de Android y, por lo tanto, no aparece como una constante en la clase PackageManager.
    • NO DEBE implementar las APIs de Android correspondientes ni informar la función com.nxp.mifare, a menos que también implemente la compatibilidad general con NFC como se describe en esta sección.

    Si una implementación de dispositivo no incluye hardware NFC, NO DEBE declarar la función android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature() [Recursos, 27] y DEBE implementar la API de NFC de Android 2.3 como no operación.

    Como las clases android.nfc.NdefMessage y android.nfc.NdefRecord representan un formato de representación de datos independiente del protocolo, las implementaciones de dispositivos DEBEN implementar estas APIs, incluso si no incluyen compatibilidad con NFC ni declaran la función android.hardware.nfc.

    7.4.5. Capacidad de red mínima

    Las implementaciones de dispositivos DEBEN incluir compatibilidad con una o más formas de redes de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos 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, Ethernet, etcétera.

    Las implementaciones de dispositivos en las que un estándar de red física (como Ethernet) es la conexión de datos principal DEBEN incluir compatibilidad con al menos un estándar de datos inalámbricos común, como 802.11 (Wi-Fi).

    Los dispositivos PUEDEN implementar más de una forma de conectividad de datos.

    7.5. Cámaras

    Las implementaciones de dispositivos DEBEN incluir una cámara posterior y PUEDEN incluir una cámara frontal. Una cámara posterior es una cámara que se encuentra en el lado del dispositivo opuesto a la pantalla; es decir, captura imágenes de escenas en el extremo opuesto del dispositivo, como una cámara tradicional. Una cámara frontal es una cámara que se encuentra en el mismo lado del dispositivo que la pantalla; es decir, una cámara que se suele usar para capturar imágenes del usuario, como en videoconferencias y aplicaciones similares.

    7.5.1. Cámara posterior

    Las implementaciones de dispositivos DEBEN incluir una cámara posterior. Si la implementación de un dispositivo incluye una cámara posterior, hace lo siguiente:

    • 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.

    7.5.2. Cámara frontal

    Las implementaciones de dispositivos PUEDEN incluir una cámara frontal. Si la implementación de un dispositivo incluye una cámara frontal, hace lo siguiente:

    • DEBEN tener una resolución de al menos VGA (es decir, 640 × 480 píxeles).
    • NO DEBE usar una cámara frontal como la predeterminada de la API de Camera. Es decir, la API de la cámara en Android 2.3 tiene compatibilidad específica con cámaras frontales, y las implementaciones de dispositivos NO DEBEN configurar la API para que trate una cámara frontal como la cámara posterior predeterminada, incluso si es la única cámara del dispositivo.
    • PUEDEN incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras posteriores, como se describe en el artículo 7.5.1.
    • DEBEN reflejar horizontalmente (es decir, duplicar) la transmisión que muestra una app en una CameraPreview, de la siguiente manera:
      • Si el usuario puede rotar la implementación del dispositivo (por ejemplo, automaticamente a través de un acelerómetro o de forma manual a través de la entrada del usuario), la vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.
      • Si la aplicación actual solicitó de forma explícita que la pantalla de la cámara se rote mediante una llamada al método android.hardware.Camera.setDisplayOrientation() [Resources, 40], la vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación especificada por la aplicación.
      • De lo contrario, la vista previa DEBE reflejarse a lo largo del eje horizontal predeterminado del dispositivo.
    • DEBEN duplicar los datos de imagen que se muestran a cualquier controlador de devolución de llamada de la cámara "postview", de la misma manera que el flujo de imágenes de vista previa de la cámara. (Si la implementación del dispositivo no admite devoluciones de llamada de vista posterior, este requisito no se aplica).
    • NO DEBE duplicar las transmisiones de video o imágenes estáticas capturadas finales que se devuelven a las devoluciones de llamada de la aplicación o se confirman en el almacenamiento de contenido multimedia.

    7.5.3. Comportamiento de la API de Camera

    Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara, tanto para la cámara frontal como para la posterior:

    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. Es decir, NV21 DEBE ser el valor predeterminado.
    3. Las implementaciones de dispositivos DEBEN admitir el formato YV12 (como se indica con la constante android.graphics.ImageFormat.YV12) para las vistas previas de la cámara, tanto frontal como posterior. Ten en cuenta que se planea que la definición de compatibilidad de una versión futura cambie este requisito a "DEBEN". Es decir, la compatibilidad con YV12 es opcional en Android 2.3, pero será obligatoria en una versión futura. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan Android 2.3 cumplan con este requisito en Android 2.3, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.

    Las implementaciones de dispositivos DEBEN implementar la API de Camera completa incluida en la documentación del SDK de Android 2.3 [Recursos, 41], 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). Ten en cuenta que esto se aplica a las cámaras frontales. Por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API aún deben ser "falsas", como se describe.

    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 documentan como constantes en android.hardware.Camera.Parameters. 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.

    7.5.4. Orientación de la cámara

    Si están presentes, las cámaras frontal y posterior DEBEN estar orientadas de modo que la dimensión larga de la cámara se alinee con la dimensión larga de la pantalla. Es decir, cuando el dispositivo se sostiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo, es decir, se aplica a los dispositivos con orientación horizontal principal y a los dispositivos con orientación vertical principal.

    7.6. Memoria y almacenamiento

    La función fundamental de Android 2.3 es ejecutar aplicaciones. Las implementaciones de dispositivos DEBEN cumplir con los requisitos de esta sección para garantizar un almacenamiento y una memoria adecuados para que las aplicaciones se ejecuten correctamente.

    7.6.1. Memoria y almacenamiento mínimos

    Las implementaciones de dispositivos DEBEN tener al menos 128 MB de memoria disponible para el kernel y el espacio de usuario. Los 128 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 ser de al menos 150 MB.

    Además de los requisitos anteriores, las implementaciones de dispositivos DEBEN tener al menos 1 GB de almacenamiento no volátil disponible para los datos del usuario. Ten en cuenta que se planea que este requisito más alto se convierta en un mínimo estricto en una versión futura de Android. Se recomienda que las implementaciones de dispositivos cumplan con estos requisitos ahora, de lo contrario, es posible que no sean compatibles con una versión futura de Android.

    Las APIs de Android incluyen un Administrador de descargas que las aplicaciones pueden usar para descargar archivos de datos. La implementación del Administrador de descargas DEBE ser capaz de descargar archivos individuales de 55 MB de tamaño o más. La implementación del Administrador de descargas DEBE ser capaz de descargar archivos de 100 MB o más.

    7.6.2. 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 1 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 de la forma de almacenamiento compartido que se use, las implementaciones de dispositivos DEBEN proporcionar algún mecanismo para acceder al contenido del almacenamiento compartido desde una computadora host, como el almacenamiento masivo USB o el protocolo de transferencia de contenido multimedia.

    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 1 GB de tamaño o superior con el dispositivo tal como se vende a los usuarios y DEBE activarse 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 1 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).

    Las implementaciones de dispositivos que incluyen varias rutas de acceso de almacenamiento compartido (como una ranura para tarjeta SD y un almacenamiento interno compartido) DEBEN modificar las aplicaciones principales, como el escáner de contenido multimedia y ContentProvider, para admitir de forma transparente los archivos ubicados en ambas ubicaciones.

    7.7. 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. Compatibilidad de rendimiento

    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.3 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.  

    9. 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, 42] 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.

    9.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, 42]. 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.*.

    9.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, 42].

    9.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, 42].

    9.4. Entornos de ejecución alternativos

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

    Los tiempos de ejecución alternativos DEBEN ser aplicaciones para Android y cumplir con el modelo de seguridad estándar de Android, como se describe en la Sección 9.

    Los entornos de ejecución alternativos NO DEBEN tener acceso a recursos protegidos por permisos que no se solicitaron en el archivo AndroidManifest.xml del entorno de ejecución a través del mecanismo <uses-permission>.

    Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones usen funciones protegidas por permisos de Android restringidos a las aplicaciones del sistema.

    Los entornos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android. Más precisamente:

    • Los entornos de ejecución alternativos DEBEN instalar apps a través de PackageManager en zonas de pruebas de Android independientes (es decir, IDs de usuario de Linux, etcétera).
    • Los entornos de ejecución alternativos PUEDEN proporcionar una sola zona de pruebas de Android que comparten todas las aplicaciones que usan el entorno de ejecución alternativo.
    • Los tiempos de ejecución alternativos y las aplicaciones instaladas que usan un tiempo de ejecución alternativo NO DEBEN volver a usar la zona de pruebas de ninguna otra app 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 iniciarse con acceso a las zonas de pruebas correspondientes a otras aplicaciones para Android, ni otorgarlo.

    Los tiempos de ejecución alternativos NO DEBEN iniciarse con privilegios del superusuario (root) ni otorgarlos a otras aplicaciones, ni otorgarlos a otras aplicaciones.

    Los archivos .apk de tiempos de ejecución alternativos PUEDEN incluirse en la imagen del sistema de una implementación de dispositivo, pero DEBEN estar firmados con una clave distinta de la que se usa para firmar otras aplicaciones incluidas con la implementación del dispositivo.

    Cuando se instalan aplicaciones, los entornos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que usa la aplicación. Es decir, si una aplicación necesita usar un recurso de dispositivo para el que hay un permiso de Android correspondiente (como la cámara, el GPS, etcétera), el entorno de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso. Si el entorno de ejecución no registra las capacidades de la aplicación de esta manera, el entorno de ejecución DEBE enumerar todos los permisos que tiene el entorno de ejecución cuando se instala cualquier aplicación que use ese entorno de ejecución.

    10. Pruebas de compatibilidad de software

    El Proyecto de código abierto de Android incluye varias herramientas de prueba para verificar que las implementaciones de dispositivos sean compatibles. Las implementaciones de dispositivos DEBEN aprobar todas las pruebas que se describen en esta sección.

    Sin embargo, ten en cuenta que ningún paquete de prueba de software es completamente exhaustivo. Por esta razón, se recomienda encarecidamente a los implementadores de dispositivos que realicen la menor cantidad posible de cambios en la implementación de referencia y preferida de Android 2.3 disponible en el Proyecto de código abierto de Android. Esto minimizará el riesgo de introducir errores que creen incompatibilidades que requieran retrabajos y posibles actualizaciones de dispositivos.

    10.1. 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.3. 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.

    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.

    10.2. Verificador del CTS

    Las implementaciones de dispositivos DEBEN ejecutar correctamente todos los casos aplicables en el verificador de CTS. El verificador del CTS se incluye en el paquete de pruebas de compatibilidad y está diseñado para que lo ejecute un operador humano para probar la funcionalidad que un sistema automatizado no puede probar, como el funcionamiento correcto de una cámara y los sensores.

    El verificador del CTS tiene pruebas para muchos tipos de hardware, incluido algunos que son opcionales. Las implementaciones de dispositivos DEBEN aprobar todas las pruebas del hardware que poseen. Por ejemplo, si un dispositivo tiene un acelerómetro, DEBE ejecutar correctamente el caso de prueba del acelerómetro en el verificador de CTS. Los casos de prueba de las funciones que se indican como opcionales en este Documento de definición de compatibilidad PUEDEN omitirse.

    Cada dispositivo y cada compilación DEBEN ejecutar correctamente el verificador de CTS, como se indicó anteriormente. Sin embargo, como muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten de forma explícita el verificador de CTS en compilaciones que solo difieren de forma trivial. Específicamente, las implementaciones de dispositivos que difieren de una implementación que pasó el verificador de CTS solo por el conjunto de configuraciones regionales, desarrollo de la marca, etc., PUEDEN omitir la prueba del verificador de CTS.

    10.3. Aplicaciones de referencia

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

    • Las aplicaciones "Apps para Android" [Recursos, 43].
    • Isla de réplica (disponible en Android Market; solo es obligatorio para las implementaciones de dispositivos que admiten OpenGL ES 2.0)

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

    11. 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.

    12. 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.

    Apéndice A: Procedimiento de prueba de Bluetooth

    El conjunto de pruebas de compatibilidad incluye casos que abarcan el funcionamiento básico de la API de Bluetooth RFCOMM de Android. Sin embargo, como Bluetooth es un protocolo de comunicación entre dispositivos, no se puede probar por completo con pruebas de unidades que se ejecutan en un solo dispositivo. Por lo tanto, las implementaciones de dispositivos TAMBIÉN DEBEN aprobar el procedimiento de prueba de Bluetooth operado por humanos que se describe a continuación.

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

    • Una implementación de dispositivo candidato que ejecuta la compilación de software que se probará
    • una implementación de dispositivo independiente que ya se sabe que es compatible y de un modelo de la implementación de dispositivo que se está probando, es decir, una implementación de dispositivo "conocida como buena"

    En el siguiente procedimiento de prueba, se hace referencia a estos dispositivos como "candidato" y "conocido como bueno", respectivamente.

    Configuración e instalación

    1. Compila BluetoothChat.apk a través de "make samples" desde un árbol de código fuente de Android.
    2. Instala BluetoothChat.apk en el dispositivo que funciona correctamente.
    3. Instala BluetoothChat.apk en el dispositivo candidato.

    Cómo probar el control Bluetooth por apps

    1. Inicia BluetoothChat en el dispositivo candidato mientras el Bluetooth está inhabilitado.
    2. Verifica que el dispositivo candidato active el Bluetooth o le solicite al usuario que lo active mediante un diálogo.

    Prueba la vinculación y la comunicación

    1. Inicia la app de Bluetooth Chat en ambos dispositivos.
    2. Haz que el dispositivo conocido y en buen estado sea detectable desde BluetoothChat (con el menú).
    3. En el dispositivo candidato, busca dispositivos Bluetooth desde BluetoothChat (con el menú) y vincúlalo con el dispositivo que funciona correctamente.
    4. Envía 10 o más mensajes desde cada dispositivo y verifica que el otro los reciba correctamente.
    5. Presiona Inicio para cerrar la app de BluetoothChat en ambos dispositivos.
    6. Desvincula cada dispositivo del otro con la app de Configuración del dispositivo.

    Prueba la vinculación y la comunicación en la dirección inversa

    1. Inicia la app de Bluetooth Chat en ambos dispositivos.
    2. Haz que el dispositivo candidato sea detectable desde BluetoothChat (con el menú).
    3. En el dispositivo que funciona correctamente, busca dispositivos Bluetooth desde BluetoothChat (con el menú) y vincúlalo con el dispositivo candidato.
    4. Envía 10 mensajes desde cada dispositivo y verifica que el otro los reciba correctamente.
    5. Para cerrar la app de Chat por Bluetooth en ambos dispositivos, presiona Atrás varias veces hasta llegar al selector.

    Pruebas de relanzamiento

    1. Vuelve a iniciar la app de Bluetooth Chat en ambos dispositivos.
    2. Envía 10 mensajes desde cada dispositivo y verifica que el otro los reciba correctamente.

    Nota: Las pruebas anteriores tienen algunos casos en los que se finaliza una sección de prueba con la tecla Inicio y otros con la tecla Atrás. Estas pruebas no son redundantes ni opcionales: el objetivo es verificar que la API y la pila de Bluetooth funcionen correctamente cuando las actividades se finalizan de forma explícita (cuando el usuario presiona Atrás, que llama a finish()) y se envían de forma implícita al segundo plano (cuando el usuario presiona Inicio). Cada secuencia de prueba DEBE realizarse como se describe.