Definición de compatibilidad con Android 5.1

1. Introducción

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

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

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

La implementación de Android Automotive se refiere a la unidad principal de un vehículo que ejecuta Android como sistema operativo para parte o la totalidad del sistema y/o la funcionalidad de infoentretenimiento. Las implementaciones de Android Automotive DEBEN admitir uiMode = UI_MODE_TYPE_CAR [ Recursos, 111 ].

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

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 nativo de actividad 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.3.2. Compatibilidad con código nativo ARM de 32 bits

La arquitectura ARMv8 desaprueba varias operaciones de la CPU, incluidas algunas operaciones utilizadas en el código nativo existente. En dispositivos ARM de 64 bits, las siguientes operaciones obsoletas DEBEN permanecer disponibles para el código ARM nativo de 32 bits, ya sea mediante soporte de CPU nativo o mediante emulación de software:

• Instrucciones SWP y SWPB
• Instrucción ESTABLECER
• Operaciones de barrera CP15ISB, CP15DSB y CP15DMB

Las versiones heredadas del NDK de Android usaban /proc/cpuinfo para descubrir funciones de CPU a partir de código nativo ARM de 32 bits. Para compatibilidad con aplicaciones creadas con este NDK, los dispositivos DEBEN incluir las siguientes líneas en /proc/cpuinfo cuando lo leen aplicaciones ARM de 32 bits:

• "Características: ", seguido de una lista de las funciones opcionales de la CPU ARMv7 admitidas por el dispositivo.
• "Arquitectura de CPU:", seguido de un número entero que describe la arquitectura ARM más compatible con el dispositivo (por ejemplo, "8" para dispositivos ARMv8)

Estos requisitos solo se aplican cuando /proc/cpuinfo es leído por aplicaciones ARM de 32 bits. Los dispositivos no DEBEN alterar /proc/cpuinfo cuando los leen aplicaciones ARM o no ARM de 64 bits.

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.1. 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)$(WEBVIEW)) 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.
  • La cadena $(WEBVIEW) PUEDE omitirse, pero si se incluye DEBE ser "; wv" para tener en cuenta que se trata de una vista web.
  • 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 ]
• la etiqueta <video> [ Recursos, 16 ]
• 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 del mecanismo <uses-library>) se vean afectadas por el mayor uso de memoria. de dichas API.

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

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

3.7. Compatibilidad 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 animación, etc.) proporcionados en las API [ Recursos, 23 ], o en la guía de estilo de iconos de la barra de estado/sistema [ Recursos, 24 ], que en el caso de un El dispositivo Android Televisión incluye la posibilidad de no mostrar las notificaciones. 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 ricas . Vistas interactivas para notificaciones en curso.
• Notificaciones de aviso . Los usuarios de Vistas interactivas pueden actuar o cerrar 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 visibilidad.

Las implementaciones de dispositivos Android, cuando dichas notificaciones se hacen visibles, DEBEN ejecutar correctamente notificaciones enriquecidas y de aviso e incluir el título/nombre, ícono 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 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 utilicen los desarrolladores de aplicaciones 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 API y ciclo de vida correspondientes que permiten a las aplicaciones exponer uno o más "fondos de pantalla en vivo" 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, a menos que sea una implementación de Android Automotive o Watch, DEBEN mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación de medios.

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 incluye soporte para fuentes Roboto 2 con diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light, que DEBEN estar incluidos todos 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 monetarios 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 pantallas de bloqueo basadas en PIN (numérico) o CONTRASEÑA (alfanumérica) 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 característica 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 incluyen los siguientes requisitos:

• Las implementaciones de Android Automotive DEBEN proporcionar una implementación del marco de accesibilidad de Android coherente con la implementación predeterminada de Android.
• Las implementaciones de dispositivos (excluido Android Automotive) DEBEN proporcionar una implementación del marco de accesibilidad de Android coherente con la implementación predeterminada de Android.
• Las implementaciones de dispositivos (excluido Android Automotive) DEBEN admitir implementaciones de servicios de accesibilidad de terceros a través de las API de android.accessibilityservice [ Recursos, 43 ]
• Las implementaciones de dispositivos (excluido Android Automotive) DEBEN generar AccessibilityEvents y entregar estos eventos a todas las implementaciones registradas de AccessibilityService de manera consistente con la implementación predeterminada de Android.
• Las implementaciones de dispositivos (dispositivos Android Automotive y Android Watch sin salida de audio excluida) 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 Android Automotive:

• DEBE admitir las API del marco TTS de Android.
• PUEDE admitir la instalación de motores TTS de terceros. Si es compatible, los socios DEBEN proporcionar una interfaz accesible para el usuario que le permita seleccionar un motor TTS para su uso a nivel del sistema.

Todas las demás 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 y reportados a través de MediaCodecList [ Recursos,112 ]. Las implementaciones de dispositivos DEBEN también poder decodificar todos los perfiles informados en su CamcorderProfile [ Recursos, 113 ]. 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

Los códecs de vídeo son opcionales para las implementaciones de dispositivos Android Watch.

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 Altamente recomendado para Android Automotive, opcional para Android Watch y obligatorio para todos los demás tipos de dispositivos.

5.2. Codificación de vídeo

Las implementaciones de dispositivos Android con compatibilidad con el códec H.264 DEBEN admitir el nivel de perfil base 3 y los siguientes perfiles de codificación de video SD (definición estándar) y DEBEN admitir el nivel de perfil principal 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 de la misma transmisión para todos los códecs VP8, VP9, ​​H.264 y H.265 expuestos a los desarrolladores a través de las API estándar de Android.

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, cuando admiten el códec H.265 como se describe en la sección 5.1.3 , DEBEN admitir el nivel principal de perfil principal 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 el perfil Main10 Nivel 5 y el perfil de decodificación UHD. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android Television admitan el perfil de decodificación HD 1080p. Si se admite el perfil de decodificación HD 1080p, DEBE admitir el nivel principal de perfil principal 4.1.

1 Requerido para la implementación 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.

5.4. Grabación de audio

Si bien algunos de los requisitos descritos en esta sección se indican como DEBEN desde Android 4.3, se planea que la Definición de compatibilidad para una versión futura los cambie a DEBE. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos que se indican como DEBERÍAN, o no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

5.4.1. Captura de audio sin procesar

Las implementaciones de dispositivos que declaran android.hardware.microphone DEBEN permitir la captura de contenido de audio sin formato 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 DEBEN permitir la captura de contenido de audio sin formato 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 utilizando la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

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

Si la plataforma admite tecnologías de supresión de ruido optimizadas para el reconocimiento de voz, el efecto DEBE poder controlarse desde la API android.media.audiofx.NoiseSuppressor. Además, el campo UUID para el descriptor de efecto del supresor de ruido DEBE identificar de forma ú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.AudioSource incluye la fuente de audio REMOTE_SUBMIX. Los dispositivos que declaran android.hardware.audio.output DEBEN implementar correctamente la fuente de audio REMOTE_SUBMIX para que cuando una aplicación use la API android.media.AudioRecord para grabar desde esta fuente de audio, pueda capturar una mezcla de todas las transmisiones de audio excepto las siguientes :

• STREAM_RING
• TRANSMISIÓN_ALARM
• TRANSMISIÓN_NOTIFICACIÓN

5.5. Reproducción de audio

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

5.5.1. Reproducción de audio sin procesar

El dispositivo DEBE permitir la reproducción de contenido de audio sin formato 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 de contenido de audio sin formato con las siguientes características:

• Tasas de muestreo : 24000, 48000

5.5.2. Efectos de audio

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

• DEBE admitir las implementaciones EFFECT_TYPE_EQUALIZER y EFFECT_TYPE_LOUDNESS_ENHANCER controlables a través de las subclases AudioEffect Equalizer, LoudnessEnhancer.
• DEBE admitir la implementación de la API del visualizador, controlable a través de la clase Visualizer.
• DEBE admitir las implementaciones EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER controlables a través de las subclases AudioEffect BassBoost, EnvironmentalReverb, PresetReverb y Virtualizer.

5.5.3. Volumen de salida de audio

Las implementaciones de dispositivos Android Television DEBEN incluir soporte para el volumen maestro del sistema y la atenuación del volumen de salida de audio digital en las salidas compatibles, excepto para la salida de paso de audio comprimido (donde no se realiza ninguna 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 se basan en latencias cortas para lograr efectos de sonido en tiempo real.

A los efectos de esta sección, utilice las siguientes definiciones:

• latencia de salida . El intervalo entre el momento en que una aplicación escribe un cuadro de datos codificados en PCM y el momento en que un oyente externo puede escuchar el sonido correspondiente u observarlo mediante un transductor.
• Latencia de salida en frío . La latencia de salida para el primer fotograma, cuando el sistema de salida de audio ha estado inactivo y apagado antes de la solicitud.
• Latencia de salida continua . La latencia de salida para fotogramas posteriores, después de que el dispositivo esté reproduciendo audio.
• latencia de entrada . El intervalo entre el momento en que se presenta un sonido externo al dispositivo y el momento en que una aplicación lee el cuadro correspondiente de datos codificados en PCM.
• Latencia de entrada en 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 estuvo inactivo y apagado antes de la solicitud.
• Latencia de entrada continua . La latencia de entrada para fotogramas posteriores, mientras el dispositivo captura audio.
• fluctuación de salida en frío . La variación entre mediciones separadas de los valores de latencia de salida en frío.
• fluctuación de entrada en frío . La variación entre mediciones separadas de valores de latencia de entrada en frío.
• Latencia continua de ida y vuelta . La suma de la latencia de entrada continua más la latencia de salida continua más 5 milisegundos.
• API de cola de búfer OpenSL ES PCM . El conjunto de API OpenSL ES relacionadas con PCM dentro del NDK de Android; consulte NDK_root/docs/opensles/index.html.

Las implementaciones de dispositivos que declaran android.hardware.audio.output DEBEN cumplir o superar 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 la fluctuación de la salida en frío

Si la implementación de un dispositivo cumple con los requisitos de esta sección después de cualquier calibración inicial cuando se utiliza la API de cola de búfer OpenSL ES PCM, para latencia de salida continua y latencia de salida fría en al menos un dispositivo de salida de audio compatible, PUEDE informar soporte para audio de baja latencia. , informando la característica android.hardware.audio.low_latency a través de la clase android.content.pm.PackageManager [ 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 continua de ida y vuelta de 50 milisegundos o menos.
• minimizar la fluctuación de entrada en frío

5.7. Protocolos de red

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

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

5.8. Medios seguros

Las implementaciones de dispositivos que admiten salida de video segura y son capaces de admitir superficies seguras DEBEN declarar soporte para Display.FLAG_SECURE. Las implementaciones de dispositivos que declaran compatibilidad con Display.FLAG_SECURE, si admiten un protocolo de visualización inalámbrica, DEBEN proteger el enlace con un mecanismo criptográficamente sólido, como HDCP 2.x o superior para pantallas inalámbricas 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 Android Television DEBEN admitir HDCP 2.2 para dispositivos que admiten resolución 4K y HDCP 1.4 o superior para resoluciones más bajas. La implementación de código abierto de Android incluye soporte para pantallas inalámbricas (Miracast) y cableadas (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:

• Puente de depuración de Android (adb) [ Recursos, 55 ]

Las implementaciones de dispositivos DEBEN admitir todas las funciones de adb como se documenta en el SDK de Android, incluido 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 Android Debug Bridge. Si la implementación de un dispositivo omite el modo periférico USB, DEBE implementar el puente de depuración de Android a través de una red de área local (como Ethernet o 802.11).

Android incluye soporte para adb seguro. Secure adb habilita adb en hosts autenticados conocidos. Las implementaciones de dispositivos DEBEN admitir adb seguro.

• Servicio Dalvik Debug Monitor (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, la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.

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

6.2. Opciones de desarrollador

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

7. Compatibilidad de hardware

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

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

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

Las implementaciones de dispositivos DEBEN informar constantemente información precisa de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella digital de compilación. [ Recursos, 53]

7.1. Pantalla y gráficos

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

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

• Tamaño diagonal físico . La distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
• puntos por pulgada (ppp) . El número de píxeles abarcados por un intervalo lineal horizontal o vertical de 1”. Cuando se enumeran valores de ppp, tanto los ppp horizontales como los verticales deben estar dentro del rango.
• relación de aspecto . La relación entre los píxeles de la dimensión más larga y la dimensión más corta de la pantalla. Por ejemplo, una pantalla 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 normalizada a una pantalla de 160 ppp, 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 tamaños de pantalla diferentes y permite que las aplicaciones consulten el tamaño de la pantalla del dispositivo (también conocido como "diseño de pantalla") a través de android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Las implementaciones del dispositivo DEBEN informar el tamaño de pantalla correcto como se define en la documentación del SDK de Android [ Recursos, 61 ] y lo determina la plataforma Android ascendente. Específicamente, las implementaciones de dispositivos DEBEN informar el tamaño de pantalla correcto de acuerdo con las siguientes dimensiones lógicas de pantalla de píxeles (dp) independientes de la densidad.

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

Además,

• Los dispositivos Android Watch DEBEN tener una pantalla con un 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 el tamaño de pantalla informado en ningún momento.

Opcionalmente, las aplicaciones indican qué tamaños de pantalla admiten a través del atributo <supports-screens> en el archivo AndroidManifest.xml. Las implementaciones de dispositivos DEBEN respetar correctamente la compatibilidad declarada de las aplicaciones para pantallas pequeñas, normales, grandes y extragrandes, como se describe en la documentación del SDK de Android.

7.1.1.2. Relación de aspecto de pantalla

La relación de aspecto de la pantalla DEBE tener un valor de 1,3333 (4:3) a 1,86 (aproximadamente 16:9), pero los dispositivos Android Watch PUEDEN tener una relación de aspecto de 1,0 (1:1) porque dicha implementación de dispositivo utilizará 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 orientar los recursos de la aplicación. Las implementaciones de dispositivos DEBEN informar solo una de las siguientes densidades lógicas del marco de trabajo de Android a través de las API android.util.DisplayMetrics, DEBEN ejecutar aplicaciones con esta densidad estándar y NO DEBEN cambiar el valor en ningún momento para la visualización predeterminada.

• 120 ppp (ldpi)
• 160 ppp (mppp)
• 213 ppp (TV ppp)
• 240 ppp (alta resolución)
• 280 ppp (280 ppp)
• 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 del marco de Android estándar que sea numéricamente más cercana a la densidad física de la pantalla, a menos que esa densidad lógica empuje el tamaño de pantalla informado por debajo del mínimo admitido. Si la densidad del marco de Android estándar que es numéricamente más cercana a la densidad física da como resultado un tamaño de pantalla más pequeño que el tamaño de pantalla compatible más pequeño admitido (320 dp de ancho), las implementaciones del dispositivo DEBEN informar la siguiente densidad de marco de Android estándar más baja.

7.1.2. Mostrar métricas

Las implementaciones de dispositivos DEBEN informar valores correctos para todas las métricas de visualización definidas en android.util.DisplayMetrics [ Recursos, 62 ] y DEBEN informar los mismos valores independientemente de si se utiliza la pantalla incorporada o externa como visualización 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 admitida. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como un televisor o una computadora portátil, DEBE informar solo android.hardware.screen.landscape.

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

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

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

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

Las implementaciones de dispositivos DEBEN admitir OpenGL ES 1.0 y 2.0, como se incluye y detalla en la documentación del SDK de Android. Las implementaciones de dispositivos DEBEN admitir OpenGL ES 3.0 o 3.1 en dispositivos capaces de admitirlo. Las implementaciones de dispositivos DEBEN también ser compatibles con Android RenderScript, como se detalla en la documentación del SDK de Android [ Recursos, 63 ].

Las implementaciones de dispositivos DEBEN también identificarse correctamente como compatibles con OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 u OpenGL 3.1. Eso es:

• Las API administradas (como a través del método GLES10.getString()) DEBEN informar compatibilidad con OpenGL ES 1.0 y OpenGL ES 2.0.
• Las API OpenGL nativas de C/C++ (API disponibles para aplicaciones a través de libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEBEN informar compatibilidad con OpenGL ES 1.0 y OpenGL ES 2.0.
• Las implementaciones de dispositivos que declaran compatibilidad con OpenGL ES 3.0 o 3.1 DEBEN admitir las API administradas correspondientes e incluir compatibilidad con las API nativas de C/C++. En implementaciones de dispositivos que declaran soporte para OpenGL ES 3.0 o 3.1, libGLESv2.so DEBE exportar los símbolos de función correspondientes además de los símbolos de función de 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 funciones gráficas avanzadas como la teselación y el formato de compresión de texturas ASTC. Las implementaciones de dispositivos Android PUEDEN admitir este paquete de extensión y, solo si están completamente implementados, DEBEN identificar el soporte a través del indicador de función android.hardware.opengles.aep.

Además, las implementaciones de dispositivos PUEDEN implementar cualquier extensión de OpenGL ES deseada. Sin embargo, las implementaciones de dispositivos DEBEN informar a través de las API nativas y administradas de OpenGL ES todas las cadenas de extensión que sí admiten y, a la inversa, NO DEBEN informar las cadenas de extensión que no admiten.

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

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D en el nivel de Aplicación, Actividad, Ventana o Vista mediante el uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas API directas [ 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="false” o deshabilitando la aceleración de hardware directamente a través de las API de Android View.

Además, las implementaciones de dispositivos DEBEN exhibir un comportamiento consistente con la documentación del SDK de Android sobre aceleración de hardware [ Recursos, 65 ].

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

Android incluye soporte para EGL_ANDROID_RECORDABLE, un atributo de EGLConfig que indica si EGLConfig admite la representación en una ANativeWindow que graba imágenes en un video. Las implementaciones de dispositivos DEBEN admitir la extensión EGL_ANDROID_RECORDABLE [ Recursos, 66 ].

7.1.5. Modo de compatibilidad de aplicaciones heredadas

Android especifica un "modo de compatibilidad" en el que el marco opera en un modo de tamaño de pantalla "normal" equivalente (ancho de 320 dp) para beneficio de aplicaciones heredadas no desarrolladas para versiones antiguas de Android anteriores a la independencia del tamaño de pantalla.

• Android Automotive no admite el modo de compatibilidad heredado.
• Todas las demás implementaciones de dispositivos DEBEN incluir soporte para el modo de compatibilidad de aplicaciones heredadas tal como lo implementa el código fuente abierto de Android. Es decir, las implementaciones de dispositivos NO DEBEN alterar los desencadenantes o umbrales en los que se activa el modo de compatibilidad, y NO DEBEN alterar el comportamiento del modo de compatibilidad en sí.

7.1.6. Tecnología de pantalla

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

• Los dispositivos DEBEN admitir pantallas capaces de reproducir gráficos en color de 16 bits y DEBEN admitir pantallas capaces de reproducir gráficos en color de 24 bits.
• Los dispositivos DEBEN admitir pantallas capaces de representar animaciones.
• La tecnología de visualización utilizada DEBE tener una relación de aspecto de píxeles (PAR) entre 0,9 y 1,15. Es decir, la relación de aspecto de los píxeles DEBE ser casi cuadrada (1,0) con una tolerancia del 10 al 15 %.

7.1.7. Pantallas secundarias

Android incluye soporte para pantalla secundaria para habilitar capacidades de intercambio de medios y API de desarrollador para acceder a pantallas externas. Si un dispositivo admite una pantalla externa, ya sea a través de una conexión de pantalla adicional cableada, inalámbrica o integrada, entonces la implementación del dispositivo DEBE implementar la API del administrador de pantalla como se describe en la documentación del SDK de Android [ Recursos, 67 ].

7.2. Los dispositivos de entrada

Los dispositivos DEBEN admitir una pantalla táctil o cumplir con los requisitos enumerados en 7.2.2 para navegación no táctil.

7.2.1. Teclado

Implementaciones de dispositivos:

• DEBE incluir soporte para el marco de administración de entrada (que permite a los desarrolladores externos crear editores de métodos de entrada, es decir, teclado virtual) como se detalla en http://developer.android.com .
• DEBE proporcionar al menos una implementación de teclado virtual (independientemente de si hay un teclado físico presente), excepto para dispositivos Android Watch donde el tamaño de la pantalla hace que sea menos razonable tener un teclado virtual.
• 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 teclas).

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 rueda) si la implementación del dispositivo no es un dispositivo Android Television.
• 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 de texto, compatible con los motores de gestión de entrada. La implementación de código abierto de Android incluye un mecanismo de selección adecuado para su uso con dispositivos que carecen de entradas de navegación no táctiles.

7.2.3. Teclas de navegación

Las funciones Inicio, Recientes y Atrás (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 Android DEBEN proporcionar las funciones Inicio, Recientes y Atrás.
• Las implementaciones de dispositivos Android Television DEBEN proporcionar las funciones Inicio y Atrás.
• Las implementaciones de dispositivos Android Watch DEBEN tener la función Inicio disponible para el usuario y la función Atrás, excepto cuando está en UI_MODE_TYPE_WATCH.
• Las implementaciones de Android Automotive DEBEN proporcionar la función Inicio y PUEDEN proporcionar funciones Atrás y Recientes.
• Todos los demás tipos de implementaciones de dispositivos DEBEN proporcionar las funciones Inicio y Atrás.

Estas funciones PUEDEN implementarse mediante botones físicos dedicados (como botones táctiles mecánicos o capacitivos), o PUEDEN implementarse mediante teclas 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, tocar, hacer doble clic o hacer un gesto) cuando estén visibles.

La función Recientes, si se proporciona, DEBE tener un botón o ícono visible a menos que esté oculta junto con otras funciones de navegación en el modo de pantalla completa. Esto no se aplica a dispositivos que se actualizan desde versiones anteriores de Android que tienen botones físicos para navegación y no tienen clave de actualizaciones recientes.

Las funciones Inicio y Atrás, si se proporcionan, DEBEN tener cada una un botón o ícono visible a menos que estén ocultas junto con otras funciones de navegación en el modo de pantalla completa o cuando uiMode UI_MODE_TYPE_MASK esté configurado en UI_MODE_TYPE_WATCH.

La función Menú está obsoleta en favor de la barra de acciones desde Android 4.0. Por lo tanto, las implementaciones de nuevos dispositivos que se envían con Android 5.0 y versiones posteriores NO DEBEN implementar un botón físico dedicado para la función Menú. Las implementaciones de dispositivos más antiguos NO DEBEN implementar un botón físico dedicado para la función Menú, pero si el botón Menú físico está implementado 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 acciones cuando esté visible y el menú emergente de desbordamiento de acción resultante no esté vacío. Para una implementación de dispositivo lanzada antes de Android 4.4 pero que se actualiza a Android 5.1, se RECOMIENDA.
• NO DEBE modificar la posición de la ventana emergente de desbordamiento de acción que se muestra al seleccionar el botón de desbordamiento en la barra de acciones.
• PUEDE mostrar la ventana emergente de desbordamiento de acción en una posición modificada en la pantalla cuando se muestra seleccionando el botón de menú físico.

Para lograr compatibilidad con versiones anteriores, las implementaciones de dispositivos DEBEN hacer que la función Menú esté disponible para las aplicaciones cuando targetSdkVersion sea inferior a 10, ya sea mediante un botón físico, una clave 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 totalmente 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 ningún elemento adicional para indicar los objetos que se están manipulando. 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 mouse o control remoto que controla un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o enfoque y luego haga clic. Numerosos dispositivos de entrada como el mouse, el trackpad, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el trackpad multitáctil pueden admitir interacciones táctiles falsas. Android incluye la característica constante 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 táctil (incluida la compatibilidad con 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 absolutas 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 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 que los usuarios muevan rápidamente el objeto a una posición diferente en la pantalla y luego 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 [ Recursos, 72 ]

2 Los usos de HID anteriores deben declararse dentro de una CA de gamepad (0x01 0x0005).

3 Este uso debe tener un mínimo lógico de 0, un máximo lógico de 7, un mínimo físico de 0, un máximo físico de 315, unidades en grados y un tamaño de informe de 4. El valor lógico se define como la rotación en el sentido de las agujas del reloj. lejos del eje vertical; por ejemplo, un valor lógico de 0 representa que no hay rotación y que se presiona el botón hacia arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionan las teclas arriba e izquierda.

4 [ Recursos, 71 ]

1 [ Recursos, 71 ]

7.2.7. Control remoto

Las implementaciones de dispositivos de televisión de Android deben proporcionar un control remoto para permitir a los usuarios acceder a la interfaz de TV. El control remoto puede ser un control remoto físico o puede ser un control remoto basado en software al que se puede acceder desde un teléfono móvil o tableta. El control remoto debe cumplir con los requisitos definidos a continuación.

• Aseguridad de búsqueda . Las implementaciones de dispositivos deben disparar KeyCode_Search cuando el usuario invoca la búsqueda de voz en el control físico o basado en software.
• Navegación . Todos los controles remotos de la televisión de Android deben incluir botones de regreso, hogar y selección y soporte para eventos D-PAD [ recursos, 72 ].

7.3. Sensores

Android incluye API para acceder a una variedad de tipos de sensores. Las implementaciones de dispositivos generalmente pueden omitir estos sensores, según lo dispuesto en las siguientes subsecciones. Si un dispositivo incluye un tipo de sensor particular que tiene una API correspondiente para desarrolladores de terceros, la implementación del dispositivo debe implementar esa API como se describe en la documentación SDK de Android y la documentación de código abierto de Android en los sensores [ recursos, 73 ]. Por ejemplo, implementaciones del dispositivo:

• Debe informar con precisión la presencia o ausencia de sensores según Android.Content.Pm.PackageManager Clase [ Recursos, 53] .
• Debe devolver una lista precisa de sensores compatibles a través del sensorManager.getSensorList () y métodos similares.
• Debe comportarse razonablemente para todas las demás API de sensores (por ejemplo, devolviendo verdadero o falso según corresponda cuando las aplicaciones intentan registrar a los oyentes, no llamar a los oyentes de los sensores cuando los sensores correspondientes no están presentes; etc.).
• Debe informar todas las mediciones del sensor utilizando los valores relevantes del sistema internacional de unidades (métrica) para cada tipo de sensor como se define en la documentación SDK de Android [ recursos, 74 ].
• Debe informar el tiempo del evento en nanosegundos tal como se define en la documentación SDK de Android, que representa el tiempo que ocurrió el evento y sincronizado con el reloj SystemClock.ElapsedRealTimenano (). Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a cumplir con estos requisitos para que puedan actualizar a las versiones futuras de la plataforma donde esto podría convertirse en un componente requerido. El error de sincronización debe ser inferior a 100 milisegundos [ recursos, 75 ].

La lista anterior no es exhaustiva; El comportamiento documentado del SDK de Android y las documentos de código abierto de Android sobre los sensores [ recursos, 73 ] se considerará autorizado.

Algunos tipos de sensores son compuestos, lo que significa que pueden derivarse de datos proporcionados por uno o más sensores. (Los ejemplos incluyen el sensor de orientación y el sensor de aceleración lineal). Las implementaciones de dispositivos deben implementar estos tipos de sensores, cuando incluyen los sensores físicos de requisitos previos como se describe en [ Recursos, 76 ]. Si una implementación del dispositivo incluye un sensor compuesto, debe implementar el sensor como se describe en la documentación de código abierto de Android en sensores compuestos [ recursos, 76 ].

Algunos sensores de Android admiten un modo de activación "continuo", que devuelve los datos continuamente [ recursos, 77 ]. Para cualquier API indicada por la documentación de SDK de Android como un sensor continuo, las implementaciones de dispositivos deben proporcionar continuamente muestras de datos periódicos que deben tener un jitter por debajo del 3%, donde la jitter se define como la desviación estándar de la diferencia de los valores de marca de tiempo informados entre consecutivos entre consecutivos eventos.

Tenga en cuenta que las implementaciones del dispositivo deben asegurarse de que la secuencia de eventos del sensor no debe evitar que la CPU del dispositivo ingrese a un estado de suspensión o despierta de un estado de suspensión.

Finalmente, cuando se activan varios sensores, el consumo de energía no debe exceder la suma del consumo de energía informado del sensor individual.

7.3.1. Acelerómetro

Las implementaciones del dispositivo deben incluir un acelerómetro de 3 ejes. Se recomienda encarecidamente que los dispositivos de mano de Android y los dispositivos de reloj Android incluyan este sensor. Si la implementación de un dispositivo incluye un acelerómetro de 3 ejes, TI: TI:

• Debe implementar e informar el sensor Type_accelerómetro [ recursos, 78 ].
• Debe poder informar eventos de hasta una frecuencia de al menos 50 Hz para dispositivos de reloj Android, ya que tales dispositivos tienen una restricción de potencia más estricta y 100 Hz para todos los demás tipos de dispositivos.
• DEBE informar eventos de hasta al menos 200 Hz.
• Debe cumplir con el sistema de coordenadas del sensor Android como se detalla en las API de Android [ recursos, 74 ].
• Debe ser capaz de medir desde la caída libre hasta cuatro veces la gravedad (4 g) o más en cualquier eje.
• Debe tener una resolución de al menos 8 bits y debe tener una resolución de al menos 16 bits.
• DEBE calibrarse mientras está en uso si las características cambian durante el ciclo de vida y compensarse, y preservar los parámetros de compensación entre reinicios del dispositivo.
• DEBE tener compensación de temperatura.
• Debe tener una desviación estándar no mayor de 0.05 m/s^, donde la desviación estándar debe calcularse por eje en las muestras recolectadas durante un período de al menos 3 segundos a la velocidad de muestreo más rápida.
• Debería implementar type_significant_motion, type_tilt_detector, type_step_detector, type_step_counter sensores compuestos como se describe en el documento SDK de Android. Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a implementar el sensor compuesto type_significant_motion. Si se implementan alguno de estos sensores, la suma de su consumo de energía siempre debe ser inferior a 4 MW y cada uno está por debajo de 2 MW y 0.5 MW para cuando el dispositivo está en una condición dinámica o estática.
• Si se incluye un sensor de giroscopio, debe implementar los sensores compuestos type_gravity y type_linear_aceleration y debe implementar el sensor compuesto type_game_rotation_vector. Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a implementar el sensor type_game_rotation_vector.
• Debe implementar un sensor compuesto type_rotation_vector, si también se incluye un sensor de giroscopio y un sensor de magnetómetro.

7.3.2. Magnetómetro

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

• Debe implementar el sensor type_magnetic_field y también debe implementar el sensor type_magnetic_field_uncalibrated. Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a implementar el sensor type_magnetic_field_uncalibrated.
• Debe poder informar eventos hasta una frecuencia de al menos 10 Hz y debe informar eventos de hasta al menos 50 Hz.
• Debe cumplir con el sistema de coordenadas del sensor Android como se detalla en las API de Android [ recursos, 74 ].
• Debe ser capaz de medir entre -900 µt y +900 µt en cada eje antes de saturar.
• Debe tener un valor de desplazamiento de hierro duro inferior a 700 µt y debe tener un valor inferior a 200 µt, colocando el magnetómetro lejos de los campos magnéticos dinámicos (inducidos por la corriente) e estáticos (inducidos por el imán).
• Debe tener una resolución igual o más densa que 0.6 µt y debe tener una resolución igual o más densa que 0.2 µ.
• DEBE tener compensación de temperatura.
• Debe admitir la calibración en línea y la compensación del sesgo de hierro duro, y preservar los parámetros de compensación entre los reinicios del dispositivo.
• Debe aplicarse la compensación de hierro blando: la calibración se puede hacer mientras se usa o durante la producción del dispositivo.
• Debe tener una desviación estándar, calculada por eje por eje en muestras recolectadas durante un período de al menos 3 segundos a la velocidad de muestreo más rápida, no más de 0.5 µt.
• Debe implementar un sensor compuesto type_rotation_vector, si también se incluye un sensor de acelerómetro y un sensor de giroscopio.
• Puede implementar el sensor type_geomagnetic_rotation_vector si también se implementa un sensor de acelerómetro. Sin embargo, si se implementa, debe consumir menos de 10 MW y debe consumir menos de 3 MW cuando el sensor está registrado para el modo por lotes a 10 Hz.

7.3.3. GPS

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

7.3.4. Giroscopio

Las implementaciones del dispositivo deben incluir un giroscopio (sensor de cambio angular). Los dispositivos no deben incluir un sensor de giroscopio a menos que también se incluya un acelerómetro de 3 ejes. Si una implementación de un dispositivo incluye un giroscopio, TI:

• Debe implementar el sensor type_gyroscope y también debe implementar el sensor type_gyroscope_uncalibrated. Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a implementar el sensor sensor_type_gyroscope_uncalibrated.
• Debe ser capaz de medir los cambios de orientación de hasta 1,000 grados por segundo.
• Debe poder informar eventos de hasta una frecuencia de al menos 50 Hz para dispositivos de reloj Android, ya que tales dispositivos tienen una restricción de potencia más estricta y 100 Hz para todos los demás tipos de dispositivos.
• DEBE informar eventos de hasta al menos 200 Hz.
• Debe tener una resolución de 12 bits o más y debe tener una resolución de 16 bits o más.
• Debe ser compensado de temperatura.
• Debe calibrarse y compensarse mientras está en uso, y preservar los parámetros de compensación entre los reinicios del dispositivo.
• Debe tener una varianza no mayor que 1e-7 rad^2 / s^2 por Hz (varianza por Hz, o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero debe estar limitada por este valor. En otras palabras, si mide la varianza del Gyro a la velocidad de muestreo de 1 Hz, no debe ser mayor que 1e-7 rad^2/s^2.
• Debería implementar un sensor compuesto type_rotation_vector, si también se incluye un sensor de acelerómetro y un sensor de magnetómetro.
• Si se incluye un sensor de acelerómetro, debe implementar los sensores compuestos type_gravity y type_linear_aceleración y debe implementar el sensor compuesto type_game_rotation_vector. Se recomienda encarecidamente a los dispositivos Android existentes y nuevos a implementar el sensor type_game_rotation_vector.

7.3.5. Barómetro

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

• Debe implementar e informar el sensor Type_Pressure.
• Debe poder entregar eventos a 5 Hz o más.
• Debe tener una precisión adecuada para permitir la estimación de la altitud.
• Debe ser compensado de temperatura.

7.3.6. Termómetro

Las implementaciones del dispositivo pueden incluir un termómetro ambiental (sensor de temperatura). Si está presente, debe definirse como sensor_type_ambient_temperature y debe medir la temperatura ambiente (habitación) en grados centígrados.

Las implementaciones del dispositivo pueden, pero no deben incluir un sensor de temperatura de la CPU. Si está presente, debe definirse como sensor_type_temperature, debe medir la temperatura de la CPU del dispositivo y no debe medir ninguna otra temperatura. Tenga en cuenta que el tipo de sensor Sensor_Type_Temperature estaba en desuso en Android 4.0.

7.3.7. Fotómetro

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

7.3.8. Sensor de proximidad

Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad. Los dispositivos que pueden hacer una llamada de voz e indicar cualquier valor que no sea phone_type_none en GetPhonetype debe incluir un sensor de proximidad. Si una implementación de un dispositivo incluye un sensor de proximidad, TI:

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

7.4. Conectividad de datos

7.4.1. Telefonía

"Telefonía" tal como la utilizan las API de Android y este documento se refiere específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes, a los efectos de Android se consideran independientes de cualquier conectividad de datos que pueda implementarse utilizando la misma red. En otras palabras, la funcionalidad de “telefonía” y las API de Android se refieren específicamente a llamadas de voz y SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas o enviar/recibir mensajes SMS no deben informar la función Android.hardware.telephony o cualquier subfaza, independientemente de si usan una red celular para la conectividad de datos.

Android PUEDE usarse en dispositivos que no incluyen hardware de telefonía. Es decir, Android es compatible con dispositivos que no son teléfonos. Sin embargo, si una implementación de un dispositivo incluye la telefonía GSM o CDMA, debe implementar el soporte completo para la API para esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía deben implementar las API completas como NO-OPS.

7.4.2. IEEE 802.11 (Wi-Fi)

Las implementaciones de dispositivos de televisión de Android deben incluir soporte para una o más formas de 802.11 (b/g/a/n, etc.) y otros tipos de implementación del dispositivo Android deben incluir soporte para una o más formas de 802.11. Si una implementación de un dispositivo incluye soporte para 802.11 y expone la funcionalidad a una aplicación de terceros, debe implementar la API de Android correspondiente y:

• Debe informar la función de hardware Flag Android.hardware.wifi.
• Debe implementar la API de multidifusión como se describe en la documentación SDK [ recursos, 79 ].
• Debe admitir DNS de multidifusión (MDN) y no debe filtrar paquetes MDNS (224.0.0.251) en cualquier momento de la operación, incluso cuando la pantalla no está en un estado activo.

7.4.2.1. Wi-Fi directo

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

• Debe informar la función de hardware android.hardware.wifi.direct.
• Debe admitir la operación Wi-Fi regular.
• Debe admitir operación directa de Wi-Fi y Wi-Fi concurrente.

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

Las implementaciones de dispositivos de televisión de Android deben incluir soporte para la configuración de enlaces directos de túnel Wi-Fi (TDLS) y otros tipos de implementaciones de dispositivos Android deben incluir soporte para TDL de Wi-Fi como se describe en la documentación SDK de Android [ recursos, 81 ]. Si la implementación de un dispositivo incluye soporte para TDLS y TDLS está habilitado por la API Wifimanager, el dispositivo:

• DEBE usar TDLS solo cuando sea posible Y beneficioso.
• DEBE tener algo de heurística y NO usar TDLS cuando su rendimiento podría ser peor que a través del punto de acceso Wi-Fi.

7.4.3. Bluetooth

Android incluye soporte para Bluetooth y Bluetooth Low Energy [ recursos, 82 ]. Las implementaciones de dispositivos que incluyen soporte para Bluetooth y Bluetooth Low Energy deben declarar las características relevantes de la plataforma (android.hardware.bluetooth y android.hardware.bluetooth_le respectivamente) e implementar las API de la plataforma. Las implementaciones de dispositivos deben implementar perfiles Bluetooth relevantes como A2DP, AVCP, OBEX, etc., según corresponda para el dispositivo. Las implementaciones de dispositivos de televisión de Android deben admitir Bluetooth y Bluetooth LE.

Implementaciones de dispositivos que incluyen soporte para Bluetooth Low Energy:

• Debe declarar la función de hardware android.hardware.bluetooth_le.
• Debe habilitar las API Bluetooth basadas en GATT (perfil de atributo genérico) como se describe en la documentación SDK y [ recursos, 82 ].
• Debe admitir la descarga de la lógica de filtrado en el chipset Bluetooth al implementar la API de escaneo [ recursos, 83 ], y debe informar el valor correcto de dónde se implementa la lógica de filtrado cuando se consulte a través del android.bluetooth.bluetoothadapter.ISOFFILLOGEDFILTEREPRESPORTINGEPORTEDEPORTED () método.
• Debe admitir la descarga del escaneo por lotes al conjunto de chips Bluetooth, pero si no es compatible, debe informar 'falso' siempre que se consulte a través del método Android.Bluetooth.BluetoothAdapater.SOffLoadedScanBatchingSupported ().
• Debe admitir múltiples anuncios con al menos 4 ranuras, pero si no se admite, debe informar 'falso' siempre que se consulte a través del método android.Bluetooth.BluetoothAdapter.IsmultIlEdvertiseMementsUpported ().

7.4.4. Comunicaciones de campo cercano

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

• Debe informar la función Android.hardware.nfc desde android.content.pm.packagemanager.hassystemfeature () método [ recursos, 53 ].
• Debe ser capaz de leer y escribir mensajes NDEF a través de los siguientes estándares de NFC:
  • Debe ser capaz de actuar como un lector/escritor del foro de la NFC (según lo definido por la especificación técnica del foro NFC NFCFORUM-TS-DIGITALPROTOCOL-1.0) a través de los siguientes estándares NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NFCF (JIS 6319-4)
    • ISODep (ISO 14443-4)
    • NFC Forum Tag Tipos 1, 2, 3, 4 (definido por el foro NFC)
  • Debe ser capaz de leer y escribir mensajes NDEF a través de los siguientes estándares NFC. Tenga en cuenta que, si bien los estándares de NFC a continuación se establecen como debería, la definición de compatibilidad para una versión futura se planea cambiarlos a Must. Estos estándares son opcionales en esta versión pero serán necesarios en versiones futuras. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan esta versión de Android cumplan con estos requisitos ahora para que puedan actualizarse a futuras versiones de la plataforma.
  • NFCV (ISO 15693)
  • Debe ser capaz de transmitir y recibir datos a través de los siguientes estándares y protocolos de igual a igual:
    • ISO 18092
    • LLCP 1.0 (definido por el foro NFC)
    • SDP 1.0 (definido por el foro NFC)
    • Protocolo NDEF Push [ Recursos, 84 ]
    • SNEP 1.0 (definido por el foro NFC)
  • Debe incluir soporte para Android Beam [ recursos, 85 ]:
    • Debe implementar el servidor predeterminado SNEP. Los mensajes NDEF válidos recibidos por el servidor SNEP predeterminado deben enviarse a las aplicaciones utilizando Android.nfc.action_ndef_discovered intent. Desactivar el haz de Android en la configuración no debe deshabilitar el envío del mensaje NDEF entrante.
    • Debe honrar el android.settings.nfcsharing_settings intención de mostrar la configuración de intercambio de NFC [ recursos, 86 ].
    • Debe implementar el servidor NPP. Los mensajes recibidos por el servidor NPP deben procesarse de la misma manera que el servidor predeterminado SNEP.
    • Debe implementar un cliente SNEP e intentar enviar P2P NDEF saliente al servidor SNEP predeterminado cuando el haz Android está habilitado. Si no se encuentra un servidor SNEP predeterminado, el cliente debe intentar enviar a un servidor NPP.
    • Debe permitir que las actividades en primer plano establezcan el mensaje P2P NDEF saliente usando android.nfc.nfcadapter.setndefpushmessage y android.nfc.nfcadapter.setndefpushmessageCallback y android.nfc.nfcadapter.enableforegroundndefpush.
    • Debe usar una confirmación de gesto o en pantalla, como 'toque a viga', antes de enviar mensajes NDEF salientes P2P.
    • Debe habilitar el haz de Android de forma predeterminada y debe poder enviar y recibir usando el haz Android, incluso cuando se enciende otro modo NFC P2P patentado.
    • Debe admitir la transferencia de conexión NFC a Bluetooth cuando el dispositivo admite el perfil de empuje de objeto Bluetooth. Las implementaciones de dispositivos deben admitir la transferencia de conexión a Bluetooth cuando se usa Android.nfc.nfcadapter.setBeamPushuris, implementando la "Versión de transferencia de conexión 1.2" [ recursos, 87 ] y "Bluetooth Secure Simple Pareing usando la versión 1.0" [ recursos, 88 ] desde las especificaciones de El foro NFC. Dicha implementación debe implementar el servicio de transferencia LLCP con el nombre del servicio "Urn: NFC: SN: Hedover" para intercambiar la solicitud de transferencia/registros de selección a través de NFC, y debe usar el perfil de empuje del objeto Bluetooth para la transferencia de datos Bluetooth real. Por razones heredadas (para permanecer compatible con los dispositivos Android 4.1), la implementación aún debe aceptar las solicitudes de obtener SNEP para intercambiar la solicitud de transferencia/registros de selección a través de NFC. Sin embargo, una implementación en sí no debe enviar solicitudes de obtención de SNP para realizar la entrega de conexión.
  • Debe encuestar para todas las tecnologías compatibles mientras está en el modo de descubrimiento de NFC.
  • DEBE estar en modo de descubrimiento NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.

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

Android incluye soporte para el modo de emulación de tarjeta host NFC (HCE). Si la implementación de un dispositivo incluye un conjunto de chips de controlador NFC capaz de enrutamiento de HCE y ID de aplicación de aplicación (ayuda), entonces:

• Debe informar la función Android.hardware.nfc.hce.
• Debe admitir las API NFC HCE como se define en el SDK de Android [ recursos, 10 ].

Además, las implementaciones de dispositivos pueden incluir soporte de lector/escritor para las siguientes tecnologías de MiFare.

• Mifare Classic
• MIFARE Ultraligero
• Ndef en Mifare Classic

Tenga en cuenta que Android incluye API para estos tipos de Mifare. Si una implementación de un dispositivo admite MIFARE en el rol de lector/escritor, TI: TI:

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

Si una implementación de un dispositivo no incluye hardware NFC, no debe declarar la función Android.hardware.nfc desde el método Android.content.pm.packagemanager.hassystemFeature () [ recursos, 53] , y debe implementar la API de Android NFC como una no-op.

Como las clases de Android.nfc.ndefmessage y android.nfc.ndefrecord representan un formato de representación de datos independiente del protocolo, las implementaciones de dispositivos deben implementar estas API incluso si no incluyen soporte para NFC o declaran la función Android.hardware.nfc.

7.4.5. Capacidad mínima de red

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

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

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

7.4.6. Configuración de sincronización

Las implementaciones de dispositivos deben tener la configuración de Auto-Sync de manera predeterminada de manera predeterminada para que el método getMastersyncaUtomatic () devuelva "verdadero" [ recursos, 89 ].

7.5. Cámaras

Las implementaciones de dispositivos deben incluir una cámara trasera y pueden incluir una cámara frontal. Una cámara trasera es una cámara ubicada en el lado del dispositivo opuesto a la pantalla; es decir, captura escenas en el lado opuesto del dispositivo, como una cámara tradicional. Una cámara frontal es una cámara ubicada en el mismo lado del dispositivo que la pantalla; es decir, una cámara que normalmente se utiliza para tomar imágenes del usuario, como por ejemplo para videoconferencias y aplicaciones similares.

Si una implementación de un dispositivo incluye al menos una cámara, debería ser posible que una aplicación asigne simultáneamente 3 mapas de bits igual al tamaño de las imágenes producidas por el sensor de cámara de resolución más grande en el dispositivo.

7.5.1. Cámara trasera

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

• Debe informar el indicador de la función Android.hardware.camera y android.hardware.camera.ally.
• Debe tener una resolución de al menos 2 megapíxeles.
• DEBE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara (transparente al software de la aplicación).
• PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
• PUEDE incluir un flash. Si la cámara incluye un flash, la lámpara de flash no debe encenderse mientras un android.hardware.camera.previewCallback instancia se ha registrado en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos flash_mode_auto o flash_mode_on de A de un Objeto Camera.Parameters. Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema incorporada del dispositivo, sino solo a las aplicaciones de terceros que usan cámara.

7.5.2. Cámara frontal

Las implementaciones de dispositivos pueden incluir una cámara frontal. Si una implementación de un dispositivo incluye al menos una cámara frontal, TI:

• Debe informar el indicador de la función Android.hardware.camera. Any Android.hardware.camera.front.
• Debe tener una resolución de al menos VGA (640x480 píxeles).
• No debe usar una cámara frontal como el valor predeterminado para la API de la cámara. La API de la cámara en Android tiene un soporte específico para las cámaras frontales y las implementaciones del dispositivo no debe configurar la API para tratar una cámara frontal como la cámara trasera predeterminada, incluso si es la única cámara en el dispositivo.
• PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras orientadas hacia atrás como se describe en la sección 7.5.1 .
• Debe reflejar horizontalmente (es decir, espejo) la transmisión que se muestra por una aplicación en un CamerApreview, de la siguiente manera:
  • Si la implementación del dispositivo es capaz de ser girada por el usuario (como automáticamente a través de un acelerómetro o manualmente a través de la entrada del usuario), la vista previa de la cámara debe reflejarse horizontalmente en relación con la orientación actual del dispositivo.
  • Si la aplicación actual ha solicitado explícitamente que la pantalla de la cámara se gire a través de una llamada al android.hardware.camera.setDisplayorientation () [ Recursos, 90 ] Método, la vista previa de la cámara debe reflejarse horizontalmente en relación con la orientación especificada por la aplicación.
  • De lo contrario, la vista previa debe reflejarse a lo largo del eje horizontal predeterminado del dispositivo.
• Debe reflejar la imagen que se muestra por la visión posterior de la misma manera que la transmisión de imagen de vista previa de la cámara. Si la implementación del dispositivo no admite Postview, este requisito obviamente no se aplica.
• No debe reflejar las transmisiones finales de imagen o video capturadas que se devuelven a las devoluciones de llamada de la aplicación o comprometidas con el almacenamiento de medios.

7.5.3. Cámara externa

Las implementaciones de dispositivos con el modo de host USB pueden incluir soporte para una cámara externa que se conecta al puerto USB. Si un dispositivo incluye soporte para una cámara externa, TI:

• Debe declarar la función de la plataforma android.hardware.camera.external y android.hardware cámaras.
• Debe admitir la clase de video USB (UVC 1.0 o superior).
• PUEDE admitir múltiples cámaras.

Se recomienda el soporte de compresión de video (como MJPEG) para permitir la transferencia de transmisiones no codificadas de alta calidad (es decir, flujos de imágenes en bruto o comprimidos independientemente). La codificación de video basada en la cámara puede ser compatible. Si es así, se debe acceder a una secuencia simultánea sin codificación/ MJPEG (QVGA o mayor resolución) a la implementación del dispositivo.

7.5.4. Comportamiento de la API de la cámara

Android incluye dos paquetes API para acceder a la cámara, la API android.hardware.camera2 más nueva expone el control de la cámara de nivel inferior a la aplicación, incluidos flujos eficientes de ráfaga/transmisión de copia cero y controles por fotograma de exposición, ganancia y balance de blancos. , conversión de color, eliminación de ruido, nitidez y más.

El paquete API anterior, android.hardware.camera, está marcado como en desorden en Android 5.0, pero como debería estar disponible para que las aplicaciones usen implementaciones de dispositivos Android deben garantizar el soporte continuo de la API como se describe en esta sección y en el SDK de Android .

Las implementaciones del dispositivo deben implementar los siguientes comportamientos para las API relacionadas con la cámara, para todas las cámaras disponibles:

• Si una aplicación nunca ha llamado android.hardware.camera.parameters.setPreviewFormat (int), entonces el dispositivo debe usar android.hardware.pixelformat.ycbcr_420_sp para los datos de vista previa proporcionadas a las devoluciones de llamada de la aplicación.
• Si una aplicación registra un método android.hardware.camera.previewcallback y el sistema llama al método OnPreviewFrame () Cuando el formato de vista previa es YCBCR_420_SP, los datos en el byte [] pasan a OnpreviewFrame () deben estar en el formato de codificación NV21. Es decir, NV21 DEBE ser el predeterminado.
• Para android.hardware.camera, las implementaciones del dispositivo deben admitir el formato YV12 (según lo denotado por Android.Graphics.ImageFormat.YV12 constante) para las vistas previas de la cámara para cámaras frontales y traseras. (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxel nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
• Para android.hardware.camera2, las implementaciones del dispositivo deben admitir los formatos android.hardware.imageformat.yuv_420_888 y android.hardware.imageformat.jpeg como salidas a través de la API de Android.Media.ImageReader.

Las implementaciones de dispositivos aún deben implementar la API de cámara completa incluida en la documentación de Android SDK [ recursos, 91 ], independientemente de si el dispositivo incluye enfoque automático de hardware u otras capacidades. Por ejemplo, las cámaras que carecen de enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no tiene relevancia para una cámara sin enfoque automático). Tenga en cuenta que esto se aplica a las cámaras frontales; por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API deben ser "falsificadas" como se describe.

Las implementaciones del dispositivo deben reconocer y honrar cada nombre de parámetro definido como una constante en la clase Android.hardware.camera.Parameters, si el hardware subyacente admite la función. Si el hardware del dispositivo no admite una función, la API debe comportarse como se documenta. Por el contrario, las implementaciones de dispositivos no deben honrar ni reconocer las constantes de cadena pasadas al método Android.hardware.camera.setParameters () que no sean las documentadas como constantes en android.hardware.camera.parameters. Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de cámara estándar si el hardware lo permite, y NO DEBEN admitir tipos de parámetros de cámara personalizados. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes utilizando técnicas de imágenes de alto rango dinámico (HDR) deben admitir la cámara de parámetros de la cámara.

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. Es decir, cuando el dispositivo se sostiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo; es decir, se aplica tanto a dispositivos primarios horizontales como a dispositivos primarios verticales.

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.

Device implementations with less than 512MB of memory available to the kernel and userspace, unless an Android Watch, MUST return the value "true" for ActivityManager.isLowRamDevice().

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

Device implementations MUST be configured with shared storage mounted by default, “out of the box”. 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, while that storage MAY share space with the application private data, it MUST be at least 1GB in size and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere).

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST allow only pre-installed and privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to write to the secondary external storage, except when writing to their package-specific directories or within the URI returned by firing the ACTION_OPEN_DOCUMENT_TREE intent.

However, device implementations 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, if the device implementation has a USB port with USB peripheral mode support, it MUST provide some mechanism to access the contents of shared storage from a host computer. Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement. If the device implementation supports Media Transfer Protocol, it:

• SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 96 ].
• DEBE informar una clase de dispositivo USB de 0x00.
• DEBE informar un nombre de interfaz USB de 'MTP'.

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. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
• 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. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
• 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 ]. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
• 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 ohmios o menos : 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. Compatibilidad de rendimiento

Some minimum performance criteria 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 . La latencia de fotogramas inconsistente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia de 5 fotogramas por segundo, y DEBEN ser inferiores a 1 fotograma por segundo.
• User interface latency . Las implementaciones de dispositivos DEBEN garantizar una experiencia de usuario de baja latencia al desplazarse por una lista de 10.000 entradas de lista según lo definido por Android Compatibility Test Suite (CTS) en menos de 36 segundos.
• Cambiar de tarea . Cuando se han iniciado varias aplicaciones, volver a iniciar una aplicación que ya se está ejecutando después de haberla iniciado DEBE tomar menos de 1 segundo.

8.2. Rendimiento del acceso a E/S de archivos

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

• Sequential write . Device implementations MUST ensure a sequential write performance of at least 5MB/s for a 256MB file using 10MB write buffer.
• Random write . Device implementations MUST ensure a random write performance of at least 0.5MB/s for a 256MB file using 4KB write buffer.
• Sequential read . Device implementations MUST ensure a sequential read performance of at least 15MB/s for a 256MB file using 10MB write buffer.
• Random read . Device implementations MUST ensure a random read performance of at least 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. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. 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 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

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. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

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 <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. 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.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. 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. If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

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. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.
• 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. Como esto hará que los medios sean ilegibles para una PC host, se requerirá que las implementaciones del dispositivo cambien a MTP o un sistema similar para proporcionar a las PC host acceso a los datos del usuario actual. 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 ] . Los mensajes SMS premium son mensajes de texto enviados a un servicio registrado con un operador que puede generar un cargo para el usuario. 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. El proyecto de código abierto de Android proporciona una implementación que satisface este requisito.

9.7. Funciones de seguridad del núcleo

The Android Sandbox includes features that can 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, if 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 an equivalent mandatory access control system if using a kernel other than Linux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

Implementaciones de dispositivos:

• MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis, and MUST configure all domains in enforcing mode. No se permiten dominios en modo permisivo, incluidos dominios específicos de un dispositivo/proveedor.
• SHOULD load policy from /sepolicy file on the device.
• MUST NOT modify, omit, or replace the neverallow rules present within the sepolicy file provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow present, for both AOSP SELinux domains as well as device/vendor specific domains .
• MUST support dynamic updates of the SELinux policy file without requiring a system image update.

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. 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.

If a device implementation has a mechanism that routes network data traffic through a proxy server or VPN gateway by default (for example, preloading a VPN service with android.permission.CONTROL_VPN granted), the device implementation MUST ask for the user's consent before enabling that mecanismo.

9.9. Cifrado de disco completo

If the device implementation supports a lock screen with PIN (numeric) or PASSWORD (alphanumeric), 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. Arranque verificado

Verified boot is a feature that guarantees the integrity of the device software. If a device implementation supports the feature, it MUST:

• Declare the platform feature flag android.software.verified_boot
• Perform verification on every boot sequence
• Start verification from a hardware key that is the root of trust, and go all the way up to the system partition
• Implement each stage of verification to check the integrity and authenticity of all the bytes in the next stage before executing the code in the next stage
• Use verification algorithms as strong as current recommendations from NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048)

Device implementations SHOULD support verified boot for device integrity. While this requirement is SHOULD for this version of the Android platform, it is strongly RECOMMENDED as we expect this to change to MUST in 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. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 5.1. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

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

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform “live” upgrades—that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

• “Over-the-air (OTA)” downloads with offline update via reboot
• “Tethered” updates over USB from a host PC
• “Offline” updates via a reboot and update from a file on removable storage

However, if the device implementation includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile:

• Android Automotive implementations SHOULD support OTA downloads with offline update via reboot.
• All other device implementations MUST support OTA downloads with offline update via reboot.

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

For device implementations that are launching with Android 5.1 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.1, 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 update available that can be applied per the mechanism just described.

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

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.1 allowed version strings: http://source.android.com/compatibility/5.1/versions.html

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://html.spec.whatwg.org/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/tools/help/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: /devices/input/diagnostics.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/devices/tech/input/touch-devices.html

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/devices/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: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. Continuous trigger mode: /docs/core/interaction/sensors/report-modes#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/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://members.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/devices/camera/versioning.html

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/connectivity/usb/accessory.html

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

99. USB Charging Specification: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

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

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

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/docs/security/features/encryption

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/

111. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

113. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

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. Any technical details provided in the references included above are considered by inclusion to be part of this Compatibility Definition.