Revisión 1
Última actualización: 12 de enero de 2015

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

Tabla de contenido

1. Introducción

Este documento enumera los requisitos que se deben cumplir para que los dispositivos sean compatibles con Android 5.0.

El uso de "DEBE", "NO DEBE", "REQUERIDO", "DEBE", "NO DEBE", "DEBE", "NO DEBE", "RECOMENDADO", "PUEDE" y "OPCIONAL" es según el 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 5.0. Una "implementación de dispositivo" o "implementación" es la solución de hardware/software así desarrollada.

Para ser considerada compatible con Android 5.0, 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, 2 ] es tanto la referencia como la implementación 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.

Muchos de los recursos enumerados en la sección 14 se derivan directa o indirectamente del SDK de Android 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 en la sección 14 se considera por inclusión parte de esta Definición de Compatibilidad.

2. Tipos de dispositivos

Si bien el Proyecto de código abierto de Android se ha utilizado en la implementación de una variedad de tipos de dispositivos y factores de forma, muchos aspectos de la arquitectura y los requisitos de compatibilidad se optimizaron para dispositivos portátiles. A partir de Android 5.0, el Proyecto de código abierto de Android pretende abarcar una variedad más amplia de tipos de dispositivos, como se describe en esta sección.

Dispositivo portátil Android se refiere a una implementación de dispositivo Android que normalmente se usa sosteniéndolo en la mano, como reproductores de mp3, teléfonos y tabletas. Implementaciones de dispositivos portátiles Android:

• DEBE tener una pantalla táctil integrada en el dispositivo
• DEBE tener una fuente de energía que proporcione movilidad, como una batería.

Dispositivo Android Television se refiere a una implementación de dispositivo Android que es una interfaz de entretenimiento para consumir medios digitales, películas, juegos, aplicaciones y/o TV en vivo para usuarios sentados a unos diez pies de distancia (una “interfaz de usuario reclinada” o “de 10 pies”). ”). Dispositivos de televisión Android:

• DEBE tener una pantalla integrada O incluir un puerto de salida de video, como VGA, HDMI o un puerto inalámbrico para visualización
• DEBE declarar las características android.software.leanback y android.hardware.type.television [ Recursos, 3 ]

Dispositivo Android Watch se refiere a una implementación de dispositivo Android destinada a usarse en el cuerpo, quizás en la muñeca, y:

• DEBE tener una pantalla con una longitud diagonal física en el rango de 1,1 a 2,5 pulgadas.
• DEBE declarar la característica android.hardware.type.watch
• DEBE admitir uiMode = UI_MODE_TYPE_WATCH [ Recursos, 4 ]

Todas las implementaciones de dispositivos Android que no se ajusten a ninguno de los tipos de dispositivos anteriores DEBEN cumplir con todos los requisitos de este documento para ser compatibles con Android 5.0, a menos que se describa explícitamente que el requisito solo es aplicable a un tipo de dispositivo Android específico.

2.1 Configuraciones del dispositivo

Este es un resumen de las principales diferencias en la configuración de hardware por tipo de dispositivo. (Las celdas vacías indican "MAYO"). No todas las configuraciones están cubiertas en esta tabla; consulte las secciones de hardware relevantes para obtener más detalles.

3.software

3.1. Compatibilidad de API administrada

El entorno de ejecución de bytecode administrado de 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 ejecución administrado. Las implementaciones de dispositivos DEBEN proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android [ Recursos, 5 ] o cualquier API decorada con el marcador "@SystemApi" en el código fuente de Android.

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 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, 6] . Tenga en cuenta que la sección 9 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, 7 ] que están destinadas a describir el dispositivo actual. Para proporcionar valores coherentes y significativos en todas las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que DEBEN ajustarse las implementaciones de dispositivos.

3.2.3. Compatibilidad de intenciones

Las implementaciones de dispositivos DEBEN respetar el sistema de intención 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 que 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

Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidad de otros componentes de Android. El proyecto ascendente de Android incluye una lista de aplicaciones consideradas aplicaciones principales de Android, que implementa varios patrones de intención para realizar acciones comunes. Las aplicaciones principales de Android son:

• Reloj de escritorio
• Navegador
• Calendario
• Contactos
• Galería
• Búsqueda global
• Lanzacohetes
• Música
• Ajustes

Las implementaciones de dispositivos DEBEN incluir las aplicaciones principales de Android según corresponda, pero DEBEN incluir un componente que implemente los mismos patrones de intención definidos por todos los componentes de Actividad o Servicio "públicos" de estas aplicaciones principales de Android. Tenga en cuenta que los componentes de Actividad o Servicio se consideran "públicos" cuando el atributo android:exported está ausente o tiene el valor verdadero.

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.1 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 intención 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 intención nueva o patrón de 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 intención nueva o patrón de intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete que pertenezca 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 intentos de notificarles sobre cambios en el entorno de hardware o software. Los dispositivos compatibles con Android DEBEN transmitir las intenciones de transmisión pública en respuesta a los eventos apropiados del sistema. Los intentos de transmisión se describen en la documentación del SDK.

3.2.3.5. Configuración predeterminada de la aplicación

Android incluye configuraciones que brindan a los usuarios una manera fácil de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla de inicio o SMS. Cuando tenga sentido, las implementaciones de dispositivos DEBEN proporcionar un menú de configuración similar y ser compatibles con el patrón de filtro de intención y los métodos API que se describen en la documentación del SDK como se muestra a continuación.

Implementaciones de dispositivos:

• DEBE respetar la intención de android.settings.HOME_SETTINGS de mostrar un menú de configuración de aplicación predeterminado para la pantalla de inicio, si la implementación del dispositivo informa android.software.home_screen [ Recursos, 10]
• DEBE proporcionar un menú de configuración que llame a la intención android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar un cuadro de diálogo para cambiar la aplicación de SMS predeterminada, si la implementación del dispositivo informa android.hardware.telephony [ Recursos, 9 ]
• DEBE respetar la intención de android.settings.NFC_PAYMENT_SETTINGS de mostrar un menú de configuración de aplicación predeterminado para Tap and Pay, si la implementación del dispositivo informa android.hardware.nfc.hce [ Recursos, 10]

3.3. Compatibilidad API nativa

3.3.1 Interfaces binarias de aplicaciones

El código de bytes de Dalvik administrado 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. Las implementaciones de dispositivos DEBEN ser compatibles con una o más ABI definidas y DEBEN implementar 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 admitir la ABI de 32 bits equivalente si se admite alguna ABI de 64 bits
• DEBE informar con precisión la interfaz binaria de aplicación (ABI) nativa admitida por el dispositivo, a través de los parámetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS y android.os.Build.SUPPORTED_64_BIT_ABIS, cada uno de los cuales es una lista separada por comas de ABI ordenados del más al menos preferido
• DEBE informar, a través de los parámetros anteriores, solo aquellas ABI documentadas en la última versión del NDK de Android, “Guía del programador del NDK | Gestión de ABI” en el directorio docs/
• 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.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• 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)
• libmediandk.so (soporte de API de medios nativos)
• 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.

Tenga en cuenta que las implementaciones de dispositivos DEBEN incluir libGLESv3.so y DEBE vincular simbólicamente (enlace simbólico) a libGLESv2.so. a su vez, DEBE exportar todos los símbolos de función de OpenGL ES 3.1 y Android Extension Pack [ Recursos, 11 ] tal como se define en la versión android-21 del NDK. Aunque todos los símbolos deben estar presentes, sólo se deben implementar completamente las funciones correspondientes a las versiones y extensiones de OpenGL ES realmente compatibles con el dispositivo.

La compatibilidad del código nativo es un desafío. Por este motivo, se recomienda encarecidamente a los implementadores de dispositivos que utilicen las implementaciones de las bibliotecas enumeradas anteriormente del Proyecto de código abierto de Android.

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

La característica de la plataforma android.software.webview DEBE informarse en cualquier dispositivo que proporcione una implementación completa de la API android.webkit.WebView, y NO DEBE informarse en dispositivos sin una implementación completa de la API. La implementación de código abierto de Android utiliza código del Proyecto Chromium para implementar android.webkit.WebView [ Recursos, 12 ]. 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 Chromium en la implementación de WebView. Específicamente:

• Las implementaciones del dispositivo android.webkit.WebView DEBEN basarse en la compilación de Chromium del proyecto de código abierto de Android para Android 5.0. Esta compilación incluye un conjunto específico de funcionalidades y correcciones de seguridad para WebView [ Recursos, 13 ].
• La cadena del agente de usuario informada por WebView DEBE tener este formato:

Mozilla/5.0 (Linux; Android $(VERSIÓN); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, como Gecko) Versión/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

• El valor de la cadena $(VERSION) DEBE ser el mismo que el valor de android.os.Build.VERSION.RELEASE.
• El valor de la cadena $(MODEL) DEBE ser el mismo que el valor de android.os.Build.MODEL.
• El valor de la cadena $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID.
• El valor de la cadena $(CHROMIUM_VER) DEBE ser la versión de Chromium en el proyecto de código abierto de Android ascendente.
• Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del agente de usuario.

El componente WebView DEBE incluir soporte para tantas funciones HTML5 como sea posible y, si es compatible, la función DEBE ajustarse a la especificación HTML5 [ Recursos, 14 ].

3.4.2. Compatibilidad del navegador

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, 14 ] 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, 15 ]
• el
• geolocalización [ Recursos, 17 ]

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

3.5. Compatibilidad de comportamiento de API

Los comportamientos de cada uno de los tipos de API (administrado, software, nativo y web) deben ser coherentes con la implementación preferida del Proyecto de código abierto de Android ascendente [ Recursos, 2 ]. Algunas áreas específicas de compatibilidad son:

• Los dispositivos NO DEBEN cambiar el comportamiento o la semántica de una intención 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 espacio de nombres com.google.* o similar: solo 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 de la mecanismo) se ven afectados 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 en tiempo de ejecución

Las implementaciones de dispositivos DEBEN admitir el formato Dalvik Executable (DEX) completo y la especificación y semántica del código de bytes de Dalvik [ Recursos, 20 ]. Los implementadores de dispositivos DEBEN utilizar ART, la implementación ascendente de referencia del formato ejecutable Dalvik y el sistema de gestión de paquetes de la implementación de referencia.

Las implementaciones de dispositivos DEBEN configurar los tiempos de ejecución de 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.

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Lanzador (pantalla de inicio)

Android incluye una aplicación de inicio (pantalla de inicio) y soporte para aplicaciones de terceros para reemplazar el iniciador del dispositivo (pantalla de inicio). Las implementaciones de dispositivos que permiten que aplicaciones de terceros reemplacen la pantalla de inicio del dispositivo DEBEN declarar la función de plataforma android.software.home_screen.

3.8.2. widgets

Android define un tipo de componente y una API y un ciclo de vida correspondientes que permiten a las aplicaciones exponer un "AppWidget" al usuario final [ Recursos, 21 ] una característica que se RECOMIENDA encarecidamente que sea compatible con implementaciones de dispositivos portátiles. Las implementaciones de dispositivos que admiten la incorporación de widgets en la pantalla de inicio DEBEN cumplir con los siguientes requisitos y declarar compatibilidad con la función de plataforma android.software.app_widgets.

• Los lanzadores de dispositivos 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.
• 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, 21 ] para obtener más detalles.
• Las implementaciones de dispositivos que incluyen soporte para la pantalla de bloqueo PUEDEN admitir widgets de aplicaciones en la pantalla de bloqueo.

3.8.3. Notificaciones

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

Algunas API permiten que las aplicaciones realicen notificaciones o atraigan 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. 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, 23 ], o en la guía de estilo de iconos de la barra de estado/sistema [ Recursos, 24 ]. 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 incluye soporte para varias notificaciones, como:

• Notificaciones enriquecidas: vistas interactivas para notificaciones en curso.
• Notificaciones de aviso: los usuarios de Vistas interactivas pueden actuar o descartar sin salir de la aplicación actual.
• Notificaciones en la pantalla de bloqueo: notificaciones que se muestran en una pantalla de bloqueo con control granular de la visibilidad.

Las implementaciones de dispositivos DEBEN mostrar y ejecutar correctamente estas notificaciones, incluido el título/nombre, icono y texto, como se documenta en las API de Android [Recursos, 25] .

Android incluye API del servicio de escucha de notificaciones que permiten que las aplicaciones (una vez habilitadas explícitamente por el usuario) reciban una copia de todas las notificaciones a medida que se publican o actualizan. Las implementaciones de dispositivos DEBEN enviar notificaciones correcta y oportunamente en su totalidad a todos los servicios de escucha instalados y habilitados por el usuario, incluidos todos y cada uno de los metadatos adjuntos al objeto de notificación.

3.8.4. Buscar

Android incluye API [ Recursos, 26 ] 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 Android DEBEN incluir búsqueda global, 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 que implementan la interfaz de búsqueda global 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.5. Brindis

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

3.8.6. Temas

Android proporciona "temas" como mecanismo para que las aplicaciones apliquen estilos en toda una actividad o aplicación.

Android incluye una familia de temas "Holo" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los utilicen si desean igualar la apariencia del tema Holo según lo definido por el SDK de Android [ Recursos, 28 ]. Las implementaciones de dispositivos NO DEBEN alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones [ Recursos, 29 ].

Android 5.0 incluye una familia de temas "Material" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los utilicen si desean igualar la apariencia del tema de diseño en la amplia variedad de diferentes tipos de dispositivos Android. Las implementaciones de dispositivos DEBEN admitir la familia de temas "Material" y NO DEBEN alterar ninguno de los atributos del tema Material ni sus activos expuestos a las aplicaciones [ Recursos, 30 ].

Android también incluye una familia de temas "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 predeterminado del dispositivo expuestos a las aplicaciones [ Recursos, 29 ].

Android admite una nueva variante de tema con barras de sistema translúcidas, que permite a los desarrolladores de aplicaciones llenar el área detrás de la barra de estado y navegación con el contenido de su aplicación. Para permitir una experiencia de desarrollador consistente en esta configuración, es importante que el estilo del ícono de la barra de estado se mantenga en diferentes implementaciones de dispositivos. Por lo tanto, las implementaciones de dispositivos Android DEBEN usar blanco para los íconos de estado del sistema (como la intensidad de la señal y el nivel de la batería) y las notificaciones emitidas por el sistema, a menos que el ícono indique un estado problemático [ Recursos, 29 ].

3.8.7. 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, 31 ]. Los fondos de pantalla en vivo 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 en vivo pueden usar un contexto OpenGL 2.0 o 3.x 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 y, cuando se implementen, DEBEN informar el indicador de función de la plataforma android.software.live_wallpaper.

3.8.8. Cambio de actividad

El código fuente de Android incluye la pantalla de descripción general [ Recursos, 32 ], una interfaz de usuario a nivel de sistema para cambiar de tarea y mostrar actividades y tareas a las que se accedió recientemente 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, incluida la tecla de navegación de función reciente, como se detalla en la sección 7.2.3 , PUEDEN alterar la interfaz, pero DEBEN cumplir con los siguientes requisitos:

• DEBE mostrar los afiliados recientes como un grupo que se mueve en conjunto
• DEBE admitir al menos hasta 20 actividades mostradas
• DEBE mostrar al menos el título de 4 actividades a la vez
• DEBE mostrar el color de resaltado, el ícono y el título de la pantalla en los últimos tiempos
• DEBE implementar el comportamiento de fijación de pantalla [ Recursos, 33 ] y proporcionar al usuario un menú de configuración para alternar la función
• DEBE mostrar una opción de cierre ("x") pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas

Se RECOMIENDA ENCARECIDAMENTE que las implementaciones de dispositivos utilicen la interfaz de usuario de Android (o una interfaz similar basada en miniaturas) para la pantalla de descripción general.

3.8.9. Gestión de entradas

Android incluye soporte para administración de entradas y soporte para editores de métodos de entrada de terceros [ Recursos, 34 ]. Las implementaciones de dispositivos que permiten a los usuarios utilizar métodos de entrada de terceros en el dispositivo DEBEN declarar la función de plataforma android.software.input_methods y admitir API de IME como se define en la documentación del SDK de Android.

Las implementaciones de dispositivos que declaran la función android.software.input_methods DEBEN proporcionar un mecanismo accesible para el usuario para agregar y configurar métodos de entrada de terceros. Las implementaciones de dispositivos DEBEN mostrar la interfaz de configuración en respuesta a la intención de android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Control de medios de pantalla de bloqueo

La API del cliente de control remoto está obsoleta en Android 5.0 en favor de la plantilla de notificación de medios que permite que las aplicaciones multimedia se integren con los controles de reproducción que se muestran en la pantalla de bloqueo [ Recursos, 35 ]. Las implementaciones de dispositivos que admiten una pantalla de bloqueo en el dispositivo DEBEN admitir la plantilla de notificación de medios junto con otras notificaciones.

3.8.11. Sueños

Android incluye soporte para protectores de pantalla interactivos llamados Dreams [ Recursos, 36 ]. Dreams permite a los usuarios interactuar con aplicaciones cuando un dispositivo conectado a una fuente de energía está inactivo o acoplado a una base de escritorio. Los dispositivos Android Watch PUEDEN implementar Dreams, pero otros tipos de implementaciones de dispositivos DEBEN incluir soporte para Dreams y brindar una opción de configuración para que los usuarios configuren Dreams en respuesta a la intención android.settings.DREAM_SETTINGS.

3.8.12. Ubicación

Cuando un dispositivo tiene un sensor de hardware (por ejemplo, GPS) que es capaz de proporcionar las coordenadas de ubicación, los modos de ubicación DEBEN mostrarse en el menú Ubicación dentro de Configuración [ Recursos, 37 ].

3.8.13. Unicode y fuente

Android incluye soporte para caracteres emoji de colores. Cuando las implementaciones de dispositivos Android incluyen un IME, los dispositivos DEBEN proporcionar un método de entrada al usuario para los caracteres Emoji definidos en Unicode 6.1 [ Recursos, 38 ]. Todos los dispositivos DEBEN ser capaces de representar estos caracteres emoji en glifos de color.

Android 5.0 incluye soporte para la fuente Roboto 2 con diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light. todos DEBEN estar incluidos para los idiomas disponibles en el dispositivo y la cobertura completa de Unicode 7.0 de latín, griego y cirílico, incluidos los rangos de latín extendido A, B, C y D, y todos los glifos en el bloque de símbolos de moneda de Unicode 7.0. .

3.9. Administración de dispositivos

Android incluye funciones que permiten que las aplicaciones conscientes de la seguridad realicen funciones de administración del dispositivo 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, 39 ]. Las implementaciones de dispositivos DEBEN proporcionar una implementación de la clase DevicePolicyManager [ Recursos, 40 ]. Las implementaciones de dispositivos que incluyen soporte para la pantalla de bloqueo DEBEN admitir la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android [ Recursos, 39 ] e informar la función de la plataforma android.software.device_admin.

Las implementaciones de dispositivos PUEDEN tener una aplicación preinstalada que realiza funciones de administración del dispositivo, pero esta aplicación NO DEBE configurarse de fábrica como la aplicación predeterminada del propietario del dispositivo [ Recursos, 41 ].

3.10. Accesibilidad

Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos más fácilmente. Además, Android 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, 42 ]. Las implementaciones de dispositivos DEBEN proporcionar una implementación del marco de accesibilidad de Android coherente con la implementación predeterminada de Android. Las implementaciones de dispositivos DEBEN cumplir los siguientes requisitos:

• DEBE admitir implementaciones de servicios de accesibilidad de terceros a través de las API de android.accessibilityservice [ Recursos, 43 ]
• DEBE generar AccessibilityEvents y entregar estos eventos a todas las implementaciones registradas de AccessibilityService de manera consistente con la implementación predeterminada de Android.
• A menos que sea un dispositivo Android Watch sin salida de audio, las implementaciones del dispositivo 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 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, 44 ].

3.11. Texto a voz

Android 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, 45 ]. Las implementaciones de dispositivos que informan la función android.hardware.audio.output DEBEN cumplir con estos requisitos relacionados con el marco TTS de Android.

Implementaciones de dispositivos:

• DEBE admitir las API del marco TTS de Android y DEBE 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.
• DEBE admitir la instalación de motores TTS de terceros
• DEBE proporcionar una interfaz accesible para el usuario que les permita seleccionar un motor TTS para su uso a nivel del sistema.

3.12. Marco de entrada de TV

Android Television Input Framework (TIF) simplifica la entrega de contenido en vivo a dispositivos Android Television. TIF proporciona una API estándar para crear módulos de entrada que controlan dispositivos Android Television. Las implementaciones de dispositivos Android Television DEBEN admitir Television Input Framework [ Recursos, 46 ].

Las implementaciones de dispositivos que admiten TIF DEBEN declarar la función de plataforma android.software.live_tv.

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

Las implementaciones de dispositivos NO DEBEN extender los formatos .apk [ Recursos, 48 ], Android Manifest [ Recursos, 49 ], código de bytes de Dalvik [ Recursos, 20 ] o código de bytes de RenderScript de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles

5. Compatibilidad multimedia

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, 50 ], 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 garantizan que estos códecs estén libres de 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.

5.1.1. Códecs de audio

1 Requerido para implementaciones de dispositivos que definen android.hardware.microphone pero opcional para implementaciones de dispositivos Android Watch.

2 Sólo se requiere una mezcla descendente de contenido 5.0/5.1; Grabar o renderizar más de 2 canales es opcional.

3 Requerido para implementaciones de dispositivos portátiles Android.

4 Requerido para implementaciones de dispositivos que definen android.hardware.microphone, incluidas las implementaciones de dispositivos Android Watch.

5.1.2. Códecs de imagen

5.1.3. Códecs de vídeo

1 Requerido para implementaciones de dispositivos que incluyen hardware de cámara y definen android.hardware.camera o android.hardware.camera.front.

2 Requerido para implementaciones de dispositivos excepto dispositivos Android Watch.

3 Para una calidad aceptable de los servicios de videoconferencia y transmisión de video web, las implementaciones de dispositivos DEBEN usar un códec de hardware VP8 que cumpla con los requisitos en [ Recursos, 51 ].

4 Las implementaciones de dispositivos DEBEN admitir la escritura de archivos Matroska WebM.

5.2. Codificación de vídeo

Las implementaciones de dispositivos Android con compatibilidad con el códec H.264 DEBEN admitir el perfil base nivel 3 y los siguientes perfiles de codificación de video SD (definición estándar) y DEBEN admitir el perfil principal nivel 4 y los siguientes perfiles de codificación de video HD (alta definición). Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android Television codifiquen vídeo HD de 1080p a 30 fps.

1 Cuando es compatible con hardware, pero SE RECOMIENDA ENCARECIDAMENTE para dispositivos Android Television.

Las implementaciones de dispositivos Android con compatibilidad con el códec VP8 DEBEN admitir los perfiles de codificación de video SD y DEBEN admitir los siguientes perfiles de codificación de video HD (alta definición).

1 Cuando lo admite el hardware.

5.3. Decodificación de vídeo

Las implementaciones de dispositivos DEBEN admitir la conmutación dinámica de resolución de video dentro del mismo flujo para los códecs VP8, VP9, ​​H.264 y H.265.

Las implementaciones de dispositivos Android con decodificadores H.264 DEBEN admitir el perfil base nivel 3 y los siguientes perfiles de decodificación de video SD y DEBEN admitir los perfiles de decodificación HD. Los dispositivos Android Television DEBEN admitir High Profile Level 4.2 y el perfil de decodificación HD 1080p.

1 Requerido para implementaciones de dispositivos Android Television, pero para otros tipos de dispositivos solo cuando son compatibles con el hardware.

2 Requerido para implementaciones de dispositivos Android Television.

Las implementaciones de dispositivos Android cuando admiten el códec VP8 como se describe en la sección 5.1.3 , DEBEN admitir los siguientes perfiles de decodificación SD y DEBEN admitir los perfiles de decodificación HD. Los dispositivos Android Television DEBEN admitir el perfil de decodificación HD 1080p.

1 Requerido para implementaciones de dispositivos Android Television, pero para otros tipos de dispositivos solo cuando son compatibles con el hardware.

2 Requerido para implementaciones de dispositivos Android Television.

Las implementaciones de dispositivos Android, cuando admiten el códec VP9 como se describe en la sección 5.1.3 , DEBEN admitir los siguientes perfiles de decodificación de video SD y DEBEN admitir los perfiles de decodificación HD. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android Television admitan el perfil de decodificación HD 1080p y DEBEN admitir el perfil de decodificación UHD. Cuando se admite el perfil de decodificación de video UHD, DEBE admitir una profundidad de color de 8 bits.

1 Requerido para implementaciones de dispositivos Android Television, pero para otros tipos de dispositivos solo cuando son compatibles con el hardware.

2 MUY RECOMENDADO para implementaciones de dispositivos Android Television cuando sean compatibles con el hardware.

Las implementaciones de dispositivos Android, al admitir el códec H.265 como se describe en la Sección 5.1.3 , deben admitir el nivel principal del Nivel 3 de perfil principal y los siguientes perfiles de decodificación de video SD y deben admitir los perfiles de decodificación HD. Los dispositivos de televisión de Android deben admitir el nivel principal del nivel de perfil principal 4.1 y el perfil de decodificación HD 1080p y deben admitir el perfil de nivel principal de nivel 5 de Main10 y el perfil de decodificación de UHD.

1 Requerido para la implementación del dispositivo de televisión Android, pero para otro tipo de dispositivos solo cuando lo admiten hardware.

2 Requerido para implementaciones de dispositivos de televisión Android cuando lo compatible con hardware.

5.4. Grabación de audio

Si bien algunos de los requisitos descritos en esta sección se establecen como debería desde Android 4.3, la definición de compatibilidad para una versión futura está planeada para cambiarlos a Must. Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a cumplir con estos requisitos, o no podrán alcanzar la compatibilidad de Android cuando se actualicen a la versión futura.

5.4.1. Captura de audio sin procesar

Implementaciones de dispositivos que declaran android.hardware.microphone deben permitir la captura de contenido de audio sin procesar con las siguientes características:

• Formato : PCM lineal, 16 bits
• Tasas de muestreo : 8000, 11025, 16000, 44100
• Canales : mono

Las implementaciones de dispositivos que declaran android.hardware.microphone deberían permitir la captura de contenido de audio sin procesar con las siguientes características:

• Formato : PCM lineal, 16 bits
• Tasas de muestreo : 22050, 48000
• Canales : estéreo

5.4.2. Captura para reconocimiento de voz

Además de las especificaciones de grabación anteriores, cuando una aplicación ha comenzado a grabar una transmisión de audio usando Android.Media.MediarCorder.audiosource.voice_recognition Fuente de audio:

• El dispositivo debe exhibir características de amplitud aproximadamente planas versus frecuencia: específicamente, ± 3 dB, de 100 Hz a 4000 Hz.
• La sensibilidad de entrada de audio debe establecerse de tal manera que una fuente de nivel de potencia de sonido de 90 dB (SPL) a 1000 Hz produce 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 SPL de 90 dB en el micrófono.
• El procesamiento de reducción de ruido, si está presente, debe deshabilitarse.
• El control de ganancia automática, si está presente, debe deshabilitarse

Si la plataforma admite tecnologías de supresión de ruido sintonizadas para el reconocimiento de voz, el efecto debe ser controlable desde Android.media.audiofx.NoisesUpsor API. Además, el campo UUID para el descriptor de efecto del supresor de ruido debe identificar de manera única cada implementación de la tecnología de supresión de ruido.

5.4.3. Captura para redirigir la reproducción

La clase android.media.mediarecorder.audiosurce incluye la fuente de audio remoto_submix. Los dispositivos que declaran android.hardware.audio.output deben implementar correctamente la fuente de audio remoto_submix para que cuando una aplicación use la API android.media.audiorecord para grabar desde esta fuente de audio, puede capturar una combinación de todas las transmisiones de audio, excepto para la siguiente :

• Stream_ring
• Stream_alarm
• Stream_notificación

5.5. Reproducción de audio

Las implementaciones de dispositivos que declaran android.hardware.audio.output deben cumplir con los requisitos en esta sección.

5.5.1. Reproducción de audio sin procesar

El dispositivo debe permitir la reproducción del contenido de audio sin procesar con las siguientes características:

• Formato : PCM lineal, 16 bits
• Tasas de muestreo : 8000, 11025, 16000, 22050, 32000, 44100
• Canales : mono, estéreo

El dispositivo debe permitir la reproducción del contenido de audio sin procesar con las siguientes características:

• Tasas de muestreo : 24000, 48000

5.5.2. Efectos de audio

Android proporciona una API para los efectos de audio para las implementaciones de dispositivos [ recursos, 52 ]. Implementaciones de dispositivos que declaran la función android.hardware.audio.output:

• Debe admitir las implementaciones de Effect_Type_Equalizer y Effect_Type_loudness_enhancer controlables a través del ecualizador de subclases de audiofectas, LoudnessenHancer
• Debe admitir la implementación de la API de visualizador, controlable a través de la clase Visualizer
• Debe admitir el efecto_type_bass_boost, effect_type_env_reverb, effect_type_preset_reverb y las implementaciones de effect_type_virtualizer controlables a través de los subclases de audio bassboost, EnvironmentalReverb, Presetreverb y Virtualizer

5.5.3. Volumen de salida de audio

Las implementaciones de dispositivos de televisión de Android deben incluir soporte para el volumen maestro del sistema y la atenuación de volumen de salida de audio digital en salidas compatibles, excepto para la salida de paso de audio comprimida (donde no se realiza una decodificación de audio en el dispositivo).

5.6. 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 dependen de latencias cortas, para lograr efectos de sonido en tiempo real.

Para los fines de esta sección, use las siguientes definiciones:

• Latencia de salida : el intervalo entre cuando una aplicación escribe un marco de datos codificados por PCM y cuándo un oyente externo puede escuchar el sonido correspondiente u observado por un transductor.
• Latencia de salida de frío : la latencia de salida para la primera trama, cuando el sistema de salida de audio ha sido inactivo y apagado antes de la solicitud.
• Latencia de salida continua : la latencia de salida para marcos posteriores, después de que el dispositivo reproduce audio.
• Latencia de entrada : el intervalo entre cuando se presenta un sonido externo al dispositivo y cuando una aplicación lee el marco correspondiente de los datos codificados por PCM.
• Latencia de entrada de frío : la suma del tiempo de entrada perdido y la latencia de entrada para el primer cuadro, cuando el sistema de entrada de audio ha sido inactivo y apagado antes de la solicitud.
• Latencia de entrada continua : la latencia de entrada para marcos posteriores, mientras que el dispositivo está capturando audio.
• Fitter de salida en frío : la varianza entre las mediciones separadas de los valores de latencia de salida de frío.
• Fitter de entrada de frío : la varianza entre las mediciones separadas de los valores de latencia de entrada de frío.
• Latencia continua de ida y vuelta : la suma de latencia de entrada continua más latencia de salida continua más 5 milisegundos.
• OPENSL ES PCM Buffer Queue API : el conjunto de API OPENSL ES relacionadas con PCM dentro de Android NDK; Ver NDK_ROOT/DOCS/OPENSLES/Index.html.

Las implementaciones de dispositivos que declaran android.hardware.audio.output deben cumplir o exceder estos requisitos de salida de audio:

• Latencia de salida en frío de 100 milisegundos o menos.
• Latencia de salida continua de 45 milisegundos o menos.
• Minimizar el jitter de salida de frío

Si una implementación de un dispositivo cumple con los requisitos de esta sección después de cualquier calibración inicial cuando se usa la API de cola de búfer PCM OPENSL ES, para la latencia de salida continua y la latencia de salida de frío en al menos un dispositivo de salida de audio compatible, puede informar el soporte de audio de baja latencia , informando la función android.hardware.audio.low_latency a través de android.content.pm.packageManager class [ recursos, 53 ]. Por el contrario, si la implementación del dispositivo no cumple con estos requisitos, no debe informar soporte para audio de baja latencia.

Las implementaciones de dispositivos que incluyen android.hardware.microphone deben cumplir con estos requisitos de audio de entrada:

• Latencia de entrada en frío de 100 milisegundos o menos.
• Latencia de entrada continua de 30 milisegundos o menos
• Latencia de ida y vuelta continua de 50 milisegundos o menos
• Minimizar el jitter de entrada de frío

5.7. Protocolos de red

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

• RTSP (RTP, SDP)
• HTTP (s) transmisión progresiva
• HTTP (S) Protocolo de borrador de transmisión en vivo, versión 3 [ Recursos, 54 ]

5.8. Medios seguros

Las implementaciones de dispositivos que admiten la salida de video segura y son capaces de admitir superficies seguras deben declarar soporte para display.flag_secure. Las implementaciones de dispositivos que declaran soporte para display.flag_secure, si admiten un protocolo de visualización inalámbrica, deben asegurar el enlace con un mecanismo criptográficamente fuerte como HDCP 2.x o superior para pantallas inalámbricas de Miracast. De manera similar, si admiten una pantalla externa con cable, las implementaciones del dispositivo deben admitir HDCP 1.2 o superior. Las implementaciones de dispositivos de televisión de Android deben admitir HDCP 2.2 para dispositivos que admiten la resolución 4K y HDCP 1.4 o superior para resoluciones más bajas. La implementación de código abierto de Android Upstream incluye soporte para pantallas inalámbricas (Miracast) y Wired (HDMI) que satisfacen este requisito.

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. Los dispositivos compatibles con Android deben ser compatibles con:

• Android Debug Bridge (ADB) [ Recursos, 55 ]

Las implementaciones de dispositivos deben admitir todas las funciones de ADB como se documenta en el SDK de Android, incluidos Dumpsys [ recursos, 56 ]. El demonio ADB del lado del dispositivo debe estar inactivo de forma predeterminada y debe haber un mecanismo accesible para el usuario para activar el puente de depuración de Android. Si una implementación del dispositivo omite el modo periférico USB, debe implementar el puente de depuración de Android a través de la red del área local (como Ethernet o 802.11).

Android incluye soporte para ADB seguro. Secure ADB habilita ADB en hosts autenticados conocidos. Las implementaciones del dispositivo deben admitir ADB seguro.

• Dalvik Depug Monitor Service (DDMS) [ Recursos, 57 ]

Las implementaciones de dispositivos DEBEN admitir todas las funciones de ddms como se documenta en el SDK de Android. Como DDMS usa ADB, el soporte para DDMS debe estar inactivo de forma predeterminada, pero debe ser compatible cada vez que el usuario haya activado el puente de depuración de Android, como se indicó anteriormente.

• Mono [ recursos, 58 ]

Las implementaciones de dispositivos DEBEN incluir el marco Monkey y ponerlo a disposición de las aplicaciones.

• Systrace [ Recursos, 59 ]

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 dispositivos Android utilizando las herramientas estándar de SDK de Android, sin soporte adicional; Sin embargo, los sistemas de Microsoft Windows generalmente requieren un controlador para nuevos dispositivos Android. (Por ejemplo, las nuevas ID de proveedor y, a veces, las nuevas ID de dispositivo requieren controladores USB personalizados para los sistemas de Windows). Si la herramienta ADB no reconoce la implementación de un dispositivo como se proporciona en el SDK de Android estándar, los implementadores de dispositivos deben proporcionar controladores de Windows que permitan a los desarrolladores conectarse a El dispositivo que usa el protocolo ADB. Estos controladores deben proporcionarse para Windows XP, Windows Vista, Windows 7, Windows 8 y Windows 9 en versiones de 32 bits y 64 bits.

6.2. Opciones de desarrollador

Android incluye soporte para los desarrolladores para configurar la configuración relacionada con el desarrollo de aplicaciones. Las implementaciones de dispositivos deben honrar el android.settings.Application_develovelment_settings intención de mostrar configuraciones relacionadas con el desarrollo de aplicaciones [ recursos, 60 ]. La implementación de Android ascendente 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 la configuración > Acerca del dispositivo > El elemento del menú de número de compilación . Las implementaciones de dispositivos deben proporcionar una experiencia consistente para las opciones de desarrolladores. Específicamente, las implementaciones de dispositivos deben ocultar las opciones de desarrollador de forma predeterminada y deben proporcionar un mecanismo para habilitar opciones de desarrollador que sea consistente con la implementación de Android ascendente.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware 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. 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 completas de clase (según lo documentado por el SDK) para las API del componente aún deben presentarse.
• Los comportamientos de la API deben implementarse como OPS de alguna manera razonable.
• Los métodos API deben devolver los valores nulos cuando lo permitan la documentación SDK.
• Los métodos API deben devolver implementaciones de no-op de clases donde la documentación SDK no permita los valores nulos.
• Los métodos API no deben lanzar excepciones no documentadas por la documentación 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 consistentemente información precisa de configuración de hardware a través de los métodos getSystemAVailableFeatuables () y HassystemFeature (String) en la clase android.content.pm.packageManager para la misma huella digital de compilación. [ Recursos, 53]

7.1. Pantalla y gráficos

Android incluye instalaciones que ajustan automáticamente los activos de aplicación y los diseños de UI adecuadamente para el dispositivo, para garantizar que las aplicaciones de terceros funcionen bien en una variedad de configuraciones de hardware [ recursos, 61 ]. Los dispositivos deben implementar adecuadamente estas API y comportamientos, como se detalla en esta sección.

Las unidades a las que se hace referencia por los requisitos en esta sección se definen de la siguiente manera:

• Tamaño diagonal físico : la distancia en pulgadas entre dos esquinas opuestas de la porción iluminada de la pantalla.
• puntos por pulgada (DPI) : el número de píxeles abarcados por un tramo horizontal o vertical lineal de 1 ". Donde se enumeran los valores de DPI, tanto el DPI horizontal como el vertical debe caer dentro del rango.
• Relación de aspecto : la relación de la dimensión más larga de la pantalla a la dimensión más corta. Por ejemplo, una visualización de 480x854 píxeles sería 854 /480 = 1.779, o aproximadamente "16: 9".
• Píxel independiente de la densidad (DP) : la unidad de píxel virtual se normalizó a una pantalla de 160 dpi, calculada como: píxeles = DPS * (densidad / 160).

7.1.1. Configuración de pantalla

7.1.1.1. Tamaño de pantalla

El marco de la interfaz de usuario de Android admite una variedad de diferentes tamaños de pantalla, 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 el screenLayout_size_mask. Las implementaciones del dispositivo deben informar el tamaño correcto de la pantalla como se define en la documentación SDK de Android [ recursos, 61 ] 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 de pantalla de píxeles independientes de densidad lógica (DP).

• Los dispositivos deben tener tamaños de pantalla de al menos 426 dp x 320 dp ('pequeño'), a menos que sea un dispositivo de reloj Android.
• Los dispositivos que informan el tamaño de la pantalla 'normal' deben tener tamaños de pantalla de al menos 480 dp x 320 dp.
• Los dispositivos que informan el tamaño de la pantalla 'grande' deben tener tamaños de pantalla de al menos 640 dp x 480 dp.
• Los dispositivos que informan el tamaño de la pantalla 'xlarge' deben tener tamaños de pantalla de al menos 960 dp x 720 dp.

Además,

• Los dispositivos de reloj de Android deben tener una pantalla con el tamaño diagonal físico en el rango de 1.1 a 2.5 pulgadas
• Otros tipos de implementaciones de dispositivos Android, con una pantalla físicamente integrada, deben tener una pantalla de al menos 2.5 pulgadas de tamaño diagonal físico.

Los dispositivos no deben cambiar su tamaño de pantalla informado en ningún momento.

Las aplicaciones opcionalmente indican qué tamaños de pantalla admiten a través del Atributo en el archivo AndroidManifest.xml. Las implementaciones de dispositivos deben honrar correctamente el soporte establecido de aplicaciones para pantallas pequeñas, normales, grandes y xlarge, como se describe en la documentación SDK de Android.

7.1.1.2. Relación de aspecto de pantalla

La relación de aspecto de la pantalla debe ser un valor de 1.3333 (4: 3) a 1.86 (aproximadamente 16: 9), pero los dispositivos de reloj Android pueden tener una relación de aspecto de 1.0 (1: 1) porque dicha implementación del dispositivo usará un UI_MODE_TYPE_WATCH como Android.content.res.configuration.uimode.

7.1.1.3. 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 dirigir los recursos de aplicaciones. Las implementaciones de dispositivos deben informar solo una de las siguientes densidades lógicas de Android Framework a través de las API android.util.displaymetrics, y debe ejecutar aplicaciones a esta densidad estándar y no debe cambiar el valor en ningún momento para la pantalla predeterminada.

• 120 ppp (ldpi)
• 160 ppp (mppp)
• 213 ppp (TV ppp)
• 240 ppp (alta resolución)
• 320 ppp (xhdpi)
• 400 ppp (400 ppp)
• 480 ppp (xxhdpi)
• 560 ppp (560 ppp)
• 640 ppp (xxxhdpi)

Las implementaciones de dispositivos deben definir la densidad de marco de Android estándar que está 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 la pantalla informado por debajo del mínimo admitido. Si la densidad de marco de Android estándar que está numéricamente más cercana a la densidad física da como resultado un tamaño de pantalla que es más pequeño que el tamaño de pantalla compatible más pequeño compatible (ancho de 320 dp), las implementaciones del dispositivo deben informar la siguiente densidad de marco de Android más baja.

7.1.2. Mostrar métricas

Las implementaciones del dispositivo deben informar los valores correctos para todas las métricas de visualización definidas en android.util.displaymetrics [ recursos, 62 ] y deben informar los mismos valores independientemente de si la pantalla incrustada o externa se usa como la pantalla predeterminada.

7.1.3. Orientación de la pantalla

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 compatible. Por ejemplo, un dispositivo con una pantalla de paisaje de orientación fija, como un televisor o una computadora portátil, solo debe informar android.hardware.screen.landscape.

Los dispositivos que informan ambas orientaciones de pantalla deben admitir la orientación dinámica mediante aplicaciones a la orientación de la pantalla de retrato o paisaje. 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 informada al cambiar la orientación.

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

Las implementaciones de dispositivos deben admitir OpenGL ES 1.0 y 2.0, según lo incorporado y detallado en las documentos de Android SDK. Las implementaciones de dispositivos deben admitir OpenGL ES 3.0 o 3.1 en dispositivos capaces de soportarlo. Las implementaciones de dispositivos también deben admitir Android RenderScript, como se detalla en la documentación de Android SDK [ recursos, 63 ].

Las implementaciones de dispositivos también deben identificarse correctamente como soporte de OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 o OpenGL 3.1. Eso es:

• Las API administradas (como a través del método GLES10.getString () deben informar soporte para OpenGL ES 1.0 y OpenGL ES 2.0.
• Las API nativas de C/C ++ OpenGL (API 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 OpenGL ES 2.0.
• Las implementaciones de dispositivos que declaran soporte para OpenGL ES 3.0 o 3.1 deben admitir las API administradas correspondientes e incluir soporte para las API nativas de C/C ++. En las implementaciones de dispositivos que declaran soporte para OpenGL ES 3.0 o 3.1, Libglesv2.So debe exportar los símbolos de la función correspondiente además de los símbolos de la función OpenGL ES 2.0.

Además de OpenGL ES 3.1, Android proporciona un paquete de extensión con interfaces Java [ recursos, 64 ] y soporte nativo para la funcionalidad gráfica avanzada, como la teselación y el formato de compresión de textura ASTC. Las implementaciones de dispositivos de Android pueden admitir este paquete de extensión y, solo si se implementan completamente, debe identificar el soporte a través de Android.hardware.opengles.aep Function Flag.

Además, 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 administradas por OpenGL ES y todas las cadenas de extensión que admiten, y por el contrario no deben informar cadenas de extensión que no admiten.

Tenga en cuenta que Android incluye soporte para aplicaciones para especificar opcionalmente que requieren formatos específicos de compresión de textura OpenGL. Estos formatos son típicamente específicos del proveedor. Android 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 textura que admitan, a través del método getString () en la API OpenGL.

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D en la aplicación, actividad, ventana o nivel de vista mediante el uso de una etiqueta manifiesta Android: HardWareAccelerated o Direct API llamadas [ recursos, 65 ].

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í lo solicita configurando Android: HardWAREACcelerated = "falso" o deshabilitar la aceleración de hardware directamente a través de las API de la vista de 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, 65 ].

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente las texturas de OpenGL con aceleración 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 aguas arriba.

Android incluye soporte para EGL_ANDROID_RECORDABLE, un atributo EGLCONFIG que indica si el EGLCONFIG admite la representación de una ventana anativa que registra imágenes en un video. Las implementaciones de dispositivos deben admitir EGL_ANDROID_RECORDABLE Extensión [ Recursos, 66 ].

7.1.5. Modo de compatibilidad de aplicaciones heredadas

Android 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 la pantalla previa a la 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 del dispositivo no deben alterar los desencadenantes o umbrales en los que se activa el modo de compatibilidad, y no debe alterar el comportamiento del modo de compatibilidad en sí.

7.1.6. Tecnología de pantalla

La plataforma Android incluye API que permiten que las aplicaciones generen gráficos ricos en la pantalla. Los dispositivos deben admitir todas estas API definidas por el SDK de Android a menos que se permita específicamente en este documento.

• Los dispositivos deben soportar pantallas capaces de hacer gráficos de color de 16 bits y deben soportar pantallas capaces de gráficos de color de 24 bits.
• Los dispositivos deben soportar pantallas capaces de hacer animaciones.
• La tecnología de visualización utilizada debe tener una relación de aspecto de píxel (PAR) entre 0.9 y 1.15. Es decir, la relación de aspecto del píxel debe estar cerca de la cuadrada (1.0) con una tolerancia al 10 ~ 15%.

7.1.7. Pantallas externas

Android 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 conectada, inalámbrica o integrada, 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, 67 ].

7.2. Los dispositivos de entrada

7.2.1. Teclado

Implementaciones de dispositivos:

• Debe incluir soporte para el marco de administración de entradas (que permite a los desarrolladores de terceros crear editores de métodos de entrada, teclado suave) como se detalla en http://developer.android.com
• Debe proporcionar al menos una implementación de teclado suave (independientemente de si un teclado duro está presente), excepto los dispositivos de reloj de Android, donde el tamaño de la pantalla hace que sea menos razonable tener un teclado suave.
• 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, 68 ] (Qwerty o 12-tecla)

7.2.2. Navegación no táctil

Implementaciones de dispositivos:

• Puede omitir una opción de navegación no táctil (Trackball, D-Pad o Wheel) si la implementación del dispositivo no es un dispositivo de televisión Android
• Debe informar el valor correcto para android.content.res.configuration.navigation [ recursos, 68 ]
• 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.

7.2.3. Teclas de navegación

Las funciones de inicio, recientes y retroceso (asignadas a los eventos clave KeyCode_Home, KeyCode_App_Switch, KeyCode_Back, respectivamente) son esenciales para el paradigma de navegación de Android y, por lo tanto,;

• Las implementaciones de dispositivos portátiles de Android deben proporcionar el hogar, los recientes y las funciones posteriores.
• Las implementaciones de dispositivos de televisión de Android deben proporcionar las funciones de inicio y respaldo.
• Las implementaciones de dispositivos de reloj de Android deben tener la función de inicio disponible para el usuario, y la función posterior, excepto cuando está en UI_MODE_TYPE_WATCH.
• Todos los demás tipos de implementaciones de dispositivos deben proporcionar las funciones de inicio y respaldo.

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 en una parte distinta de la pantalla, gestos, panel táctil, etc. Android admite ambas implementaciones. Todas estas funciones deben ser accesibles con una sola acción (por ejemplo, toque, hacer doble clic o gesto) cuando sea visible.

La función de los recientes, si se proporciona, debe tener un botón o icono visibles a menos que se oculten junto con otras funciones de navegación en modo de pantalla completa. Esto no se aplica a los dispositivos que actualizan de versiones anteriores de Android que tienen botones físicos para la navegación y sin la clave de recientes.

Las funciones de inicio y respaldo, si se proporcionan, deben tener un botón o icono visibles a menos que se oculten junto con otras funciones de navegación en modo de pantalla completa o cuando el UIMode ui_mode_type_mask está configurado en ui_mode_type_watch.

La función del menú está en desuso a favor de la barra de acción desde Android 4.0. Por lo tanto, el envío de nuevas implementaciones de dispositivos con Android 5.0 no debe implementar un botón físico dedicado para la función de menú. Las implementaciones de dispositivos más antiguas no deben implementar un botón físico dedicado para la función de menú, pero si se implementa el botón de menú físico y el dispositivo ejecuta aplicaciones con TargetSDKVersion> 10, la implementación del dispositivo:

• Debe mostrar el botón de desbordamiento de acción en la barra de acción cuando sea visible y la ventana emergente del menú de desbordamiento de acción resultante no está vacía. Para una implementación del dispositivo lanzada antes de Android 4.4 pero actualizando a Android 5.0, esto se recomienda.
• No debe modificar la posición de la ventana emergente de desbordamiento de la acción que se muestra seleccionando el botón de desbordamiento en la barra de acción
• Puede representar la ventana emergente de desbordamiento de la acción en una posición modificada en la pantalla cuando se muestra seleccionando el botón de menú físico

Para la compatibilidad hacia atrás, las implementaciones del dispositivo deben hacer que la función del menú esté disponible para las aplicaciones cuando TargetSDKVersion <= 10, ya sea por un botón físico, una tecla de software o gestos. Esta función de menú debe presentarse a menos que se oculte junto con otras funciones de navegación.

Android admite la acción de asistencia [ recursos, 69 ]. Las implementaciones de dispositivos de Android, excepto los dispositivos de reloj de Android, deben poner la acción de asistencia a disposición del usuario en todo momento al ejecutar aplicaciones. La acción de asistencia debe implementarse como una presión a larga data en el botón de inicio o un gesto de deslizamiento en la tecla de inicio del software. Esta función puede implementarse a través de otro botón físico, tecla de software o gesto, pero debe ser accesible con una sola acción (por ejemplo, toque, doble clic o gesto) cuando se ven otras teclas de navegación.

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.

7.2.4. Entrada de pantalla táctil

Las implementaciones de dispositivos deben tener un sistema de entrada de puntero de algún tipo (ya sea como un mouse o tacto). Sin embargo, si una implementación de un dispositivo no admite un sistema de entrada de puntero, no debe informar el android.hardware.Touchscreen o Android.hardware.faketouch Function constante. Las implementaciones de dispositivos que incluyen un sistema de entrada de puntero:

• Debe admitir punteros rastreados de forma completamente independiente, si el sistema de entrada del dispositivo admite múltiples punteros
• Debe informar el valor de android.content.res.configuration.Touchscreen [ recursos, 68 ] correspondiente al tipo de pantalla táctil específica en el dispositivo

Android incluye soporte para una variedad de pantallas táctiles, almohadillas táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basadas en la pantalla táctil están asociadas con una pantalla [ recursos, 70 ] de modo que el usuario tenga la impresión de manipular directamente los elementos en la pantalla. Dado que el usuario toca directamente la pantalla, el sistema no requiere ninguna posibilidad adicional para indicar los objetos que se manipulan. En contraste, una interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un subconjunto de capacidades de pantalla táctil. Por ejemplo, un control remoto o mouse que impulsa un cursor en pantalla se aproxima al tacto, pero requiere que el usuario apunte o se concentre y luego haga clic. Numerosos dispositivos de entrada como Mouse, TrackPad, Air Mouse, Gyro-Pointer, Gyro-Pointer, Joystick y Multi-Touch Trackpad pueden soportar interacciones táctiles falsas. Android 5.0 incluye la característica constante de Android.hardware.faketouch, que corresponde a un dispositivo de entrada no táctil (basado en puntero) de alta fidelidad, como un mouse o trackpad que puede emular adecuadamente la entrada basada en el toque (incluido el soporte de gestos básicos), y indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil. Las implementaciones de dispositivos que declaran la función Fake Touch deben cumplir con los requisitos táctiles falsos en la Sección 7.2.5 .

Las implementaciones del dispositivo deben informar la característica correcta correspondiente al tipo de entrada utilizada. Las implementaciones de dispositivos que incluyen una pantalla táctil (táctil o mejor) deben informar la función de la plataforma constante android.hardware.Touchscreen. Las implementaciones de dispositivos que informan la función de la plataforma constante android.hardware.TouchScreen también deben informar la función de la plataforma constante 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 si cumplen con los requisitos táctiles falsos en la Sección 7.2.5 .

7.2.5. Entrada táctil falsa

Implementaciones de dispositivos que declaran soporte para android.hardware.faketouch:

• Debe informar las posiciones de pantalla X e Y absoluta de la ubicación del puntero y mostrar un puntero visual en la pantalla [ Recursos, 71 ]
• Debe informar el evento táctil con el código de acción que especifica el cambio de estado que ocurre en el puntero que baja o sube en la pantalla [ recursos, 71 ]
• Debe admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios emular toque en un objeto en la pantalla
• Debe admitir el puntero hacia abajo, el puntero hacia arriba, el puntero hacia abajo y luego el puntero en el mismo lugar en un objeto en la pantalla dentro de un umbral de tiempo, lo que permite a los usuarios emular doble toque en un objeto en la pantalla [ Recursos, 71 ]
• Debe admitir el puntero hacia abajo en un punto arbitrario en la pantalla, el puntero se mueve a cualquier otro punto arbitrario en la pantalla, seguido de un puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil
• Debe admitir el puntero hacia abajo y luego permitir a los usuarios mover rápidamente el objeto a una posición diferente en la pantalla y luego obtener un puntero en la pantalla, lo que permite a los usuarios arrojar un objeto en la pantalla

Los dispositivos que declaran soporte para android.hardware.faketouch.multitouch.distast deben cumplir con los requisitos para Faketouch anterior, y también deben admitir un seguimiento distinto de dos o más entradas independientes de puntero.

7.2.6. Soporte de controlador de juego

Las implementaciones de dispositivos de televisión de Android deben admitir asignaciones de botones para controladores de juegos como se enumeran a continuación. La implementación de Android ascendente incluye la implementación para controladores de juegos que satisfacen este requisito.

7.2.6.1. Asignaciones de botones

Las implementaciones de dispositivos de televisión de Android deben admitir las siguientes asignaciones clave:

1 [ Resources, 72 ]

2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).

3 This usage must have a Logical Minimum of 0, a Logical Maximum of 7, a Physical Minimum of 0, a Physical Maximum of 315, Units in Degrees, and a Report Size of 4. The logical value is defined to be the clockwise rotation away from the vertical axis; for example, a logical value of 0 represents no rotation and the up button being pressed, while a logical value of 1 represents a rotation of 45 degrees and both the up and left keys being pressed.

4 [ Resources, 71 ]

1 [ Resources, 71 ]

7.2.7. Control remoto

Android Television device implementations SHOULD provide a remote control to allow users to access the TV interface. The remote control MAY be a physical remote or can be a software-based remote that is accessible from a mobile phone or tablet. The remote control MUST meet the requirements defined below.

• Search affordance —Device implementations MUST fire KEYCODE_SEARCH when the user invokes voice search either on the physical or software-based remote.
• Navigation —All Android Television remotes MUST include Back, Home, and Select buttons and support for D-pad events [ Resources, 72 ].

7.3. Sensores

Android includes APIs for accessing a variety of sensor types. Devices implementations generally MAY omit these sensors, as provided for in the following subsections. If a device includes a particular sensor type that has a corresponding API for third-party developers, the device implementation MUST implement that API as described in the Android SDK documentation and the Android Open Source documentation on sensors [ Resources, 73 ]. For example, device implementations:

• MUST accurately report the presence or absence of sensors per the android.content.pm.PackageManager class [ Resources, 53]
• MUST return an accurate list of supported sensors via the SensorManager.getSensorList() and similar methods
• MUST behave reasonably for all other sensor APIs (for example, by returning true or false as appropriate when applications attempt to register listeners, not calling sensor listeners when the corresponding sensors are not present; etc.)
• MUST report all sensor measurements using the relevant International System of Units (metric) values for each sensor type as defined in the Android SDK documentation [ Resources, 74 ]
• SHOULD report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are very strongly encouraged to meet these requirement so they will be able to upgrade to the future platform releases where this might become a REQUIRED component. The synchronization error SHOULD be below 100 milliseconds [ Resources, 75 ].

The list above is not comprehensive; the documented behavior of the Android SDK and the Android Open Source Documentations on Sensors [ Resources, 73 ] is to be considered authoritative.

Some sensor types are composite, meaning they can be derived from data provided by one or more other sensors. (Examples include the orientation sensor, and the linear acceleration sensor.) Device implementations SHOULD implement these sensor types, when they include the prerequisite physical sensors as described in [ Resources, 76 ]. If a device implementation includes a composite sensor it MUST implement the sensor as described in the Android Open Source documentation on composite sensors [ Resources, 76 ].

Some Android sensor supports a "continuous" trigger mode, which returns data continuously [ Resources, 77 ]. For any API indicated by the Android SDK documentation to be a continuous sensor, device implementations MUST continuously provide periodic data samples that SHOULD have a jitter below 3%, where jitter is defined as the standard deviation of the difference of the reported timestamp values between consecutive eventos.

Note that the device implementations MUST ensure that the sensor event stream MUST NOT prevent the device CPU from entering a suspend state or waking up from a suspend state.

Finally, when several sensors are activated, the power consumption SHOULD NOT exceed the sum of the individual sensor's reported power consumption.

7.3.1. Acelerómetro

Device implementations SHOULD include a 3-axis accelerometer. Android Handheld devices and Android Watch devices are strongly encouraged to include this sensor. If a device implementation does include a 3-axis accelerometer, it:

• MUST implement and report TYPE_ACCELEROMETER sensor [ Resources, 78 ]
• MUST be able to report events up to a frequency of at least 100 Hz and SHOULD report events up to at least 200 Hz
• MUST comply with the Android sensor coordinate system as detailed in the Android APIs [ Resources, 74 ]
• MUST be capable of measuring from freefall up to four times the gravity (4g) or more on any axis
• MUST have a resolution of at least 8-bits and SHOULD have a resolution of at least 16-bits
• SHOULD be calibrated while in use if the characteristics changes over the life cycle and compensated, and preserve the compensation parameters between device reboots
• SHOULD be temperature compensated
• MUST have a standard deviation no greater than 0.05 m/s^, where the standard deviation should be calculated on a per axis basis on samples collected over a period of at least 3 seconds at the fastest sampling rate
• SHOULD implement the TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER composite sensors as described in the Android SDK document. Existing and new Android devices are very strongly encouraged to implement the TYPE_SIGNIFICANT_MOTION composite sensor. If any of these sensors are implemented, the sum of their power consumption MUST always be less than 4 mW and SHOULD each be below 2 mW and 0.5 mW for when the device is in a dynamic or static condition.
• If a gyroscope sensor is included, MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices are strongly encouraged to implement the TYPE_GAME_ROTATION_VECTOR sensor.
• SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope sensor and a magnetometer sensor is also included

7.3.2. Magnetómetro

Device implementations SHOULD include a 3-axis magnetometer (compass). If a device does include a 3-axis magnetometer, it:

• MUST implement the TYPE_MAGNETIC_FIELD sensor and SHOULD also implement TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor. Existing and new Android devices are strongly encouraged to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.
• MUST be able to report events up to a frequency of at least 10 Hz and SHOULD report events up to at least 50 Hz
• MUST comply with the Android sensor coordinate system as detailed in the Android APIs [ Resources, 74 ]
• MUST be capable of measuring between -900 μT and +900 μT on each axis before saturating
• MUST have a hard iron offset value less than 700 μT and SHOULD have a value below 200 μT, by placing the magnetometer far from dynamic (current-induced) and static (magnet-induced) magnetic fields
• MUST have a resolution equal or denser than 0.6 μT and SHOULD have a resolution equal or denser than 0.2 μT
• SHOULD be temperature compensated
• MUST support online calibration and compensation of the hard iron bias, and preserve the compensation parameters between device reboots
• MUST have the soft iron compensation applied—the calibration can be done either while in use or during the production of the device
• SHOULD have a standard deviation, calculated on a per axis basis on samples collected over a period of at least 3 seconds at the fastest sampling rate, no greater than 0.5 μT
• SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer sensor and a gyroscope sensor is also included
• MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor if an accelerometer sensor is also implemented. However if implemented, it MUST consume less than 10 mW and SHOULD consume less than 3 mW when the sensor is registered for batch mode at 10 Hz.

7.3.3. GPS

Device implementations SHOULD include a GPS receiver. If a device implementation does include a GPS receiver, it SHOULD include some form of "assisted GPS" technique to minimize GPS lock-on time.

7.3.4. Giroscopio

Device implementations SHOULD include a gyroscope (angular change sensor). Devices SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is also included. If a device implementation includes a gyroscope, it:

• MUST implement the TYPE_GYROSCOPE sensor and SHOULD also implement TYPE_GYROSCOPE_UNCALIBRATED sensor. Existing and new Android devices are strongly encouraged to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sensor.
• MUST be capable of measuring orientation changes up to 1,000 degrees per second
• MUST be able to report events up to a frequency of at least 100 Hz and SHOULD report events up to at least 200 Hz
• MUST have a resolution of 12-bits or more and SHOULD have a resolution of 16-bits or more
• MUST be temperature compensated
• MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots
• MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but must be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.
• SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer sensor and a magnetometer sensor is also included
• If an accelerometer sensor is included, MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices are strongly encouraged to implement the TYPE_GAME_ROTATION_VECTOR sensor.

7.3.5. Barómetro

Device implementations SHOULD include a barometer (ambient air pressure sensor). If a device implementation includes a barometer, it:

• MUST implement and report TYPE_PRESSURE sensor
• MUST be able to deliver events at 5 Hz or greater
• MUST have adequate precision to enable estimating altitude
• MUST be temperature compensated

7.3.6. Termómetro

Device implementations MAY include an ambient thermometer (temperature sensor). If present, it MUST be defined as SENSOR_TYPE_AMBIENT_TEMPERATURE and it MUST measure the ambient (room) temperature in degrees Celsius.

Device implementations MAY but SHOULD NOT include a CPU temperature sensor. If present, it MUST be defined as SENSOR_TYPE_TEMPERATURE, it MUST measure the temperature of the device CPU, and it MUST NOT measure any other temperature. Note the SENSOR_TYPE_TEMPERATURE sensor type was deprecated in Android 4.0.

7.3.7. Fotómetro

Device implementations MAY include a photometer (ambient light sensor).

7.3.8. Sensor de proximidad

Device implementations MAY include a proximity sensor. Devices that can make a voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType SHOULD include a proximity sensor. If a device implementation does include a proximity sensor, it:

• MUST measure the proximity of an object in the same direction as the screen. That is, the proximity sensor MUST be oriented to detect objects close to the screen, as the primary intent of this sensor type is to detect a phone in use by the user. If a device implementation includes a proximity sensor with any other orientation, it MUST NOT be accessible through this API.
• MUST have 1-bit of accuracy or more

7.4. Conectividad de datos

7.4.1. Telefonía

"Telephony" as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages via a GSM or CDMA network. While these voice calls may or may not be packet-switched, they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words, the Android "telephony" functionality and APIs refer specifically to voice calls and SMS. For instance, device implementations that cannot place calls or send/receive SMS messages MUST NOT report the android.hardware.telephony feature or any subfeatures, regardless of whether they use a cellular network for data connectivity.

Android MAY be used on devices that do not include telephony hardware. That is, Android is compatible with devices that are not phones. However, if a device implementation does include GSM or CDMA telephony, it MUST implement full support for the API for that technology. Las implementaciones de dispositivos que no incluyen hardware de telefonía deben implementar las API completas como NO-OPS.

7.4.2. IEEE 802.11 (Wi-Fi)

Android Television device implementations MUST include support for one or more forms of 802.11 (b/g/a/n, etc.) and other types of Android device implementation SHOULD include support for one or more forms of 802.11. If a device implementation does include support for 802.11 and exposes the functionality to a third-party application, it MUST implement the corresponding Android API and:

• MUST report the hardware feature flag android.hardware.wifi
• MUST implement the multicast API as described in the SDK documentation [ Resources, 79 ]
• MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251) at any time of operation including when the screen is not in an active state

7.4.2.1. Wi-Fi directo

Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi peer-to-peer). If a device implementation does include support for Wi-Fi Direct, it MUST implement the corresponding Android API as described in the SDK documentation [ Resources, 80 ]. If a device implementation includes support for Wi-Fi Direct, then it:

• MUST report the hardware feature android.hardware.wifi.direct
• MUST support regular Wi-Fi operation
• SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation

7.4.2.2. Configuración de enlace directo con túnel Wi-Fi

Android Television device implementations MUST include support for Wi-Fi Tunneled Direct Link Setup (TDLS) and other types of Android device implementations SHOULD include support for Wi-Fi TDLS as described in the Android SDK Documentation [ Resources, 81 ]. If a device implementation does include support for TDLS and TDLS is enabled by the WiFiManager API, the device:

• SHOULD use TDLS only when it is possible AND beneficial
• SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point

7.4.3. Bluetooth

Android includes support for Bluetooth and Bluetooth Low Energy [ Resources, 82 ]. Device implementations that include support for Bluetooth and Bluetooth Low Energy MUST declare the relevant platform features (android.hardware.bluetooth and android.hardware.bluetooth_le respectively) and implement the platform APIs. Device implementations SHOULD implement relevant Bluetooth profiles such as A2DP, AVCP, OBEX, etc. as appropriate for the device. Android Television device implementations MUST support Bluetooth and Bluetooth LE.

Device implementations including support for Bluetooth Low Energy:

• MUST declare the hardware feature android.hardware.bluetooth_le
• MUST enable the GATT (generic attribute profile) based Bluetooth APIs as described in the SDK documentation and [ Resources, 82 ]
• SHOULD support offloading of the filtering logic to the bluetooth chipset when implementing the ScanFilter API [ Resources, 83 ], and MUST report the correct value of where the filtering logic is implemented whenever queried via the android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method
• SHOULD support offloading of the batched scanning to the bluetooth chipset, but if not supported, MUST report 'false' whenever queried via the android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() method.
• SHOULD support multi advertisement with at least 4 slots, but if not supported, MUST report 'false' whenever queried via the android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() method

7.4.4. Comunicaciones de campo cercano

Device implementations SHOULD include a transceiver and related hardware for Near-Field Communications (NFC). If a device implementation does include NFC hardware and plans to make it available to third-party apps, then it:

• MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 53 ]
• MUST be capable of reading and writing NDEF messages via the following NFC standards:
  • MUST be capable of acting as an NFC Forum reader/writer (as defined by the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
  • SHOULD be capable of reading and writing NDEF messages via the following NFC standards. Note that while the NFC standards below are stated as SHOULD, the Compatibility Definition for a future version is planned to change these to MUST. These standards are optional in this version but will be required in future versions. Existing and new devices that run this version of Android are very strongly encouraged to meet these requirements now so they will be able to upgrade to the future platform releases.
    • NfcV (ISO 15693)
  • MUST be capable of transmitting and receiving data via the following peer-to-peer standards and protocols:
    • ISO 18092
    • LLCP 1.0 (defined by the NFC Forum)
    • SDP 1.0 (defined by the NFC Forum)
    • NDEF Push Protocol [ Resources, 84 ]
    • SNEP 1.0 (defined by the NFC Forum)
  • MUST include support for Android Beam [ Resources, 85 ]:
    • MUST implement the SNEP default server. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
    • MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 86 ]
    • MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
    • MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
    • MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush
    • SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages
    • SHOULD enable Android Beam by default and MUST be able to send and receive using Android Beam, even when another proprietary NFC P2p mode is turned on
    • MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations MUST support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 87 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 88 ] specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name "urn:nfc:sn:handover" for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
  • MUST poll for all supported technologies while in NFC discovery mode
  • SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked

(Note that publicly available links are not available for the JIS, ISO, and NFC Forum specifications cited above.)

Android 5.0 includes support for NFC Host Card Emulation (HCE) mode. If a device implementation does include an NFC controller capable of HCE and Application ID (AID) routing, then it:

• MUST report the android.hardware.nfc.hce feature constant
• MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 10 ]

Additionally, device implementations MAY include reader/writer support for the following MIFARE technologies.

• MIFARE Classic
• MIFARE Ultralight
• NDEF on MIFARE Classic

Note that Android includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

• MUST implement the corresponding Android APIs as documented by the Android SDK
• MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() meth od [Resources, 53] . Note that this is not a standard Android feature and as such does not appear as a constant on the PackageManager class.
• MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare feature unless it also implements general NFC support as described in this section

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 53] , and MUST implement the Android NFC API as a no-op.

As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

7.4.5. Capacidad mínima de red

Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

Devices MAY implement more than one form of data connectivity.

7.4.6. Configuración de sincronización

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns "true" [ Resources, 89 ].

7.5. Cámaras

Device implementations SHOULD include a rear-facing camera and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

If a device implementation includes at least one camera, it SHOULD be possible for an application to simultaneously allocate 3 bitmaps equal to the size of the images produced by the largest-resolution camera sensor on the device.

7.5.1. Cámara trasera

Device implementations SHOULD include a rear-facing camera. If a device implementation includes at least one rear-facing camera, it:

• MUST report the feature flag android.hardware.camera and android.hardware.camera.any
• DEBE tener una resolución de al menos 2 megapíxeles
• SHOULD have either hardware auto-focus or software auto-focus implemented in the camera driver (transparent to application software)
• 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. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback.

7.5.2. Cámara frontal

Las implementaciones de dispositivos pueden incluir una cámara frontal. If a device implementation includes at least one front-facing camera, it:

• MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front
• MUST have a resolution of at least VGA (640x480 pixels)
• MUST NOT use a front-facing camera as the default for the Camera API. The camera API in Android has specific support for front-facing cameras and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the device.
• MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in section 7.5.1
• MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation()[ Resources, 90 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
• MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. If the device implementation does not support postview, this requirement obviously does not apply.
• MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3. Cámara externa

Device implementations with USB host mode MAY include support for an external camera that connects to the USB port. If a device includes support for an external camera, it:

• MUST declare the platform feature android.hardware.camera.external and android.hardware camera.any
• MUST support USB Video Class (UVC 1.0 or higher)
• MAY support multiple cameras

Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of high-quality unencoded streams (ie raw or independently compressed picture streams). Camera-based video encoding MAY be supported. If so, a simultaneous unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the device implementation.

7.5.4. Comportamiento de la API de la cámara

Android includes two API packages to access the camera, the newer android.hardware.camera2 API expose lower-level camera control to the app, including efficient zero-copy burst/streaming flows and per-frame controls of exposure, gain, white balance gains, color conversion, denoising, sharpening, and more.

The older API package, android.hardware.Camera, is marked as deprecated in Android 5.0 but as it should still be available for apps to use Android device implementations MUST ensure the continued support of the API as described in this section and in the Android SDK .

Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras:

• Si una aplicación nunca ha llamado a android.hardware.Camera.Parameters.setPreviewFormat(int), entonces el dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para obtener una vista previa de los datos proporcionados a las devoluciones de llamada de la aplicación.
• Si una aplicación registra una instancia de android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() cuando el formato de vista previa es YCbCr_420_SP, los datos en el byte[] pasados ​​a onPreviewFrame() deben estar además en el formato de codificación NV21. That is, NV21 MUST be the default.
• For android.hardware.Camera, device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)
• For android.hardware.camera2, device implementations must support the android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG formats as outputs through the android.media.ImageReader API.

Device implementations MUST still implement the full Camera API included in the Android SDK documentation [ Resources, 91 ], regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

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. Conversely, device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the 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. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 92 ].

Because not all device implementations can fully support all the features of the android.hardware.camera2 API, device implementations MUST report the proper level of support with the android.info.supportedHardwareLevel property as described in the Android SDK [ Resources, 93] and report the appropriate framework feature flags [ Resources, 94] .

Device implementations MUST also declare its Individual camera capabilities of android.hardware.camera2 via the android.request.availableCapabilities property and declare the appropriate feature flags [ Resources, 94] ; a device must define the feature flag if any of its attached camera devices supports the feature.

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.5. Orientación de la cámara

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6. Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

The memory available to the kernel and userspace on device implementations MUST be at least equal or larger than the minimum values specified by the following table. (See section 7.1.1 for screen size and density definitions.)

The minimum memory values MUST be in addition to any memory space already dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Android Television devices MUST have at least 5GB and other device implementations MUST have at least 1.5GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 5GB for Android Television devices and at least 1.5GB for other device implementations. Device implementations that run Android are very strongly encouraged to have at least 3GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications MAY use to download data files [ Resources, 95 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Almacenamiento compartido de aplicaciones

Device implementations MUST offer shared storage for applications also often referred as “shared external storage”.

Las implementaciones de dispositivos deben configurarse con almacenamiento compartido montado de forma predeterminada, "fuera de la caja". If the shared storage is not mounted on the Linux path /sdcard, then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital (SD) card slot. If this slot is used to satisfy the shared storage requirement, the device implementation:

• MUST implement a toast or pop-up user interface warning the user when there is no SD card
• MUST include a FAT-formatted SD card 1GB in size or larger OR show on the box and other material available at time of purchase that the SD card has to be separately purchased
• MUST mount the SD card by default

Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps as included in the upstream Android Open Source Project; device implementations SHOULD use this configuration and software implementation. If a device implementation uses internal (non-removable) storage to satisfy the shared storage requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted en otra parte).

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

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST allow only pre-installed & privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to write to the secondary external storage, except for the package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol, it:

• SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 96 ]
• SHOULD report a USB device class of 0x00
• SHOULD report a USB interface name of 'MTP'

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

7.7. USB

Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode.

If a device implementation includes a USB port supporting peripheral mode:

• The port MUST be connectable to a USB host that has a standard type-A or type -C USB port.
• The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• The port SHOULD either be located on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• It SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation, and if it is an Android Handheld device it MUST implement the AOA API. Device implementations implementing the AOA specification:
  • MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 97 ]
  • MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ]
• It SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ]. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
• The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB port supporting host mode, it:

• SHOULD use a type-C USB port, if the device implementation supports USB 3.1
• MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to a standard type-A or type-C USB port
• MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables adapting the port to a standard type-A or type-C USB port
• is very strongly RECOMMENDED to implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ]
• MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 100 ]
• SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ].

7.8. Audio

7.8.1. Micrófono

Device implementations MAY omit a microphone. However, if a device implementation omits a microphone, it MUST NOT report the android.hardware.microphone feature constant, and MUST implement the audio recording API at least as no-ops, per section 7 . Conversely, device implementations that do possess a microphone:

• MUST report the android.hardware.microphone feature constant
• MUST meet the audio recording requirements in section 5.4
• MUST meet the audio latency requirements in section 5.6

7.8.2. Salida de audio

Device implementations including a speaker or with an audio/multimedia output port for an audio output peripheral as a headset or an external speaker:

• MUST report the android.hardware.audio.output feature constant
• MUST meet the audio playback requirements in section 5.5
• MUST meet the audio latency requirements in section 5.6

Conversely, if a device implementation does not include a speaker or audio output port, it MUST NOT report the android.hardware.audio output feature, and MUST implement the Audio Output related APIs as no-ops at least.

Android Watch device implementation MAY but SHOULD NOT have audio output, but other types of Android device implementations MUST have an audio output and declare android.hardware.audio.output.

7.8.2.1. Puertos de audio analógico

In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem [ Resources, 101 ], if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:

• MUST support audio playback to stereo headphones and stereo headsets with a microphone, and SHOULD support audio recording from stereo headsets with a microphone
• MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support audio plugs with the OMTP pin-out order
• MUST support the detection of microphone on the plugged in audio accessory, if the device implementation supports a microphone, and broadcast the android.intent.action.HEADSET_PLUG with the extra value microphone set as 1
• SHOULD support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 70 ohm or less : KEYCODE_HEADSETHOOK
  • 210–290 Ohm : KEYCODE_VOLUME_UP
  • 360–680 Ohm : KEYCODE_VOLUME_DOWN
• SHOULD support the detection and mapping to the keycode for the following range of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 110–180 Ohm: KEYCODE_VOICE_ASSIST
• MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack
• MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm speaker impedance
• MUST have a microphone bias voltage between 1.8V ~ 2.9V

8. Performance Compatibility

Some minimum performance criterias are critical to the user experience and impacts the baseline assumptions developers would have when developing an app. Android Watch devices SHOULD and other type of device implementations MUST meet the following criteria:

8.1. Coherencia de la experiencia del usuario

Device implementations MUST provide a smooth user interface by ensuring a consistent frame rate and response times for applications and games. Device implementations MUST meet the following requirements:

• Consistent frame latency Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
• User interface latency Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.
• Task switching When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

8.2. Rendimiento del acceso a E/S de archivos

Device implementations MUST ensure file access performance consistency for read and write operations.

• Sequential write Device implementations MUST ensure a sequential write performance of 5MB/s for a 256MB file using 10MB write buffer.
• Random write Device implementations MUST ensure a random write performance of 0.5MB/s for a 256MB file using 4KB write buffer.
• Sequential read Device implementations MUST ensure a sequential read performance of 15MB/s for a 256MB file using 10MB write buffer.
• Random read Device implementations MUST ensure a random read performance of 3.5MB/s for a 256MB file using 4KB write buffer.

9. Compatibilidad del modelo de seguridad

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 102 ] in the Android developer documentation. Las implementaciones de dispositivos deben admitir la instalación de aplicaciones autofirmadas sin requerir ningún permiso/certificado adicionales de terceros/autoridades. Specifically, compatible devices MUST support the security mechanisms described in the follow subsections.

9.1. Permisos

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 102 ]. 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

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unixstyle UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 102 ].

9.3. Permisos del sistema de archivos

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 102 ].

9.4. Entornos de ejecución alternativos

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik Executable Format or native code. 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.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in section 9 .

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the mecanismo.

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. Specifically, alternate runtimes:

• SHOULD install apps via the PackageManager into separate Android sandboxes ( Linux user IDs, etc.)
• MAY provide a single Android sandbox shared by all applications using the alternate runtime
• and installed applications using an alternate runtime, MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
• MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications
• MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID

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. If an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource. 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 includes support for multiple users and provides support for full user isolation [ Resources, 103] . Device implementations MAY enable multiple users, but when enabled MUST meet the following requirements related to multi-user support [ Resources, 104 ]:

• Device implementations that do not declare the android.hardware.telephony feature flag MUST support restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments.
• Conversely device implementations that declare the android.hardware.telephony feature flag MUST NOT support restricted profiles but MUST align with the AOSP implementation of controls to enable /disable other users from accessing the voice calls and SMS.
• Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 102 ]
• Device implementations MAY support creating users and managed profiles via the android.app.admin.DevicePolicyManager APIs, and if supported, MUST declare the platform feature flag android.software.managed_users.
• Device implementations that declare the feature flag android.software.managed_users MUST use the upstream AOSP icon badge to represent the managed applications and other badge UI elements like Recents & Notifications.
• Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the primary external storage APIs MUST encrypt the contents of the SD card if multiuser is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 105 ] for primary external storage.

9.6. Advertencia de SMS premium

Android includes support for warning users of any outgoing premium SMS message [ Resources, 106 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. Funciones de seguridad del núcleo

The Android Sandbox includes features that use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features implemented below the Android framework:

• MUST maintain compatibility with existing applications
• MUST NOT have a visible user interface when a security violation is detected and successfully blocked, but MAY have a visible user interface when an unblocked security violation occurs resulting in a successful exploit
• SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux or, if using a kernel other than Linux, an equivalent mandatory access control system. Devices must also meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

Implementaciones de dispositivos:

• MUST set SELinux to global enforcing mode,
• MUST configure all domains in enforcing mode. No permissive mode domains are allowed, including domains specific to a device/vendor.
• MUST NOT modify, omit, or replace the neverallow rules present within the external/sepolicy folder provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present, for both AOSP SELinux domains as well as device/vendor specific domains.

Device implementations SHOULD retain the default SELinux policy provided in the external/sepolicy folder of the upstream Android Open Source Project and only further add to this policy for their own device-specific configuration. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8. Privacidad

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9.9. Cifrado de disco completo

If the device implementation has a lock screen, the device MUST support full-disk encryption of the application private data, (/data partition) as well as the SD card partition if it is a permanent, non-removable part of the device [ Resources, 107 ]. For devices supporting full-disk encryption, the full-disk encryption SHOULD be enabled all the time after the user has completed the out-of-box experience. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted. Other than when in active use, the encryption key SHOULD be AES encrypted with the lockscreen passcode stretched using a slow stretching algorithm (eg PBKDF2 or scrypt). If the user has not specified a lockscreen passcode or has disabled use of the passcode for encryption, the system SHOULD use a default passcode to wrap the encryption key. If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore. The encryption key MUST NOT be sent off the device (even when wrapped with the user passcode and/or hardware bound key). The upstream Android Open Source project provides a preferred implementation of this feature based on the linux kernel feature dm-crypt.

9.10. Verified Boot

Device implementations SHOULD support verified boot for device integrity, and if the feature is supported it MUST declare the platform feature flag android.software.verified_boot. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. The upstream Android Open Source Project provides a preferred implementation of this feature based on the linux kernel feature dm-verity.

10. Pruebas de compatibilidad de software

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Conjunto de pruebas de compatibilidad

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 108 ] available from the Android Open Source Project, using the final shipping software on the device. 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 5.0. 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 that 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 Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

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

However, if the device implementation includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, the device MUST support Over-the-air download with offline update via reboot.

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.

For device implementations that are launching with Android 5.0 and later, the update mechanism SHOULD support verifying that the system image is binary identical to expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.0, satisfies this requirement.

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. Registro de cambios del documento

The following table contains a summary of the changes to the Compatibility Definition in this release.

13. Contáctenos

You can join the android-compatibility forum [Resources, 109 ] and ask for clarifications or bring up any issues that you think the document does not cover.

14. Resources

1. IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Android Television features: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android Watch feature: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API definitions and documentation: http://developer.android.com/reference/packages.html

6. Android Permissions reference: http://developer.android.com/reference/android/Manifest.permission.html

7. android.os.Build reference: http://developer.android.com/reference/android/os/Build.html

8. Android 5.0 allowed version strings: http://source.android.com//docs/compatibility/5.0/versions

9. Telephony Provider: http://developer.android.com/reference/android/provider/Telephony.html

10. Host-based Card Emulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html

13. WebView compatibility: http://www.chromium.org/

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

15. HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C webstorage API: http://www.w3.org/TR/webstorage/

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

20. Dalvik Executable Format and bytecode specification: available in the Android source code, at dalvik/docs

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

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

23. Application Resources: https://developer.android.com/guide/topics/resources/available-resources.html

24. Status Bar icon style guide: http://developer.android.com/design/style/iconography.html

25. Notifications Resources: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

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

29. R.style class: http://developer.android.com/reference/android/R.style.html

30. Material design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Live Wallpapers: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Overview screen resources: http://developer.android.com/guide/components/recents.html

33. Screen pinning: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Input methods: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Media Notification: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html

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

41. Android Device Owner App:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Android Accessibility Service APIs: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html

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

45. Text-To-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. Television Input Framework: /devices/tv/index.html

47. Reference tool documentation (for adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

48. Android apk file description: http://developer.android.com/guide/components/fundamentals.html

49. Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android Media Formats: http://developer.android.com/guide/appendix/media-formats.html

51. RTC Hardware Coding Requirements: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android android.content.pm.PackageManager class and Hardware Features List:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey testing tool: http://developer.android.com/tools/help/monkey.html

59. SysyTrace tool: http://developer.android.com/tools/help/systrace.html

60. Android Application Development-Related Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. Supporting Multiple Screens: http://developer.android.com/guide/practices/screens_support.html

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

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Android extension pack for OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Hardware Acceleration: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL Extension-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

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

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Touch Input Configuration: http://source.android.com/docs/core/interaction/input/touch-devices

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Android Open Source sensors: http://source.android.com/docs/core/interaction/sensors

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

75. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source composite sensors: http://source.android.com/devices/sensors/composite_sensors.html

77. Continuous trigger mode: http://source.android.com/devices/sensors/base_triggers.html#continuous

78. Accelerometer sensor: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

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

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

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

86. Android NFC Sharing Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. NFC Connection Handover: http://www.nfc-forum.org/specs/spec_list/#conn_handover

88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

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

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

93. Camera hardware level: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Camera version support: http://source.android.com/docs/core/camera/versioning

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android File Transfer: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html

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

99. USB Battery Charging Specification, Revision 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

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

101. Wired audio headset: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

102. Android Security and Permissions reference: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager reference: http://developer.android.com/reference/android/os/UserManager.html

104. External Storage reference: http://source.android.com/docs/core/storage

105. External Storage APIs: http://developer.android.com/reference/android/os/Environment.html

106. SMS Short Code: http://en.wikipedia.org/wiki/Short_code

107. Android Open Source Encryption: http://source.android.com/devices/tech/encryption/index.html

108. Android Compatibility Program Overview: http://source.android.com/docs/compatibility

109. Android Compatibility forum: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM project: http://www.webmproject.org/

Many of these resources are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK's documentation. 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.