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

Para ser considerada compatible con Android 4.2, 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.

2. Recursos

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

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

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

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

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

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

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

Representación de script: http://developer.android.com/guide/topics/graphics/renderscript.html

Aceleración de hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html

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

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

Capacidades HTML5 sin conexión: http://dev.w3.org/html5/spec/Overview.html#offline

Etiqueta de vídeo HTML5: http://dev.w3.org/html5/spec/Overview.html#video

API de geolocalización HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API de base de datos web HTML5/W3C: http://www.w3.org/TR/webdatabase/

API HTML5/W3C IndexedDB: http://www.w3.org/TR/IndexedDB/

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

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

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

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

Guía de estilo de iconos de la barra de estado: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

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

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

Temas: http://developer.android.com/guide/topics/ui/themes.html

Clase R.style: http://developer.android.com/reference/android/R.style.html

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

Administración de dispositivos Android: http://developer.android.com/guide/topics/admin/device-admin.html

Referencia de DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

API del servicio de accesibilidad de Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

API de accesibilidad de Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

Proyecto Eyes Free: http://code.google.com/p/eyes-free

API de texto a voz: http://developer.android.com/reference/android/speech/tts/package-summary.html

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

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

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

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

Clase Android android.content.pm.PackageManager y lista de características de hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html

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

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

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

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

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

Protocolo push NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

API de orientación de la cámara: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

Cámara: http://developer.android.com/reference/android/hardware/Camera.html

Accesorios abiertos de Android: http://developer.android.com/guide/topics/usb/accessory.html

API de host USB: http://developer.android.com/guide/topics/usb/host.html

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

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

Administrador de descargas de Android: http://developer.android.com/reference/android/app/DownloadManager.html

Transferencia de archivos de Android: http://www.android.com/filetransfer

Formatos multimedia de Android: http://developer.android.com/guide/appendix/media-formats.html

Protocolo preliminar de transmisión en vivo HTTP: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

Traspaso de conexión NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover

Emparejamiento simple y seguro de Bluetooth mediante NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

API de multidifusión Wifi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

Asistencia de acción: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

Especificación de carga USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html

Audio USB de Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Configuración para compartir NFC de Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wifi Directo (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

Widget de bloqueo y pantalla de inicio: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

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

Referencia de almacenamiento externo: https://source.android.com/docs/core/storage

API de almacenamiento externo: http://developer.android.com/reference/android/os/Environment.html

Código corto de SMS: http://en.wikipedia.org/wiki/Short_code

Cliente de control remoto multimedia: http://developer.android.com/reference/android/media/RemoteControlClient.html

Administrador de pantalla: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

Sueños: http://developer.android.com/reference/android/service/dreams/DreamService.html

Configuraciones relacionadas con el desarrollo de aplicaciones de Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

Cámara: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

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

3.software

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 4.2 [ Recursos, 4 ].

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

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.

3.2.1. Permisos

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

3.2.2. Parámetros de construcción

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

Parámetro	Comentarios
android.os.Build.VERSION.RELEASE	La versión del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en [ Recursos, 7 ].
android.os.Build.VERSIÓN.SDK	La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 4.2, este campo DEBE tener el valor entero 17.
android.os.Build.VERSION.SDK_INT	La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 4.2, este campo DEBE tener el valor entero 17.
android.os.Build.VERSIÓN.INCREMENTAL	Un valor elegido por el implementador del dispositivo que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO DEBE reutilizarse para diferentes compilaciones disponibles para los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de fuente se utilizó para generar la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.BOARD	Un valor elegido por el implementador del dispositivo que identifica el hardware interno específico utilizado por el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.BRAND	Un valor elegido por el implementador del dispositivo que identifica el nombre de la empresa, organización, individuo, etc. que produjo el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar el OEM y/o el proveedor que vendió el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.CPU_ABI	El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Consulte la Sección 3.3: Compatibilidad de API nativa .
android.os.Build.CPU_ABI2	El nombre del segundo conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Consulte la Sección 3.3: Compatibilidad de API nativa .
android.os.Build.DEVICE	Un valor elegido por el implementador del dispositivo que identifica la configuración o revisión específica del cuerpo (a veces llamado "diseño industrial") del dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.FINGERPRINT	Una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Por ejemplo: `acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys` La huella digital NO DEBE incluir espacios en blanco. Si otros campos incluidos en la plantilla anterior tienen espacios en blanco, DEBEN reemplazarse en la huella digital de compilación con otro carácter, como el carácter de guión bajo ("_"). El valor de este campo DEBE poder codificarse como ASCII de 7 bits.
android.os.Build.HARDWARE	El nombre del hardware (de la línea de comando del kernel o /proc). DEBE ser razonablemente legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.HOST	Una cadena que identifica de forma única el host en el que se creó la compilación, en formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.ID	Un identificador elegido por el implementador del dispositivo para hacer referencia a una versión específica, en formato legible por humanos. Este campo puede ser el mismo que android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.FABRICANTE	El nombre comercial del fabricante de equipos originales (OEM) del producto. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.MODEL	Un valor elegido por el implementador del dispositivo que contiene el nombre del dispositivo tal como lo conoce el usuario final. Este DEBE ser el mismo nombre con el que se comercializa y vende el dispositivo a los usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
android.os.Build.PRODUCTO	Un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre en código del producto (SKU). DEBE ser legible por humanos, pero no necesariamente está destinado a ser visto por usuarios finales. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.SERIAL	Un número de serie del hardware, si está disponible. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^([a-zA-Z0-9]{0,20})$"` .
android.os.Build.TAGS	Una lista de etiquetas separadas por comas elegidas por el implementador del dispositivo que distinguen aún más la compilación. Por ejemplo, "sin firmar, depurar". El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.TIME	Un valor que representa la marca de tiempo de cuando ocurrió la compilación.
android.os.Build.TYPE	Un valor elegido por el implementador del dispositivo que especifica la configuración de tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: "user", "userdebug" o "eng". El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `"^[a-zA-Z0-9.,_-]+$"` .
android.os.Build.USER	Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").

3.2.3. Compatibilidad de intenciones

Las implementaciones de dispositivos DEBEN respetar el sistema Intent de acoplamiento flexible de Android, como se describe en las secciones siguientes. 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 contactos, calendario, galería de fotos, 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
Contactos
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, las implementaciones de dispositivos DEBEN permitir que cada patrón de Intención al que se hace referencia en la Sección 3.2.3.2 sea anulado por aplicaciones de terceros. La implementación 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.

Sin embargo, las implementaciones de dispositivos PUEDEN proporcionar actividades predeterminadas para patrones de URI específicos (por ejemplo, http://play.google.com) si la actividad predeterminada proporciona un filtro más específico para el URI de datos. Por ejemplo, un filtro de intención que especifica el URI de datos "http://www.android.com" es más específico que el filtro del navegador para "http://". Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario para que los usuarios modifiquen la actividad predeterminada para los intentos.

3.2.3.3. Espacios de nombres de intención

Las implementaciones 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.* o com.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. Las implementaciones de dispositivos PUEDEN incluir patrones de Intención que utilizan espacios de nombres asociados clara y obviamente con su propia organización.

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

3.3.1 Interfaces binarias de aplicaciones

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.html . 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 OpenSL ES 1.0.1)
libOpenMAXAL.so (soporte para OpenMAX AL 1.0.1)
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

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 534.30 del árbol de código abierto de Android ascendente para Android 4.2. Esta compilación incluye un conjunto específico de funcionalidades y correcciones de seguridad para WebView. Los implementadores de dispositivos PUEDEN incluir personalizaciones en la implementación de WebKit; sin embargo, dichas personalizaciones NO DEBEN alterar el comportamiento de WebView, incluido el comportamiento de representación.
La cadena del agente de usuario informada por WebView DEBE tener este formato:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
- 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
- Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del agente de usuario

El componente WebView DEBE incluir soporte para la mayor cantidad de HTML5 [ Recursos, 11 ] 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, 12 ]
la etiqueta <video> [ Recursos, 13 ]
geolocalización [ Recursos, 14 ]

Además, las implementaciones de dispositivos DEBEN admitir la API de almacenamiento web HTML5/W3C [ Recursos, 15 ], y DEBEN admitir la API IndexedDB HTML5/W3C [ Recursos, 16 ]. 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, 11 ] 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, 12 ]
la etiqueta <video> [ Recursos, 13 ]
geolocalización [ Recursos, 14 ]

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

Las implementaciones de dispositivos DEBEN configurar Dalvik para asignar memoria de acuerdo con la plataforma Android ascendente y como se especifica en la siguiente tabla. (Consulte la Sección 7.1.1 para conocer las definiciones de tamaño y densidad de pantalla).

Tenga en cuenta que los valores de memoria especificados a continuación se consideran valores mínimos y las implementaciones de dispositivos PUEDEN asignar más memoria por aplicación.

Tamaño de pantalla	Densidad de la pantalla	Memoria de aplicación
pequeño/normal/grande	ldpi/mdpi	16MB
pequeño/normal/grande	tvdpi / hdpi	32MB
pequeño/normal/grande	xhdpi	64MB
extra grande	mdpi	32MB
extra grande	tvdpi / hdpi	64MB
extra grande	xhdpi	128MB

3.8. Compatibilidad de la interfaz de usuario

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, 18 ]. La versión de referencia de código abierto de Android incluye una aplicación de inicio que incluye funciones de interfaz de usuario que permiten al usuario agregar, ver y eliminar AppWidgets de la pantalla de inicio.

Las implementaciones 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 las posibilidades 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, la implementación del dispositivo DEBE proporcionar una aplicación separada accesible desde el Iniciador que permita a los usuarios agregar, configurar, ver y eliminar AppWidgets.

Las implementaciones de dispositivos DEBEN ser capaces de representar widgets de 4 x 4 en el tamaño de cuadrícula estándar. (Consulte las Pautas de diseño de widgets de aplicaciones en la documentación del SDK de Android [ Recursos, 18 ] para obtener más detalles.

3.8.2. Notificaciones

Android incluye API que permiten a los desarrolladores notificar a los usuarios sobre eventos notables [ Recursos, 19 ], utilizando funciones de hardware y software del dispositivo.

Algunas API permiten que las aplicaciones realicen notificaciones o llamen la atención mediante hardware, específicamente sonido, vibración y luz. Las implementaciones de dispositivos DEBEN admitir notificaciones que utilizan funciones de hardware, como se describe en la documentación del SDK y, en la medida de lo posible, con el hardware de implementación del dispositivo. Por ejemplo, si la implementación de un dispositivo incluye un vibrador, DEBE implementar correctamente las API de vibración. Si la implementación de un dispositivo carece de hardware, las API correspondientes DEBEN implementarse como no operativas. Tenga en cuenta que este comportamiento se detalla más en la Sección 7.

Además, la implementación DEBE representar correctamente todos los recursos (iconos, archivos de sonido, etc.) proporcionados en las API [ Recursos, 20 ], o en la guía de estilo de iconos de la barra de estado/sistema [ Recursos, 21 ]. 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.

Android 4.2 incluye soporte para notificaciones enriquecidas, como vistas interactivas para notificaciones en curso. Las implementaciones de dispositivos DEBEN mostrar y ejecutar correctamente notificaciones enriquecidas, como se documenta en las API de Android.

3.8.3. Buscar

Android incluye API [ Recursos, 22 ] 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.

3.8.4. Brindis

Las aplicaciones pueden usar la API "Toast" (definida en [ Recursos, 23 ]) 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. Temas

Android proporciona "temas" como mecanismo para que las aplicaciones apliquen estilos en toda una actividad o aplicación. Android 4.2 incluye un tema "Holo" o "holográfico" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones lo utilicen si desean igualar la apariencia del tema Holo según lo definido por el SDK de Android [ Recursos, 24 ]. Las implementaciones de dispositivos NO DEBEN alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones [ Recursos, 25 ].

Android 4.2 incluye un nuevo tema "Predeterminado del dispositivo" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los utilicen si desean igualar la apariencia del tema del dispositivo según lo definido por el implementador del dispositivo. Las implementaciones de dispositivos PUEDEN modificar los atributos del tema DeviceDefault expuestos a las aplicaciones [ Recursos, 25 ].

3.8.6. 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, 26 ]. 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.

3.8.7. Visualización de aplicaciones recientes

El código fuente de Android 4.2 incluye una interfaz de usuario para mostrar aplicaciones recientes utilizando una imagen en miniatura del estado gráfico de la aplicación en el momento en que el usuario abandonó la aplicación por última vez. Las implementaciones de dispositivos PUEDEN alterar o eliminar esta interfaz de usuario; sin embargo, está prevista una versión futura de Android para hacer un uso más amplio de esta funcionalidad. Se recomienda encarecidamente que las implementaciones de dispositivos utilicen la interfaz de usuario de Android 4.2 (o una interfaz similar basada en miniaturas) para aplicaciones recientes; de lo contrario, es posible que no sean compatibles con una versión futura de Android.

3.8.8. Configuración de gestión de entrada

Android 4.2 incluye soporte para motores de administración de entrada. Las API de Android 4.2 permiten que los IME de aplicaciones personalizadas especifiquen configuraciones ajustables por el usuario. Las implementaciones de dispositivos DEBEN incluir una forma para que el usuario acceda a la configuración de IME en todo momento cuando se muestra un IME que proporciona dicha configuración de usuario.

3.8.9. Widgets de bloqueo y pantalla de inicio

Android 4.2 incluye soporte para widgets de aplicaciones que los usuarios pueden incrustar en la pantalla de inicio o en la pantalla de bloqueo (consulte las Pautas de diseño de widgets de aplicaciones en la documentación del SDK de Android [ Recursos, 69 ] para obtener más detalles). Los widgets de aplicaciones permiten un acceso rápido a los datos y servicios de las aplicaciones sin iniciar una nueva actividad. Los widgets declaran compatibilidad con el uso en la pantalla de inicio o en la pantalla de bloqueo declarando la etiqueta de manifiesto android:widgetCategory que le indica al sistema dónde se puede colocar el widget. Específicamente, las implementaciones de dispositivos DEBEN cumplir los siguientes requisitos.

Las implementaciones de dispositivos DEBEN admitir widgets de aplicaciones en la pantalla de inicio.
Las implementaciones de dispositivos DEBEN admitir la pantalla de bloqueo. Si las implementaciones del dispositivo incluyen soporte para la pantalla de bloqueo, entonces las implementaciones del dispositivo DEBEN admitir widgets de aplicaciones en la pantalla de bloqueo.

3.8.10. Control remoto multimedia de pantalla de bloqueo

Android 4.2 incluye soporte para la API de control remoto que permite que las aplicaciones multimedia se integren con los controles de reproducción que se muestran en una vista remota como la pantalla de bloqueo del dispositivo [ Recursos, 74 ]. Las implementaciones de dispositivos DEBEN incluir soporte para incorporar controles remotos en la pantalla de bloqueo del dispositivo.

3.8.11. Sueños

Android 4.2 incluye soporte para protectores de pantalla interactivos llamados Dreams [ Recursos, 76 ]. Dreams permite a los usuarios interactuar con aplicaciones cuando un dispositivo de carga está inactivo o acoplado a una base de escritorio. Las implementaciones de dispositivos DEBEN incluir soporte para Dreams y proporcionar una opción de configuración para que los usuarios configuren Dreams.

3.9 Administración del dispositivo

Android 4.2 incluye funciones que permiten que las aplicaciones conscientes de la seguridad realicen funciones de administración de dispositivos a nivel del sistema, como aplicar políticas de contraseña o realizar un borrado remoto, a través de la API de administración de dispositivos Android [ Recursos, 27 ]. Las implementaciones de dispositivos DEBEN proporcionar una implementación de la clase DevicePolicyManager [ Recursos, 28 ] y DEBEN admitir la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android [ Recursos, 27 ].

Nota: si bien algunos de los requisitos descritos anteriormente se indican como "DEBERÍAN" para Android 4.2, las implementaciones de dispositivos que admiten la pantalla de bloqueo DEBEN admitir políticas de dispositivo para administrar widgets en la pantalla de bloqueo como se define en la documentación del SDK de Android [ Recursos, 27 ].

Nota: si bien algunos de los requisitos descritos anteriormente se indican como "DEBERÍAN" para Android 4.2, 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 4.2 pero serán requeridos en una versión futura. Se recomienda encarecidamente que los dispositivos nuevos y existentes que ejecutan Android 4.2 cumplan con estos requisitos en Android 4.2 , o no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

3.10 Accesibilidad

Android 4.2 proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos más fácilmente. Además, Android 4.2 proporciona API de plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamadas para eventos del usuario y del sistema y generen mecanismos de retroalimentación alternativos, como texto a voz, retroalimentación háptica y navegación con trackball/d-pad [ Recursos, 29 ] . Las implementaciones de dispositivos DEBEN proporcionar una implementación del marco de accesibilidad de Android coherente con la implementación predeterminada de Android. Específicamente, las implementaciones de dispositivos DEBEN cumplir los siguientes requisitos.

Las implementaciones de dispositivos DEBEN admitir implementaciones de servicios de accesibilidad de terceros a través de las API android.accessibilityservice [ Recursos, 30 ].
Las implementaciones de dispositivos DEBEN generar AccessibilityEvents y entregar estos eventos a todas las implementaciones registradas AccessibilityService de manera consistente con la implementación predeterminada de Android.
Las implementaciones de dispositivos DEBEN proporcionar un mecanismo accesible para el usuario para habilitar y deshabilitar los servicios de accesibilidad, y DEBEN mostrar esta interfaz en respuesta a la intención de android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS .

Además, las implementaciones de dispositivos DEBEN proporcionar una implementación de un servicio de accesibilidad en el dispositivo y DEBEN proporcionar un mecanismo para que los usuarios habiliten el servicio de accesibilidad durante la configuración del dispositivo. Una implementación de código abierto de un servicio de accesibilidad está disponible en el proyecto Eyes Free [ Recursos, 31 ].

3.11 Texto a voz

Android 4.2 incluye API que permiten que las aplicaciones utilicen servicios de texto a voz (TTS) y permite a los proveedores de servicios proporcionar implementaciones de servicios TTS [ Recursos, 32 ]. Las implementaciones de dispositivos DEBEN cumplir estos requisitos relacionados con el marco TTS de Android:

Las implementaciones de dispositivos DEBEN admitir las API del marco TTS de Android y DEBEN incluir un motor TTS que admita los idiomas disponibles en el dispositivo. Tenga en cuenta que el software de código abierto de Android incluye una implementación de motor TTS con todas las funciones.
Las implementaciones de dispositivos DEBEN admitir la instalación de motores TTS de terceros.
Las implementaciones de dispositivos DEBEN proporcionar una interfaz accesible para el usuario que les permita seleccionar un motor TTS para su uso a nivel del sistema.

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

Las implementaciones de dispositivos NO DEBEN extender los formatos .apk [ Recursos, 34 ], Android Manifest [ Recursos, 35 ], código de bytes de Dalvik [ Recursos, 17 ] o código de bytes renderscript 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 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 formatos de medios principales especificados en la documentación del SDK de Android [ Recursos, 58 ], excepto donde se permita explícitamente en este documento. Específicamente, las implementaciones de dispositivos DEBEN admitir los formatos de medios, codificadores, decodificadores, tipos de archivos y formatos de contenedores definidos en las tablas siguientes. 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.

Tenga en cuenta que estas tablas no enumeran los requisitos de velocidad de bits específicos para la mayoría de los códecs de vídeo porque el hardware del dispositivo actual no necesariamente admite velocidades de bits que se correspondan exactamente con las velocidades de bits requeridas 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.

Tipo	Formato/Códec	Codificador	Descifrador	Detalles	Tipo(s) de archivo/Formatos de contenedor
Audio	Perfil MPEG-4 AAC (AAC LC)	REQUERIDO Requerido para implementaciones de dispositivos que incluyen hardware de micrófono y definen `android.hardware.microphone` .	REQUERIDO	Compatibilidad con contenido mono/estéreo/5.0/5.1* con frecuencias de muestreo estándar de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, decodificar en Android 3.1+, codificar en Android 4.0+, ADIF no compatible) MPEG-TS (.ts, no buscable, Android 3.0+)
	Perfil MPEG-4 HE AAC (AAC+)	REQUERIDO para implementaciones de dispositivos que incluyen hardware de micrófono y definen android.hardware.microphone	REQUERIDO	Compatibilidad con contenido mono/estéreo/5.0/5.1* con frecuencias de muestreo estándar de 16 a 48 kHz.
	Perfil MPEG-4 HE AAC v2 (AAC+ mejorado)		REQUERIDO	Compatibilidad con contenido mono/estéreo/5.0/5.1* con frecuencias de muestreo estándar de 16 a 48 kHz.
	Tipo de objeto de audio MPEG-4 ER AAC ELD (AAC de bajo retardo mejorado)	REQUERIDO para implementaciones de dispositivos que incluyen hardware de micrófono y definen android.hardware.microphone	REQUERIDO	Soporte para contenido mono/estéreo con frecuencias de muestreo estándar de 16 a 48 kHz.
	AMR-NB	REQUERIDO Requerido para implementaciones de dispositivos que incluyen hardware de micrófono y definen `android.hardware.microphone` .	REQUERIDO	4,75 a 12,2 kbps muestreados a 8 kHz	3GPP (.3gp)
	AMR-WB	REQUERIDO Requerido para implementaciones de dispositivos que incluyen hardware de micrófono y definen `android.hardware.microphone` .	REQUERIDO	9 velocidades de 6,60 kbit/s a 23,85 kbit/s muestreadas a 16 kHz	3GPP (.3gp)
	FLAC		REQUERIDO (Androide 3.1+)	Mono/Estéreo (sin multicanal). Frecuencias de muestreo de hasta 48 kHz (pero se recomienda hasta 44,1 kHz en dispositivos con salida de 44,1 kHz, ya que el downsampler de 48 a 44,1 kHz no incluye un filtro de paso bajo). Se recomienda 16 bits; no se aplica ningún tramado para 24 bits.	Solo FLAC (.flac)
	MP3		REQUERIDO	Mono/estéreo 8-320 Kbps constante (CBR) o velocidad de bits variable (VBR)	MP3 (.mp3)
	midi		REQUERIDO	MIDI Tipo 0 y 1. DLS Versión 1 y 2. XMF y XMF móvil. Compatibilidad con formatos de tonos de llamada RTTTL/RTX, OTA e iMelody	Tipo 0 y 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelodía (.imy)
	Vorbis		REQUERIDO		Ogg (.ogg) Matroska (.mkv)
	PCM/ONDA	REQUERIDO	REQUERIDO	PCM lineal de 8 y 16 bits** (velocidades hasta el límite del hardware). Los dispositivos DEBEN admitir velocidades de muestreo para grabación PCM sin procesar a frecuencias de 8000,16000 y 44100 Hz.	ONDA (.wav)
Imagen	JPEG	REQUERIDO	REQUERIDO	Base+progresiva	JPEG (.jpg)
	GIF		REQUERIDO		GIF (.gif)
	PNG	REQUERIDO	REQUERIDO		PNG (.png)
	BMP		REQUERIDO		BMP (.bmp)
	WEBP	REQUERIDO	REQUERIDO		WebP (.webp)
Video	H.263	REQUERIDO Requerido para implementaciones de dispositivos que incluyen hardware de cámara y definen `android.hardware.camera` o `android.hardware.camera.front` .	REQUERIDO		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	REQUERIDO Requerido para implementaciones de dispositivos que incluyen hardware de cámara y definen `android.hardware.camera` o `android.hardware.camera.front` .	REQUERIDO	Perfil basal (PA)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, solo audio AAC, no buscable, Android 3.0+)
	MPEG-4SP		REQUERIDO		3GPP (.3gp)
	VP8		REQUERIDO (Androide 2.3.3+)		WebM (.webm) y Matroska (.mkv, Android 4.0+)

*Nota: Sólo se requiere una mezcla de contenido 5.0/5.1; Grabar o renderizar más de 2 canales es opcional. **Nota: la captura PCM lineal de 16 bits es obligatoria. La captura PCM lineal de 8 bits no es obligatoria.

5.2 Codificación de vídeo

Las implementaciones de dispositivos Android que incluyen una cámara trasera y declaran android.hardware.camera DEBEN admitir los siguientes perfiles de codificación de video.

	SD (baja calidad)	SD (alta calidad)	HD (cuando es compatible con hardware)
Códec de vídeo	Perfil de línea base H.264	Perfil de línea base H.264	Perfil de línea base H.264
Resolución de video	176 x 144 píxeles	480 x 360 píxeles	1280 x 720 píxeles
Velocidad de fotogramas de vídeo	12 fps	30 fps	30 fps
Bitrate de vídeo	56 kbps	500 Kbps o más	2 Mbps o más
Códec de audio	AAC-LC	AAC-LC	AAC-LC
Canales de audio	1 (mono)	2 (estéreo)	2 (estéreo)
tasa de bits de audio	24 Kbps	128 kbps	192 Kbps

5.3 Decodificación de vídeo

Las implementaciones de dispositivos Android DEBEN admitir los siguientes perfiles de decodificación de video VP8.

	SD (baja calidad)	SD (alta calidad)	alta definición 720p (Cuando es compatible con hardware)	alta definición 1080p (Cuando es compatible con hardware)
Resolución de video	320 x 180 píxeles	640 x 360 píxeles	1280 x 720 píxeles	1920 x 1080 píxeles
Velocidad de fotogramas de vídeo	30 fps	30 fps	30 fps	30 fps
Bitrate de vídeo	800 kbps	2Mbps	8Mbps	20Mbps

5.4. 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 de dispositivos que incluyen hardware de micrófono y declaran android.hardware.microphone DEBEN muestrear y grabar audio con cada uno de estos comportamientos:

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 2500 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% para 1 Khz a un nivel de entrada de 90 dB SPL.

Además de las especificaciones de grabación anteriores, cuando una aplicación ha comenzado a grabar una transmisión de audio utilizando la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION :

El procesamiento de reducción de ruido, si está presente, DEBE estar desactivado.
El control automático de ganancia, si está presente, DEBE estar desactivado.

5.5. Latencia de audio

La latencia de audio es el retraso de tiempo cuando una señal de audio pasa a través de un sistema. Muchas clases de aplicaciones se basan en latencias cortas para lograr efectos en tiempo real, como efectos de sonido o comunicación VOIP.

Para los efectos de esta sección:

La "latencia de salida" se define como el intervalo entre el momento en que una aplicación escribe un cuadro de datos codificados en PCM y el momento en que un oyente externo puede escuchar el sonido correspondiente u observarlo mediante un transductor.
La "latencia de salida en frío" se define como la latencia de salida para el primer fotograma, cuando el sistema de salida de audio ha estado inactivo y apagado antes de la solicitud.
La "latencia de salida continua" se define como la latencia de salida para fotogramas posteriores, después de que el dispositivo ya esté reproduciendo audio.
La "latencia de entrada" es el intervalo entre el momento en que se presenta un sonido externo al dispositivo y el momento en que una aplicación lee el cuadro correspondiente de datos codificados en PCM.
La "latencia de entrada en frío" se define como la suma del tiempo de entrada perdido y la latencia de entrada para el primer fotograma, cuando el sistema de entrada de audio ha estado inactivo y apagado antes de la solicitud.
La "latencia de entrada continua" se define como la latencia de entrada para fotogramas posteriores, mientras el dispositivo ya está capturando audio.
La "API de cola de búfer OpenSL ES PCM" es el conjunto de API de OpenSL ES relacionadas con PCM dentro del NDK de Android; consulte NDK_root /docs/opensles/index.html

Según la Sección 5 , todas las implementaciones de dispositivos compatibles DEBEN incluir al menos una forma de salida de audio. Las implementaciones de dispositivos DEBEN cumplir o superar estos requisitos de latencia de salida:

Latencia de salida en frío de 100 milisegundos o menos.
Latencia de salida continua de 45 milisegundos o menos.

Si la implementación de un dispositivo cumple con los requisitos de esta sección después de cualquier calibración inicial cuando se utiliza la API de cola de búfer OpenSL ES PCM, para latencia de salida continua y latencia de salida fría en al menos un dispositivo de salida de audio compatible, 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, 37 ] Por el contrario, si la implementación del dispositivo no cumple con estos requisitos, NO DEBE informar soporte para audio de baja latencia.

Según la Sección 7.2.5 , las implementaciones del dispositivo pueden omitir el hardware del micrófono.

Las implementaciones de dispositivos que incluyen hardware de micrófono y declaran android.hardware.microphone DEBEN cumplir con estos requisitos de latencia de audio de entrada:

Latencia de entrada en frío de 100 milisegundos o menos.
Latencia de entrada continua de 50 milisegundos o menos.

5.6. Protocolos de red

Los dispositivos DEBEN admitir los protocolos de red de medios para la reproducción de audio y video como se especifica en la documentación del SDK de Android [ Recursos, 58 ]. Específicamente, los dispositivos DEBEN admitir los siguientes protocolos de red de medios:

RTSP (RTP, SDP)
Transmisión progresiva HTTP(S)
Protocolo preliminar de transmisión en vivo HTTP(S), versión 3 [ Recursos, 59 ]

6. Compatibilidad de opciones y herramientas de desarrollador

6.1 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, 33 ]
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 y DEBE haber un mecanismo accesible para el usuario para activar Android Debug Bridge.

Android 4.2.2 incluye soporte para adb seguro. Secure adb habilita adb en hosts autenticados conocidos. Se recomienda encarecidamente que los dispositivos nuevos y existentes que ejecutan Android 4.2.2 cumplan con este requisito en Android 4.2 , o no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

Servicio Dalvik Debug Monitor (conocido como ddms) [ Recursos, 33 ]
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, 36 ]
Las implementaciones de dispositivos DEBEN incluir el marco Monkey y ponerlo a disposición de las aplicaciones.
SysTrace [ Recursos, 33 ]
Las implementaciones de dispositivos DEBEN admitir la herramienta systrace como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar Systrace.

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, Windows 7 y Windows 8, en versiones de 32 y 64 bits.

6.2 Opciones de desarrollador

Android 4.2 incluye soporte para que los desarrolladores configuren ajustes relacionados con el desarrollo de aplicaciones. Las implementaciones de dispositivos DEBEN respetar la intención de android.settings.APPLICATION_DEVELOPMENT_SETTINGS de mostrar la configuración relacionada con el desarrollo de aplicaciones [ Recursos, 77 ]. La implementación ascendente de Android oculta el menú Opciones de desarrollador de forma predeterminada y permite a los usuarios iniciar Opciones de desarrollador después de presionar siete (7) veces en el elemento de menú Configuración > Acerca del dispositivo > Número de compilación. Las implementaciones de dispositivos DEBEN proporcionar una experiencia coherente para las Opciones de desarrollador. Específicamente, las implementaciones de dispositivos DEBEN ocultar las Opciones de desarrollador de forma predeterminada y DEBEN proporcionar un mecanismo para habilitar las Opciones de desarrollador que sea coherente con la implementación de Android.

7. Compatibilidad de hardware

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, 37 ]

7.1. Pantalla y gráficos

Android 4.2 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, 38 ]. Los dispositivos DEBEN implementar correctamente estas API y comportamientos, como se detalla en esta sección.

Las unidades a las que hacen referencia los requisitos de esta sección 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".
Un "píxel independiente de la densidad" o ("dp") es la unidad de píxel virtual normalizada a una pantalla de 160 ppp, calculada como: pixels = dps * (density / 160) .

7.1.1. Configuración de pantalla

Tamaño de pantalla

El marco de la interfaz de usuario de Android admite una variedad de tamaños de pantalla diferentes y permite que las aplicaciones consulten el tamaño de la pantalla del dispositivo (también conocido como "diseño de pantalla") a través de android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK . Las implementaciones de dispositivos DEBEN informar el tamaño de pantalla correcto según lo definido en la documentación del SDK de Android [ Recursos, 38 ] y determinado por la plataforma Android ascendente. Específicamente, las implementaciones de dispositivos deben informar el tamaño de pantalla correcto de acuerdo con las siguientes dimensiones lógicas de pantalla de píxeles (dp) independientes de la densidad.

Los dispositivos DEBEN tener tamaños de pantalla de al menos 426 dp x 320 dp ("pequeño")
Los dispositivos que informan que el tamaño de pantalla es "normal" DEBEN tener tamaños de pantalla de al menos 480 dp x 320 dp
Los dispositivos que informan que el tamaño de pantalla es "grande" DEBEN tener tamaños de pantalla de al menos 640 dp x 480 dp
Los dispositivos que informan que el tamaño de pantalla es "xlarge" DEBEN tener tamaños de pantalla de al menos 960 dp x 720 dp

Además, los dispositivos DEBEN tener tamaños de pantalla de al menos 2,5 pulgadas en diagonal física.

Los dispositivos NO DEBEN cambiar el tamaño de pantalla informado en ningún momento.

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, normales, grandes y extragrandes, como se describe en la documentación del SDK de Android.

Relación de aspecto de pantalla

La relación de aspecto DEBE estar entre 1,3333 (4:3) y 1,85 (16:9).

Densidad de la pantalla

El marco de la interfaz de usuario de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientar los recursos de la aplicación. Las implementaciones de dispositivos DEBEN informar una de las siguientes densidades del marco lógico de Android a través de las API android.util.DisplayMetrics y DEBEN ejecutar aplicaciones con esta densidad estándar.

120 ppp, conocido como 'ldpi'
160 ppp, conocido como 'mdpi'
213 ppp, conocido como 'tvdpi'
240 ppp, conocido como 'hdpi'
320 ppp, conocido como 'xhdpi'
480 ppp, conocido como 'xxhdpi'

Las implementaciones de dispositivos DEBEN definir la densidad del marco de Android estándar que sea numéricamente más cercana a la densidad física de la pantalla, a menos que esa densidad lógica empuje el tamaño de pantalla informado por debajo del mínimo admitido. Si la densidad del marco de Android estándar que es numéricamente más cercana a la densidad física da como resultado un tamaño de pantalla más pequeño que el tamaño de pantalla compatible más pequeño admitido (320 dp de ancho), las implementaciones del dispositivo DEBEN informar la siguiente densidad de marco de Android estándar más baja.

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

7.1.3. Orientación de la pantalla

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

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

Los dispositivos NO DEBEN cambiar el tamaño o la densidad de la pantalla informados al cambiar de orientación.

Los dispositivos DEBEN informar qué orientaciones de pantalla admiten ( android.hardware.screen.portrait y/o android.hardware.screen.landscape ) y DEBEN informar al menos una orientación admitida. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como un televisor o una computadora portátil, DEBE informar solo android.hardware.screen.landscape .

7.1.4. Aceleración de gráficos 2D y 3D

Las implementaciones de dispositivos DEBEN admitir OpenGL ES 1.0 y 2.0, como se incluye y detalla en la documentación del SDK de Android. Las implementaciones de dispositivos también deben admitir Android RenderScript, como se detalla en la documentación de Android SDK [ recursos, 8 ].

Las implementaciones de dispositivos también deben identificarse correctamente como compatibles con OpenGL ES 1.0 y 2.0. Eso es:

Las API administradas (como a través del método GLES10.getString() ) deben informar soporte para OpenGL ES 1.0 y 2.0
Las API nativas de C/C ++ OpenGL (es decir, las disponibles para las aplicaciones a través de libgles_v1cm.so, libgles_v2.so o libegl.so) deben informar soporte para OpenGL ES 1.0 y 2.0.

Las implementaciones de dispositivos pueden implementar las extensiones OpenGL ES deseadas. Sin embargo, las implementaciones de dispositivos DEBEN informar a través de las API nativas y administradas de OpenGL ES todas las cadenas de extensión que sí admiten y, a la inversa, NO DEBEN informar las cadenas de extensión que no admiten.

Tenga en cuenta que Android 4.2 incluye soporte para aplicaciones para especificar opcionalmente que requieren formatos específicos de compresión de textura OpenGL. Estos formatos suelen ser específicos del proveedor. Android 4.2 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.

Android 4.2 incluye un mecanismo para que las aplicaciones declaren que querían habilitar la aceleración de hardware para gráficos 2D en la aplicación, actividad, ventana o vista de vista mediante el uso de una etiqueta manifiesta android:hardwareAccelerated o direct Direct API llamadas [ recursos, 9 ].

En Android 4.2, las implementaciones de dispositivos deben habilitar la aceleración de hardware de forma predeterminada y deben deshabilitar la aceleración de hardware si el desarrollador así solicita configurando android:hardwareAccelerated="false" o deshabilitar la aceleración de hardware directamente a través de las API de View Android.

Además, las implementaciones de dispositivos deben exhibir un comportamiento consistente con la documentación de Android SDK sobre la aceleración de hardware [ recursos, 9 ].

Android 4.2 incluye un objeto TextureView que permite a los desarrolladores integrar directamente las texturas OpenGL aceleradas de hardware como objetivos de representación en una jerarquía de UI. Las implementaciones de dispositivos DEBEN admitir la API TextureView y DEBEN exhibir un comportamiento consistente con la implementación de Android.

7.1.5. Modo de compatibilidad de aplicaciones heredadas

Android 4.2 especifica un "modo de compatibilidad" en el que el marco funciona en un modo equivalente de tamaño de pantalla 'normal' (ancho de 320dp) para el beneficio de aplicaciones heredadas que no se desarrollan para versiones antiguas de Android esa independencia de tamaño previa de pantalla. Las implementaciones de dispositivos deben incluir soporte para el modo de compatibilidad de aplicaciones heredadas implementadas por el código de código abierto de Android Upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los desencadenantes o umbrales en los que se activa el modo de compatibilidad, y NO DEBEN alterar el comportamiento del modo de compatibilidad en sí.

7.1.6. Tipos de pantalla

Las pantallas de implementación del dispositivo se clasifican como uno de los dos tipos:

Implementaciones de visualización de píxeles fijos: la pantalla es un solo panel que admite solo un solo ancho y altura de píxeles. Por lo general, la pantalla está físicamente integrada con el dispositivo. Los ejemplos incluyen teléfonos móviles, tabletas, etc.
Implementaciones de visualización de píxeles variables: la implementación del dispositivo no tiene pantalla incrustada e incluye un puerto de salida de video como VGA, HDMI o un puerto inalámbrico para la pantalla, o tiene una pantalla incrustada que puede cambiar las dimensiones de píxeles. Los ejemplos incluyen televisores, decodificadores, etc.

Implementaciones de dispositivos de píxeles fijos

Las implementaciones de dispositivos de píxeles fijos pueden usar pantallas de cualquier dimensión de píxeles, siempre que cumplan con los requisitos definidos esta definición de compatibilidad.

Las implementaciones de píxeles fijos pueden incluir un puerto de salida de video para usar con una pantalla externa. Sin embargo, si esa pantalla alguna vez se usa para ejecutar aplicaciones, el dispositivo debe cumplir con los siguientes requisitos:

El dispositivo debe informar la misma configuración de pantalla y mostrar métricas, como se detalla en las Secciones 7.1.1 y 7.1.2, como la pantalla de píxel fijo.
El dispositivo debe informar la misma densidad lógica que la pantalla de píxel fijo.
El dispositivo debe informar las dimensiones de la pantalla que son las mismas o muy cercanas a la pantalla de píxel fijo.

Por ejemplo, una tableta que tiene un tamaño diagonal de 7 "con una resolución de 1024x600 píxeles se considera una implementación de pantalla MDPI grande de píxeles fijos. Si contiene un puerto de salida de video que se muestra a 720p o 1080p, la implementación del dispositivo debe escalar la salida de modo que Las aplicaciones solo se ejecutan en una gran ventana MDPI, independientemente de si la pantalla de píxel fijo o el puerto de salida de video están en uso.

Implementaciones de dispositivos de píxeles variables

Las implementaciones de dispositivos de píxeles variables deben admitir uno o ambos de 1280x720, o 1920x1080 (es decir, 720p o 1080p). Las implementaciones de dispositivos con pantallas de píxeles variables no deben admitir ninguna otra configuración o modo de pantalla. Las implementaciones del dispositivo con pantallas de píxeles variables pueden cambiar la configuración o el modo de la pantalla en tiempo de ejecución o tiempo de arranque. Por ejemplo, un usuario de un cuadro establecido puede reemplazar una pantalla de 720p con una pantalla de 1080p, y la implementación del dispositivo puede ajustarse en consecuencia.

Además, las implementaciones de dispositivos de píxeles variables deben informar los siguientes cubos de configuración para estas dimensiones de píxeles:

1280x720 (también conocido como 720p): densidad 'grande' de pantalla 'grande', 'TVDPI' (213 DPI)
1920x1080 (también conocido como 1080p): densidad 'grande' de pantalla 'grande', densidad 'XHDPI' (320 DPI)

Para mayor claridad, las implementaciones de dispositivos con dimensiones de píxeles variables están restringidas a 720p o 1080p en Android 4.2, y deben configurarse para informar los cubos de tamaño y densidad de la pantalla como se indicó anteriormente.

7.1.7. Tecnología de pantalla

La plataforma Android incluye API que permiten que las aplicaciones muestren gráficos enriquecidos en la pantalla. Los dispositivos DEBEN admitir todas estas API según lo definido por el SDK de Android, a menos que se permita específicamente en este documento. Específicamente:

Los dispositivos DEBEN admitir pantallas capaces de reproducir gráficos en color de 16 bits y DEBEN admitir pantallas capaces de reproducir gráficos en color de 24 bits.
Los dispositivos DEBEN admitir pantallas capaces de representar animaciones.
La tecnología de visualización utilizada debe tener una relación de aspecto de píxel (PAR) entre 0.9 y 1.1. Es decir, la relación de aspecto de píxeles debe estar cerca de la cuadrada (1.0) con una tolerancia al 10%.

7.1.8. Pantallas externas

Android 4.2 incluye soporte para la pantalla secundaria para habilitar las capacidades de intercambio de medios y las API de desarrollador para acceder a pantallas externas. Si un dispositivo admite una pantalla externa a través de una conexión de pantalla adicional con cable, inalámbrica o incrustada, la implementación del dispositivo debe implementar la API de Manager de visualización como se describe en la documentación SDK de Android [ recursos, 75 ]. Las implementaciones de dispositivos que admiten una salida de video segura y son capaces de admitir superficies seguras deben declarar soporte para Display.SECURE_FLAG . Específicamente, las implementaciones de dispositivos que declaran soporte para Display.SECURE_FLAG deben admitir HDCP 2.x o superior para pantallas inalámbricas de Miracast o HDCP 1.2 o superior para pantallas con cable. La implementación de código abierto de Android incluye soporte para pantallas inalámbricas (Miracast) y cableadas (HDMI) que satisfacen este requisito.

7.2. Los dispositivos de entrada

7.2.1. Teclado

Implementaciones de dispositivos:

Debe incluir soporte para el marco de gestión de entrada (que permite a los desarrolladores de terceros crear motores de administración de entrada, es decir, teclado suave) como se detalla en http://developer.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, 40 ] (es decir, qwerty o 12 key)

Implementaciones de dispositivos:

Puede omitir una opción de navegación no táctil (es decir, puede omitir una bola de seguimiento, d-pad o rueda)
Debe informar el valor correcto para android.content.res.Configuration.navigation [ recursos, 40 ]
Debe proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición del texto, compatible con los motores de gestión de entrada. La implementación de código abierto de Android Upstream incluye un mecanismo de selección adecuado para su uso con dispositivos que carecen de entradas de navegación no táctiles.

Las funciones Inicio, Menú y Atrás son esenciales para el paradigma de navegación de Android. Las implementaciones de dispositivos deben hacer que estas funciones estén disponibles para el usuario en todo momento al ejecutar aplicaciones. Estas funciones pueden implementarse a través de botones físicos dedicados (como botones táctiles mecánicos o capacitivos), o pueden implementarse utilizando claves de software dedicadas, gestos, panel táctil, etc. Android 4.2 admite ambas implementaciones.

Android 4.2 incluye soporte para la acción de asistencia [ recursos, 63 ]. Las implementaciones de dispositivos deben poner la acción de asistencia a disposición del usuario en todo momento al ejecutar aplicaciones. Esta función puede implementarse a través de claves de hardware o software.

Las implementaciones del dispositivo pueden usar una parte distinta de la pantalla para mostrar las teclas de navegación, pero si es así, deben cumplir con estos requisitos:

Las teclas de navegación de implementación del dispositivo deben usar una parte distinta de la pantalla, no disponible para las aplicaciones, y no deben oscurecer o interferir con la parte de la pantalla disponible para las aplicaciones.
Las implementaciones del dispositivo deben poner a disposición una parte de la pantalla a las aplicaciones que cumplan con los requisitos definidos en la Sección 7.1.1 .
Las implementaciones del dispositivo deben mostrar las claves de navegación cuando las aplicaciones no especifican un modo de interfaz de usuario del sistema o especifican SYSTEM_UI_FLAG_VISIBLE .
Las implementaciones de dispositivos deben presentar las claves de navegación en un modo discreto de "perfil bajo" (por ejemplo, atenuado) cuando las aplicaciones especifican SYSTEM_UI_FLAG_LOW_PROFILE .
Las implementaciones del dispositivo deben ocultar las claves de navegación cuando las aplicaciones especifican SYSTEM_UI_FLAG_HIDE_NAVIGATION .
La implementación del dispositivo debe presentar una tecla de menú para las aplicaciones cuando TargetSDKVersion <= 10 y no debe presentar una tecla de menú cuando el TargetSDKVersion> 10.

7.2.4. Entrada de pantalla táctil

Implementaciones de dispositivos:

Debe tener un sistema de entrada de puntero de algún tipo (ya sea como un mouse o tacto)
Puede tener una pantalla táctil de cualquier modalidad (como capacitiva o resistiva)
Debe admitir punteros rastreados de forma completamente independiente, si una pantalla táctil admite múltiples punteros
Debe informar el valor de android.content.res.Configuration [ recursos, 39 ] reflejando correspondiente al tipo de pantalla táctil específica en el dispositivo

Las implementaciones del dispositivo deben informar la característica correcta correspondiente al tipo de entrada utilizada. Tenga en cuenta que Android 4.2 incluye la función android.hardware.faketouch , que corresponde a un dispositivo de entrada no táctil (es decir, basado en puntero), como un mouse o un trackpad que puede emular adecuadamente la entrada táctil (incluida la entrada básica Soporte de gestos), e indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil. Las implementaciones de dispositivos que incluyen una pantalla táctil (táctil o mejor) también deben informar android.hardware.faketouch. Las implementaciones de dispositivos que no incluyen una pantalla táctil (y confían solo en un dispositivo de puntero) no deben informar ninguna función de pantalla táctil, y solo deben informar android.hardware.faketouch .

7.2.5. Micrófono

Las implementaciones de dispositivos pueden omitir un micrófono. Sin embargo, si una implementación de un dispositivo omite un micrófono, no debe informar la constante de la función android.hardware.microphone , y debe implementar la API de grabación de audio como OPS NO-OPS, según la Sección 7 . Por el contrario, las implementaciones de dispositivos que poseen un micrófono:

Debe informar la función android.hardware.microphone constante
Debe cumplir con los requisitos de calidad de audio en la Sección 5.4
Debe cumplir con los requisitos de latencia de audio en la Sección 5.5

7.3. Sensores

Android 4.2 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 de terceros, la implementación del dispositivo debe implementar esa API como se describe en la documentación SDK de Android. Por ejemplo, implementaciones del dispositivo:

Debe informar con precisión la presencia o ausencia de sensores según android.content.pm.PackageManager Clase. [ Recursos, 37 ]
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 a los oyentes, no llamar a los oyentes de los sensores cuando los sensores correspondientes no están presentes; etc.)
Debe informar todas las mediciones del sensor utilizando los valores relevantes del sistema internacional de unidades (es decir, métrica) para cada tipo de sensor como se define en la documentación SDK de Android [ recursos, 41 ]

La lista anterior no es completa; El comportamiento documentado del SDK de Android se considerará autorizado.

Algunos tipos de sensores son sintéticos, lo que significa que pueden derivarse de los datos proporcionados por uno o más otros 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 requisitos previos.

El Android 4.2 incluye una noción de un sensor de "transmisión", que es uno que devuelve los datos continuamente, en lugar de solo cuando cambia los datos. Las implementaciones del dispositivo deben proporcionar continuamente muestras de datos periódicos para cualquier API indicada por la documentación de SDK de Android 4.2 para que sea un sensor de transmisión. Tenga en cuenta que las implementaciones del dispositivo deben garantizar que la corriente del sensor no debe evitar que la CPU del dispositivo ingrese a un estado de suspensión o se despierte de un estado de suspensión.

7.3.1. Acelerómetro

Las implementaciones del dispositivo deben incluir un acelerómetro de 3 ejes. Si la implementación de un dispositivo incluye un acelerómetro de 3 ejes, TI: TI:

Debería poder entregar eventos a 120 Hz o más. Tenga en cuenta que si bien la frecuencia del acelerómetro anterior se establece como "debería" para Android 4.2, la definición de compatibilidad para una versión futura se planea cambiarlos a "debe". Es decir, estos estándares son opcionales en Android 4.2, pero se requerirán en futuras versiones. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 4.2 para cumplir con estos requisitos en Android 4.2 para que puedan actualizar a las versiones de plataforma futuras
Debe cumplir con el sistema de coordenadas del sensor Android como se detalla en las API de Android (ver [ Recursos, 41 ])
Debe ser capaz de medir desde la caída libre hasta dos veces la gravedad (2g) 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 más de 0.05 m/s^2

7.3.2. Magnetómetro

Las implementaciones del dispositivo deben incluir un magnetómetro de 3 ejes (es decir, brújula). Si un dispositivo incluye un magnetómetro de 3 ejes, TI:

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, 41 ]).
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 compensado de temperatura
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)
Debería poder entregar eventos a 200 Hz o más. Tenga en cuenta que si bien la frecuencia de giroscopio anterior se establece como "debería" para Android 4.2, la definición de compatibilidad para una versión futura está planeada para cambiarlos a "imprescindibles". Es decir, estos estándares son opcionales en Android 4.2, pero se requerirán en futuras versiones. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 4.2 para cumplir con estos requisitos en Android 4.2 para que puedan actualizar a las versiones de plataforma futuras
Debe tener 12 bits de precisión o más
Debe tener una varianza no mayor que 1e-7 rad^2 / s^2 por Hz (varianza por Hz, o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero debe estar limitada por este valor. En otras palabras, si mide la varianza del Gyro a la velocidad de muestreo de 1 Hz, no debe ser mayor que 1e-7 rad^2/s^2.
Debe tener marcas de tiempo lo más cerca posible cuando ocurrió el evento de hardware. La latencia constante debe eliminarse.

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
Debe ser compensado de temperatura

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 4.2).

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

7.4.1. Telefonía

"Telefonía" según lo utilizado por las API de Android 4.2 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 4.2 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 4.2 se puede usar en dispositivos que no incluyen hardware de telefonía. Es decir, Android 4.2 es compatible con dispositivos que no son teléfonos. Sin embargo, si una implementación de un dispositivo incluye la telefonía GSM o CDMA, debe implementar el soporte completo para la API para esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía deben implementar las API completas como NO-OPS.

7.4.2. IEEE 802.11 (wifi)

Las implementaciones del dispositivo Android 4.2 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.

Las implementaciones de dispositivos deben implementar la API de multidifusión como se describe en la documentación SDK [ recursos, 62 ]. Las implementaciones de dispositivos que incluyen soporte WiFi deben admitir DNS de multidifusión (MDN). Las implementaciones del dispositivo no deben filtrar paquetes MDNS (224.0.0.251) en cualquier momento de la operación, incluso cuando la pantalla no está en un estado activo.

7.4.2.1. Wi-Fi directo

Las implementaciones de dispositivos deben incluir soporte para WiFi Direct (WiFi Peer-to-Peer). Si una implementación de un dispositivo incluye soporte para WiFi Direct, debe implementar la API de Android correspondiente como se describe en la documentación SDK [ Recursos, 68 ]. Si una implementación de un dispositivo incluye soporte para WiFi Direct, entonces:

Debe admitir la operación WiFi regular
Debe admitir operación directa de wifi y wifi concurrente

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, 42 ]. 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, 37 ]
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)
  - Isodep (ISO 14443-4)
  - NFC Forum Tag Tipos 1, 2, 3, 4 (definido por el foro NFC)
Debe ser capaz de leer y escribir mensajes NDEF a través de los siguientes estándares NFC. Tenga en cuenta que si bien los estándares de NFC a continuación se establecen como "debería" para Android 4.2, la definición de compatibilidad para una versión futura está planeada para cambiarlos a "imprescindibles". Es decir, estos estándares son opcionales en Android 4.2, pero se requerirán en futuras versiones. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 4.2 para cumplir con estos requisitos en Android 4.2 para que puedan actualizar a las versiones de plataforma futuras.
- NFCV (ISO 15693)
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, 43 ]
- SNEP 1.0 (definido por el foro NFC)
Debe incluir soporte para Android Beam [ recursos, 65 ]:
- Debe implementar el servidor predeterminado SNEP. Los mensajes NDEF válidos recibidos por el servidor SNEP predeterminado deben enviarse a las aplicaciones utilizando Android.nfc.action_ndef_discovered intent. Desactivar el haz de Android en la configuración no debe deshabilitar el envío del mensaje NDEF entrante.
- Las implementaciones de dispositivos deben honrar el android.settings.nfcsharing_settings con la intención de mostrar la configuración de intercambio de NFC [ recursos, 67 ].
- Debe implementar el servidor NPP. Los mensajes recibidos por el servidor NPP deben procesarse de la misma manera que el servidor predeterminado SNEP.
- Debe implementar un cliente SNEP e intentar enviar P2P NDEF saliente al servidor SNEP predeterminado cuando el haz Android está habilitado. Si no se encuentra un servidor SNEP predeterminado, el cliente debe intentar enviar a un servidor NPP.
- Debe permitir que las actividades en primer plano establezcan el mensaje P2P NDEF saliente usando android.nfc.nfcadapter.setndefpushmessage y android.nfc.nfcadapter.setndefpushmessageCallback y android.nfc.nfcadapter.enableforegroundndefpush.
- Debe usar una confirmación de gesto o en pantalla, como 'toque a viga', antes de enviar mensajes NDEF salientes P2P.
- Debe habilitar el haz de Android de forma predeterminada
- Debe admitir la transferencia de conexión NFC a Bluetooth cuando el dispositivo admite el perfil de empuje de objeto Bluetooth. Las implementaciones del dispositivo deben admitir la transferencia de conexión a Bluetooth cuando use Android.nfc.nfcadapter.setBeamPushuris, implementando la "Versión de transferencia de conexión 1.2" [ recursos, 60 ] y "Bluetooth Secure Simple Pareing usando la versión 1.0" [ recursos, 61 ] desde El foro NFC. Dicha implementación debe usar solicitudes de obtención de SNEP para intercambiar la solicitud de entrega / selección de registros a través de NFC, y debe usar el perfil de empuje del objeto Bluetooth para la transferencia de datos Bluetooth real.
Debe encuestar para todas las tecnologías compatibles mientras está en el modo de descubrimiento de NFC.
Debe estar en modo de descubrimiento NFC mientras el dispositivo está despierto con la pantalla activa y la pantalla de bloqueo desbloqueada.

(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 pueden incluir soporte de lector/escritor para las siguientes tecnologías de MiFare.

Mifare Classic (NXP MF1S503X [ Recursos, 44 ], MF1S703X [ Recursos, 44 ])
Mifare Ultralight (NXP MF0ICU1 [ Recursos, 46 ], MF0ICU2 [ Recursos, 46 ])
NDEF en Mifare Classic (NXP AN130511 [ Recursos, 48 ], AN130411 [ Recursos, 49 ])

Tenga en cuenta que Android 4.2 incluye API para estos tipos de Mifare. Si una implementación de un dispositivo admite MIFARE en el rol de lector/escritor, TI: 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, 37 ] 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 del dispositivo no incluye hardware NFC, no debe declarar la función Android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature() [ Recursos, 37 ], y debe implementar la API de Android 4.2 NFC tan 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 implementado el enfoque automático por hardware o por software en el controlador de la cámara (transparente al software de la aplicación)
PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida)
PUEDE incluir un flash. Si la cámara incluye un flash, la lámpara del flash NO DEBE estar encendida mientras se haya registrado una instancia de android.hardware.Camera.PreviewCallback en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un Objeto Camera.Parameters . Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara integrada del sistema del dispositivo, sino solo a aplicaciones de terceros que utilizan Camera.PreviewCallback .

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 4.2 tiene 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, 50 ] 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 la imagen que se muestra por la visión posterior 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 Postview, 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:

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.
Si una aplicación registra una instancia android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() cuando el formato de vista previa es YCbCr_420_SP, los datos en el byte[] pasados a onPreviewFrame() deben estar además en el formato de codificación NV21. Es decir, NV21 debe ser el valor predeterminado.
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. (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxel nativo, pero la implementación del dispositivo debe admitir la conversión a YV12).

Las implementaciones de dispositivos deben implementar la API de cámara completa incluida en la documentación SDK de Android 4.2 [ recursos, 51 ]), 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. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes utilizando técnicas de imágenes de alto rango dinámico (HDR) deben admitir la Camera.SCENE_MODE_HDR de parámetros de la cámara.

Las implementaciones de dispositivos deben transmitir la Camera.ACTION_NEW_PICTURE Intent cada vez que la cámara tome una nueva imagen y la entrada de la imagen se ha agregado a la tienda de medios.

Las implementaciones de dispositivos deben transmitir la Camera.ACTION_NEW_VIDEO Intent cada vez que la cámara grabe un nuevo video y la entrada de la imagen se ha agregado a la tienda de medios.

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

7.6.1. Memoria y almacenamiento mínimos

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

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

Las API de Android incluyen un administrador de descarga que las aplicaciones pueden usar para descargar archivos de datos [ recursos, 56 ]. La implementación del dispositivo del administrador de descargas debe ser capaz de descargar archivos individuales de al menos 100 MB de tamaño a la ubicación predeterminada de "caché".

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 (UMS) o el Protocolo de transferencia de medios (MTP). Las implementaciones de dispositivos pueden usar el almacenamiento masivo USB, pero deben usar el protocolo de transferencia de medios. Si la implementación del dispositivo admite el protocolo de transferencia de medios:

La implementación del dispositivo debe ser compatible con el host MTP Android de referencia, transferencia de archivos Android [ recursos, 57 ].
La implementación del dispositivo debe informar una clase de dispositivo USB de 0x00 .
La implementación del dispositivo debe informar un nombre de interfaz USB de 'MTP'.

Si la implementación del dispositivo carece de puertos USB, debe proporcionar a una computadora de host acceso al contenido del almacenamiento compartido por otros medios, como un sistema de archivos de red.

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

Las implementaciones de dispositivos deben incluir un puerto de cliente USB e incluir un puerto de host USB.

Si una implementación de un dispositivo incluye un puerto de cliente USB:

El puerto debe ser conectable a un host USB con un puerto USB-A estándar
El puerto debe usar el factor de forma micro USB en el lado del dispositivo. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 4.2 para cumplir con estos requisitos en Android 4.2 para que puedan actualizar a las versiones de plataforma futuras
El puerto debe estar centrado en el medio de un borde. Las implementaciones del dispositivo deben ubicar el puerto en la parte inferior del dispositivo (según la orientación natural) o habilitar la rotación de la pantalla del software para todas las aplicaciones (incluida la pantalla de inicio), de modo que la pantalla se dibuja correctamente cuando el dispositivo está orientado con el puerto en la parte inferior. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 4.2 para cumplir con estos requisitos en Android 4.2 para que puedan actualizar a futuras versiones de plataforma.
Si el dispositivo tiene otros puertos (como un puerto de carga no USB), debe estar en el mismo borde que el puerto Micro-USB
Debe permitir que un host conectado al dispositivo acceda al contenido del volumen de almacenamiento compartido utilizando el almacenamiento de masa USB o el protocolo de transferencia de medios
Debe implementar la API y la especificación de Android Open Accessory como se documenta en la documentación SDK de Android, y debe declarar soporte para la función de hardware android.hardware.usb.accessory [ recursos, 52 ]
Debe implementar la clase de audio USB como se documenta en la documentación SDK de Android [ recursos, 66 ]
Debe implementar soporte para la especificación de carga de baterías USB [ recursos, 64 ] se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan Android 4.2 a cumplir con estos requisitos en Android 4.2 para que puedan actualizar a las versiones futuras de la plataforma

Si una implementación de un dispositivo incluye un puerto de host USB:

Puede usar un factor de forma de puerto no estándar, pero si es así, debe enviarse con un cable o cables que adapta el puerto al USB-A estándar
Debe implementar la API de host USB de Android como se documenta en el SDK de Android, y debe declarar soporte para la función de hardware android.hardware.usb.host [ recursos, 53 ]

Las implementaciones de dispositivos deben implementar el puente de depuración de Android. Si una implementación del dispositivo omite un puerto de cliente USB, debe implementar el puente de depuración de Android a través de la red de área local (como Ethernet o 802.11)

8. Compatibilidad de rendimiento

Las implementaciones del dispositivo deben cumplir con las métricas clave de rendimiento de un dispositivo compatible de Android 4.2 definido en la tabla a continuación:

Métrico	Umbral de rendimiento	Comentarios
Tiempo de lanzamiento de la aplicación	Las siguientes aplicaciones deben lanzarse dentro del tiempo especificado. Navegador: menos de 1300 ms Contactos: menos de 700 ms Configuración: menos de 700 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, 54 ] 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, 54 ]. 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 del dispositivo deben admitir la ejecución de múltiples aplicaciones como la misma ID de usuario de Linux, siempre que las aplicaciones estén correctamente firmadas y construidas, como se define en la referencia de seguridad y permisos [ Recursos, 54 ].

9.3. Permisos del sistema de archivos

Las implementaciones de dispositivos deben admitir el modelo de permisos de acceso a archivos Android como se define en la referencia de seguridad y permisos [ recursos, 54 ].

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.

9.5. Soporte multiusuario

Android 4.2 incluye soporte para múltiples usuarios y proporciona soporte para el aislamiento completo del usuario [ recursos, 70 ].

Las implementaciones de dispositivos deben cumplir con estos requisitos relacionados con el soporte de usuarios múltiples [ recursos, 71 ]:

Como el comportamiento de las API de telefonía en dispositivos con múltiples usuarios está actualmente indefinido, las implementaciones de dispositivos que declaran android.hardware.telephony no deben habilitar el soporte de usuarios múltiples.
Las implementaciones de dispositivos deben, para cada usuario, 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, 54]

Cada instancia de usuario en un dispositivo Android debe tener directorios de almacenamiento externos separados y aislados. Las implementaciones de dispositivos pueden almacenar los datos de varios usuarios en el mismo volumen o sistema de archivos. Sin embargo, la implementación del dispositivo debe garantizar que las aplicaciones propiedad de y en ejecución en nombre de un usuario dado no puedan enumerar, leer o escribir en datos propiedad de cualquier otro usuario. Tenga en cuenta que los medios extraíbles, como las ranuras para tarjetas SD, pueden permitir que un usuario acceda a los datos de otro mediante una PC host. Por esta razón, las implementaciones de dispositivos que usan medios extraíbles para las API de almacenamiento externos deben cifrar el contenido de la tarjeta SD si el usuario múltiple está habilitado utilizando una clave almacenada solo en medios no remotables accesibles solo al sistema. Como esto hará que los medios sean ilegibles por una PC host, las implementaciones de dispositivos deberán cambiar a MTP o un sistema similar para proporcionar a las PC host con acceso a los datos del usuario actual. En consecuencia, las implementaciones de dispositivos pueden, pero no deben habilitar el usuario múltiple si usan medios extraíbles [ recursos, 72 ] para el almacenamiento externo primario. El proyecto de código abierto de Android Upstream incluye una implementación que utiliza el almacenamiento interno del dispositivo para la aplicación API de almacenamiento externo; Las implementaciones de dispositivos deben usar esta configuración e implementación de software. Las implementaciones de dispositivos que incluyen múltiples rutas de almacenamiento externas no deben permitir que las aplicaciones de Android escriban en el almacenamiento externo secundario

9.6. Advertencia de SMS premium

Android 4.2 incluye soporte para los usuarios de advertencia para cualquier mensaje SMS premium saliente. Los mensajes SMS premium son mensajes de texto enviados a un servicio registrado con un operador que puede incurrir en un cargo al usuario. Implementaciones de dispositivos que declaran soporte para android.hardware.telephony deben advertir a los usuarios antes de enviar un mensaje SMS a los números identificados por expresiones regulares definidas en /data/misc/sms/codes.xml archivo en el dispositivo. El proyecto de código abierto Android ascendente proporciona una implementación que satisface este requisito.

10. Pruebas de compatibilidad de software

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 4.2 disponible en el proyecto de código abierto de Android. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

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. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Las implementaciones de dispositivos deben pasar la última versión CTS disponible en el momento en que se completa el software del dispositivo.

10.2. Verificador CTS

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. Reference Applications

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Android Market)

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. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

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. That is, the update mechanism MUST preserve application private data and application shared data. Tenga en cuenta que el software Android ascendente incluye un mecanismo de actualización que satisface este requisito.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a 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. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. El procedimiento requiere dos dispositivos:

Una implementación de dispositivos candidatos que ejecuta la compilación de software para ser probado
a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

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

Configuración e instalación

Build BluetoothChat.apk via 'make samples' from an Android source code tree
Install BluetoothChat.apk on the known-good device
Install BluetoothChat.apk on the candidate device

Pruebe el control de Bluetooth por aplicaciones

Launch BluetoothChat on the candidate device, while Bluetooth is disabled
Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth

Emparejamiento de pruebas y comunicación

Launch the Bluetooth Chat app on both devices
Make the known-good device discoverable from within BluetoothChat (using the Menu)
On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device
Send 10 or more messages from each device, and verify that the other device receives them correctly
Close the BluetoothChat app on both devices by pressing Home
Unpair each device from the other, using the device Settings app

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

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

Realicias de prueba

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

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