Definición de compatibilidad con Android 2.3

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

Tabla de contenido

1. Introducción

Este documento enumera los requisitos que se deben cumplir para que los teléfonos móviles sean compatibles con Android 2.3.

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

Tal como se utiliza en este documento, un "implementador de dispositivos" o "implementador" es una persona u organización que desarrolla una solución de hardware/software que ejecuta Android 2.3. Una "implementación de dispositivo" o "implementación" es la solución de hardware/software así desarrollada.

Para ser considerado compatible con Android 2.3, las implementaciones de dispositivos DEBEN cumplir con los requisitos presentados en esta Definición de compatibilidad, incluido cualquier documento incorporado mediante referencia.

Cuando esta definición o las pruebas de software descritas en la Sección 10 no dicen nada, son ambiguas o están incompletas, es responsabilidad del implementador del dispositivo garantizar la compatibilidad con las implementaciones existentes. Por esta razón, el Proyecto de código abierto de Android [ Recursos, 3 ] es la implementación de referencia y preferida de Android. Se recomienda encarecidamente a los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente "ascendente" disponible en el Proyecto de código abierto de Android. Si bien hipotéticamente algunos componentes pueden reemplazarse con implementaciones alternativas, se desaconseja encarecidamente esta práctica, ya que pasar las pruebas de software será sustancialmente más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluido y más allá del Compatibility Test Suite. Finalmente, tenga en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

Tenga en cuenta que esta Definición de compatibilidad se emite para corresponder con la actualización 2.3.3 de Android, que es el nivel de API 10. Esta Definición 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 posterior.

2. Recursos

1. Niveles de requisitos IETF RFC2119: 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 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. Capacidades HTML5 sin conexión: http://dev.w3.org/html5/spec/Overview.html#offline
11. Etiqueta de vídeo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. API de geolocalización HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. API de base de datos web HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. API HTML5/W3C IndexedDB: http://www.w3.org/TR/IndexedDB/
15. Especificación de la máquina virtual 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 iconos 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. Brindis: http://developer.android.com/reference/android/widget/Toast.html
22. Fondos de pantalla en vivo: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Documentación de la herramienta de referencia (para adb, aapt, 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 monos: 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. Compatible 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 push 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 permisos y seguridad de Android: http://developer.android.com/guide/topics/security/security.html
43. Aplicaciones para Android: http://code.google.com/p/apps-for-android

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

3.software

La plataforma Android incluye un conjunto de API administradas, un conjunto de API nativas y un conjunto de API denominadas "blandas", como el sistema Intent y las API de aplicaciones web. Esta sección detalla las API físicas y blandas que son parte integral de la compatibilidad, así como otros comportamientos técnicos y de interfaz de usuario relevantes. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos de esta sección.

3.1. Compatibilidad de API administrada

El entorno de ejecución administrado (basado en Dalvik) es el vehículo principal para las aplicaciones de Android. La interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma Android expuestas a aplicaciones que se ejecutan en el entorno de VM administrado. Las implementaciones de dispositivos DEBEN proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android 2.3 [ Recursos, 4 ].

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

Esta Definición de compatibilidad permite que las implementaciones de dispositivos omitan algunos tipos de hardware para los cuales Android incluye API. En tales casos, las API DEBEN seguir estando presentes y comportarse de forma razonable. Consulte la Sección 7 para conocer los requisitos específicos para este escenario.

3.2. Compatibilidad de API suave

Además de las API administradas de la Sección 3.1, Android también incluye una importante API "suave" solo en tiempo de ejecución, en forma de elementos como intenciones, permisos y aspectos similares de las aplicaciones de Android que no se pueden aplicar en el momento de la compilación de la aplicación. Esta sección detalla las API "soft" y los comportamientos del sistema necesarios para la compatibilidad con Android 2.3. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos presentados en esta sección.

3.2.1. Permisos

Los implementadores de dispositivos DEBEN admitir y hacer cumplir todas las constantes de permisos según lo documentado en la página de referencia de permisos [ Recursos, 5 ]. Tenga en cuenta que la Sección 10 enumera requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de construcción

Las API de Android incluyen una serie de constantes en la clase android.os.Build [ Recursos, 6 ] que están destinadas a describir el dispositivo actual. Para proporcionar valores coherentes y significativos en todas las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que DEBEN ajustarse las implementaciones de dispositivos.

3.2.3. Compatibilidad de intenciones

Android usa Intents para lograr una integración débil entre aplicaciones. Esta sección describe los requisitos relacionados con los patrones de intención que DEBEN ser respetados por las implementaciones de dispositivos. Por "honrado" se entiende que el implementador del dispositivo DEBE proporcionar una Actividad o Servicio de Android que especifique un filtro de Intención coincidente y se vincule e implemente el comportamiento correcto para cada patrón de Intención especificado.

3.2.3.1. Intenciones principales de la aplicación

El proyecto upstream de Android define una serie de aplicaciones principales, como un marcador telefónico, un calendario, una libreta de contactos, un reproductor de música, etc. Los implementadores de dispositivos PUEDEN reemplazar estas aplicaciones con versiones alternativas.

Sin embargo, cualquiera de estas versiones alternativas DEBE respetar los mismos patrones de intención proporcionados por el proyecto inicial. Por ejemplo, si un dispositivo contiene un reproductor de música alternativo, aún debe respetar el patrón de intención emitido por aplicaciones de terceros para elegir una canción.

Las siguientes aplicaciones se consideran aplicaciones principales del sistema Android:

• Reloj de escritorio
• Navegador
• Calendario
• Calculadora
• Contactos
• Correo electrónico
• Galería
• Búsqueda global
• Lanzacohetes
• Música
• Ajustes

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

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

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

3.2.3.2. Anulaciones de intención

Como Android es una plataforma extensible, los implementadores de dispositivos DEBEN permitir que cada patrón de Intención al que se hace referencia en la Sección 3.2.3.1 sea anulado por aplicaciones de terceros. El proyecto de código abierto de Android permite esto de forma predeterminada; Los implementadores de dispositivos NO DEBEN otorgar privilegios especiales al uso de estos patrones de Intent por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros se vinculen y asuman el control de estos patrones. Esta prohibición incluye específicamente, entre otras, la desactivación de la interfaz de usuario "Selector", que permite al usuario seleccionar entre múltiples aplicaciones que manejan el mismo patrón de intención.

3.2.3.3. Espacios de nombres de intención

Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier nuevo patrón de Intención o Intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en el espacio de nombres android.*. Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier nuevo patrón de Intención o Intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete que pertenece a otra organización. Los implementadores de dispositivos NO DEBEN alterar ni ampliar ninguno de los patrones de Intención utilizados por las aplicaciones principales enumeradas en la Sección 3.2.3.1.

Esta prohibición es análoga a la especificada para las clases de lenguaje Java en la Sección 3.6.

3.2.3.4. Intenciones de transmisión

Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos Intents y notificarles sobre cambios en el entorno de hardware o software. Los dispositivos compatibles con Android DEBEN transmitir los Intents de transmisión pública en respuesta a los eventos apropiados del sistema. Las intenciones de transmisión se describen en la documentación del SDK.

3.3. Compatibilidad API nativa

El código administrado que se ejecuta en Dalvik puede llamar al código nativo proporcionado en el archivo .apk de la aplicación como un archivo ELF .so compilado para la arquitectura de hardware del dispositivo adecuada. Como el código nativo depende en gran medida de la tecnología del procesador subyacente, Android define una serie de interfaces binarias de aplicaciones (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 muestra a continuación.

Si la implementación de un dispositivo incluye soporte para una ABI de Android,:

• DEBE incluir soporte para el código que se ejecuta en el entorno administrado para llamar al código nativo, utilizando la semántica estándar de la interfaz nativa de Java (JNI).
• DEBE ser compatible con el código fuente (es decir, compatible con el encabezado) y con los binarios (para ABI) con cada biblioteca requerida en la lista siguiente
• DEBE informar con precisión la interfaz binaria de aplicación (ABI) nativa admitida por el dispositivo, a través de la API android.os.Build.CPU_ABI
• DEBE informar solo aquellas ABI documentadas en la última versión del NDK de Android, en el archivo docs/CPU-ARCH-ABIS.txt
• DEBE construirse utilizando el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android.

Las siguientes API de código nativo DEBEN estar disponibles para aplicaciones que incluyen código nativo:

• libc (biblioteca C)
• libm (biblioteca de matemáticas)
• Soporte mínimo para C++
• interfaz JNI
• liblog (registro de Android)
• libz (compresión Zlib)
• libdl (enlazador dinámico)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libEGL.so (gestión de superficie nativa OpenGL)
• libjnigraphics.so
• libOpenSLES.so (soporte de audio de Open Sound Library)
• libandroid.so (soporte de actividad nativo de Android)
• Soporte para OpenGL, como se describe a continuación

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

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

3.4. Compatibilidad web

Muchos desarrolladores y aplicaciones dependen del comportamiento de la clase android.webkit.WebView [ Recursos, 8 ] para sus interfaces de usuario, por lo que la implementación de WebView debe ser compatible con todas las implementaciones de Android. De manera similar, 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 anterior y DEBEN incluir un navegador moderno compatible con HTML5, como se describe a continuación.

3.4.1. Compatibilidad con WebView

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

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

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

• caché de aplicaciones/operación sin conexión [ Recursos, 10 ]
• la etiqueta <video> [ Recursos, 11 ]
• geolocalización [ Recursos, 12 ]

Además, las implementaciones de dispositivos DEBEN admitir la API de almacenamiento web HTML5/W3C [ Recursos, 13 ], y DEBEN admitir la API IndexedDB HTML5/W3C [ Recursos, 14 ]. Tenga en cuenta que a medida que los organismos de estándares de desarrollo web están haciendo la transición para favorecer IndexedDB sobre el almacenamiento web, se espera que IndexedDB se convierta en un componente requerido en una versión futura de Android.

Las API HTML5, como todas las API de JavaScript, DEBEN estar deshabilitadas de forma predeterminada en un WebView, a menos que el desarrollador las habilite explícitamente a través de las API habituales de Android.

3.4.2. Compatibilidad del navegador

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

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

La aplicación de navegador independiente (ya sea basada en la aplicación de navegador WebKit anterior o en un reemplazo de terceros) DEBE incluir soporte para la mayor cantidad de HTML5 [ Recursos, 9 ] posible. Como mínimo, las implementaciones de dispositivos DEBEN admitir cada una de estas API asociadas con HTML5:

• caché de aplicaciones/operación sin conexión [ Recursos, 10 ]
• la etiqueta <video> [ Recursos, 11 ]
• geolocalización [ Recursos, 12 ]

Además, las implementaciones de dispositivos DEBEN admitir la API de almacenamiento web HTML5/W3C [ Recursos, 13 ], y DEBEN admitir la API IndexedDB HTML5/W3C [ Recursos, 14 ]. Tenga en cuenta que a medida que los organismos de estándares de desarrollo web están haciendo la transición para favorecer IndexedDB sobre el almacenamiento web, se espera que IndexedDB se convierta en un componente requerido en una versión futura de Android.

3.5. Compatibilidad de comportamiento de API

Los comportamientos de cada uno de los tipos de API (administrada, suave, nativa y web) deben ser consistentes con la implementación preferida del proyecto de código abierto de Android [ Recursos, 3 ]. Algunas áreas específicas de compatibilidad son:

• Los dispositivos NO DEBEN cambiar el comportamiento o la semántica de un Intent estándar
• Los dispositivos NO DEBEN alterar el ciclo de vida o la semántica del ciclo de vida de un tipo particular de componente del sistema (como Servicio, Actividad, Proveedor de contenido, etc.)
• Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar

La lista anterior no es exhaustiva. El Compatibility Test Suite (CTS) prueba partes importantes de la plataforma para determinar la compatibilidad del comportamiento, pero no todas. Es responsabilidad del implementador garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android. Por esta razón, los implementadores de dispositivos DEBEN utilizar el código fuente disponible a través del Proyecto de código abierto de Android siempre que sea posible, en lugar de volver a implementar partes importantes del sistema.

3.6. Espacios de nombres API

Android sigue las convenciones de espacio de nombres de paquetes y clases definidas por el lenguaje de programación Java. Para garantizar la compatibilidad con aplicaciones de terceros, los implementadores de dispositivos NO DEBEN realizar modificaciones prohibidas (ver a continuación) en estos espacios de nombres de paquetes:

• Java.*
• javax.*
• sol.*
• androide.*
• com.android.*

Las modificaciones prohibidas incluyen:

• Las implementaciones de dispositivos NO DEBEN modificar las API expuestas públicamente en la plataforma Android cambiando cualquier método o firma de clase, o eliminando clases o campos de clase.
• Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las API, pero dichas modificaciones NO DEBEN afectar el comportamiento declarado ni la firma en lenguaje Java de las API expuestas públicamente.
• Los implementadores de dispositivos NO DEBEN agregar ningún elemento expuesto públicamente (como clases o interfaces, o campos o métodos a clases o interfaces existentes) a las API anteriores.

Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide" como se usa en el código fuente de Android. En otras palabras, los implementadores de dispositivos NO DEBEN exponer nuevas API ni alterar las API existentes en los espacios de nombres mencionados anteriormente. Los implementadores de dispositivos PUEDEN realizar modificaciones solo internas, pero esas modificaciones NO DEBEN publicitarse ni exponerse de otro modo a los desarrolladores.

Los implementadores de dispositivos PUEDEN agregar API personalizadas, pero dichas API NO DEBEN estar en un espacio de nombres que sea propiedad de otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar API al com.google.* o espacio de nombres similar; sólo Google puede hacerlo. De manera similar, Google NO DEBE agregar API a los espacios de nombres de otras empresas. Además, si la implementación de un dispositivo incluye API personalizadas fuera del espacio de nombres estándar de Android, esas API DEBEN estar empaquetadas en una biblioteca compartida de Android para que solo las aplicaciones que las usan explícitamente (a través del mecanismo <uses-library> ) se vean afectadas por el mayor uso de memoria. de dichas API.

Si un implementador de dispositivo propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando nuevas funciones útiles a una API existente o agregando una nueva API), el implementador DEBE visitar source.android.com y comenzar el proceso para contribuir con cambios y código, según la información de ese sitio.

Tenga en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar API en el lenguaje de programación Java; Esta sección simplemente tiene como objetivo reforzar esas convenciones y hacerlas vinculantes mediante su inclusión en esta definición de compatibilidad.

3.7. Compatibilidad de máquinas virtuales

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

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

3.8. Compatibilidad de la interfaz de usuario

La plataforma Android incluye algunas API para desarrolladores que les permiten conectarse a la interfaz de usuario del sistema. Las implementaciones de dispositivos DEBEN incorporar estas API de UI estándar en interfaces de usuario personalizadas que desarrollen, como se explica a continuación.

3.8.1. widgets

Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten a las aplicaciones exponer un "AppWidget" al usuario final [ Recursos, 16 ]. La versión de referencia de código abierto de Android incluye una aplicación de inicio que incluye elementos de interfaz de usuario que permiten al usuario agregar, ver y eliminar AppWidgets de la pantalla de inicio.

Los implementadores de dispositivos PUEDEN sustituir una alternativa al Iniciador de referencia (es decir, la pantalla de inicio). Los lanzadores alternativos DEBEN incluir soporte integrado para AppWidgets y exponer elementos de la interfaz de usuario para agregar, configurar, ver y eliminar AppWidgets directamente dentro del Lanzador. Los lanzadores alternativos PUEDEN omitir estos elementos de la interfaz de usuario; sin embargo, si se omiten, el implementador del dispositivo DEBE proporcionar una aplicación separada accesible desde el Iniciador que permita a los usuarios agregar, configurar, ver y eliminar AppWidgets.

3.8.2. Notificaciones

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

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

3.8.3. Buscar

Android incluye API [ Recursos, 20 ] que permiten a los desarrolladores incorporar búsquedas en sus aplicaciones y exponer los datos de sus aplicaciones en la búsqueda global del sistema. En términos generales, esta funcionalidad consta de una única interfaz de usuario para todo el sistema que permite a los usuarios ingresar consultas, muestra sugerencias a medida que los usuarios escriben y muestra resultados. Las API de Android permiten a los desarrolladores reutilizar esta interfaz para realizar búsquedas dentro de sus propias aplicaciones y les permiten proporcionar resultados a la interfaz de usuario de búsqueda global común.

Las implementaciones de dispositivos DEBEN incluir una interfaz de usuario de búsqueda única, compartida y en todo el sistema capaz de realizar sugerencias en tiempo real en respuesta a las entradas del usuario. Las implementaciones de dispositivos DEBEN implementar las API que permitan a los desarrolladores reutilizar esta interfaz de usuario para realizar búsquedas dentro de sus propias aplicaciones. Las implementaciones de dispositivos DEBEN implementar las API que permiten que las aplicaciones de terceros agreguen sugerencias al cuadro de búsqueda cuando se ejecuta en modo de búsqueda global. Si no hay aplicaciones de terceros instaladas que utilicen esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar resultados y sugerencias del motor de búsqueda web.

Las implementaciones de dispositivos PUEDEN incluir interfaces de usuario de búsqueda alternativas, pero DEBEN incluir un botón de búsqueda dedicado físico o virtual, que se puede usar en cualquier momento dentro de cualquier aplicación para invocar el marco de búsqueda, con el comportamiento previsto en la documentación de la API.

3.8.4. Brindis

Las aplicaciones pueden usar la API "Toast" (definida en [ Recursos, 21 ]) para mostrar cadenas cortas no modales al usuario final, que desaparecen después de un breve período de tiempo. Las implementaciones de dispositivos DEBEN mostrar los brindis de las aplicaciones a los usuarios finales de alguna manera de alta visibilidad.

3.8.5. Fondos de pantalla vivos

Android define un tipo de componente y su correspondiente API y ciclo de vida que permite a las aplicaciones exponer uno o más "Live Wallpapers" al usuario final [ Recursos, 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.

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

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

4. Compatibilidad del embalaje de la aplicación

Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android generados por la herramienta "aapt" incluida en el SDK oficial de Android [ Recursos, 23 ].

Las implementaciones de dispositivos NO DEBEN extender los formatos .apk [ Recursos, 24 ], Android Manifest [ Recursos, 25 ] o Dalvik bytecode [ Recursos, 15 ] de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles. . Los implementadores de dispositivos DEBEN utilizar la implementación ascendente de referencia de Dalvik y el sistema de gestión de paquetes de la implementación de referencia.

5. Compatibilidad multimedia

Las implementaciones de dispositivos DEBEN implementar completamente todas las API multimedia. Las implementaciones de dispositivos DEBEN incluir soporte para todos los códecs multimedia que se describen a continuación y DEBEN cumplir con las pautas de procesamiento de sonido que se describen a continuación. Las implementaciones de dispositivos DEBEN incluir al menos una forma de salida de audio, como altavoces, conector para auriculares, conexión de altavoz externo, etc.

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 de Android preferida del Proyecto de código abierto de Android.

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

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

5.1.1. Decodificadores de medios

Las implementaciones de dispositivos DEBEN incluir una implementación de un decodificador para cada códec y formato descrito en la siguiente tabla. Tenga en cuenta que los decodificadores para cada uno de estos tipos de medios los proporciona el proyecto de código abierto de Android.

5.1.2. Codificadores de medios

Las implementaciones de dispositivos DEBEN incluir codificadores para tantos formatos de medios enumerados en la Sección 5.1.1. como sea posible. Sin embargo, algunos codificadores no tienen sentido para dispositivos que carecen de cierto hardware opcional; Por ejemplo, un codificador de vídeo H.263 no tiene sentido si el dispositivo no tiene cámaras. Por lo tanto, las implementaciones de dispositivos DEBEN implementar codificadores de medios de acuerdo con las condiciones descritas en la siguiente tabla.

Consulte la Sección 7 para obtener detalles sobre las condiciones bajo las cuales las implementaciones de dispositivos pueden omitir hardware.

Además de los codificadores enumerados anteriormente, las implementaciones de dispositivos DEBEN incluir un codificador H.264. Tenga en cuenta que está previsto que la Definición de compatibilidad para una versión futura cambie este requisito a "DEBE". Es decir, la codificación H.264 es opcional en Android 2.3 pero será requerida en una versión futura. Se recomienda encarecidamente que los dispositivos nuevos y existentes que ejecutan Android 2.3 cumplan con este requisito en Android 2.3 , o no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

5.2. Grabación de audio

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

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

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

5.3. Latencia de audio

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

Para los efectos de esta sección:

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

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

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

Nota: si bien los requisitos descritos anteriormente se indican como "DEBERÍAN" para Android 2.3, se planea que la Definición de compatibilidad para una versión futura los cambie a "DEBE". Es decir, estos requisitos son opcionales en Android 2.3 pero serán requeridos en una versión futura. Se recomienda encarecidamente que los dispositivos nuevos y existentes que ejecutan Android 2.3 cumplan con estos requisitos en Android 2.3 , o no podrán lograr 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 soporte para audio de baja latencia, al informar la característica "android.hardware.audio.low-latency" a través de 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 soporte para audio de baja latencia.

6. Compatibilidad de herramientas de desarrollo

Las implementaciones de dispositivos DEBEN ser compatibles con las herramientas de desarrollo de Android proporcionadas en el SDK de Android. Específicamente, los dispositivos compatibles con Android DEBEN ser compatibles con:

• Puente de depuración de Android (conocido como adb) [ Recursos, 23 ]
  Las implementaciones de dispositivos DEBEN admitir todas las funciones adb como se documenta en el SDK de Android. El demonio adb del lado del dispositivo DEBE estar inactivo de forma predeterminada, pero DEBE haber un mecanismo accesible para el usuario para activar el Puente de depuración de Android.
• Servicio Dalvik Debug Monitor (conocido como ddms) [ Recursos, 23 ]
  Las implementaciones de dispositivos DEBEN admitir todas las funciones ddms como se documenta en el SDK de Android. Como ddms usa adb , la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.
• Mono [ Recursos, 26 ]
  Las implementaciones de dispositivos DEBEN incluir el marco Monkey y ponerlo a disposición de las aplicaciones.

La mayoría de los sistemas basados ​​en Linux y los sistemas Apple Macintosh reconocen los dispositivos Android utilizando las herramientas estándar del SDK de Android, sin soporte adicional; sin embargo, los sistemas Microsoft Windows normalmente requieren un controlador para los nuevos dispositivos Android. (Por ejemplo, las nuevas ID de proveedores y, a veces, las nuevas ID de dispositivos requieren controladores USB personalizados para sistemas Windows). Si la herramienta adb no reconoce la implementación de un 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 a el dispositivo utilizando el protocolo adb . Estos controladores DEBEN proporcionarse para Windows XP, Windows Vista y Windows 7, tanto en versiones de 32 como de 64 bits.

7. Compatibilidad de hardware

Android está destinado a permitir a los implementadores de dispositivos crear configuraciones y factores de forma innovadores. Al mismo tiempo, los desarrolladores de Android escriben aplicaciones innovadoras que se basan en los diversos hardware y funciones disponibles a través de las API de Android. Los requisitos de esta sección logran un equilibrio entre las innovaciones disponibles para los implementadores de dispositivos y las necesidades de los desarrolladores de garantizar que sus aplicaciones solo estén disponibles para dispositivos en los que se ejecutarán correctamente.

Si un dispositivo incluye un componente de hardware particular que tiene una API correspondiente para desarrolladores externos, la implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android. Si una API en el SDK interactúa con un componente de hardware que se declara opcional y la implementación del dispositivo no posee ese componente:

• Las definiciones de clase completas (según lo documentado por el SDK) para las API del componente DEBEN estar presentes
• Los comportamientos de la API DEBEN implementarse como no operativos de alguna manera razonable.
• Los métodos API DEBEN devolver valores nulos cuando lo permita la documentación del SDK
• Los métodos API DEBEN devolver implementaciones no operativas de clases donde la documentación del SDK no permite valores nulos
• Los métodos API NO DEBEN generar excepciones no documentadas en la documentación del SDK

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

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

7.1. Pantalla y gráficos

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

7.1.1. Configuraciones de pantalla

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

• Las pantallas DEBEN tener al menos 2,5 pulgadas de tamaño diagonal físico.
• la densidad DEBE ser de al menos 100 ppp
• la relación de aspecto DEBE estar entre 1,333 (4:3) y 1,779 (16:9)
• la tecnología de visualización utilizada consta de píxeles cuadrados

Las implementaciones de dispositivos con una pantalla que cumple con los requisitos anteriores se consideran compatibles y no es necesaria ninguna acción adicional. La implementación del marco de trabajo de Android calcula automáticamente las características de visualización, como el tamaño de la pantalla y el tamaño de la pantalla. En la mayoría de los casos, las decisiones marco son las correctas. Si se utilizan los cálculos del marco predeterminado, no es necesaria ninguna acción adicional. Los implementadores de dispositivos que deseen cambiar los valores predeterminados o utilizar una pantalla que no cumpla con los requisitos anteriores DEBEN comunicarse con el Equipo de compatibilidad de Android para obtener orientación, según lo dispuesto en la Sección 12.

Las unidades utilizadas por 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.
• "ppp" (que significa "puntos por pulgada") es el número de píxeles abarcados por un intervalo lineal horizontal o vertical de 1". Cuando se enumeran valores de ppp, tanto los ppp horizontales como los verticales deben estar dentro del rango.
• "Relación de aspecto" es la relación entre la dimensión más larga de la pantalla y la dimensión más corta. Por ejemplo, una pantalla de 480x854 píxeles sería 854/480 = 1,779, o aproximadamente "16:9".

Las implementaciones de dispositivos DEBEN utilizar únicamente pantallas con una única configuración estática. Es decir, las implementaciones de dispositivos NO DEBEN habilitar múltiples configuraciones de pantalla. Por ejemplo, dado que un televisor típico admite múltiples resoluciones, como 1080p, 720p, etc., esta configuración no es compatible con Android 2.3. (Sin embargo, se está investigando la compatibilidad con dichas configuraciones y se está planificando para una versión futura de Android).

7.1.2. Mostrar métricas

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

7.1.3. Soporte de pantalla declarado

Opcionalmente, 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 la pantalla

Los dispositivos compatibles DEBEN admitir la orientación dinámica de las aplicaciones en orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una orientación de pantalla específica. Las implementaciones de dispositivos PUEDEN seleccionar la orientación vertical u horizontal como opción predeterminada. Los dispositivos que no se pueden rotar físicamente PUEDEN cumplir con este requisito mediante aplicaciones "buzón" que solicitan el modo vertical, utilizando solo una parte de la pantalla disponible.

Los dispositivos DEBEN informar el valor correcto para la orientación actual del dispositivo, siempre que se realice una consulta a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() u otras API.

7.1.5. Aceleración de gráficos 3D

Las implementaciones de dispositivos DEBEN ser compatibles con OpenGL ES 1.0, según lo exigen las API de Android 2.3. Para los dispositivos que carecen de 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 Open GL ES 2.0; sin embargo, si se omite la compatibilidad, las implementaciones de dispositivos NO DEBEN informar que admiten OpenGL ES 2.0. Específicamente, si las implementaciones de un dispositivo carecen de compatibilidad con OpenGL ES 2.0:

• las API administradas (como a través del método GLES10.getString() ) NO DEBEN informar soporte para OpenGL ES 2.0
• las API OpenGL nativas de C/C++ (es decir, aquellas disponibles para aplicaciones 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 la implementación de un dispositivo es compatible con OpenGL ES 2.0, DEBE informar con precisión esa compatibilidad a través de las rutas que se acaban de enumerar.

Tenga en cuenta que Android 2.3 incluye soporte para que las aplicaciones especifiquen opcionalmente que requieren formatos de compresión de textura OpenGL específicos. Estos formatos suelen ser específicos del proveedor. Android 2.3 no requiere implementaciones de dispositivos para implementar ningún formato de compresión de textura específico. Sin embargo, DEBEN informar con precisión cualquier formato de compresión de texturas que admitan, a través del método getString() en la API OpenGL.

7.2. Los dispositivos de entrada

Android 2.3 admite varias modalidades de entrada del usuario. Las implementaciones de dispositivos DEBEN admitir dispositivos de entrada de usuario según lo dispuesto en esta sección.

7.2.1. Teclado

Implementaciones de dispositivos:

• DEBE incluir soporte para el marco de administración de entrada (que permite a los desarrolladores externos crear motores de administración de entrada, es decir, teclado virtual) como se detalla en desarrollador.android.com
• DEBE proporcionar al menos una implementación de teclado virtual (independientemente de si hay un teclado físico presente)
• PUEDE incluir implementaciones adicionales de teclado virtual
• PUEDE incluir un teclado de hardware
• NO DEBE incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.keyboard [ Recursos, 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 trackball, un d-pad o una rueda)
• DEBE informar el valor correcto para android.content.res.Configuration.navigation [ Recursos, 30 ]
• DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición de texto, compatible con los motores de gestión de entrada. El código fuente abierto de Android incluye un mecanismo de selección adecuado para su uso con dispositivos que carecen de entradas de navegación no táctiles.

7.2.3. Teclas de navegación

Las funciones Inicio, Menú y Atrás son esenciales para el paradigma de navegación de Android. Las implementaciones de dispositivos DEBEN poner estas funciones a disposición del usuario en todo momento, independientemente del estado de la aplicación. Estas funciones DEBEN implementarse mediante botones dedicados. PUEDEN implementarse mediante software, gestos, panel táctil, etc., pero de ser así DEBEN estar siempre accesibles y no oscurecer ni interferir con el área de visualización de la aplicación disponible.

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

7.2.4. Entrada de pantalla táctil

Implementaciones de dispositivos:

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

7.3. Sensores

Android 2.3 incluye API para acceder a una variedad de tipos de sensores. Las implementaciones de dispositivos generalmente PUEDEN omitir estos sensores, según lo dispuesto en las siguientes subsecciones. Si un dispositivo incluye un tipo de sensor 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, implementaciones de dispositivos:

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

La lista anterior no es exhaustiva; el comportamiento documentado del SDK de Android debe considerarse autorizado.

Algunos tipos de sensores son sintéticos, lo que significa que pueden derivarse de datos proporcionados por uno o más sensores. (Los ejemplos 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 prerrequisitos.

Las API de Android 2.3 introducen una noción de sensor de "transmisión", que es uno que devuelve datos continuamente, en lugar de solo cuando los datos cambian. Las implementaciones de dispositivos DEBEN proporcionar continuamente muestras de datos periódicas para cualquier API indicada en la documentación del SDK de Android 2.3 como 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:

• DEBE poder entregar eventos a 50 Hz o más
• DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en las API de Android (consulte [ Recursos, 31 ])
• DEBE ser capaz de medir desde caída libre hasta el doble de gravedad (2 g) o más en cualquier vector tridimensional
• DEBE tener 8 bits de precisión o más
• DEBE tener una desviación estándar no mayor a 0,05 m/s^2

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:

• Debe poder entregar eventos a 10 Hz o más
• Debe cumplir con el sistema de coordenadas del sensor Android como se detalla en las API de Android (ver [ Recursos, 31 ]).
• Debe ser capaz de probar una gama de fuerzas de campo adecuadas para cubrir el campo geomagnético
• Debe tener 8 bits de precisión o más
• Debe tener una desviación estándar no más de 0.5 µt

7.3.3. GPS

Las implementaciones de dispositivos deben incluir un receptor GPS. Si una implementación de un dispositivo incluye un receptor GPS, debe incluir alguna forma de técnica de "GPS asistido" para minimizar el tiempo de bloqueo del GPS.

7.3.4. Giroscopio

Las implementaciones del dispositivo deben incluir un giroscopio (es decir, el 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 un dispositivo incluye un giroscopio, TI:

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

7.3.5. Barómetro

Las implementaciones del dispositivo pueden incluir un barómetro (es decir, sensor de presión de aire ambiente). Si una implementación de un dispositivo incluye un barómetro, TI:

• Debe poder entregar eventos a 5 Hz o más
• Debe tener una precisión adecuada para habilitar la altitud de estimación

7.3.7. Termómetro

Las implementaciones del dispositivo pueden, pero no deben incluir un termómetro (es decir, sensor de temperatura). Si la implementación de un dispositivo incluye un termómetro, debe medir la temperatura de la CPU del dispositivo. No debe medir ninguna otra temperatura. (Tenga en cuenta que este tipo de sensor está en desuso en las API de Android 2.3).

7.3.7. Fotómetro

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

7.3.8. Sensor de proximidad

Las implementaciones de dispositivos pueden incluir un sensor de proximidad. Si una 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 la intención principal de este tipo de sensor es detectar un teléfono en uso por parte del usuario. Si una 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 una 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 la red y el acceso a Internet son características vitales de Android. Mientras tanto, la interacción de dispositivo a dispositivo agrega un valor significativo a los dispositivos y aplicaciones de Android. Las implementaciones de dispositivos deben cumplir con los requisitos de conectividad de datos en esta sección.

7.4.1. Telefonía

"Telefonía" como lo utilizó las API de Android 2.3 y este documento se refiere específicamente al hardware relacionado con la colocació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, se consideran para Android 2.3 independientemente de cualquier conectividad de datos que pueda implementarse utilizando la misma red. En otras palabras, la funcionalidad y las API de Android se refieren específicamente a llamadas de voz y SMS; Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas o enviar/recibir mensajes SMS no deben informar la función "Android.hardware.telephony" o cualquier subfreencia, independientemente de si usan una red celular para la conectividad de datos.

Android 2.3 se puede usar 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 un dispositivo incluye la telefonía GSM o CDMA, debe implementar el soporte completo para la API para esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía deben implementar las API completas como NO-OPS.

7.4.2. IEEE 802.11 (Wi-Fi)

Las implementaciones de dispositivos Android 2.3 deben incluir soporte para una o más formas de 802.11 (b/g/a/n, etc.) Si una implementación de un dispositivo incluye soporte para 802.11, debe implementar la API de Android correspondiente.

7.4.3. Bluetooth

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

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

7.4.4. Comunicaciones de campo cercano

Las implementaciones de dispositivos deben incluir un transceptor y hardware relacionado para comunicaciones de campo cercano (NFC). Si una implementación de un dispositivo incluye hardware NFC, entonces:

• Debe informar la función Android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature() . [ Recursos, 27 ]
• Debe ser capaz de leer y escribir mensajes NDEF a través de los siguientes estándares de NFC:
  • Debe ser capaz de actuar como un lector/escritor del foro de la NFC (según lo definido por la especificación técnica del foro NFC NFCFORUM-TS-DIGITALPROTOCOL-1.0) a través de los siguientes estándares NFC:
    • NFCA (ISO14443-3a)
    • NFCB (ISO14443-3b)
    • NFCF (JIS 6319-4)
    • NFCV (ISO 15693)
    • Isodep (ISO 14443-4)
    • NFC Forum Tag Tipos 1, 2, 3, 4 (definido por el foro NFC)
  • Debe ser capaz de transmitir y recibir datos a través de los siguientes estándares y protocolos de igual a igual:
    • ISO 18092
    • LLCP 1.0 (definido por el foro NFC)
    • SDP 1.0 (definido por el foro NFC)
    • Protocolo NDEF Push [ Recursos, 33 ]
  • Debe escanear todas las tecnologías compatibles mientras está en el modo de descubrimiento NFC.
  • Debe estar en modo de descubrimiento NFC mientras el dispositivo está despierto con la pantalla activa.

  (Tenga en cuenta que los enlaces disponibles públicamente no están disponibles para las especificaciones del foro JIS, ISO y NFC citadas anteriormente).

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

  • Mifare Classic (NXP MF1S503X [ Recursos, 34 ], MF1S703X [ Recursos, 35 ])
  • Mifare Ultralight (NXP MF0ICU1 [ Recursos, 36 ], MF0ICU2 [ Recursos, 37 ])
  • NDEF en Mifare Classic (NXP AN130511 [ Recursos, 38 ], AN130411 [ Recursos, 39 ])

  Tenga en cuenta que Android 2.3.3 incluye API para estos tipos de MIFARE. Si una implementación de un dispositivo admite MIFARE, TI:

  • Debe implementar las API de Android correspondientes según lo documente el SDK de Android
  • Debe informar la función com.nxp.mifare desde el método android.content.pm.PackageManager.hasSystemFeature() . [ Recursos, 27 ] Tenga en cuenta que esta no es una característica de Android estándar, y como tal no aparece como una constante en la clase PackageManager .
  • No debe implementar las API de Android correspondientes ni informar la función Com.NXP.Mifare a menos que también implementa el soporte general de NFC como se describe en esta sección

  Si una implementación de un 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 Android 2.3 NFC como un no-op.

  Como las clases de 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 API incluso si no incluyen soporte para NFC o declaran la función Android.hardware.nfc.

  7.4.5. Capacidad mínima de red

  Las implementaciones de dispositivos deben incluir soporte para una o más formas de redes de datos. Específicamente, las implementaciones del dispositivo deben incluir soporte para al menos un estándar de datos capaz de 200 kbit/seg o más. Ejemplos de tecnologías que satisfacen este requisito incluyen Edge, HSPA, EV-DO, 802.11g, Ethernet, etc.

  Las implementaciones de dispositivos donde un estándar de red física (como Ethernet) es la conexión de datos primario también debe incluir soporte para al menos un estándar de datos inalámbricos comunes, como 802.11 (WiFi).

  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 trasera, y pueden incluir una cámara frontal. Una cámara trasera es una cámara ubicada en el costado del dispositivo frente a la pantalla; Es decir, imágenes de escenas en el lado más alejado del dispositivo, como una cámara tradicional. Una cámara frontal es una cámara ubicada en el mismo lado del dispositivo que la pantalla; Es decir, una cámara se usa típicamente para obtener imágenes del usuario, como para videoconferencias y aplicaciones similares.

  7.5.1. Cámara trasera

  Las implementaciones de dispositivos deben incluir una cámara trasera. Si una implementación de un dispositivo incluye una cámara trasera, TI: TI:

  • Debe tener una resolución de al menos 2 megapíxeles
  • Debe tener un enfoque automático de hardware o un enfoque automático de software implementado en el controlador de la cámara (transparente al software de aplicación)
  • Puede tener hardware de enfoque fijo o EDOF (profundidad de campo extendida)
  • Puede incluir un flash. Si la cámara incluye un flash, la lámpara de flash no debe encenderse mientras un android.hardware.camera.previewCallback instancia se ha registrado en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de A de un Camera.Parameters Objeto de parámetros. Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema incorporada 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 una implementación de un dispositivo incluye una cámara frontal, TI:

  • Debe tener una resolución de al menos VGA (es decir, 640x480 píxeles)
  • No debe usar una cámara frontal como el valor predeterminado para la API de la cámara. Es decir, la API de la cámara en Android 2.3 tiene un soporte específico para las cámaras frontales, y las implementaciones de dispositivos no deben configurar la API para tratar una cámara frontal como la cámara trasera predeterminada, incluso si es la única cámara en el dispositivo.
  • Puede incluir características (como enfoque automático, flash, etc.) disponibles para las cámaras orientadas al trasero como se describe en la Sección 7.5.1.
  • Debe reflejar horizontalmente (es decir, espejo) la transmisión que se muestra por una aplicación en un CamerApreview, de la siguiente manera:
  • Si la implementación del dispositivo es capaz de ser girada por el usuario (como automáticamente a través de un acelerómetro o manualmente 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 ha solicitado explícitamente que la pantalla de la cámara se gire a través de una llamada al android.hardware.Camera.setDisplayOrientation() [ Recursos, 40 ] Método, la vista previa de la cámara debe reflejarse 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.
  • Debe reflejar los datos de la imagen devueltos a cualquier manipulador de devolución de llamada de la cámara "postview", de la misma manera que la transmisión de imagen de vista previa de la cámara. (Si la implementación del dispositivo no admite devoluciones de llamada posterior a la vista, este requisito obviamente no se aplica).
  • No debe reflejar las transmisiones finales de imagen o video capturadas que se devuelven a las devoluciones de llamada de la aplicación o comprometidas con el almacenamiento de medios

  7.5.3. Comportamiento de la API de la cámara

  Las implementaciones de dispositivos deben implementar los siguientes comportamientos para las API relacionadas con la cámara, para cámaras orientadas al frontal y hacia atrás:

  1. Si una aplicación nunca ha llamado android.hardware.camera.parameters.setPreviewFormat (int), entonces el dispositivo debe usar android.hardware.pixelformat.ycbcr_420_sp para los datos de vista previa proporcionadas a las devoluciones de llamada de la aplicación.
  2. Si una aplicación registra un método 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 [] pasan a OnpreviewFrame () deben estar más 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 (según lo denotado por android.graphics.ImageFormat.YV12 Constant) para las vistas previas de la cámara para cámaras orientadas al frontal y hacia atrás. Tenga en cuenta que la definición de compatibilidad para una versión futura está prevista para cambiar este requisito a "imprescindible". Es decir, el soporte YV12 es opcional en Android 2.3, pero será requerido por una versión futura. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 2.3 para cumplir con este requisito en Android 2.3 , o no podrán alcanzar la compatibilidad de Android cuando se actualice a la versión futura.

  Las implementaciones de dispositivos deben implementar la API de cámara completa incluida en la documentación SDK de Android 2.3 [ recursos, 41 ]), independientemente de si el dispositivo incluye enfoque automático de hardware u otras capacidades. Por ejemplo, las cámaras que carecen de enfoque automático aún deben llamar a cualquier android.hardware.Camera.AutoFocusCallback registrado.camera.autofocuscallback instancias (aunque esto no tiene relevancia para una cámara que no es de autococo). Tenga 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 API aún deben ser "falsificadas" como se describe.

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

  7.5.4. Orientación de la cámara

  Tanto las cámaras orientadas al frontal como en la parte trasera, si están presentes, deben orientarse para 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 mantiene en la orientación del paisaje, las cámaras deben capturar imágenes en la orientación del paisaje. Esto se aplica independientemente de la orientación natural del dispositivo; Es decir, se aplica a los dispositivos del paisaje-primario, así como a los dispositivos de retrato.

  7.6. Memoria y almacenamiento

  La función fundamental de Android 2.3 es ejecutar aplicaciones. Implementaciones de dispositivos Los requisitos de esta sección, para garantizar un almacenamiento y 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 usuarios. El 128 MB debe ser adicional a cualquier memoria dedicada a componentes de hardware como radio, memoria, etc., eso no está 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.

  Más allá 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. Tenga en cuenta que este requisito más alto se planea convertirse en un mínimo difícil en una versión futura de Android. Se recomienda encarecidamente a las implementaciones de dispositivos a cumplir con estos requisitos ahora, o de lo contrario pueden no ser elegibles para la compatibilidad para una versión futura de Android.

  Las API de Android incluyen un administrador de descarga 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 de tamaño o más grande.

  7.6.2. Almacenamiento compartido de aplicaciones

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

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

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

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

  Independientemente de la forma de almacenamiento compartido utilizado, las implementaciones de dispositivos deben proporcionar algún mecanismo para acceder al contenido de almacenamiento compartido desde una computadora host, como el almacenamiento de masa USB o el protocolo de transferencia de medios.

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

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

  7.7. USB

  Implementaciones de dispositivos:

  • Debe implementar un cliente USB, conectable a un host USB con un puerto USB-A estándar
  • Debe implementar el puente de depuración de Android sobre USB (como se describe en la Sección 7)
  • Debe implementar 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 si es 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 simplemente se ejecuten correctamente en el dispositivo, sino que lo hacen con un rendimiento razonable y una buena experiencia de usuario en general. Las implementaciones del dispositivo deben cumplir con las métricas clave de rendimiento de un dispositivo compatible de Android 2.3 definido en la tabla a continuación:

  Métrico	Umbral de rendimiento	Comentarios
  Tiempo de lanzamiento de la aplicación	Las siguientes aplicaciones deben lanzarse dentro del tiempo especificado. Navegador: menos de 1300 ms MMS/SMS: menos de 700 ms ALARMCLOCK: Menos de 650 ms	El tiempo de lanzamiento se mide como el tiempo total para completar la carga de la actividad predeterminada para la aplicación, incluido el tiempo que lleva iniciar el proceso de Linux, cargar el paquete de Android en la VM Dalvik y llamar a OnCreate.
  Aplicaciones simultáneas	Cuando se han lanzado múltiples aplicaciones, el relanzamiento de una aplicación que ya está en funcionamiento después de que se haya lanzado debe tomar menos que el tiempo de lanzamiento original.

  9. Compatibilidad del modelo de seguridad

  Las implementaciones de dispositivos deben implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma Android como se define en el documento de referencia de seguridad y permisos en las API [ recursos, 42 ] en la documentación del desarrollador de Android. Las implementaciones de dispositivos deben admitir la instalación de aplicaciones autofirmadas sin requerir ningún permiso/certificado adicionales de terceros/autoridades. Específicamente, los dispositivos compatibles deben admitir los mecanismos de seguridad descritos en las siguientes subsecciones.

  9.1. Permisos

  Las implementaciones de dispositivos deben admitir el modelo de permisos de Android como se define en la documentación del desarrollador de Android [ recursos, 42 ]. Específicamente, las implementaciones deben hacer cumplir cada permiso definido como se describe en la documentación SDK; No se pueden omitir, alterar o ignorar los permisos. Las implementaciones pueden agregar permisos adicionales, siempre que las nuevas cadenas de ID de permiso no estén en el espacio de nombres de Android.*

  9.2. UID y aislamiento de procesos

  Las implementaciones de dispositivos deben admitir el modelo Sandbox de la aplicación Android, en el que cada aplicación se ejecuta como un UID de estilo UNIX único y en un proceso separado. Las implementaciones de dispositivos deben admitir la ejecución de múltiples aplicaciones como la misma ID de usuario de Linux, siempre que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de seguridad y permisos [ Recursos, 42 ].

  9.3. Permisos del sistema de archivos

  Las implementaciones del dispositivo 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 tiempo de ejecución que ejecutan aplicaciones utilizando algún otro software o tecnología que la máquina virtual Dalvik o el código nativo. Sin embargo, tales entornos de ejecución alternativos no deben comprometer el modelo de seguridad de Android o la seguridad de las aplicaciones de Android instaladas, como se describe en esta sección.

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

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

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

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

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

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

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

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

  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 del dispositivo deben aprobar todas las pruebas descritas en esta sección.

  Sin embargo, tenga en cuenta que ningún paquete de prueba de software es completamente completo. Por esta razón, se recomienda a los implementadores de dispositivos que se recomiendan con el número mínimo de cambios como sea posible a la referencia y la implementación 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 reelaboración y posibles actualizaciones de dispositivos.

  10.1. Conjunto de pruebas de compatibilidad

  Las implementaciones de dispositivos deben pasar el Suite de prueba de compatibilidad de Android (CTS) [ recursos, 2 ] disponible en el proyecto de código abierto de Android, utilizando el software de envío final en el dispositivo. Además, los implementadores de dispositivos deben usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible, y deben garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier reimplementación de partes del código fuente de referencia.

  El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, el CTS puede contener errores. El CTS se verificará independientemente de esta definición de compatibilidad, y se pueden publicar múltiples revisiones del CTS para Android 2.3. Las implementaciones de dispositivos deben pasar la última versión CTS disponible en el momento en que se completa el software del dispositivo.

  Debe pasar la versión más reciente del suite de prueba de compatibilidad de Android (CTS) disponible en el momento del 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, de los componentes descritos en este documento.

  10.2. Verificador CTS

  Las implementaciones del dispositivo deben ejecutar correctamente todos los casos aplicables en el verificador CTS. El verificador CTS se incluye con el conjunto de pruebas de compatibilidad, y está destinado a ser ejecutado por un operador humano para probar la funcionalidad que no puede ser probada por un sistema automatizado, como el funcionamiento correcto de una cámara y los sensores.

  El verificador CTS tiene pruebas para muchos tipos de hardware, incluido algunos hardware que es opcional. Las implementaciones de dispositivos deben pasar todas las pruebas de hardware que poseen; Por ejemplo, si un dispositivo posee un acelerómetro, debe ejecutar correctamente el caso de prueba del acelerómetro en el verificador CTS. Los casos de prueba para las características observadas como opcionales por este documento de definición de compatibilidad pueden omitirse u omitirse.

  Cada dispositivo y cada construcción deben ejecutar correctamente el verificador CTS, como se señaló anteriormente. Sin embargo, dado que muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten explícitamente el verificador CTS en compilaciones que difieren solo de manera trivial. Específicamente, las implementaciones de dispositivos que difieren de una implementación que ha aprobado el verfier de CTS solo por el conjunto de locales incluidos, marca, etc., pueden omitir la prueba del verificador CTS.

  10.3. Aplicaciones de referencia

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

  • Las aplicaciones "Aplicaciones para Android" [ Recursos, 43 ].
  • REplica Island (disponible en el mercado de Android; solo requerido para implementaciones de dispositivos que admiten con OpenGL ES 2.0)

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

  11. Software actualizable

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

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

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

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

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

  12. Contáctenos

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

  Apéndice A: Procedimiento de prueba de Bluetooth

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

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

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

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

  Configuración e instalación

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

  Pruebe el control de Bluetooth por aplicaciones

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

  Emparejamiento de pruebas y comunicación

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

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

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

  Realicias de prueba

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

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