Definición de compatibilidad de Android 7.0 (N)

Índice

1. Introducción

En este documento, se enumeran los requisitos que se deben cumplir para que los dispositivos sean compatibles con Android 7.0.

El uso de "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" según el estándar IETF definido en RFC2119.

Como se usa en este documento, un “implementador de dispositivos” o “implementador” es una persona u organización que desarrolla una solución de hardware o software con Android 7.0. Una “implementación de dispositivo” o “implementación de dispositivo” es la solución de hardware/software tan desarrollada.

Para que se consideren compatibles con Android 7.0, las implementaciones del dispositivo DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos que se incorporan como referencia.

Cuando esta definición o las pruebas de software descritas en la sección 10 son silenciosas, ambiguas o incompletas, es responsabilidad del implementador de dispositivos garantizar la compatibilidad con las implementaciones existentes.

Por este motivo, el Proyecto de código abierto de Android es la referencia y la implementación preferida de Android. Se recomienda que los implementadores de dispositivos 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 algunos componentes pueden reemplazarse hipotéticamente con implementaciones alternativas, es SEGURO RECOMENDADO no seguir esta práctica, ya que pasar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluida y más allá del Conjunto de pruebas de compatibilidad. Por último, ten en cuenta que en este documento se prohíben explícitamente algunas sustituciones y modificaciones de componentes.

Muchos de los recursos vinculados en este documento derivan directa o indirectamente del SDK de Android y serán funcionalmente idénticos a la información de la documentación de dicho SDK. En los casos en los 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 confiable. Cualquier detalle técnico que se proporcione en los recursos vinculados en este documento se considerará por inclusión como parte de esta definición de compatibilidad.

2. Tipos de dispositivo

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

Dispositivo de mano Android hace referencia a la implementación de dispositivos Android que generalmente se usa al sostenerlo en la mano, como reproductores de mp3, teléfonos y tablets. Implementaciones de dispositivos de mano Android:

  • DEBE tener una pantalla táctil incorporada en el dispositivo.
  • DEBE tener una fuente de alimentación que proporcione movilidad, como una batería.

Dispositivo Android Television hace referencia a una implementación de dispositivos Android que es una interfaz de entretenimiento que permite consumir contenido multimedia digital, películas, juegos, apps o TV en vivo para usuarios que están sentados a unos tres metros de distancia (una “interfaz de usuario “simplificada” o “interfaz de usuario de 10 pies”). Dispositivos Android Television:

  • DEBE tener una pantalla incorporada O incluir un puerto de salida de video, como VGA, HDMI o un puerto inalámbrico para pantalla.
  • SE DEBE declarar las funciones android.software.Leanback y android.hardware.type.television.

El dispositivo Android Watch hace referencia a la implementación de un dispositivo Android para llevar en el cuerpo, quizás en la muñeca, y:

  • DEBE tener una pantalla con una longitud diagonal física de 1.1 a 2.5 pulgadas.
  • SE DEBE declarar la función android.hardware.type.watch.
  • DEBE admitir uiMode = UI_MODE_TYPE_WATCH.

La implementación de Android Automotive hace referencia a la consola central de un vehículo que ejecuta Android como sistema operativo para una parte o la totalidad del sistema o la funcionalidad de infoentretenimiento. Implementaciones de Android Automotive:

  • DEBE tener una pantalla con una longitud diagonal física igual o superior a 6 pulgadas.
  • SE DEBE declarar la función android.hardware.type.automotive.
  • DEBE admitir uiMode = UI_MODE_TYPE_CAR.
  • Las implementaciones de Android Automotive DEBEN admitir todas las APIs públicas en el espacio de nombres de android.car.*.

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 de ser compatibles con Android 7.0, a menos que el requisito se describa explícitamente como aplicable solo a un tipo de dispositivo Android específico de 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 “MAY”). No todas las configuraciones se incluyen en esta tabla. consulta las secciones de hardware relevantes para obtener más detalles.

Categoría Función Sección Dispositivo manual Televisión Mirar Automóviles Otro
Entrada Pad direccional 7.2.2 Navegación no táctil DEBEN
Pantalla táctil 7.2.4 Entrada de pantalla táctil DEBEN DEBEN DEBES
Micrófono 7.8.1 Micrófono DEBEN DEBES DEBEN DEBEN DEBES
Sensores Acelerómetro 7.3.1 Acelerómetro DEBES DEBES DEBES
GPS 7.3.3 GPS DEBES DEBES
Conectividad Wi-Fi 7.4.2 IEEE 802.11 DEBES DEBES DEBES DEBES
Wi-Fi directo 7.4.2.1 Wi-Fi directo DEBES DEBES DEBES
Bluetooth 7.4.3 Bluetooth DEBES DEBEN DEBEN DEBEN DEBES
Bluetooth de bajo consumo 7.4.3 Bluetooth DEBES DEBEN DEBES DEBES DEBES
Radio móvil 7.4.5 Capacidad de red mínima DEBES
Periférico USB/modo de host 7.7 USB DEBES DEBES DEBES
Salida Puertos de salida de audio o bocina 7.8.2 Salida de audio DEBEN DEBEN DEBEN DEBEN

3. Software

3.1. Compatibilidad con APIs administradas

El entorno de ejecución de código de bytes administrado de Dalvik es el vehículo principal para las aplicaciones para Android. La interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma de Android expuestas a las aplicaciones que se ejecutan en el entorno de ejecución administrado. Las implementaciones en dispositivos DEBEN proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android o cualquier API decorada con el marcador "@SystemApi" en el código fuente ascendente de Android.

Las implementaciones de dispositivos DEBEN admitir o preservar todas las clases, los métodos y los elementos asociados marcados por la anotación TestApi (@TestApi).

Las implementaciones del dispositivo NO DEBEN omitir ninguna API administrada, alterar las interfaces o firmas de las APIs, desviarse del comportamiento documentado ni incluir no-ops, salvo que esta definición de compatibilidad lo permita específicamente.

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

3.1.1. Extensiones de Android

Android incluye la posibilidad de extender las APIs administradas y de mantener la misma versión de nivel de API. Las implementaciones en dispositivos Android DEBEN precargar la implementación de AOSP de la biblioteca compartida ExtShared y los servicios ExtServices con versiones superiores o iguales a las versiones mínimas permitidas por cada nivel de API. Por ejemplo, las implementaciones en dispositivos con Android 7.0 y el nivel de API 24 DEBEN incluir, al menos, la versión 1.

3.2. Compatibilidad con la API de Soft

Además de las APIs administradas de la sección 3.1, Android también incluye una API “secundaria” significativa de solo tiempo de ejecución, en forma de intents, permisos y aspectos similares de aplicaciones para Android que no se pueden aplicar en el tiempo de compilación de la aplicación.

3.2.1. Permisos

Los implementadores de dispositivos DEBEN admitir y aplicar todas las constantes de permisos según se indica en la página de referencia de permisos. Ten en cuenta que en la sección 9 se indican requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de compilación

Las APIs de Android incluyen una serie de constantes en la clase android.os.Build que están pensadas para describir el dispositivo actual. Para proporcionar valores coherentes y significativos en las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores que DEBEN cumplir las implementaciones de dispositivos.

Parámetro Detalles
VERSION.LANZAMIENTO Es la versión del sistema Android en ejecución actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en el archivo 7.0.
VERSION.SDK Es la versión del sistema Android en ejecución actualmente, en un formato accesible para el código de la aplicación de terceros. Para Android 7.0, este campo DEBE tener el valor entero 7.0_INT.
VERSION.SDK_INT Es la versión del sistema Android en ejecución actualmente, en un formato accesible para el código de la aplicación de terceros. Para Android 7.0, este campo DEBE tener el valor entero 7.0_INT.
VERSION.INCREMENTAL Es un valor elegido por el implementador de dispositivos que designa la compilación específica del sistema Android en ejecución actualmente, en un formato legible por humanos. Este valor NO SE DEBE volver a usar en diferentes compilaciones que se ponen a disposición de los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de origen se usó para generar la compilación. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
JUEGOS DE MESA Es un valor que elige el implementador del dispositivo para identificar el hardware interno específico que utiliza el dispositivo, en un formato legible por humanos. Este campo puede usarse para indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SEGURIDAD Un valor que refleja el nombre de la marca asociada con el dispositivo, como lo conocen los usuarios finales. DEBE tener un formato legible por humanos y DEBERÍA representar al fabricante del dispositivo o a la marca de la empresa con la que se comercializa el dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ABIS_COMPATIBLES Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABIS_COMPATIBLES_32_BIT Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABIS_COMPATIBLES_64_BIT Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABI_de_CPU Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABI2 de CPU Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
DISPOSITIVO Es un valor elegido por el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno que identifica la configuración de las características del hardware y el diseño industrial del dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este dispositivo NO DEBE cambiar durante la vida útil del producto.
IMPRESIÓN DE DEDOS Es una cadena que identifica esta compilación de forma exclusiva. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla:

$(BRAND)/$(PRODUCT)/
$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Por ejemplo:

acme/miproducto/
midispositivo:7.0/LMYXX/3359:userdebug/test-keys

La huella digital NO DEBE incluir caracteres de espacio en blanco. Si otros campos incluidos en la plantilla anterior tienen caracteres de espacio en blanco, se DEBEN reemplazar en la huella digital de compilación por otro carácter, como el carácter de guion bajo (“_”). El valor de este campo SE DEBE codificar como ASCII de 7 bits.

HARDWARE Es el nombre del hardware (de la línea de comandos del kernel o /proc). DEBE ser razonablemente legible por humanos. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ORGANIZADOR Es una cadena que identifica de forma única el host en el que se compiló la compilación, en un formato legible. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
ID Es un identificador que elige el implementador de dispositivos para hacer referencia a una versión específica, en formato legible por humanos. Este campo puede ser igual a android.os.Build.VERSION.INCREMENTAL, pero DEBERÍA ser un valor lo suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE Es el nombre comercial del fabricante del equipo original (OEM) del producto. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
MODELO. Es un valor elegido por el implementador de dispositivos que contiene el nombre del dispositivo como lo conoce el usuario final. Debe ser el mismo nombre con el que el dispositivo se comercializa y vende a usuarios finales. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
PRODUCTO Es un valor elegido por el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente para que lo vean los usuarios finales. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este producto NO DEBE cambiar durante la vida útil del producto.
SERIE Un número de serie de hardware, que DEBE estar disponible y ser único en todos los dispositivos con el mismo MODELO y FABRICANTE. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^([a-zA-Z0-9]{6,20})$”.
ETIQUETAS Una lista de etiquetas separadas por comas que elige el implementador de dispositivos que distingue aún más la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones de firma típicas de la plataforma de Android: release-keys, dev-keys y test-keys.
TIEMPO Un valor que representa la marca de tiempo del momento en que se produjo la compilación.
TIPO Es un valor que elige el implementador de dispositivos que especifica la configuración del tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: user, userdebug o eng.
USUARIO Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
PANTALLA_SEGURIDAD Es un valor que indica el nivel de parche de seguridad de una compilación. DEBE indicar que la compilación no es vulnerable de ninguna manera a ninguno de los problemas descritos en el Boletín de seguridad pública de Android designado. DEBE tener el formato [YYYY-MM-DD], que coincida con una cadena definida documentada en el Boletín de seguridad pública de Android o en el Aviso de seguridad de Android, por ejemplo, "2015-11-01".
BASE_SO Un valor que representa el parámetro FINGERPRINT de la compilación que es idéntico a esta compilación, excepto por los parches proporcionados en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si tal compilación no existe, informar una cadena vacía ("").

3.2.3. Compatibilidad con intents

3.2.3.1. Intents de aplicaciones principales

Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidades a otros componentes de Android. El proyecto upstream de Android incluye una lista de aplicaciones que se consideran aplicaciones principales de Android, la cual implementa varios patrones de intents para realizar acciones comunes. Las aplicaciones principales para Android son las siguientes:

  • Reloj de escritorio
  • Navegador
  • Calendario
  • Contactos
  • Galería
  • Búsqueda global
  • Selector
  • Música
  • Configuración

Las implementaciones del dispositivo DEBEN incluir las aplicaciones principales para Android, según corresponda, o un componente que implemente los mismos patrones de intents definidos por todos los componentes de actividad o servicio de estas aplicaciones principales para Android expuestas a otras aplicaciones, de forma implícita o explícita, a través del atributo android:exported.

3.2.3.2. Resolución de intents

Como Android es una plataforma extensible, las implementaciones de dispositivos DEBEN permitir que aplicaciones de terceros anulen cada patrón de intents al que se hace referencia en la sección 3.2.3.1. La implementación ascendente de código abierto de Android lo permite de forma predeterminada. los implementadores de dispositivos NO DEBEN adjuntar privilegios especiales a las aplicaciones el uso de estos patrones de intenciones o evitar que las aplicaciones de terceros se vinculen con estos patrones y asuman el control de ellos. Esta prohibición incluye, entre otros aspectos, la inhabilitación de la interfaz de usuario del "Selector", que permite al usuario elegir entre varias aplicaciones que manejan el mismo patrón de intents.

Las implementaciones en dispositivos DEBEN proporcionar una interfaz de usuario para que los usuarios modifiquen la actividad predeterminada para intents.

Sin embargo, PODRÍAN proporcionar actividades predeterminadas para patrones de URI específicos (por ejemplo, http://play.google.com) en las implementaciones de dispositivos cuando la actividad predeterminada proporcione un atributo más específico para el URI de datos. Por ejemplo, un patrón de filtro de intents que especifica el URI de datos "http://www.android.com" es más específico que el patrón de intent principal del navegador para "http://".

Android también incluye un mecanismo para que las apps de terceros declaren un comportamiento de vinculación de apps predeterminado para ciertos tipos de intents de URI web. Cuando se definen dichas declaraciones autorizadas en los patrones de filtro de intents de una app, las implementaciones de dispositivos hacen lo siguiente:

  • SE DEBE intentar validar cualquier filtro de intents. Para ello, se deben realizar los pasos de validación definidos en la especificación de Vínculos de recursos digitales, tal como la implementó el Administrador de paquetes en el Proyecto de código abierto de Android ascendente.
  • DEBEN intentar la validación de los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de UIR validados correctamente como controladores de app predeterminados para sus UIRs.
  • PUEDE establecer filtros de intents de URI específicos como controladores de app predeterminados para sus URI si se verifican correctamente, pero los demás filtros de URI candidatos no aprueban la verificación. Si la implementación de un dispositivo hace esto, DEBE proporcionar al usuario anulaciones de patrones por URI apropiadas en el menú de configuración.
  • DEBE proporcionar al usuario controles de App Links por app en Configuración de la siguiente manera:
    • El usuario DEBE ser capaz de anular de forma integral el comportamiento predeterminado de los vínculos de aplicaciones para que una aplicación sea siempre abierta, siempre preguntar o nunca abierta, lo que debe aplicarse a todos los filtros de intents de URI candidatos por igual.
    • El usuario DEBE poder ver una lista de los filtros de intents de URI candidatos.
    • La implementación del dispositivo PUEDE brindar al usuario la capacidad de anular filtros de intents de URI candidatos específicos que se verificaron correctamente, en función del filtro de intents.
    • La implementación del dispositivo DEBE permitir que los usuarios vean y anulen filtros de intents de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros candidatos de intents de URI tengan éxito en la verificación, mientras que otros pueden fallar.

3.2.3.3 Espacios de nombres de intents

Las implementaciones del dispositivo NO DEBEN incluir ningún componente de Android que respete un intent nuevo o patrón de intent de transmisión usando una ACTION, CATEGORY u otra cadena de clave en Android. or com.android.. Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete un intent nuevo o patrón de intent de transmisión usando una ACTION, CATEGORY, o bien otra cadena de clave en un espacio de paquete que pertenezca a otra organización. Los implementadores de dispositivos NO DEBEN alterar ni extender ninguno de los patrones de intents que usan las apps principales que se enumeran en la sección 3.2.3.1. Las implementaciones de dispositivos PUEDEN incluir patrones de intents que usen espacios de nombres asociados de forma clara y evidente 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. Intents de transmisión

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

3.2.3.5 Configuración predeterminada de la app

Android incluye parámetros de configuración que les permiten a los usuarios seleccionar fácilmente sus aplicaciones predeterminadas, por ejemplo, para la pantalla principal o los 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 intents y los métodos de la API descritos en la documentación del SDK, como se muestra a continuación.

Implementaciones en dispositivos:

  • DEBE respetar el intent android.settings.HOME_CONFIGURACIÓN de mostrar un menú de configuración de la aplicación predeterminado para la pantalla principal, si la implementación del dispositivo informa android.software.home_screen.
  • DEBE proporcionar un menú de configuración que llame al intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar un diálogo que cambie la aplicación de SMS predeterminada, si la implementación del dispositivo informa android.hardware.telephony.
  • DEBE cumplir con el intent android.settings.NFC_PAYMENT_CONFIGURACIÓN de mostrar un menú de configuración predeterminado de la app para Pago sin contacto, si la implementación del dispositivo informa android.hardware.nfc.hce.
  • DEBE respetar el intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar un diálogo que permita al usuario cambiar la aplicación de teléfono predeterminada, si la implementación del dispositivo informa android.hardware.telephony .

3.3. Compatibilidad con APIs nativas

La compatibilidad de código nativo es un desafío. Por este motivo, SE RECOMIENDA EJECUTAR a los implementadores de dispositivos que usen las implementaciones de las bibliotecas que se indican a continuación del proyecto ascendente de código abierto de Android.

3.3.1. Interfaces binarias de la aplicación

El código de bytes 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 apropiada. Como el código nativo depende en gran medida de la tecnología de procesador subyacente, Android define varias interfaces binarias de la aplicación (ABI) en el NDK de Android. Las implementaciones en dispositivos DEBEN ser compatibles con una o más ABI definidas, y DEBEN implementar la compatibilidad con el NDK de Android, como se muestra a continuación.

Si la implementación de un dispositivo incluye compatibilidad con una ABI de Android, sucederá lo siguiente:

  • DEBE incluir compatibilidad con el código que se ejecuta en el entorno administrado para llamar al código nativo, mediante la semántica estándar de la interfaz nativa de Java (JNI).
  • DEBE ser compatible con la fuente (es decir, con el encabezado) y con el formato binario (para la ABI) con cada biblioteca obligatoria de la siguiente lista.
  • DEBE admitir la ABI de 32 bits equivalente si se admite cualquier ABI de 64 bits.
  • DEBEN informar con precisión la interfaz binaria de la aplicación (ABI) nativa compatible con 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 ellos con una lista de ABI separadas por comas ordenadas de la más a la menos preferida.
  • SE DEBE informar, a través de los parámetros anteriores, solo las ABI documentadas y descritas en la versión más reciente de la documentación de Administración de ABI de NDK de Android, y DEBEN incluir compatibilidad con la extensión SIMD avanzada (también conocida como NEON).
  • SE DEBE compilar con el código fuente y los archivos de encabezado disponibles en el Proyecto de código abierto de Android ascendente.

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

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

  • libandroid.so (compatibilidad con actividades nativas de Android)
  • libc (biblioteca C)
  • libcamera2ndk.so
  • libdl (vinculador dinámico)
  • libEGL.so (administración de superficie nativa de OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (registro de Android)
  • libmediandk.so (compatibilidad con APIs de medios nativos)
  • libm (biblioteca de matemáticas)
  • libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
  • libOpenSLES.so (compatibilidad con audio de OpenSL ES 1.0.1)
  • libRS.so.
  • libstdc++ (compatibilidad mínima con C++)
  • libvulkan.so (Vulkan)
  • libz (compresión Zlib)
  • Interfaz JNI
  • Compatibilidad con OpenGL, como se describe a continuación

En el caso de las bibliotecas nativas mencionadas anteriormente, la implementación en dispositivos NO DEBE agregar ni quitar las funciones públicas.

Bibliotecas nativas que no se mencionaron anteriormente, pero que se implementaron y proporcionaron en AOSP, ya que las bibliotecas del sistema están reservadas y NO DEBEN exponerse a apps de terceros que se orientan al nivel de API 24 o versiones posteriores.

Las implementaciones de dispositivos PUEDEN agregar bibliotecas ajenas al AOSP y exponerlas directamente como una API a apps de terceros, pero las bibliotecas adicionales DEBEN estar en /vendor/lib o /vendor/lib64, y DEBEN estar incluidas en /vendor/etc/public.libraries.txt .

Ten en cuenta que las implementaciones de dispositivos DEBEN incluir libGLESv3.so y, a su vez, DEBEN exportar todos los símbolos de función de OpenGL ES 3.1 y Android Extension Pack, como se define en la versión android-24 del NDK. Si bien todos los símbolos deben estar presentes, solo deben estar implementadas por completo las funciones correspondientes para las versiones y extensiones de OpenGL ES que realmente son compatibles con el dispositivo.

3.3.1.1. Bibliotecas gráficas

Vulkan es una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento. Las implementaciones en dispositivos, incluso si no incluyen compatibilidad con las APIs de Vulkan, DEBEN cumplir con los siguientes requisitos:

  • Siempre DEBE proporcionar una biblioteca nativa llamada libvulkan.so que exporta símbolos de funciones para la API principal de Vulkan 1.0 , así como las extensiones VK_KHR_surface , VK_KHR_android_surface y VK_KHR_swapchain.

Implementaciones en dispositivos, si se incluye compatibilidad con las APIs de Vulkan:

  • DEBEN informar uno o más VkPhysicalDevices a través de la llamada a vkEnumeratePhysicalDevices.
  • Cada VkPhysicalDevices enumerado DEBE implementar por completo la API de Vulkan 1.0.
  • DEBE informar las marcas de función correctas PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL y PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
  • SE DEBE enumerar las capas, que se encuentran en las bibliotecas nativas llamadas libVkLayer*.so, en el directorio de bibliotecas nativas del paquete de la aplicación, a través de las funciones vkEnumerateInstanceLayerProperties y vkEnumerateDeviceLayerProperties en libvulkan.so.
  • NO DEBE enumerar las capas proporcionadas por bibliotecas fuera del paquete de la aplicación ni proporcionar otras formas de seguimiento o intercepción de la API de Vulkan, a menos que la aplicación tenga el atributo android:debuggable=”true”.

Implementaciones en dispositivos, si no incluyen compatibilidad con las APIs de Vulkan:

3.3.2. Compatibilidad con código nativo ARM de 32 bits

En la arquitectura ARMv8, se dan de baja varias operaciones de CPU, incluidas algunas operaciones usadas en el código nativo existente. En los dispositivos ARM de 64 bits, las siguientes operaciones obsoletas DEBEN permanecer disponibles para el código ARM nativo de 32 bits, ya sea a través de la compatibilidad nativa de la CPU o de la emulación de software:

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

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

  • "Features": ", seguida de una lista de todas las funciones opcionales de la CPU ARMv7 compatibles con el dispositivo.
  • "Arquitectura de la CPU: ", seguido de un número entero que describe la arquitectura ARM compatible más alta del dispositivo (p.ej., “8” para dispositivos ARMv8).

Estos requisitos solo se aplican cuando una aplicación ARM de 32 bits lee /proc/cpuinfo. Los dispositivos no DEBEN alterar /proc/cpuinfo cuando los leen aplicaciones ARM de 64 bits o que no son ARM.

3.4. Compatibilidad con la Web

3.4.1. Compatibilidad con WebView

PUEDEN LOS dispositivos Android Watch, pero todas las demás implementaciones en dispositivos DEBEN proporcionar una implementación completa de la API de android.webkit.Webview.

La función android.software.webview de la plataforma DEBE informarse en cualquier dispositivo que proporcione una implementación completa de la API de android.webkit.WebView, y NO DEBE informarse en dispositivos que no tienen una implementación completa de la API. La implementación de Código abierto de Android usa código del proyecto de Chromium para implementar android.webkit.WebView. Debido a que no es factible desarrollar un conjunto de pruebas completo para un sistema de renderización web, los implementadores de dispositivos DEBEN usar la compilación ascendente específica de Chromium en la implementación de WebView. Más precisamente:

  • Las implementaciones de android.webkit.WebView del dispositivo DEBEN basarse en la compilación de Chromium del Proyecto de código abierto de Android ascendente para Android 7.0. Esta compilación incluye un conjunto específico de correcciones de funcionalidad y seguridad para WebView.

  • La cadena de usuario-agente informada por WebView DEBE tener el siguiente formato:

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) 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 de android.os.Build.VERSION.release.
    • El valor de la cadena $(MODEL) DEBE ser el mismo que el 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 a dispositivos móviles en la string de usuario-agente.

El componente de WebView DEBE incluir compatibilidad con la mayor cantidad posible de funciones HTML5. Si es compatible, DEBE cumplir con la especificación de HTML5.

3.4.2. Compatibilidad del navegador

Las implementaciones de Android Television, Watch y Android Automotive PUEDEN omitir una aplicación de navegador, pero DEBEN admitir los patrones de intents públicos, como se describe en la sección 3.2.3.1. Todos los demás tipos de implementaciones en dispositivos DEBEN incluir una aplicación de navegador independiente para la navegación web de los usuarios en general.

El navegador independiente PUEDE basarse en una tecnología de navegador distinta de WebKit. No obstante, incluso si se utiliza una aplicación de navegador alternativa, el componente android.webkit.WebView proporcionado a aplicaciones de terceros DEBE basarse en WebKit, como se describe en la sección 3.4.1.

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

La aplicación de navegador independiente (ya sea que se base en la aplicación del navegador webKit ascendente o en un reemplazo de terceros) DEBE incluir compatibilidad con la mayor cantidad de archivos HTML5 posible. Como mínimo, las implementaciones en dispositivos DEBEN admitir cada una de las siguientes API asociadas con HTML5:

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

3.5 Compatibilidad de comportamiento de las APIs

Los comportamientos de cada uno de los tipos de API (administradas, de software, nativas y web) deben ser coherentes con la implementación preferida del Proyecto de código abierto de Android ascendente. Estas son algunas áreas específicas de compatibilidad:

  • Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent estándar.
  • Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo determinado de componente del sistema (como Service, Activity, ContentProvider, etcétera).
  • Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.

La lista anterior no es exhaustiva. El Conjunto de pruebas de compatibilidad (CTS) analiza la compatibilidad de comportamiento en partes significativas de la plataforma, pero no en todas. El implementador es responsable de garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android. Por esta razón, los implementadores de dispositivos DEBEN usar el código fuente disponible a través del Proyecto de código abierto de Android siempre que sea posible, en lugar de volver a implementar partes significativas del sistema.

3.6 Espacios de nombres de API

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

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

Las modificaciones prohibidas incluyen lo siguiente :

  • Las implementaciones de dispositivos NO DEBEN modificar las APIs expuestas públicamente en la plataforma de Android cambiando ningún método o firma de clases, o quitando clases o campos de clases.
  • Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero esas modificaciones NO DEBEN afectar el comportamiento indicado y la firma del lenguaje Java de las APIs expuestas públicamente.
  • Los implementadores de dispositivos NO DEBEN agregar elementos expuestos públicamente (como clases o interfaces, o campos o métodos a clases o interfaces existentes) a las APIs anteriores.

Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide" como se utiliza en el código fuente ascendente de Android. En otras palabras, los implementadores de dispositivos NO DEBEN exponer nuevas APIs ni alterar las APIs existentes en los espacios de nombres que se indican arriba. Los implementadores de dispositivos PUEDEN hacer modificaciones solo de forma interna, pero esas modificaciones NO DEBEN anunciarse ni exponerse de ninguna otra manera a los desarrolladores.

Los implementadores de dispositivos PUEDEN agregar APIs personalizadas, pero estas APIs NO DEBEN estar en un espacio de nombres que pertenezca a otra organización o haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* o uno similar: solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a las aplicaciones los espacios de nombres. Además, si la implementación de un dispositivo incluye APIs personalizadas fuera del espacio de nombres estándar de Android, esas APIs DEBEN empaquetarse en una biblioteca compartida de Android para que solo las apps que las usen de forma explícita (a través del mecanismo <uses-library>) se vean afectadas por el aumento en el uso de memoria de esas APIs.

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

Ten en cuenta que las restricciones anteriores corresponden a las convenciones estándar para asignar nombres a APIs en el lenguaje de programación Java. el objetivo de esta sección simplemente es reforzar esas convenciones y hacerlas vinculantes a través de la inclusión en esta definición de compatibilidad.

3.7 Compatibilidad del entorno de ejecución

Las implementaciones en dispositivos DEBEN admitir el formato Dalvik Executable (DEX) completo y la especificación y semántica del código de bytes Dalvik. Los implementadores de dispositivos DEBEN usar ART, la implementación ascendente de referencia del formato ejecutable Dalvik, y el sistema de administració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 según se especifica en la siguiente tabla. (Consulta la sección 7.1.1 para conocer las definiciones de tamaño y densidad de pantalla). Ten en cuenta que los valores de memoria especificados a continuación se consideran valores mínimos y las implementaciones en dispositivos PUEDEN asignar más memoria por aplicación.

Diseño de pantalla Densidad de la pantalla Memoria mínima de la aplicación
Reloj Android 120 DPI (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi) 36MB
280 DPI (280 DPI)
320 dpi (xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 DPI (420 DPI) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
pequeño/normal 120 DPI (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi) 48MB
240 dpi (hdpi)
280 DPI (280 DPI)
320 dpi (xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 DPI (420 DPI) 112MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
Grande 120 DPI (ldpi) 32MB
160 dpi (mdpi) 48MB
213 dpi (tvdpi) 80MB
240 dpi (hdpi)
280 DPI (280 DPI) 96MB
320 dpi (xhdpi) 128MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 DPI (420 DPI) 228MB
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512 MB
Extragrande 120 DPI (ldpi) 48MB
160 dpi (mdpi) 80MB
213 dpi (tvdpi) 96MB
240 dpi (hdpi)
280 DPI (280 DPI) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 DPI (420 DPI) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8. Compatibilidad con la interfaz de usuario

3.8.1. Selector (pantalla principal)

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

3.8.2. Widgets

Los widgets son opcionales para todas las implementaciones de dispositivos Android, pero SE DEBEN ser compatibles con los dispositivos portátiles Android.

Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan un "AppWidget" para el usuario final, una función que SE RECOMIENDA ES IMPORTANTE en las implementaciones de dispositivos de mano. Las implementaciones de dispositivos que admiten la incorporación de widgets en la pantalla principal DEBEN cumplir con los siguientes requisitos y declarar la compatibilidad con la función de la plataforma android.software.app_widgets.

  • Los selectores de dispositivos DEBEN tener compatibilidad integrada con AppWidgets y exponer las condiciones de la interfaz de usuario para agregar, configurar, ver y quitar los widgets de las apps directamente dentro del selector.
  • Las implementaciones del dispositivo DEBEN poder renderizar widgets de 4 x 4 en el tamaño de cuadrícula estándar. Para obtener más información, consulta los Lineamientos de diseño de widgets de apps en la documentación del SDK de Android.
  • Las implementaciones de dispositivos que incluyen compatibilidad con la pantalla de bloqueo PUEDEN admitir widgets de aplicaciones en la pantalla de bloqueo.

3.8.3. Notificaciones

Android incluye APIs que permiten a los desarrolladores notificar a los usuarios sobre eventos notables mediante funciones de hardware y software del dispositivo.

Algunas APIs permiten que las aplicaciones realicen notificaciones o llamen la atención mediante hardware (en particular, sonido, vibración y luz). Las implementaciones de dispositivos DEBEN admitir notificaciones que usen 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 APIs de vibración. Si la implementación de un dispositivo no tiene hardware, las APIs correspondientes DEBEN implementarse como modalidad no-ops. Este comportamiento se detalla con más detalle en la sección 7.

Además, la implementación DEBE renderizar correctamente todos los recursos (íconos, archivos de animación, etc.) proporcionados en las APIs o en la guía de estilo de íconos de la barra de estado/sistema, que, en el caso de un dispositivo Android Television, incluye la posibilidad de no mostrar las notificaciones. Los implementadores de dispositivos PUEDEN ofrecer una experiencia del usuario para las notificaciones alternativa a la que ofrece la implementación de Código Abierto de Android de referencia. sin embargo, dichos sistemas alternativos de notificación DEBEN admitir los recursos de notificación existentes, como se detalla anteriormente.

Las implementaciones de Android Automotive PUEDEN administrar la visibilidad y el momento de las notificaciones para mitigar la distracción del conductor, pero DEBEN mostrar notificaciones que usen CarExtender cuando las aplicaciones las soliciten.

Android admite varias notificaciones, como las siguientes:

  • Notificaciones enriquecidas . Vistas interactivas para notificaciones en curso.
  • Notificaciones de atención . Los usuarios pueden actuar con vistas interactivas o descartarlas sin salir de la app actual.
  • Notificaciones en la pantalla de bloqueo Notificaciones que se muestran en una pantalla de bloqueo con control detallado sobre la visibilidad.

Las implementaciones en dispositivos Android, cuando tales notificaciones se hacen visibles, DEBEN ejecutar correctamente notificaciones enriquecidas y de atención, e incluir el título, el nombre, el ícono y el texto, como se documenta en las APIs de Android.

Android incluye las API del servicio de detección de notificaciones que permiten que las apps (una vez habilitadas de manera explícita por el usuario) reciban una copia de todas las notificaciones a medida que se publican o actualizan. Las implementaciones de dispositivos DEBEN enviar notificaciones de manera correcta y oportuna 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.

Las implementaciones de dispositivos que admiten la función No interrumpir (No interrumpir) DEBEN cumplir con los siguientes requisitos:

  • SE DEBE implementar una actividad que responda al intent ACTION_NOTIFICATION_POLICY_ACCESS_CONFIG, que, en el caso de las implementaciones con UI_MODE_TYPE_NORMAL, DEBE ser una actividad en la que el usuario pueda otorgar o denegar el acceso de la app a las configuraciones de la política de DND.
  • Cuando la implementación del dispositivo haya proporcionado un medio para que el usuario otorgue o rechace que apps de terceros accedan a la configuración de la política de No interrumpir, se deben mostrar Reglas automáticas de No interrumpir creadas por las aplicaciones junto con las reglas creadas por el usuario y predefinidas.
  • DEBE respetar los valores de suppressedVisualEffects que se pasan junto con el NotificationManager.Policy y, si una app estableció alguna de las marcas SUPPRESSED_Effect_SCREEN_OFF o SUPPRESSED_Effect_SCREEN_ON, DEBE indicar al usuario que los efectos visuales se suprimen en el menú de configuración de No interrumpir.

Android incluye API que permiten a los desarrolladores incorporar la búsqueda en sus aplicaciones y exponer los datos de estas en la búsqueda global del sistema. En términos generales, esta funcionalidad consiste en una única interfaz de usuario para todo el sistema que permite que los usuarios ingresen consultas, muestre sugerencias a medida que los usuarios escriban y muestre los resultados. Las API de Android permiten a los desarrolladores reutilizar esta interfaz para proporcionar búsquedas dentro de sus propias apps y proporcionar resultados a la interfaz de usuario de búsqueda global común.

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

Las implementaciones en dispositivos Android DEBEN, y las de Android Automotive, implementar un asistente en el dispositivo para manejar la acción de asistencia.

Android también incluye las APIs de Assist para permitir que las aplicaciones elijan cuánta información del contexto actual se comparte con el Asistente en el dispositivo. Las implementaciones de dispositivos que admiten la acción de asistencia DEBEN indicar claramente al usuario final cuando se comparte el contexto mostrando una luz blanca alrededor de los bordes de la pantalla. Para garantizar una visibilidad clara para el usuario final, la indicación DEBE cumplir o superar la duración y el brillo de la implementación del Proyecto de código abierto de Android.

3.8.5. Avisos

Las aplicaciones pueden usar la API de “Avisos” para mostrar al usuario final cadenas no modales cortas que desaparecen después de un período breve. Las implementaciones del dispositivo DEBEN mostrar avisos de las aplicaciones a los usuarios finales de una manera de visibilidad alta.

3.8.6. Temas

Android proporciona "temas" como un 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 usen si quieren que coincidan con el diseño del tema Holo según lo definido por el SDK de Android. Las implementaciones en dispositivos NO DEBEN alterar los atributos del tema Holo expuestos a las aplicaciones.

Android incluye una familia de temas "Material" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen si quieren que coincidan con la apariencia del tema de diseño en la amplia variedad de diferentes tipos de dispositivos Android. Las implementaciones en dispositivos DEBEN admitir la familia de temas "Material" y NO alterar ninguno de los atributos del tema de Material ni sus recursos expuestos a las aplicaciones.

Android también incluye una familia de temas "Device Default" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen si quieren que coincidan con el aspecto del tema del dispositivo según lo definido por el implementador de dispositivos. Las implementaciones de dispositivos PUEDEN modificar los atributos del tema predeterminado del dispositivo expuestos a las aplicaciones.

Android admite un tema de variante con barras de sistema translúcidas, lo 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 app. Para permitir que el desarrollador tenga una experiencia coherente en esta configuración, es importante que se mantenga el estilo del ícono de la barra de estado 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 batería) y las notificaciones que emite el sistema, a menos que el ícono indique un estado problemático o que una app solicite una barra de estado luminosa con la marca SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Cuando una app solicita una barra de estado de luz, las implementaciones en dispositivos Android DEBEN cambiar el color de los íconos de estado del sistema a negro (para obtener más información, consulta R.style).

3.8.7. Fondos de pantalla animados

Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan uno o varios "fondos de pantalla animados" al usuario final. Los fondos de pantalla animados son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como fondo de pantalla detrás de otras aplicaciones.

Se considera que un hardware es capaz de ejecutar fondos de pantalla animados de manera confiable si puede ejecutar todos los fondos de pantalla animados, sin limitaciones de funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware hacen que los fondos de pantalla o las aplicaciones fallen, fallen, consuman demasiada energía de la CPU o la batería, o se ejecuten a velocidades de fotogramas inaceptables, se considera que el hardware no puede ejecutar fondos de pantalla animados. Por ejemplo, algunos fondos de pantalla animados pueden usar un contexto OpenGL 2.0 o 3.x para renderizar su contenido. El fondo animado no se ejecutará de manera confiable en hardware que no admite varios contextos OpenGL, ya que el uso del fondo animado de un contexto de 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 animados de manera confiable, como se describió anteriormente, DEBEN implementar fondos de pantalla animados, y al hacerlo, DEBEN informar el parámetro de función de la plataforma android.software.live_wallpaper.

3.8.8. Cambio de actividad

Como la tecla de navegación de funciones recientes es OPCIONAL, el requisito de implementar la pantalla de información general es OPCIONAL para las implementaciones de Android Watch y Android Automotive, y RECOMENDADA para dispositivos de televisión Android. Aun así, DEBERÍA haber un método para alternar entre las actividades en las implementaciones de Android Automotive.

El código fuente ascendente de Android incluye la pantalla de información general, una interfaz de usuario a nivel del sistema que permite cambiar tareas y mostrar las actividades y tareas a las que se accedió recientemente mediante 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 en dispositivos, incluida la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, PUEDEN alterar la interfaz, pero DEBEN cumplir con los siguientes requisitos:

  • DEBE admitir hasta 6 actividades mostradas.
  • SE RECOMIENDA mostrar, al menos, el título de 4 actividades a la vez.
  • SE DEBE implementar el comportamiento de fijación de pantalla y proporcionarle al usuario un menú de configuración para activar o desactivar la función.
  • SE DEBE mostrar el color de resaltado, el ícono, el título de la pantalla en recientes.
  • SE DEBE mostrar una indicación visual de cierre ("x"), pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas.
  • SE RECOMIENDA implementar una combinación de teclas para cambiar fácilmente a la actividad anterior
  • PUEDE mostrar los recientes afiliados como un grupo que se mueve de forma conjunta.
  • SE DEBE activar la acción de cambio rápido entre las dos apps usadas más recientemente cuando se presione dos veces la tecla de función Recientes.
  • SE DEBE activar el modo multiventana de pantalla dividida, si es compatible, cuando se mantiene presionada la tecla de funciones recientes.

SE RECOMIENDA EJECUTAR implementaciones en dispositivos que usen la interfaz de usuario ascendente de Android (o una interfaz basada en miniaturas similar) para la pantalla de información general.

3.8.9. Administración de entradas

Android incluye compatibilidad con la Administración de entradas y compatibilidad con editores de métodos de entrada de terceros. Las implementaciones en dispositivos que permiten a los usuarios usar métodos de entrada de terceros DEBEN declarar la función de la plataforma android.software.input_methods y admitir APIs de IME según 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 al intent android.settings.INPUT_METHOD_d.

3.8.10. Control multimedia de la pantalla de bloqueo

La API de cliente de control remoto dejó de estar disponible en Android 5.0 y se reemplazó por la Plantilla de notificación multimedia, que permite a las aplicaciones multimedia integrarse con los controles de reproducción que se muestran en la pantalla de bloqueo. 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 notificaciones multimedia.

3.8.11. Protectores de pantalla (anteriormente, Sueños)

Android incluye compatibilidad con interactscreensavers, conocidos anteriormente como Dreams. Los protectores de pantalla permiten a los usuarios interactuar con aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o en un conector para escritorio. PUEDEN implementar los protectores de pantalla en los dispositivos Android Watch, pero otros tipos de implementaciones DE dispositivos DEBEN incluir compatibilidad con protectores de pantalla y proporcionar una opción de configuración para que los usuarios los configuren en respuesta al intent android.settings.DREAM_SETTINGS.

3.8.12. Ubicación

Cuando un dispositivo tiene un sensor de hardware (p.ej., GPS) capaz de proporcionar las coordenadas de la ubicación, los modos de ubicación DEBEN mostrarse en el menú Ubicación en Configuración.

3.8.13. Unicode y fuentes

Android admite los caracteres de emojis que se definen en Unicode 9.0. Todas las implementaciones de dispositivos DEBEN poder representar estos caracteres emoji en glifos de color y, cuando las implementaciones en dispositivos Android incluyen un IME, DEBEN proporcionar al usuario un método de entrada para esos caracteres emoji.

Los dispositivos de mano Android DEBEN admitir el tono de piel y los diversos emojis familiares, como se especifica en el Informe técnico de Unicode n° 51.

Android es compatible con la fuente Roboto 2 con diferentes grosores (sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light), que DEBEN incluirse en los idiomas disponibles en el dispositivo y la cobertura completa de monedas Unicode y los rangos de moneda latino, cias 7.0 y los símbolos latino y cromo DG.

3.8.14. Multiventana

La implementación de un dispositivo PUEDE optar por no implementar ningún modo multiventana, pero, si tiene la capacidad de mostrar varias actividades al mismo tiempo, DEBE hacerlo de acuerdo con los comportamientos de la aplicación y las APIs que se describen en la documentación de compatibilidad del modo multiventana del SDK de Android y debe cumplir con los siguientes requisitos:

  • Las aplicaciones pueden indicar si son capaces de operar en el modo multiventana en el archivo AndroidManifest.xml, ya sea de forma explícita a través del atributo android:resizeableActivity o implícitamente por incluir targetSdkVersion >. Las aplicaciones que establecen explícitamente este atributo como falso en su manifiesto no DEBEN iniciarse en el modo multiventana. Las aplicaciones que no establecen el atributo en su archivo de manifiesto (targetSdkVersion < 24) se pueden iniciar en el modo multiventana, pero el sistema DEBE advertir que la aplicación puede no funcionar como se espera en el modo multiventana.
  • Las implementaciones en dispositivos NO DEBEN ofrecer el modo de pantalla dividida ni forma libre si la altura y el ancho de la pantalla son inferiores a 440 dp.
  • Las implementaciones en dispositivos con tamaño de pantalla xlarge DEBEN admitir el modo de forma libre.
  • Las implementaciones de dispositivos de televisión de Android DEBEN admitir el modo multiventana en pantalla (PIP) y colocar la ventana múltiple de PIP en la esquina superior derecha cuando PIP está ACTIVADA.
  • Las implementaciones de dispositivos que admiten el modo multiventana en modo de PIP DEBEN asignar al menos 240 x 135 dp para la ventana de PIP.
  • Si se admite el modo multiventana de PIP, se DEBE usar la clave KeyEvent.KEYCODE_WINDOW para controlar la ventana de PIP. De lo contrario, la clave DEBE estar disponible para la actividad en primer plano.

3.9 Administración del dispositivo

Android incluye funciones que permiten que las aplicaciones conscientes de la seguridad lleven a cabo funciones de administración de dispositivos a nivel del sistema, como la aplicación de políticas de contraseñas o la limpieza remota, a través de la API de administración de dispositivos Android. Las implementaciones del dispositivo DEBEN proporcionar una implementación de la clase DevicePolicyManager. Las implementaciones de dispositivos que admiten una pantalla de bloqueo segura DEBEN implementar la gama completa de políticas de administración de dispositivos que se definen en la documentación del SDK de Android y, además, informar sobre la función de la plataforma android.software.device_admin.

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

Si una implementación de dispositivos declara la función android.software.device_admin, DEBE implementar el aprovisionamiento de la app del propietario del dispositivo de una aplicación cliente de política de dispositivo (DPC), como se indica a continuación:

Las implementaciones de dispositivos PUEDEN tener una aplicación preinstalada que realice funciones de administración del dispositivo, pero esta NO DEBE configurarse como la aplicación del propietario del dispositivo sin el consentimiento explícito o la acción del usuario o el administrador del dispositivo.

3.9.1.2 Aprovisionamiento de perfiles administrados

Si la implementación de un dispositivo declara android.software.managed_users, DEBE ser posible inscribir una aplicación de Device Policy Controller (DPC) como el propietario de un nuevo perfil administrado.

La experiencia del usuario del proceso de aprovisionamiento de perfiles administrados (el flujo que inicia android.app.action.PROVISION_MANAGED_PROFILE) DEBE alinearse con la implementación de AOSP.

Las implementaciones de dispositivos DEBEN proporcionar las siguientes indicaciones de usuario dentro de la interfaz de usuario de Configuración para indicarle al usuario que el controlador de política de dispositivo (DPC) inhabilitó una función específica del sistema:

  • Un ícono coherente u otra indicación visual del usuario (por ejemplo, el ícono de información ascendente de AOSP) para representar cuando un administrador de dispositivos restringe una configuración específica
  • Un mensaje de explicación breve, proporcionado por el administrador de dispositivos a través de setShortSupportMessage.
  • Ícono de la aplicación de DPC

3.9.2 Asistencia para perfiles administrados

Los dispositivos compatibles con perfiles administrados son aquellos que cumplen con las siguientes condiciones:

Los dispositivos compatibles con perfiles administrados DEBEN:

  • Declara la marca de función de la plataforma android.software.managed_users .
  • Admite perfiles administrados a través de las APIs de android.app.admin.DevicePolicyManager.
  • Permite que se cree un perfil administrado únicamente.
  • Usa una insignia de ícono (similar a la insignia de trabajo upstream de AOSP) para representar las aplicaciones y widgets administrados, y otros elementos de la IU con insignias, como Recientes y Notificaciones.
  • Muestra un ícono de notificación (similar a la insignia de trabajo upstream de AOSP) para indicar que el usuario está dentro de una aplicación de perfil administrado.
  • Muestra un aviso que indica que el usuario está en el perfil administrado si se activa el dispositivo (ACTION_USER_PRESENT) y la aplicación en primer plano está dentro del perfil administrado.
  • Cuando exista un perfil administrado, muestra una indicación visual en el "Selector de intents" de intents. para permitir que el usuario reenvíe el intent del perfil administrado al usuario principal o viceversa, si el controlador de política de dispositivo lo habilita.
  • Si existe un perfil administrado, expone las siguientes condiciones del usuario, tanto para el usuario principal como para el perfil administrado:
    • Contabilización independiente de la batería, la ubicación, los datos móviles y el uso del almacenamiento del usuario principal y el perfil administrado
    • Administración independiente de aplicaciones de VPN instaladas dentro del usuario principal o perfil administrado
    • Administración independiente de aplicaciones instaladas dentro del usuario principal o perfil administrado
    • Administración independiente de cuentas dentro del usuario principal o el perfil administrado
  • Asegúrate de que el marcador preinstalado, los contactos y las aplicaciones de mensajería puedan buscar y buscar la información del emisor desde el perfil administrado (si existe) junto con los del perfil principal, si el controlador de política de dispositivo lo permite. Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la IU durante la llamada, las notificaciones de llamadas perdidas y en curso, los contactos y las aplicaciones de mensajería, SE DEBE usar la misma insignia que se utiliza para indicar las aplicaciones del perfil administrado.
  • DEBE asegurarse de que cumpla con todos los requisitos de seguridad aplicables para un dispositivo con varios usuarios habilitados (consulta la sección 9.5), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.
  • Admite la capacidad de especificar una pantalla de bloqueo independiente que cumpla con los siguientes requisitos para otorgar acceso a las apps que se ejecutan en un perfil administrado.

3.10. Accesibilidad

Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos con mayor facilidad. Además, Android proporciona APIs de plataforma que permiten que las implementaciones del servicio de accesibilidad reciban devoluciones de llamada para eventos de usuarios y del sistema, y generen mecanismos alternativos de respuesta, como texto a voz, respuesta táctil y navegación con bola de seguimiento o pad direccional.

Las implementaciones en dispositivos incluyen los siguientes requisitos:

  • Las implementaciones de Android Automotive DEBEN proporcionar una implementación del framework de accesibilidad de Android coherente con la implementación de Android predeterminada.
  • Las implementaciones en dispositivos (excepto Android Automotive) DEBEN proporcionar una implementación del framework de accesibilidad de Android coherente con la implementación predeterminada de Android.
  • Las implementaciones de dispositivos (excepto Android Automotive) DEBEN admitir implementaciones de servicios de accesibilidad de terceros a través de las APIs de android.accessibilityservice.
  • Las implementaciones en dispositivos (excepto Android Automotive) DEBEN generar AccessibilityEvents y publicar estos eventos a todas las implementaciones registradas de AccessibilityService de manera coherente con la implementación predeterminada de Android

  • Las implementaciones en dispositivos (Android Automotive y Android Watch sin excluir salida de audio), DEBEN proporcionar un mecanismo accesible para el usuario para habilitar e inhabilitar los servicios de accesibilidad, y DEBEN mostrar esta interfaz en respuesta al intent android.provider.Settings.ACTION_ACCESSIBILITY_CONFIG.

  • SE RECOMIENDA ELEGIR implementaciones en dispositivos Android con salida de audio para proporcionar implementaciones de servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de TalkBack** y los servicios de accesibilidad de Accesibilidad con interruptores (https://github.com/google/talkback) o que las superen.

  • Los dispositivos Android Watch con salida de audio DEBEN proporcionar implementaciones de un servicio de accesibilidad en el dispositivo que sea comparable con la funcionalidad del servicio de accesibilidad TalkBack o que la supere (https://github.com/google/talkback).
  • Las implementaciones en dispositivos DEBEN proporcionar un mecanismo en el flujo de configuración listo para usar a fin de que los usuarios habiliten servicios de accesibilidad relevantes, así como opciones para ajustar el tamaño de la fuente, el tamaño de la pantalla y los gestos de ampliación.

** Para los idiomas compatibles con Text-to-Speech.

Además, ten en cuenta que si hay un servicio de accesibilidad precargado, DEBE ser una app de {directBootAware} que reconoce el inicio directo si el dispositivo tiene almacenamiento encriptado con la encriptación basada en archivos (FBE).

3.11. Text-to-Speech

Android incluye API que permiten a las aplicaciones utilizar servicios de texto a voz (TTS) y permite a los proveedores de servicios implementar implementaciones de servicios de TTS. Las implementaciones de dispositivos que informan la función android.hardware.audio.output DEBEN cumplir con los requisitos relacionados con el marco de trabajo de TTS de Android.

Implementaciones de Android Automotive:

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

Todas las demás implementaciones en dispositivos:

  • DEBE ser compatible con las APIs del framework de TTS de Android y DEBE incluir un motor de TTS que admita los idiomas disponibles en el dispositivo. Ten en cuenta que el software de código abierto ascendente de Android incluye una implementación del motor de TTS con todas las funciones.
  • DEBE admitir la instalación de motores de TTS de terceros.
  • DEBEN proporcionar una interfaz accesible para los usuarios que les permita seleccionar un motor de TTS para su uso a nivel del sistema.

3.12. Framework de entrada de TV

El marco de trabajo de entrada de televisión (TIF) de Android simplifica la entrega de contenido en vivo a los dispositivos de televisión Android. El TIF proporciona una API estándar para crear módulos de entrada que controlan los dispositivos de Android Television. Las implementaciones en dispositivos de televisión de Android DEBEN ser compatibles con el framework de entrada de TV.

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

3.12.1. App para TV

Cualquier implementación de dispositivo que declare compatibilidad con TV en vivo DEBE tener una aplicación para TV (app de TV) instalada. El Proyecto de código abierto de Android proporciona una implementación de la app para TV.

La app de TV DEBE proporcionar instalaciones para instalar y usar canales de TV. Además, debe cumplir con los siguientes requisitos:

  • Las implementaciones en dispositivos DEBEN permitir que se instalen y administren entradas de terceros basadas en el TIF ( entradas de terceros).
  • Las implementaciones en dispositivos PUEDEN proporcionar una separación visual entre las entradas basadas en TIF (instaladas) preinstaladas y las de terceros.
  • Las implementaciones del dispositivo NO DEBEN mostrar las entradas de terceros más de una sola acción de navegación fuera de la app para TV (es decir, expandir una lista de entradas de terceros desde la app para TV).

3.12.1.1. Guía electrónica de programas

Las implementaciones de dispositivos Android Television DEBEN mostrar una superposición informativa e interactiva, que DEBE incluir una guía electrónica de programas (EPG) generada a partir de los valores de los campos TvContract.Programs. La EPG DEBE cumplir con los siguientes requisitos:

  • La EPG DEBE mostrar información de todas las entradas instaladas y de terceros.
  • Es posible que la EPG proporcione una separación visual entre las entradas instaladas y las de terceros.
  • Se RECOMIENDA EPG que se muestre la EPG para que muestre las entradas instaladas y de terceros con la misma importancia. La EPG NO DEBE mostrar las entradas de terceros más de una sola acción de navegación fuera de las entradas instaladas en la EPG.
  • Durante el cambio de canal, las implementaciones del dispositivo DEBEN mostrar los datos de EPG para el programa en reproducción.

3.12.1.2. Navegación

La app de TV DEBE permitir la navegación para las siguientes funciones a través del pad direccional, las teclas Atrás y Inicio en los dispositivos de entrada del dispositivo de TV Android (es decir, control remoto, aplicación de control remoto o controlador de juegos):

  • Cambio de canales de TV
  • Abriendo EPG
  • Configura y ajusta entradas de terceros basadas en TIF
  • Abriendo el menú Configuración

La app para TV DEBE pasar los eventos clave a entradas HDMI a través del CEC.

3.12.1.3. Vinculación de apps de entrada de TV

Las implementaciones de dispositivos de televisión de Android DEBEN admitir la vinculación de apps de entrada de TV, que permite que todas las entradas proporcionen vínculos de actividad de la actividad actual a otra actividad (es decir, un vínculo de la programación en vivo a contenido relacionado). Cuando se proporciona, la app de TV DEBE mostrar la vinculación de la app de entrada de TV.

3.12.1.4. Pausa en vivo

Las implementaciones en dispositivos de Android Television DEBEN admitir la pausa en directo, que permite al usuario pausar y reanudar el contenido en vivo. Si la pausa en directo de ese programa está disponible, las implementaciones en dispositivos DEBEN proporcionarle al usuario una forma de pausar y reanudar el programa en reproducción.

3.12.1.5. Grabación de TV

Se RECOMIENDA ELEGIR implementaciones en dispositivos de Android Television para admitir la grabación de TV. Si la entrada de TV admite la grabación, la EPG PUEDE proporcionar una forma de grabar un programa si la grabación de dicho programa no está prohibida. Las implementaciones en dispositivos DEBEN proporcionar una interfaz de usuario para reproducir programas grabados.

3.13. Configuración rápida

Las implementaciones en dispositivos Android DEBEN incluir un componente de IU de Configuración rápida que permita un acceso rápido a las acciones usadas con frecuencia o que se necesitan con urgencia.

Android incluye la API de quicksettings, lo que permite que las apps de terceros implementen tarjetas que el usuario puede agregar junto con las tarjetas proporcionadas por el sistema en el componente de IU de Configuración rápida. Si la implementación de un dispositivo tiene un componente de IU de Configuración rápida, hace lo siguiente:

  • DEBE permitir que el usuario agregue o quite tarjetas de una app de terceros en la Configuración rápida.
  • NO DEBE agregar automáticamente una tarjeta de una app de terceros directamente a la Configuración rápida.
  • DEBE mostrar todos los mosaicos agregados por el usuario desde apps de terceros junto con los mosaicos de configuración rápida proporcionados por el sistema.

3.14. APIs de IU de vehículos

3.14.1. IU multimedia del vehículo

Cualquier implementación de dispositivo que declara la compatibilidad con la industria automotriz DEBE incluir un framework de IU que admita las apps de terceros que consumen las APIs de MediaBrowser y MediaSession.

El framework de IU compatible con apps de terceros que dependen de MediaBrowser y MediaSession tiene los siguientes requisitos visuales:

  • SE DEBEN mostrar los íconos de MediaItem y de notificación sin alteraciones.
  • DEBEN mostrar esos elementos como se describe en MediaSession; p.ej., metadatos, íconos e imágenes.
  • DEBE mostrar el título de la app.
  • DEBE tener un panel lateral para presentar la jerarquía de MediaBrowser.

4. Compatibilidad con paquetes de aplicaciones

Las implementaciones en dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android generados por la herramienta "aapt" incluida en el SDK oficial de Android. Por este motivo, las implementaciones en dispositivos DEBEN usar el sistema de administración de paquetes de la implementación de referencia.

El administrador de paquetes DEBE admitir la verificación de archivos ".apk" con el esquema de firma de APK v2 y la firma JAR.

Las implementaciones en dispositivos NO DEBEN extender los formatos de código de bytes .apk, manifiesto de Android, código de bytes Dalvik ni RenderScript de manera que eviten que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.

5. Compatibilidad multimedia

5.1. Códecs de contenido multimedia

Implementaciones en dispositivos:

  • DEBE admitir los formatos multimedia principales especificados en la documentación del SDK de Android, salvo que se permita explícitamente en este documento.

  • DEBE admitir los formatos de medios, codificadores, decodificadores, tipos de archivo y formatos de contenedor definidos en las tablas a continuación y que se informan a través de MediaCodecList.

  • También DEBE poder decodificar todos los perfiles informados en su CamcorderProfile.

  • DEBE ser capaz de decodificar todos los formatos que pueda codificar. Esto incluye todos los flujos de bits que generan sus codificadores.

Los códecs DEBEN alcanzar una latencia mínima de códecs, es decir, códecs.

  • NO SE DEBE consumir ni almacenar búferes de entrada ni devolver búferes de entrada solo una vez que se hayan procesado.
  • NO SE DEBEN retener los búferes decodificados durante más tiempo del que se especifica en el estándar (p.ej., SPS).
  • NO DEBERÍAS retener los búferes codificados más tiempo que el requerido por la estructura del GOP.

Todos los códecs que se indican en la siguiente tabla se proporcionan como implementaciones de software en la implementación de Android preferida del Proyecto de código abierto de Android.

Ten en cuenta que ni Google ni Open Handset Alliance declaran que estos códecs no tienen patentes de terceros. Quienes deseen utilizar este código fuente en productos de hardware o software deben considerar que las implementaciones de este código, incluso en software de código abierto o shareware, pueden requerir licencias de patentes de los titulares de patentes pertinentes.

5.1.1 Códecs de audio

Formato/códec Codificador Decodificador Detalles Tipos de archivos/formatos de contenedor admitidos
Perfil MPEG-4 AAC
(AAC LC) 		OBLIGATORIO 1 OBLIGATORIO Compatibilidad con contenido mono/estéreo/5.0/5.1 2 con tasas de muestreo estándar de 8 kHz a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC sin formato ADTS (.aac, decodificación en Android 3.1 y versiones posteriores, codificación en Android 4.0 y versiones posteriores, ADIF no es compatible)
  • MPEG-TS (.ts, no permite búsquedas, Android 3.0 y versiones posteriores)
Perfil MPEG-4 HE AAC (AAC+) OBLIGATORIO 1
(Android 4.1 y versiones posteriores) 		OBLIGATORIO Compatibilidad con contenido mono/estéreo/5.0/5.1 2 con tasas de muestreo estándar de 16 a 48 kHz.
MPEG-4 HE AACv2
Perfil (AAC+ mejorado) 		OBLIGATORIO Compatibilidad con contenido mono/estéreo/5.0/5.1 2 con tasas de muestreo estándar de 16 a 48 kHz.
AAC ELD (AAC mejorado de bajo retraso) OBLIGATORIO 1
(Android 4.1 y versiones posteriores) 		OBLIGATORIO
(Android 4.1 y versiones posteriores) 		Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 kHz a 48 kHz.
AMR-NB OBLIGATORIO 3 OBLIGATORIO 3 4.75 a 12.2 Kbps con muestreo a 8 kHz 3GPP (.3gp)
AMR-WB OBLIGATORIO 3 OBLIGATORIO 3 9 tasas de 6.60 kbit/s a 23.85 kbit/s de muestra a 16 kHz
FLAC OBLIGATORIO
(Android 3.1 o superior) 		Mono/estéreo (sin multicanal). Tasas de muestreo de hasta 48 kHz (pero hasta 44.1 kHz se RECOMIENDA en dispositivos con salida de 44.1 kHz, ya que el reducción de muestreo de 48 a 44.1 kHz no incluye un filtro de paso bajo). 16 bits RECOMENDADOS; no se aplicó interpolación para 24 bits. FLAC (.flac) solo
MP3 OBLIGATORIO Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps MP3 (.mp3)
MIDI OBLIGATORIO MIDI tipo 0 y 1. Versión 1 y 2 de DLS. XMF y Mobile XMF. Compatibilidad con los formatos de tono RTTTL/RTX, OTA y iMelody.
  • Tipos 0 y 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • Inalámbrico (.ota)
  • iMelody (.imy)
Vorbis OBLIGATORIO
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 y versiones posteriores)
PCM/WAVE OBLIGATORIO 4
(Android 4.1 y versiones posteriores) 		OBLIGATORIO PCM lineal de 16 bits (las tasas llegan hasta el límite del hardware). Los dispositivos DEBEN admitir tasas de muestreo para la grabación PCM sin procesar a frecuencias de 8000, 11025, 16000 y 44100 Hz. WAVE (.wav)
Opus OBLIGATORIO
(Android 5.0 y versiones posteriores) 		Matroska (.mkv) y Ogg(.ogg)

1 Es obligatorio para las implementaciones en dispositivos que definen android.hardware.microphone, pero es opcional para las implementaciones en dispositivos Android Watch.

2 La grabación o reproducción puede realizarse en mono o estéreo, pero la decodificación de los búferes de entrada AAC de transmisiones multicanal (es decir, más de dos canales) en PCM a través del decodificador de audio AAC predeterminado en la API android.media.MediaCodec, lo siguiente DEBE ser compatible:

  • la decodificación se realiza sin mezclar (por ejemplo, una transmisión 5.0 AAC se debe decodificar en cinco canales de PCM, una transmisión 5.1 AAC se debe decodificar en seis canales de PCM).
  • metadatos de rango dinámico, como se define en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3 y las claves DRC android.media.MediaFormat para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves DRC de AAC se introdujeron en la API 21 y son: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL y KEY_AAC_ENCODED_TARGET_LEVEL

3 Se requiere para las implementaciones en dispositivos de mano Android.

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

5.1.2. Códecs de imagen

Formato/códec Codificador Decodificador Detalles Tipos de archivos/formatos de contenedor admitidos
JPEG OBLIGATORIO OBLIGATORIO Básica + progresiva JPEG (.jpg)
GIF OBLIGATORIO GIF (.gif)
PNG OBLIGATORIO OBLIGATORIO PNG (.png)
BMP OBLIGATORIO BMP (.bmp)
WebP OBLIGATORIO OBLIGATORIO WebP (.webp)
Sin procesar OBLIGATORIO ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3 Códecs de video

  • Los códecs que anuncian la compatibilidad con perfiles HDR DEBEN admitir el análisis y la administración de metadatos estáticos de HDR.

  • Si un códec de medios anuncia compatibilidad con actualizaciones internas, DEBE admitir períodos de actualización en el rango de 10 a 60 fotogramas y operar con precisión dentro del 20% del período de actualización configurado.

  • Los códecs de video DEBEN admitir tamaños de búfer de bytes de salida y entrada que se adapten al mayor fotograma comprimido y sin comprimir posible según lo determine el estándar y la configuración, pero que no se apliquen de manera general.

  • Los codificadores y decodificadores de video DEBEN ser compatibles con el formato de color flexible YUV420 (COLOR_FormatYUV420Flexible).

Formato/códec Codificador Decodificador Detalles Tipos de archivos admitidos/
Formatos de contenedores
H.263 MAYO MAYO
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC OBLIGATORIO 2 OBLIGATORIO 2 Consulta los artículos 5.2 y 5.3 para obtener más información.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, AAC solo de audio, no permite búsquedas, Android 3.0 o versiones posteriores)
H.265 HEVC OBLIGATORIO 5 Consulta la sección 5.3 para obtener más información. MPEG-4 (.mp4)
MPEG-2 RECOMENDADOS 6 Perfil principal MPEG2-TS
MPEG-4 SP OBLIGATORIO 2 3GPP (.3gp)
VP8 3 OBLIGATORIO 2
(Android 4.3 y versiones posteriores) 		OBLIGATORIO 2
(Android 2.3.3 o superior) 		Consulta los artículos 5.2 y 5.3 para obtener más información.
  • WebM (.webm)
  • Matroska (.mkv, Android 4.0 y versiones posteriores) 4
VP9 OBLIGATORIO 2
(Android 4.4 y versiones posteriores) 		Consulta la sección 5.3 para obtener más información.
  • WebM (.webm)
  • Matroska (.mkv, Android 4.0 y versiones posteriores) 4

1 Se requiere para las implementaciones en dispositivos que incluyen hardware de cámara y definen android.hardware.camera o android.hardware.camera.front.

2 Se requiere para las implementaciones en dispositivos, excepto en los dispositivos Android Watch.

3 Para obtener una calidad aceptable de transmisión de video por Internet y servicios de videoconferencia, las implementaciones de dispositivos DEBEN usar un códec de hardware VP8 que cumpla con los requisitos.

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

5 RECOMENDADA PARA Android Automotive, opcional para Android Watch y obligatorio para todos los demás tipos de dispositivos.

6 Se aplica solo a las implementaciones de dispositivos Android Television.

5.2 Codificación de videos

Los códecs de video son opcionales para las implementaciones en dispositivos de Android Watch.

Codificadores de video H.264, VP8, VP9 y HEVC,

  • DEBE admitir tasas de bits configurables de forma dinámica.
  • DEBE admitir velocidades de fotogramas variables, en las que el codificador de video DEBE determinar la duración instantánea de los fotogramas según las marcas de tiempo de los búferes de entrada y asignar su intervalo de bits en función de esa duración de fotogramas.

Los codificadores de video H.263 y MPEG-4 DEBEN admitir tasas de bits configurables dinámicamente.

Todos los codificadores de video DEBEN cumplir con los siguientes objetivos de tasa de bits en dos ventanas variables:

  • No DEBE ser superior a ~15% por encima de la tasa de bits entre los intervalos intraframe (I-frame).
  • En una ventana variable de 1 segundo, NO DEBE ser superior a ~100% por encima de la tasa de bits.

5.2.1 H.263

Las implementaciones en dispositivos Android con codificadores H.263 DEBEN ser compatibles con el nivel 45 de perfil de Baseline.

5.2.2. H‐264

Implementaciones en dispositivos Android compatibles con el códec H.264:

  • DEBE admitir el nivel 3 del perfil de Baseline.
    Sin embargo, la compatibilidad con ASO (ordenamiento de Slices arbitrario), FMO (pedido de macrobloqueo flexible) y RS (Slices redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no usen ASO, FMO ni RS para el perfil de Baseline.
  • SE DEBE admitir los perfiles de codificación de video SD (definición estándar) que se indican en la siguiente tabla.
  • SE DEBE admitir el perfil principal de nivel 4.
  • SE RECOMIENDA admitir los perfiles de codificación de video HD (alta definición) como se indica en la siguiente tabla.
  • Además, se RECOMIENDA QUE los dispositivos Android Television codifiquen video HD de 1080p a 30 fps.
SD (baja calidad) SD (alta calidad) HD: 720p1 HD: 1080p1
Resolución de video 320 x 240 px 720 × 480 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 20 fps 30 fps 30 fps 30 fps
Tasa de bits del video 384 Kbps 2 Mbps 4 Mbps 10 Mbps

1 Cuando es compatible con hardware, pero ES IMPORTANTE para dispositivos Android Television.

5.2.3. VP8

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

SD (baja calidad) SD (alta calidad) HD: 720p1 HD: 1080p1
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps
Tasa de bits del video 800 Kbps 2 Mbps 4 Mbps 10 Mbps

1 Cuando el hardware es compatible.

5.3 Decodificación de video

Los códecs de video son opcionales para las implementaciones en dispositivos de Android Watch.

Implementaciones en dispositivos:

  • DEBE admitir la resolución de video dinámica y el cambio de velocidad de fotogramas a través de las API estándar de Android dentro de la misma transmisión para todos los códecs VP8, VP9, H.264 y H.265 en tiempo real y hasta la resolución máxima admitida por cada códec en el dispositivo.

  • Implementaciones compatibles con el decodificador Dolby Vision:

  • DEBE incluir un extractor compatible con Dolby Vision.

  • DEBE mostrar correctamente el contenido de Dolby Vision en la pantalla del dispositivo o en un puerto de salida de video estándar (p.ej., HDMI).

  • Las implementaciones que proporcionan un extractor compatible con Dolby Vision DEBEN establecer el índice de seguimiento de las capas base retrocompatibles (si las hay) para que sea el mismo que el índice de seguimiento de la capa combinada de Dolby Vision.

5.3.1 MPEG-2

Las implementaciones en dispositivos Android con decodificadores MPEG-2 deben admitir el perfil principal de alto nivel.

5.3.2. H.263

Las implementaciones en dispositivos Android con decodificadores H.263 DEBEN admitir el nivel 30 y 45 del perfil de Baseline.

5.3.3. MPEG-4

Las implementaciones en dispositivos Android con decodificadores MPEG-4 DEBEN ser compatibles con el nivel 3 de perfil simple.

5.3.4. H.264

Implementaciones en dispositivos Android con decodificadores H.264:

  • DEBE admitir el perfil principal nivel 3.1 y el perfil de Baseline.
    La compatibilidad con ASO (ordenamiento de Slices arbitrario), FMO (orden de macrobloqueo flexible) y RS (Slices redundantes) es OPCIONAL.
  • DEBE ser capaz de decodificar videos con los perfiles de SD (definición estándar) que se indican en la siguiente tabla y codificados con el perfil de Baseline y el perfil principal nivel 3.1 (incluida la resolución 720p30).
  • SE DEBE poder decodificar videos con los perfiles HD (alta definición) como se indica en la siguiente tabla.
  • Además, los dispositivos Android Television,
    • DEBE admitir el perfil de alto perfil 4.2 y el perfil de decodificación HD 1080p60.
    • DEBE ser capaz de decodificar videos con ambos perfiles HD, como se indica en la siguiente tabla, y codificados con el perfil de Baseline, el perfil principal o el perfil alto 4.2.
SD (baja calidad) SD (alta calidad) HD: 720p1 HD: 1080p1
Resolución de video 320 x 240 px 720 × 480 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 30 fps 30 fps 60 fps 30 fps (60 fps 2 )
Tasa de bits del video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

1 OBLIGATORIO cuando la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del video.

2 OBLIGATORIO para las implementaciones en dispositivos de Android Television.

5.3.5 H.265 (HEVC)

Implementaciones en dispositivos Android, cuando se admite el códec H.265, como se describe en la sección 5.1.3:

  • DEBE admitir el nivel principal de nivel 3 del perfil principal y los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • SE RECOMIENDA admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
  • DEBE admitir los perfiles de decodificación HD, como se indica en la siguiente tabla, si hay un decodificador de hardware.
  • Además, los dispositivos Android Television:
  • DEBE admitir el perfil de decodificación HD 720p.
  • SE RECOMIENDA admitir el perfil de decodificación HD 1080p. Si el perfil de decodificación HD de 1080p es compatible, DEBE ser compatible con el nivel de perfil principal 4.1.
  • SE DEBE admitir el perfil de decodificación en UHD. Si el perfil de decodificación UHD es compatible, el códec DEBE admitir el perfil de nivel principal de Main10 nivel 5.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p UHD
Resolución de video 352 × 288 px 720 × 480 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps (60 fps 1 ) 60 fps
Tasa de bits del video 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 OBLIGATORIO para las implementaciones en dispositivos Android Television con decodificación por hardware H.265.

5.3.6. VP8

Implementaciones en dispositivos Android, cuando se admite el códec VP8, como se describe en la sección 5.1.3:

  • DEBE admitir los perfiles de decodificación SD que se indican en la siguiente tabla.
  • SE RECOMIENDA admitir los perfiles de decodificación HD que se indican en la siguiente tabla.
  • Los dispositivos Android Television DEBEN admitir el perfil de decodificación HD 1080p60.
SD (baja calidad) SD (alta calidad) HD: 720p1 HD: 1080p1
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps (60 fps 2 ) 30 (60 fps 2 )
Tasa de bits del video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

1 OBLIGATORIO cuando la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del video.

2 OBLIGATORIO para las implementaciones en dispositivos de Android Television.

5.3.7. VP9

Implementaciones en dispositivos Android, cuando se admite el códec VP9, como se describe en la sección 5.1.3:

  • DEBE admitir los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • SE RECOMIENDA admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
  • DEBE admitir los perfiles de decodificación HD, como se indica en la siguiente tabla, si hay un decodificador de hardware.

  • Además, los dispositivos Android Television:

    • DEBE admitir el perfil de decodificación HD 720p.
    • SE RECOMIENDA admitir el perfil de decodificación HD 1080p.
    • SE DEBE admitir el perfil de decodificación en UHD. Si el perfil de decodificación de videos UHD es compatible, DEBE admitir una profundidad de color de 8 bits y el perfil 2 de VP9 (10 bits).
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p UHD
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps (60 fps 1 ) 60 fps
Tasa de bits del video 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 OBLIGATORIO para las implementaciones en dispositivos Android Television con decodificación por hardware de VP9.

5.4. Grabación de audio

Si bien algunos de los requisitos descritos en esta sección se indican como DEBEN a partir de Android 4.3, se planea cambiar la definición de compatibilidad para una versión futura a DEBE. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con los requisitos indicados como DEBEN. De lo contrario, no serán compatibles con Android cuando se actualicen a la versión futura.

5.4.1 Captura de audio sin procesar

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

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

La captura de las tasas de muestreo anteriores DEBE realizarse sin sobremuestreo, y cualquier reducción de muestreo DEBE incluir un filtro de suavizado de contorno adecuado.

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

  • Formato : PCM lineal, 16 bits
  • Tasas de muestreo : 22,050, 48,000
  • Canales : estéreo

Si se admite la captura para las tasas de muestreo anteriores, la captura DEBE realizarse sin sobremuestreo en cualquier relación superior a 16,000:22,050 o 44,100:48,000. Cualquier sobremuestreo o submuestreo DEBE incluir un filtro de suavizado de contorno adecuado.

5.4.2. Capturar para el reconocimiento de voz

La fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION DEBE admitir la captura con una de las tasas de muestreo (44,100 y 48,000).

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

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

Si la plataforma admite tecnologías de supresión de ruido ajustadas para el reconocimiento de voz, el efecto DEBE poder controlarse desde la API de android.media.audiofx.NoiseSuppressor. Además, el campo UUID para el descriptor de efectos del supresor de ruido DEBE identificar de manera única cada implementación de la tecnología de supresión de ruido.

5.4.3. Captura para el redireccionamiento de 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 de android.media.AudioRecord para grabar desde esa fuente de audio, pueda capturar una combinación de todas las transmisiones de audio, excepto las siguientes:

  • SONIDO DE TRANSMISIONES
  • ALARMA DE TRANSMISIÓN
  • NOTIFICACIÓN_DE_TRANSMISIÓ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 procesar con las siguientes características:

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

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

  • Tasas de muestreo : 24,000, 48,000

5.5.2. Efectos de audio

Android proporciona una API de efectos de audio para implementaciones en dispositivos. 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 de AudioEffect Equalizer y LoudnessEnhancer.
  • DEBE admitir la implementación de la API del visualizador, que se puede controlar a través de la clase de Visualizer.
  • SE DEBE admitir las implementaciones Effect_TYPE_BASS_BOOST, Effect_TYPE_ENV_REVERB, Effect_TYPE_PRESET_REVERB, y Effect_TYPE_VIRTUALIZER que se pueden controlar a través de las subclases de AudioEffect BassBoost, EnvironmentalReverb, PresetReverb y Virtualizer.

5.5.3. Volumen de audio saliente

Las implementaciones para dispositivos de televisión de Android DEBEN incluir compatibilidad con el volumen principal del sistema y la atenuación del volumen de salida de audio digital en las salidas compatibles, excepto con la salida de transferencia de audio comprimido (en la que no se realiza la decodificación de audio en el dispositivo).

Las implementaciones en dispositivos Android Automotive DEBEN permitir el ajuste del volumen del audio por separado para cada transmisión de audio usando el tipo de contenido o uso, como se define en AudioAttributes, y el uso del audio del vehículo, como se define públicamente en android.car.CarAudioManager .

5.6. Latencia de audio

La latencia de audio es el retraso de tiempo cuando una señal de audio pasa a través de un sistema. Muchas clases de aplicaciones dependen de latencias cortas para lograr efectos de sonido en tiempo real.

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

  • latencia de salida . El intervalo entre el momento en que una aplicación escribe una trama de datos codificados en PCM y el momento en que el sonido correspondiente se presenta al entorno en un transductor o una señal integrados en el dispositivo sale del dispositivo a través de un puerto y se puede observar externamente.
  • latencia de salida en frío . La latencia de salida del primer fotograma, cuando el sistema de salida de audio estuvo inactivo y apagado antes de la solicitud.
  • latencia de salida continua . La latencia de salida para los fotogramas posteriores, después de que el dispositivo reproduce audio.
  • latencia de entrada . El intervalo entre el momento en que el entorno presenta un sonido al dispositivo cuando un transductor o la señal del dispositivo ingresa al dispositivo a través de un puerto y cuando una aplicación lee la trama correspondiente de datos codificados en PCM.
  • entrada perdida . La parte inicial de una señal de entrada que no se puede usar o no está disponible.
  • latencia de entrada en frío . La suma del tiempo de entrada perdido y la latencia de entrada de la primera trama cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
  • latencia de entrada continua . La latencia de entrada para los fotogramas posteriores, mientras el dispositivo está capturando audio.
  • Jitter de salida en frío La variabilidad entre mediciones independientes de valores de latencia de salida en frío.
  • Jitter de entrada en frío La variabilidad entre mediciones independientes de valores de latencia de entrada en frío.
  • latencia de ida y vuelta continua . Es la suma de la latencia de entrada continua más la latencia de salida continua más un período de búfer. El período de búfer permite que la app procese la señal y que mitigue la diferencia de fase entre las transmisiones de entrada y salida.
  • API de cola de búfer PCM de OpenSL ES Conjunto de APIs de OpenSL ES relacionadas con PCM dentro del NDK de Android.

SE RECOMIENDA ELEGIR LAS implementaciones en dispositivos que declaran android.hardware.audio.output para cumplir o superar los siguientes 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
  • minimiza el jitter de salida fría

Si la implementación de un dispositivo cumple con los requisitos de esta sección después de cualquier calibración inicial cuando se usa la API de cola de búfer de PCM de OpenSL ES para latencia de salida continua y latencia de salida en frío en al menos un dispositivo de salida de audio compatible, se RECOMIENDA INFORMAR la compatibilidad con audio de baja latencia informando la función android.hardware.audio.low_Latency a través de la clase android.content.pm.PackageManager. Por el contrario, si la implementación del dispositivo no cumple con estos requisitos, NO DEBE informar la compatibilidad con audio de baja latencia.

Se RECOMIENDA EFICIENTEMENTE las implementaciones en dispositivos que incluyen android.hardware.microphone para cumplir con los siguientes 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
  • una latencia de ida y vuelta continua de 50 milisegundos o menos
  • minimiza el jitter de entrada fría

5.7. Protocolos de red

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

Formatos de segmentos Referencias Compatibilidad con códecs requeridos
MPEG-2 Transport Stream ISO 13818 Códecs de video:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consulta la sección 5.1.3 para obtener detalles sobre H264 AVC, MPEG2-4 SP,
y MPEG-2.

Códecs de audio:

  • AAC
Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes.
AAC con enmarcado ADTS y etiquetas ID3 ISO 13818‐7 Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
WebVTT WebVTT

  • RTSP (RTP, SDP)

    DEBEN ser compatibles el siguiente perfil de audio de RTP y los códecs relacionados. Para conocer las excepciones, consulte las notas al pie de la tabla de la sección 5.1.

Nombre del perfil Referencias Compatibilidad con códecs requeridos
H264 AVC RFC 6184 Consulta la sección 5.1.3 para obtener información detallada acerca de H264 AVC.
MP4A-LATM RFC 6416 Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Consulta la sección 5.1.3 para obtener detalles sobre H263.
H263-2000 RFC 4629 Consulta la sección 5.1.3 para obtener detalles sobre H263.
AMR RFC 4867 Consulta la sección 5.1.1 para obtener detalles sobre AMR-NB
AMR-WB RFC 4867 Consulta la sección 5.1.1 para obtener detalles sobre AMR-WB.
MP4V‐ES RFC 6416 Consulta la sección 5.1.3 para obtener información detallada acerca de MPEG-4 SP
MPEG-4-genérico RFC 3640 Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
MP2T RFC 2250 Consulta MPEG-2 Transport Stream debajo de HTTP Live Streaming para obtener más detalles.

5.8. Contenido multimedia seguro

Las implementaciones de dispositivos que admiten salida de video segura y que pueden admitir superficies seguras DEBEN declarar la compatibilidad con 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 vínculo con un mecanismo criptográficamente seguro, como HDCP 2.x o versiones posteriores para pantallas inalámbricas Miracast. Del mismo modo, si admiten una pantalla externa con cable, las implementaciones del dispositivo DEBEN ser compatibles con HDCP 1.2 o versiones posteriores. Las implementaciones de dispositivos de televisión de Android DEBEN ser compatibles con HDCP 2.2 en los dispositivos que admiten resolución 4K y HDCP 1.4 o superior para resoluciones más bajas. La implementación ascendente de código abierto de Android incluye compatibilidad con pantallas inalámbricas (Miracast) y con cable (HDMI) que cumplen con este requisito.

5.9 Interfaz digital para instrumentos musicales (MIDI)

Si la implementación de un dispositivo admite el transporte de software MIDI entre apps (dispositivos MIDI virtuales) y admite MIDI en todos los siguientes transportes de hardware compatibles con MIDI para los cuales proporciona conectividad genérica que no es MIDI, se RECOMIENDA INFORMAR LA compatibilidad con la función android.software.midi a través de la clase android.content.pm.PackageManager.

Los transportes de hardware compatibles con MIDI son los siguientes:

  • Modo de host USB (sección 7.7 USB)
  • Modo periférico USB (sección 7.7 USB)
  • Funcionamiento central de MIDI mediante Bluetooth de bajo consumo (sección 7.4.3 Bluetooth)

Por el contrario, si la implementación del dispositivo proporciona conectividad genérica que no es MIDI en un transporte de hardware compatible con MIDI en particular mencionado anteriormente, pero no admite MIDI en ese transporte de hardware, NO DEBE informar la compatibilidad con la función android.software.midi.

5.10. Audio profesional

Si la implementación de un dispositivo cumple con todos estos requisitos, SE RECOMIENDA QUE informes la compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager.

  • La implementación del dispositivo DEBE informar la compatibilidad con la función android.hardware.audio.low_Latency.
  • La latencia de audio de ida y vuelta continua, tal como se define en la sección 5.6 Latencia de audio, DEBE ser de 20 milisegundos o menos, y DEBE ser de 10 milisegundos o menos en al menos una ruta de acceso admitida.
  • Si el dispositivo incluye un conector de audio de 3,5 mm de 4 conductores, la latencia de audio de ida y vuelta continua DEBE ser de 20 milisegundos o menos en la ruta del conector de audio, y DEBE ser de 10 milisegundos o menos en la ruta del conector de audio.
  • La implementación del dispositivo DEBE incluir uno o más puertos USB que admitan el modo de host USB y el modo periférico USB.
  • El modo de host USB DEBE implementar la clase de audio USB.
  • Si el dispositivo incluye un puerto HDMI, la implementación del dispositivo DEBE admitir salidas en estéreo y ocho canales con una profundidad de 20 o 24 bits y 192 kHz sin pérdida de profundidad de bits ni remuestreo.
  • La implementación del dispositivo DEBE informar la compatibilidad con la función android.software.midi.
  • Si el dispositivo incluye un conector de audio de 3.5 mm de 4 conductores, se RECOMIENDA ENCENDER que su implementación cumpla con la sección Especificaciones para dispositivos móviles (conector) de la Especificación de auriculares de audio con cable (v1.1).

Los requisitos de latencia y audio USB SE DEBEN cumplir con la API de cola de búfer PCM de OpenSL ES.

Además, una implementación de dispositivo que informe sobre la compatibilidad con esta función DEBE:

  • Proporcionar un nivel sostenible de rendimiento de CPU mientras el audio está activo.
  • Minimiza la inexactitud y la desviación del reloj de audio en relación con la hora estándar.
  • Minimiza el desvío del reloj de audio en relación con el CLOCK_MONOTONIC de la CPU cuando ambos están activos.
  • Minimiza la latencia de audio en los transductores integrados en el dispositivo.
  • Minimiza la latencia de audio mediante audio digital USB.
  • Documenta las mediciones de latencia de audio en todas las rutas de acceso.
  • Minimiza el jitter en los tiempos de entrada de devolución de llamada de finalización del búfer de audio, ya que esto afecta el porcentaje utilizable del ancho de banda total de la CPU por parte de la devolución de llamada.
  • No proporciones ningún subdesbordamiento (salida) ni exceso (entrada) de audio en condiciones de uso normal con la latencia informada.
  • No proporciones una diferencia de latencia entre canales de cero.
  • Minimizar la latencia media de MIDI en todos los transportes.
  • Minimiza la variabilidad de la latencia de MIDI bajo carga (jitter) en todos los transportes.
  • Proporciona marcas de tiempo MIDI precisas en todos los transportes.
  • Minimiza el ruido de la señal de audio con los transductores integrados en el dispositivo, incluido el período inmediatamente posterior al inicio en frío.
  • Proporciona una diferencia de reloj de audio de cero entre los lados de entrada y salida de los extremos correspondientes, cuando ambos están activos. Algunos ejemplos de los extremos correspondientes incluyen el micrófono y la bocina integrados en el dispositivo o la entrada y salida del conector de audio.
  • Controla las devoluciones de llamada de finalización del búfer de audio para los extremos de entrada y salida de los extremos correspondientes en el mismo subproceso cuando ambos están activos y, luego, ingresa la devolución de llamada de salida inmediatamente después del retorno de la devolución de llamada de entrada. O, si no es posible manejar las devoluciones de llamada en el mismo subproceso, ingresa la devolución de llamada de salida poco después de ingresar la devolución de llamada de entrada para permitir que la aplicación tenga una sincronización coherente de los lados de entrada y salida.
  • Minimiza la diferencia de fase entre el almacenamiento en búfer de audio de HAL para la entrada y salida de los extremos correspondientes.
  • Minimiza la latencia de la pantalla táctil.
  • Minimiza la variabilidad de la latencia táctil bajo carga (jitter).

5.11. Captura para contenido sin procesar

A partir de Android 7.0, se agregó una nueva fuente de grabación. Se puede acceder a través de la fuente de audio android.media.MediaRecorder.AudioSource.UNPROCESSED. En OpenSL ES, se puede acceder a él con el ajuste predeterminado de grabación SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Un dispositivo DEBE cumplir con todos los requisitos que se indican a continuación para informar la compatibilidad de la fuente de audio sin procesar a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED:

  • El dispositivo DEBE exhibir aproximadamente características planas de amplitud frente a frecuencia en el rango de frecuencia media: específicamente ±10 dB, de 100 Hz a 7,000 Hz.

  • El dispositivo DEBE exhibir niveles de amplitud en el rango de frecuencia baja, específicamente de ±20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencia media.

  • El dispositivo DEBE exhibir niveles de amplitud en el rango de alta frecuencia, específicamente de ±30 dB, de 7000 Hz a 22 KHz en comparación con el rango de frecuencia media.

  • La sensibilidad de entrada de audio SE DEBE establecer de modo que una fuente de tono sinusoidal de 1,000 Hz, reproducida a un nivel de presión sonora (SPL) de 94 dB, produzca una respuesta con una RMS de 520 para muestras de 16 bits (o de -36 dB en escala completa para muestras de punto flotante o de doble precisión).

  • SNR > 60 dB (diferencia entre 94 dB de SPL y SPL equivalente de ruido propio, ponderado A).

  • La distorsión armónica total DEBE ser inferior al 1% para 1 kHZ a un nivel de entrada de SPL de 90 dB en el micrófono.

  • El único procesamiento de indicadores permitido en la ruta de acceso es un multiplicador de niveles para llevar el nivel al rango deseado. Este multiplicador de niveles NO DEBE generar demora ni latencia en la ruta de acceso de la señal.

  • No se permite ningún otro procesamiento de señales en la ruta, como el control automático de ganancia, el filtro de paso alto o la cancelación de eco. Si hay algún procesamiento de señal presente en la arquitectura por cualquier motivo, se DEBE inhabilitar y, de manera efectiva, introducir cero retraso o latencia adicional en la ruta de acceso de la señal.

Todas las mediciones del SPL se realizan directamente junto al micrófono que se está probando.

Para varias configuraciones de micrófono, estos requisitos se aplican a cada micrófono.

SE RECOMIENDA ENcarecidamente que un dispositivo cumpla con la misma cantidad de requisitos de la ruta de acceso de la señal para la fuente de registro no procesada. Sin embargo, un dispositivo debe cumplir con todos estos requisitos mencionados anteriormente si afirma admitir la fuente de audio no procesada.

6. Compatibilidad de las Herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Las implementaciones en dispositivos DEBEN ser compatibles con las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android. Los dispositivos compatibles con Android DEBEN ser compatibles con lo siguiente:

  • Android Debug Bridge (adb)
      .
    • Las implementaciones en dispositivos DEBEN admitir todas las funciones de adb como se documenta en el SDK de Android, incluido dumpsys.
    • El daemon adb 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 Android Debug Bridge a través de una red de área local (como Ethernet u 802.11).
    • Android admite adb seguro. adb seguro habilita adb en hosts autenticados conocidos. Las implementaciones del dispositivo DEBEN admitir adb seguro.
  • Servicio Dalvik Debug Monitor (ddms)
      .
    • Las implementaciones en dispositivos DEBEN admitir todas las funciones de DDMS, tal como se documenta en el SDK de Android.
    • Dado que ddms usa adb, su compatibilidad DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario activa Android Debug Bridge, como se indicó anteriormente.
  • Las implementaciones en dispositivos de Monkey DEBEN incluir el framework de Monkey y ponerlo a disposición de las aplicaciones.
  • SysTrace
      .
    • Las implementaciones en dispositivos DEBEN admitir la herramienta systrace tal 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 activarlo.
    • La mayoría de los sistemas basados en Linux y Apple Macintosh reconocen dispositivos Android que usan las herramientas estándar del SDK de Android, sin compatibilidad adicional. Sin embargo, los sistemas Microsoft Windows suelen requerir un controlador para los dispositivos Android nuevos. (Por ejemplo, los IDs de proveedores nuevos y, a veces, los IDs de dispositivos nuevos requieren controladores USB personalizados para los 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 al dispositivo mediante el protocolo adb. Estos controladores DEBEN estar disponibles para Windows XP, Windows Vista, Windows 7, Windows 8 y Windows 10 en las versiones de 32 y 64 bits.

6.2. Opciones para desarrolladores

Android incluye asistencia para que los desarrolladores configuren la configuración relacionada con el desarrollo de aplicaciones. Las implementaciones de dispositivos DEBEN cumplir con la intención android.settings.APPLICATION_DEVELOPMENT_CONFIGURACIÓN de mostrar la configuración relacionada con el desarrollo de la aplicación. La implementación ascendente de Android oculta el menú Opciones para desarrolladores de forma predeterminada y permite a los usuarios iniciar Opciones para desarrolladores después de presionar siete (7) veces en Configuración. Acerca del dispositivo > Elemento de menú Número de compilación (Build Number). Las implementaciones en dispositivos DEBEN proporcionar una experiencia coherente para las Opciones para desarrolladores. Específicamente, las implementaciones de dispositivos DEBEN ocultar las Opciones para desarrolladores de forma predeterminada y DEBEN proporcionar un mecanismo para habilitarlas que sea coherente con la implementación ascendente de Android.

Es posible que las implementaciones de Android Automotive limiten el acceso al menú Opciones para desarrolladores ocultando o inhabilitando visualmente el menú cuando el vehículo esté en movimiento.

7. Compatibilidad de hardware

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

  • Se DEBEN presentar las definiciones completas de las clases (como se documenta en el SDK) para las APIs de componentes.
  • Los comportamientos de la API DEBEN implementarse como no-ops de alguna manera razonable.
  • Los métodos de la API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
  • Los métodos de API DEBEN mostrar implementaciones no-op de clases donde la documentación del SDK no permite valores nulos.
  • Los métodos de la API NO DEBEN generar excepciones que no estén documentadas en la documentación del SDK.

Un ejemplo típico de una situación en la que se aplican estos requisitos es la API de telefonía: incluso en dispositivos que no sean teléfonos, estas APIs deben implementarse como no-ops razonables.

Las implementaciones de dispositivos DEBEN informar de manera coherente información precisa sobre la 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.

7.1. Pantalla y gráficos

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

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

  • tamaño diagonal físico . Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
  • puntos por pulgada (DPI) . Es la cantidad de píxeles incluidos en un intervalo horizontal o vertical lineal de 1". En los casos en que se enumeran los valores de DPI, los DPI horizontales y verticales deben estar dentro del rango.
  • relación de aspecto . Es la proporción entre los píxeles de la dimensión más larga y la más corta de la pantalla. Por ejemplo, una pantalla de 480 x 854 píxeles sería 854/480 = 1.779 o aproximadamente “16:9”.
  • píxel independiente de la densidad (dp) La unidad de píxeles virtuales normalizada en una pantalla de 160 dpi, calculada de la siguiente manera: píxeles = dps * (densidad/160).

7.1.1 Configuración de pantalla

7.1.1.1. Tamaño de la pantalla

Los dispositivos Android Watch (detallados en la sección 2) PUEDEN tener tamaños de pantalla más pequeños, como se describe en esta sección.

El framework de IU de Android admite una variedad de tamaños de pantalla diferentes y permite a las aplicaciones consultar el tamaño de pantalla del dispositivo (también conocido como “diseño de pantalla”) a través de android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Las implementaciones de dispositivos DEBEN informar el tamaño de pantalla correcto según se define en la documentación del SDK de Android y según lo determine la plataforma de Android ascendente. Específicamente, las implementaciones en dispositivos DEBEN informar el tamaño de pantalla correcto según las siguientes dimensiones de pantalla de píxeles independientes de la densidad lógica (dp).

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

A su vez:

  • Los dispositivos Android Watch DEBEN tener una pantalla con un tamaño diagonal físico de entre 1.1 y 2.5 pulgadas.
  • Los dispositivos Android Automotive DEBEN tener una pantalla con un tamaño físico diagonal superior o igual a 6 pulgadas.
  • Los dispositivos Android Automotive DEBEN tener un tamaño de pantalla de al menos 750 dp x 480 dp.
  • Otros tipos de implementaciones en dispositivos Android, con una pantalla integrada físicamente, 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.

De manera opcional, las aplicaciones pueden indicar los tamaños de pantalla que admiten mediante la sección <supports-screens> en el archivo AndroidManifest.xml. Las implementaciones en dispositivos DEBEN respetar correctamente las capacidades de asistencia declarada 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 la pantalla

Si bien no hay restricciones para el valor de la relación de aspecto de la pantalla física, la relación de aspecto de la pantalla de la superficie en la que se renderizan las apps de terceros y que puede derivar de los valores informados a través de DisplayMetrics DEBE cumplir con los siguientes requisitos:

  • Si uiMode está configurado como UI_MODE_TYPE_WATCH, el valor de relación de aspecto PUEDE establecerse como 1.0 (1:1).
  • Si la app de terceros indica que se puede cambiar su tamaño mediante el atributo android:resizeableActivity, no hay restricciones para el valor de la relación de aspecto.
  • Para todos los demás casos, la relación de aspecto DEBE ser un valor entre 1.3333 (4:3) y 1.86 (aproximadamente 16:9), a menos que la app haya indicado explícitamente que admite una relación de aspecto de pantalla más alta a través del valor de metadatos maxAspectRatio.

7.1.1.3. Densidad de la pantalla

El framework de la IU de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientarse a los recursos de la aplicación. Las implementaciones de dispositivos DEBEN informar solo una de las siguientes densidades lógicas de framework de Android a través de las APIs de android.util.DisplayMetrics. Además, DEBEN ejecutar las aplicaciones con esta densidad estándar, y NO DEBEN cambiar el valor en ningún momento para la pantalla predeterminada.

  • 120 DPI (ldpi)
  • 160 dpi (mdpi)
  • 213 dpi (tvdpi)
  • 240 dpi (hdpi)
  • 280 DPI (280 DPI)
  • 320 dpi (xhdpi)
  • 360 dpi (360dpi)
  • 400 dpi (400dpi)
  • 420 DPI (420 DPI)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

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

SE RECOMIENDA LAS implementaciones en dispositivos para proporcionarles a los usuarios una configuración que les permita cambiar el tamaño de la pantalla. Si existe una implementación para cambiar el tamaño de pantalla del dispositivo, DEBE alinearse con la implementación de AOSP, como se indica a continuación:

  • El tamaño de la pantalla NO DEBE ajustarse a más de 1.5 veces la densidad nativa ni producir una dimensión de pantalla mínima efectiva inferior a 320 dp (equivalente al calificador de recursos sw320 dp), lo que ocurra primero.
  • El tamaño de la pantalla NO se DEBE ajustar a una escala inferior a 0.85 veces la densidad nativa.
  • Para garantizar una buena usabilidad y tamaños de fuente coherentes, se RECOMIENDA proporcionar la siguiente escala de opciones de anuncios gráficos nativos (siempre y cuando se cumplan los límites especificados anteriormente):
  • Pequeño: 0.85x
  • Predeterminado: 1x (escala de visualización nativa)
  • Grande: 1.15x
  • Más grande: 1.3 veces
  • Mayor 1.45 veces

7.1.2. Métricas de Display

Las implementaciones de dispositivos DEBEN informar los valores correctos para todas las métricas de pantalla definidas en android.util.DisplayMetrics, y DEBEN informar los mismos valores independientemente de si se usa la pantalla integrada o externa como pantalla predeterminada.

7.1.3 Orientación de pantalla

Los dispositivos DEBEN informar qué orientaciones de pantalla admiten (android.hardware.screen.portrait o android.hardware.screen.landscape) y DEBEN informar, al menos, una orientación compatible. Por ejemplo, un dispositivo con una pantalla horizontal con orientación fija, como una televisión o una laptop, solo DEBE informar android.hardware.screen.landscape.

Los dispositivos que informan ambas orientaciones de pantalla DEBEN admitir la orientación dinámica de las aplicaciones para la orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación respecto 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 de la orientación actual del dispositivo, siempre que se realicen consultas a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() o alguna otra API.

Los dispositivos NO DEBEN modificar la densidad o el tamaño de pantalla informados cuando cambian la orientación.

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

Las implementaciones en dispositivos DEBEN ser compatibles con OpenGL ES 1.0 y 2.0, tal como se incorpora y se detalla en la documentación del SDK de Android. Las implementaciones en dispositivos DEBEN admitir OpenGL ES 3.0, 3.1 o 3.2 en dispositivos compatibles. Las implementaciones en dispositivos DEBEN ser compatibles con Android RenderScript, como se detalla en la documentación del SDK de Android.

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

  • Las APIs administradas (por ejemplo, a través del método GLES10.getString()) DEBEN informar compatibilidad con OpenGL ES 1.0 y OpenGL ES 2.0.
  • Las API nativas de C/C++ OpenGL (API disponibles para apps 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, 3.1 o 3.2 DEBEN admitir las API administradas correspondientes e incluir compatibilidad con las API nativas de C/C++. En implementaciones de dispositivos que declaren compatibilidad con OpenGL ES 3.0, 3.1 o 3.2, libGLESv2.so, DEBEN exportar los símbolos de función correspondientes además de los símbolos de función de OpenGL ES 2.0

Android proporciona un paquete de extensión OpenGL ES con interfaces Java y compatibilidad nativa para la funcionalidad de gráficos avanzados, como el teselado y el formato de compresión de texturas ASTC. Las implementaciones en dispositivos Android DEBEN admitir el paquete de extensiones si el dispositivo es compatible con OpenGL ES 3.2 y, de lo contrario, PUEDEN admitirlo. Si todo el paquete de extensiones es compatible, el dispositivo DEBE identificar la compatibilidad a través de la marca de función android.hardware.opengles.aep.

Además, las implementaciones en dispositivos PUEDEN implementar cualquier extensión de OpenGL ES deseada. Sin embargo, las implementaciones en dispositivos DEBEN informar a través de las APIs nativas y administradas de OpenGL ES todas las cadenas de extensión que admiten y, por el contrario, NO DEBEN informar las cadenas de extensión que no admiten.

Ten en cuenta que Android admite que las aplicaciones especifiquen opcionalmente que requieren formatos de compresión de texturas OpenGL específicos. Por lo general, estos formatos son específicos del proveedor. Android no requiere implementaciones en dispositivos para implementar ningún formato específico de compresión de texturas. Sin embargo, DEBEN informar con precisión cualquier formato de compresión de texturas que sí admitan, a través del método getString() en la API de OpenGL.

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D a nivel de aplicación, actividad, ventana o vista mediante el uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas directas a la API.

Las implementaciones en dispositivos DEBEN habilitar la aceleración de hardware de forma predeterminada y DEBEN inhabilitarla si el desarrollador lo solicita configurando android:hardwareAccelerated="false” o inhabilitando la aceleración de hardware directamente a través de las API de Android View.

Además, las implementaciones en dispositivos DEBEN mostrar un comportamiento coherente con la documentación del SDK de Android sobre la aceleración de hardware.

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas de OpenGL ES con aceleración de hardware como objetivos de renderización en una jerarquía de IU. Las implementaciones del dispositivo DEBEN admitir la API de TextureView y DEBEN exhibir un comportamiento coherente con la implementación ascendente de Android.

Android incluye compatibilidad con EGL_ANDROID_RECORDABLE, un atributo EGLConfig que indica si EGLConfig admite la renderización en una ANativeWindow que registra imágenes en un video. Las implementaciones de dispositivos DEBEN admitir la extensión EGL_ANDROID_RECORDABLE.

7.1.5 Modo de compatibilidad de aplicaciones heredadas

Android especifica un “modo de compatibilidad” en el que el framework funciona de forma “normal” modo equivalente al tamaño de pantalla (320 dp de ancho) para el beneficio de aplicaciones heredadas no desarrolladas para versiones anteriores de Android que son anteriores a la independencia del tamaño de la pantalla.

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

7.1.6. Tecnología de pantalla

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

  • Los dispositivos DEBEN admitir pantallas capaces de renderizar gráficos a color de 16 bits y deben admitir pantallas compatibles con gráficos de color de 24 bits.
  • Los dispositivos DEBEN admitir pantallas capaces de renderizar animaciones.
  • La tecnología de visualización que se utilice DEBE tener una relación de aspecto de píxeles (PAR) de entre 0.9 y 1.15. Es decir, la relación de aspecto de los píxeles DEBE ser cercana al cuadrado (1.0) con una tolerancia del 10% al 15%.

7.1.7 Pantallas secundarias

Android incluye compatibilidad con la pantalla secundaria para habilitar las capacidades de uso compartido de contenido multimedia y APIs para desarrolladores para acceder a pantallas externas. Si un dispositivo admite una pantalla externa, ya sea con una conexión de cable, inalámbrica o una pantalla adicional incorporada, la implementación del dispositivo DEBE implementar la API del administrador de pantallas, como se describe en la documentación del SDK de Android.

7.2. Dispositivos de entrada

Los dispositivos DEBEN ser compatibles con una pantalla táctil o cumplir con los requisitos que se mencionan en 7.2.2 para la navegación no táctil.

7.2.1. Teclado

Las implementaciones de Android Watch y Android Automotive PODRÁN implementar un teclado en pantalla. Todas las demás implementaciones en dispositivos DEBEN implementar un teclado en pantalla y:

Implementaciones en dispositivos:

  • DEBE incluir compatibilidad con el marco de trabajo de administración de entradas (que permite a desarrolladores externos crear editores de método de entrada, es decir, teclado en pantalla), como se detalla en http://developer.android.com.
  • DEBE proporcionar al menos una implementación de teclado en pantalla (independientemente de si hay un teclado de hardware presente), excepto en el caso de los dispositivos Android Watch en los que el tamaño de la pantalla hace que sea menos razonable tener un teclado en pantalla.
  • PUEDE incluir implementaciones adicionales de teclado en pantalla.
  • PUEDE incluir un teclado de hardware.
  • NO DEBE incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.tecla (QWERTY o de 12 teclas).

7.2.2. Navegación no táctil

Los dispositivos de televisión Android DEBEN ser compatibles con el pad direccional.

Implementaciones en dispositivos:

  • PUEDE omitir una opción de navegación no táctil (bola de seguimiento, pad direccional o rueda) si la implementación del dispositivo no es un dispositivo de televisión Android.
  • SE DEBE informar el valor correcto de android.content.res.Configuration.navigation.
  • DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición de texto que sea compatible con los motores de administración de entradas. La implementación ascendente 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

Los requisitos de disponibilidad y visibilidad de las funciones Principal, Recientes y Atrás difieren entre los tipos de dispositivos, como se describe en esta secció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, tienen las siguientes características:

  • Las implementaciones de dispositivos de mano Android DEBEN proporcionar las funciones Inicio, Recientes y Atrás.
  • Las implementaciones en dispositivos de Android Television DEBEN proporcionar las funciones Home y Back.
  • Las implementaciones en dispositivos de Android Watch DEBEN tener la función de inicio y la función de retroceso disponibles para el usuario, excepto cuando se encuentran en UI_MODE_TYPE_WATCH .
  • Las implementaciones en dispositivos de Android Watch, y ningún otro tipo de dispositivo Android, PUEDEN consumir el evento de presión prolongada del evento clave KEYCODE_BACK y omitirlo para que no se envíe a la aplicación en primer plano.
  • 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 en dispositivos DEBEN proporcionar las funciones Home y Back.

Estas funciones PUEDEN implementarse mediante botones físicos exclusivos (como botones táctiles mecánicos o capacitivos) o pueden implementarse usando teclas de software dedicadas en una parte distinta de la pantalla, gestos, panel táctil, etc. Android admite ambas implementaciones. Se DEBE poder acceder a todas estas funciones con una sola acción (p.ej., tocar, hacer doble clic o gesto) cuando estén visibles.

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

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

La función Menú dejó de estar disponible y se reemplazó por la barra de acciones desde Android 4.0. Por lo tanto, las implementaciones de dispositivos nuevos que se envían con Android 7.0 y versiones posteriores NO DEBEN implementar un botón físico exclusivo para la función de menú. Las implementaciones en dispositivos más antiguos NO DEBEN implementar un botón físico exclusivo para la función Menú, pero si se implementa el botón de menú físico y el dispositivo ejecuta aplicaciones con targetSdkVersion > 10, la implementación del dispositivo:

  • DEBE mostrar el botón de menú ampliado de acciones en la barra de acciones cuando está visible y la ventana emergente del menú ampliado de acciones no está vacía. Para una implementación de dispositivos lanzada antes de Android 4.4, pero que se actualiza a Android 7.0, esto es RECOMENDADO.
  • NO DEBE modificar la posición de la ventana emergente de ampliación de acciones que se muestra seleccionando el botón de menú ampliado en la barra de acciones.
  • PUEDE renderizar la ventana emergente de ampliación de acciones en una posición modificada en la pantalla cuando se muestra seleccionando el botón físico de menú.

Para ofrecer retrocompatibilidad, las implementaciones de dispositivos DEBEN hacer que la función Menú esté disponible para las aplicaciones cuando la targetSdkVersion sea menor que 10, ya sea por un botón físico, una tecla de software o gestos. Esta función del menú debe mostrarse, a menos que esté oculta junto con otras funciones de navegación.

Las implementaciones de dispositivos Android que admiten la acción de asistencia o VoiceInteractionService DEBEN poder iniciar una aplicación de asistencia con una sola interacción (p.ej., presión, doble clic o gesto) cuando otras teclas de navegación estén visibles. SE RECOMIENDA Mantener presionado el botón de inicio para este tipo de interacción. La interacción designada DEBE iniciar la aplicación de asistencia seleccionada por el usuario; en otras palabras, la aplicación que implementa un VoiceInteractionService o una actividad que controla el intent ACTION_ASSIST.

Las implementaciones del dispositivo PUEDEN usar una parte distinta de la pantalla para mostrar las teclas de navegación, pero, de ser así, DEBEN cumplir con estos requisitos:

  • Las teclas de navegación de la implementación del dispositivo DEBEN utilizar una parte distinta de la pantalla, no deben estar disponibles para las aplicaciones, y NO DEBEN ocultar ni interferir de ninguna otra manera con la parte de la pantalla disponible para las aplicaciones.
  • Las implementaciones en dispositivos DEBEN poner a disposición de las aplicaciones una parte de la pantalla que cumpla con los requisitos definidos en la sección 7.1.1.
  • Las implementaciones del dispositivo DEBEN mostrar las teclas de navegación cuando las aplicaciones no especifican un modo de IU del sistema o especifican SYSTEM_UI_FLAG_VISIBLE.
  • Las implementaciones del dispositivo DEBEN presentar las teclas de navegación en un modo discreto de “perfil bajo” (p. ej., atenuado) cuando las aplicaciones especifican SYSTEM_UI_FLAG_LOW_PROFILE.
  • Las implementaciones del dispositivo DEBEN ocultar las teclas de navegación cuando las aplicaciones especifican SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Entrada de pantalla táctil

Los dispositivos portátiles y de reloj Android DEBEN ser compatibles con la entrada de pantalla táctil.

Las implementaciones de dispositivos DEBEN tener algún tipo de sistema de entrada de puntero (ya sea similar a un mouse o táctil). Sin embargo, si la implementación de un dispositivo no admite un sistema de entrada de puntero, NO DEBE informar la constante de la función android.hardware.touchscreen ni android.hardware.faketouch. Implementaciones de dispositivos que sí incluyen un sistema de entrada de puntero:

  • Si el sistema de entrada del dispositivo admite varios punteros, SE DEBE admitir punteros con seguimiento independiente.
  • SE DEBE informar el valor de android.content.res.Configuration.touchscreen correspondiente al tipo de pantalla táctil específica del dispositivo.

Android admite una variedad de pantallas táctiles, paneles táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basados en pantallas táctiles se asocian con una pantalla de modo que el usuario tenga la impresión de manipular directamente elementos en pantalla. Dado que el usuario está tocando directamente la pantalla, el sistema no requiere indicaciones adicionales para indicar los objetos que se están manipulando. Por el contrario, una interfaz táctil falsa proporciona al usuario un sistema de entrada que se aproxima a un subconjunto de capacidades de pantalla táctil. Por ejemplo, un mouse o un control remoto que impulsa un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o enfoque y, luego, haga clic. Varios dispositivos de entrada, como el mouse, el panel táctil, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el panel táctil multitáctil, pueden admitir interacciones táctiles falsas. Android incluye la función constante android.hardware.faketouch, que corresponde a un dispositivo de entrada de alta fidelidad no táctil (basado en puntero), como un mouse o un panel táctil que puede emular de forma adecuada una entrada táctil (incluida la compatibilidad básica con gestos), e indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil. Las implementaciones de dispositivos que declaran la función táctil falsa DEBEN cumplir con los requisitos de la función táctil falsa de la sección 7.2.5.

Las implementaciones del dispositivo DEBEN informar la función correcta en relación con el tipo de entrada usada. Las implementaciones de dispositivos que incluyen una pantalla táctil (de un solo toque o mejor) DEBEN informar que la plataforma presenta la función android.hardware.touchscreen constante. Las implementaciones de dispositivos que informan la función constante android.hardware.touchscreen también DEBEN informar la constante de la función android.hardware.faketouch de la plataforma. Las implementaciones de dispositivos que no incluyen una pantalla táctil (y solo dependen de un dispositivo puntero) NO DEBEN informar ninguna función de pantalla táctil, y solo DEBEN informar android.hardware.faketouch si cumplen con los requisitos de entradas táctiles falsas de la sección 7.2.5.

7.2.5. Entrada táctil falsa

Implementaciones de dispositivos que declaran la compatibilidad con android.hardware.faketouch:

  • DEBE informar las posiciones X e Y absolutas de la pantalla de la ubicación del puntero y mostrar un puntero visual en la pantalla.
  • DEBE informar un evento táctil con el código de acción que especifica el cambio de estado que se produce cuando el puntero hacia abajo o hacia arriba en la pantalla.
  • DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios emular el toque en un objeto en pantalla.
  • DEBE admitir el puntero hacia abajo, hacia arriba, hacia abajo y, luego, hacia arriba en el mismo lugar de un objeto en la pantalla dentro de un límite de tiempo, lo que permite a los usuarios emular presionar dos veces en un objeto en pantalla.
  • DEBE admitir el puntero hacia abajo en un punto arbitrario de la pantalla, el cursor se mueve a cualquier otro punto arbitrario en la pantalla y el puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
  • DEBE admitir el puntero hacia abajo y, luego, permitir a los usuarios mover rápidamente el objeto a una posición diferente en la pantalla y, luego, apuntar hacia arriba en la pantalla, lo que permite a los usuarios deslizar un objeto en la pantalla.

Los dispositivos que declaran compatibilidad con android.hardware.faketouch.multitouch.distinct DEBEN cumplir con los requisitos de faketouch anteriores, y también DEBEN admitir un seguimiento distinto de dos o más entradas de puntero independientes.

7.2.6. Compatibilidad con controles de juegos

Las implementaciones de dispositivos de televisión de Android DEBEN admitir asignaciones de botones para controles de juegos, como se indica a continuación. La implementación ascendente de Android incluye una implementación para controles de juegos que cumple con este requisito.

7.2.6.1. Asignaciones de botones

Las implementaciones en dispositivos de Android Television DEBEN admitir las siguientes asignaciones de claves:

Botón Uso de HID2 Botón de Android
R 1 0x09 0x0001. KEYCODE_BUTTON_A (96)
B 1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X 1 0x090x0004. KEYCODE_BUTTON_X (99)
A 1 0x090x0005. KEYCODE_BUTTON_Y (100)
Pad direccional arriba 1
Pad direccional abajo 1 		0x01 0x0039 3 AXIS_HAT_Y 4
Pad direccional izquierdo 1
Pad direccional derecho 1 		0x01 0x0039 3 AXIS_HAT_X 4
Botón del hombro izquierdo 1 0x090x0007. KEYCODE_BUTTON_L1 (102)
Botón del hombro derecho 1 0x09 0x0008. KEYCODE_BUTTON_R1 (103)
Clic con la palanca izquierda 1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Hacer clic con el botón derecho del mouse 1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Página principal 1 0x0c 0x0223 KEYCODE_HOME (3)
Atrás 1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores se deben declarar en una CA de pad para juegos (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 del informe de 4. El valor lógico se define como la rotación en el sentido de las manecillas 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 Arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionan las teclas Arriba y la izquierda.

4 MotionEvent

Controles analógicos1 Uso de HID Botón de Android
Activador izquierdo 0x02 0x00C5 AXIS_LTRIGGER
Activador derecho 0x02 0x00C4 AXIS_RTRIGGER
Joystick izquierdo 0x01 0x0030
0x01 0x0031 		AXIS_X
EJE_Y
Joystick derecho 0x01 0x0032
0x01 0x0035. 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Control remoto

Las implementaciones de dispositivos de televisión para Android DEBEN proporcionar un control remoto para permitir que los usuarios accedan a la interfaz de la TV. El control remoto PUEDE ser un control remoto físico o basado en software al que se puede acceder desde un teléfono celular o una tablet. El control remoto DEBE cumplir con los requisitos que se definen a continuación.

7.3 Sensores

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

  • DEBE informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager.
  • DEBE mostrar una lista precisa de los sensores compatibles mediante SensorManager.getSensorList() y métodos similares.
  • DEBE comportarse de manera razonable para todas las demás API de sensores (por ejemplo, mostrar verdadero o falso según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamar a objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etc.).
  • SE DEBE informar todas las mediciones de los sensores con los valores correspondientes del sistema internacional de unidades (métricas) para cada tipo de sensor, como se define en la documentación del SDK de Android.
  • SE DEBE informar la hora del evento en nanosegundos, como se define en la documentación del SDK de Android, que representa la hora en que ocurrió el evento y se sincronizó con el reloj SystemClock.elapsedRealtimeNano(). Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma, en las que se podría convertir en un componente OBLIGATORIO. El error de sincronización DEBE ser inferior a 100 milisegundos.
  • DEBE informar los datos del sensor con una latencia máxima de 100 milisegundos + 2 * sample_time para el caso de un sensor transmitido con una latencia mínima requerida de 5 ms + 2 * sample_time cuando el procesador de la aplicación está activo. Esta demora no incluye ninguna demora en el filtrado.
  • DEBE informar la primera muestra del sensor dentro de los 400 milisegundos + 2 * sample_time de la activación del sensor. La exactitud aceptable de esta muestra es 0.

La lista anterior no es exhaustiva. el comportamiento documentado del SDK de Android y la Documentación de código abierto de Android sobre sensors debe considerarse autoritario.

Algunos tipos de sensores son compuestos, lo que significa que pueden derivarse de los datos proporcionados por uno o más sensores. (algunos 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 necesarios, como se describe en los tipos de sensores. Si la implementación de un dispositivo incluye un sensor compuesto, DEBE hacerlo tal como se describe en la documentación de código abierto de Android sobre sensores compuestos.

Algunos sensores de Android admiten un modo de activación "continuo", que muestra datos de manera continua. Para que cualquier API indicada en la documentación del SDK de Android sea un sensor continuo, las implementaciones de dispositivos DEBEN proporcionar continuamente muestras de datos periódicas que DEBEN tener un jitter inferior al 3%, en el que el jitter se define como la desviación estándar de la diferencia de los valores de marca de tiempo informados entre eventos consecutivos.

Ten en cuenta que las implementaciones del dispositivo DEBEN asegurarse de que la transmisión de eventos del sensor NO DEBE evitar que la CPU del dispositivo entre en un estado de suspensión ni se active después de un estado de suspensión.

Por último, cuando se activan varios sensores, el consumo de energía NO DEBE superar la suma del consumo de energía informado del sensor individual.

7.3.1. Acelerómetro

Las implementaciones en dispositivos DEBEN incluir un acelerómetro de 3 ejes. SE RECOMIENDA ENcarecidamente que los dispositivos de mano Android, las implementaciones de Android Automotive y los dispositivos Android Watch incluyan este sensor. Si la implementación de un dispositivo incluye un acelerómetro de 3 ejes, hará lo siguiente:

  • DEBE implementar y, luego, informar el sensor TYPE_ACCELEROMETER.
  • DEBE ser capaz de informar eventos con una frecuencia de al menos 50 Hz para los dispositivos Android Watch, ya que estos tienen una restricción de energía más estricta y de 100 Hz para todos los demás tipos de dispositivos.
  • SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.
  • DEBE cumplir con el sistema de coordenadas de sensores de Android, como se detalla en las APIs de Android. Las implementaciones de Android Automotive DEBEN cumplir con el sistema de coordenadas de sensores de vehículos de Android.
  • DEBE ser capaz de medir desde caída libre hasta cuatro veces la gravedad (4g) o más en cualquier eje.
  • DEBE tener una resolución de al menos 12 bits y DEBE tener una resolución de al menos 16 bits.
  • SE DEBE calibrar mientras está en uso si las características cambian durante el ciclo de vida y se compensan, y se conservan los parámetros de compensación entre los reinicios del dispositivo.
  • SE DEBE compensar la temperatura.
  • DEBE tener una desviación estándar no superior a 0.05 m/s^, en la que la desviación estándar se debe calcular por eje en las muestras recopiladas durante un período de al menos 3 segundos a la tasa de muestreo más rápida.
  • SE DEBE implementar los sensores compuestos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER como se describe en el documento del SDK de Android. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos implementen el sensor compuesto TYPE_SIGNIFICANT_MOTION. Si se implementa alguno de estos sensores, la suma de su consumo de energía DEBE ser siempre inferior a 4 mW y cada uno DEBE ser inferior a 2 mW y 0.5 mW cuando el dispositivo está en condiciones dinámicas o estáticas.
  • Si se incluye un sensor giroscopio, DEBES implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION, y DEBE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR. Se RECOMIENDA ENERGAR DISPOSITIVOS Android existentes y nuevos para implementar el sensor TYPE_GAME_ROTATION_VECTOR.
  • DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluyen un sensor de giroscopio y un sensor de magnetómetro.

7.3.2. Magnetómetro

Las implementaciones en dispositivos DEBEN incluir un magnetómetro de 3 ejes (brújula). Si el dispositivo incluye un magnetómetro de 3 ejes, significa que:

  • SE DEBE implementar el sensor TYPE_MAGNETIC_FIELD y también DEBES implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. Se RECOMIENDA ENERGMENTE la implementación del sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED en los dispositivos Android existentes y nuevos.
  • SE DEBE poder informar eventos con una frecuencia de al menos 10 Hz y SE DEBE informar hasta un mínimo de 50 Hz.
  • DEBE cumplir con el sistema de coordenadas de sensores de Android, como se detalla en las APIs de Android.
  • 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 resistente inferior a 700 μT y SE DEBE tener un valor inferior a 200 μT. Para ello, coloca el magnetómetro lejos de los campos magnéticos dinámicos (inducidos por la corriente) y estáticos (inducidos por imán).
  • DEBE tener una resolución igual o superior a 0.6 μT y SE DEBE tener una resolución igual o superior a 0.2 μT.
  • SE DEBE compensar la temperatura.
  • DEBE admitir la calibración en línea y la compensación del sesgo de hierro resistente, y conservar los parámetros de compensación entre los reinicios del dispositivo.
  • SE DEBE aplicar la compensación de hierro suave: la calibración se puede realizar mientras se usa o durante la producción del dispositivo.
  • SE RECOMIENDA tener una desviación estándar, calculada por eje, en muestras recopiladas durante un período de al menos 3 segundos con la tasa de muestreo más rápida, no superior a 0.5 μT.
  • DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluyen un sensor acelerómetro y un sensor de giroscopio.
  • PUEDE implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR si también se implementa un sensor 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 en el modo por lotes a 10 Hz.

7.3.3. GPS

Las implementaciones en dispositivos DEBEN incluir un receptor GPS/GNSS. Si la implementación de un dispositivo incluye un receptor de GPS/GNSS e informa la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps:

  • Se recomienda encarecidamente que el dispositivo siga proporcionando salidas de GPS/GNSS normales a las aplicaciones durante una llamada telefónica de emergencia y que la salida de ubicación no se bloquee durante una llamada de emergencia.
  • DEBE admitir salidas de ubicación a una tasa de al menos 1 Hz cuando se solicita a través de LocationManager#requestLocationUpdate .
  • DEBE ser capaz de determinar la ubicación en condiciones a cielo abierto (señales fuertes, insignificantes de ruta múltiple, HDOP < 2) en un plazo de 10 segundos (tiempo rápido para la primera corrección), cuando se conecta a una conexión a Internet de velocidad de datos de 0.5 Mbps o superior. Por lo general, este requisito se cumple con algún tipo de técnica de GPS/GNSS asistido o previsto para minimizar el tiempo de bloqueo del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y la efeméris/reloj del satélite).
    • Después de realizar ese cálculo de ubicación, se RECOMIENDA QUE el dispositivo pueda determinar su ubicación a cielo abierto en un plazo de 10 segundos, cuando se reinicien las solicitudes de ubicación, hasta una hora después del cálculo de ubicación inicial, incluso cuando la solicitud posterior se realice sin una conexión de datos o después de un reinicio.
  • En condiciones a cielo abierto después de determinar la ubicación, mientras estás detenido o en movimiento a menos de 1 metro por segundo al cuadrado de aceleración:
    • DEBE poder determinar la ubicación dentro de los 20 metros y la velocidad dentro de los 0.5 metros por segundo, al menos el 95% del tiempo.
    • DEBE realizar un seguimiento y, también, informar simultáneamente a través de GnssStatus.Callback al menos 8 satélites de una constelación.
    • DEBERÍA hacer un seguimiento simultáneo de al menos 24 satélites de múltiples constelaciones (por ejemplo, GPS +, al menos, uno de los objetos Glonass, BeiDou, Galileo).
  • DEBE informar la generación de tecnología de GNSS a través de la API de prueba “getGnssYearOfHardware”.
  • SE RECOMIENDA COMPLETAMENTE cumplir con todos los requisitos que se indican a continuación si la generación de tecnología de GNSS se informa como el año “2016” o una más reciente.
    • DEBE informar las mediciones de GPS, tan pronto como se encuentran, aunque todavía no se haya informado una ubicación calculada a partir del GPS/GNSS.
    • DEBE informar pseudorrangos y velocidades de pseudorrango de GPS que, en condiciones de cielo abierto después de determinar la ubicación, mientras se encuentra detenido o en movimiento con menos de 0.2 metros por segundo de aceleración, son suficientes para calcular la posición dentro de 20 metros y la velocidad dentro de 0.2 metros por segundo, al menos el 95% del tiempo.

Ten en cuenta que, si bien algunos de los requisitos de GPS anteriores se indican como MUY RECOMENDADOS, se espera que la definición de compatibilidad de la próxima versión principal los cambie por una DEBE.

7.3.4. Giroscopio

Las implementaciones en dispositivos 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 la implementación de un dispositivo incluye un giroscopio, hará lo siguiente:

  • SE DEBE implementar el sensor TYPE_GYROSCOPE y también SE DEBE implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED. Se RECOMIENDA ENERGMENTE la implementación del sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED en los dispositivos Android existentes y nuevos.
  • DEBE ser capaz de medir los cambios de orientación de hasta 1,000 grados por segundo.
  • DEBE ser capaz de informar eventos con una frecuencia de al menos 50 Hz para los dispositivos Android Watch, ya que estos tienen una restricción de energía más estricta y de 100 Hz para todos los demás tipos de dispositivos.
  • SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.
  • DEBE tener una resolución de 12 bits o más y DE 16 bits o más.
  • DEBE compensar la temperatura.
  • SE DEBE calibrar y compensar durante el uso, además de conservar los parámetros de compensación entre los reinicios del dispositivo.
  • DEBE tener una varianza no superior a 1e-7 rad^2 / s^2 por Hz (varianza por Hz o rad^2 / s). Se permite que la varianza varíe con la tasa de muestreo, pero debe limitarse por este valor. En otras palabras, si mides la varianza del giroscopio a una tasa de muestreo de 1 Hz, no debería ser superior a 1e-7 rad^2/s^2.
  • DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluyen un sensor acelerómetro y un sensor magnetómetro.
  • Si se incluye un sensor acelerómetro, DEBES implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION, y DEBERÍA implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR. SE RECOMIENDA ENERGAR DISPOSITIVOS Android existentes y nuevos para implementar el sensor TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barómetro

Las implementaciones en dispositivos DEBEN incluir un barómetro (sensor de presión de aire ambiental). Si la implementación de un dispositivo incluye un barómetro, hará lo siguiente:

  • SE DEBE implementar e informar el sensor TYPE_PRESSURE.
  • DEBE ser capaz de transmitir eventos a 5 Hz o más.
  • DEBE tener una precisión adecuada para permitir la estimación de la altitud.
  • DEBE compensar la temperatura.

7.3.6. Termómetro

Las implementaciones del dispositivo PUEDEN incluir un termómetro de ambiente (sensor de temperatura). Si está presente, DEBE definirse como SENSOR_TYPE_AMBIENT_TEMPERATURE y DEBE medir la temperatura ambiente (de la habitación) en grados Celsius.

PUEDEN POSIBLES implementaciones en dispositivos, pero NO DEBEN incluir un sensor de temperatura de la CPU. Si está presente, DEBE definirse como SENSOR_TYPE_TEMPERATURE, se DEBE medir la temperatura de la CPU del dispositivo y NO DEBE medir ninguna otra. Ten en cuenta que el tipo de sensor SENSOR_TYPE_TEMPERATURE dejó de estar disponible en Android 4.0.

En el caso de las implementaciones de Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE DEBE medir la temperatura dentro de la cabina del vehículo.

7.3.7. Fotómetro

Las implementaciones del dispositivo PUEDEN incluir un fotómetro (sensor de luz ambiente).

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 diferente de PHONE_TYPE_NONE en getPhoneType DEBEN incluir un sensor de proximidad. Si la implementación de un dispositivo incluye un sensor de proximidad, hará lo siguiente:

  • 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 cercanos a la pantalla, ya que la intención principal de este tipo de sensor es detectar un teléfono en uso por el usuario. Si la implementación de un dispositivo incluye un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API.
  • DEBE tener 1 bit de precisión o más.

7.3.9. Sensores de alta fidelidad

Las implementaciones de dispositivos que admiten un conjunto de sensores de mayor calidad que pueden cumplir con todos los requisitos enumerados en esta sección DEBEN identificar la compatibilidad a través de la marca de función android.hardware.sensor.hifi_sensors.

Un dispositivo que declara android.hardware.sensor.hifi_sensors DEBE admitir los siguientes tipos de sensores que cumplen con los requisitos de calidad que se indican a continuación:

  • TIPO_DE_SENSOR_ACCELEROMETER
    • DEBE tener un rango de medición entre -8 g y +8 g.
    • DEBE tener una resolución de medición de al menos 1024 LSB/G.
    • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 400 uG/√ Hz.
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 3,000 eventos de sensores.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 3 mW.
    • SE DEBE tener una estabilidad de sesgo de ruido estacionario de \<15 μg √Hz a partir de un conjunto de datos estático de 24 horas.
    • SE RECOMIENDA tener un cambio de sesgo respecto a la temperatura de ≤ +/- 1 mg / °C.
    • SE RECOMIENDA tener una no linealidad de la línea que mejor se ajuste a ≤ 0.5% y un cambio de sensibilidad en comparación con la temperatura de ≤ 0.03%/C°.

  • TIPO_DE_SENSOR_GYROSCOPE

    • DEBE tener un rango de medición de al menos -1,000 y +1,000 dps.
    • DEBE tener una resolución de medición de al menos 16 LSB/dps.
    • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 0.014 °/s/√ Hz.
    • SE DEBE tener una estabilidad de sesgo estacionaria de < 0.0002 °/s √ Hz a partir de un conjunto de datos estático de 24 horas.
    • SE RECOMIENDA tener un cambio de sesgo respecto a la temperatura de ≤ +/- 0.05 °/ s / °C.
    • SE RECOMIENDA cambiar la sensibilidad frente a la temperatura de ≤ 0.02% / °C.
    • SE DEBE tener una no linealidad de la línea más adecuada de ≤ 0.2%.
    • SE DEBE tener una densidad de ruido igual o superior a ≤ 0.007 °/s/√ Hz.

  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED con los mismos requisitos de calidad que SENSOR_TYPE_GYROSCOPE.

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • DEBE tener un rango de medición de al menos -900 y +900 uT.
    • DEBE tener una resolución de medición de al menos 5 LSB/uT.
    • DEBE tener una frecuencia de medición mínima de 5 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 50 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 0.5 uT.
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que SENSOR_TYPE_GEOMAGNETIC_FIELD y además:
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 600 eventos de sensores.
  • TIPO DE SENSOR DE PRESIÓN
    • DEBE tener un rango de medición de al menos 300 y 1,100 hPa.
    • DEBE tener una resolución de medición de al menos 80 LSB/hPa.
    • DEBE tener una frecuencia de medición mínima de 1 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 10 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 2 Pa/√Hz.
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 300 eventos de sensores.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 2 mW.
  • SENSOR_TYPE_GAME_ROTATION_VECTOR
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 300 eventos de sensores.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 4 mW.
  • TIPO_DE_SENSOR_SIGNIFICANT_MOTION
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
  • DETECTOR DE TIPO DE SENSOR
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 100 eventos de sensores.
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 4 mW.
  • SENSOR_TYPE_STEP_COUNTER
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
  • SENSOR_TILT_DETECTOR
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.

Además, ese dispositivo DEBE cumplir con los siguientes requisitos del subsistema del sensor:

  • La marca de tiempo del mismo evento físico que informan el acelerómetro, el sensor del giroscopio y el magnetómetro DEBE tener un máximo de 2.5 milisegundos de diferencia entre sí.
  • Las marcas de tiempo de eventos del sensor del giroscopio DEBEN estar en la misma base de tiempo que el subsistema de la cámara y dentro de 1 milisegundos desde el error.
  • Los sensores de alta fidelidad DEBEN enviar muestras a las aplicaciones en un plazo de 5 milisegundos desde el momento en que los datos están disponibles en el sensor físico de la aplicación.
  • El consumo de energía no DEBE ser superior a 0.5 mW cuando el dispositivo está estático y 2.0 mW cuando el dispositivo está en movimiento cuando se habilita cualquier combinación de los siguientes sensores:
    • TIPO_DE_SENSOR_SIGNIFICANT_MOTION
    • DETECTOR DE TIPO DE SENSOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

Ten en cuenta que todos los requisitos de consumo de energía de esta sección no incluyen el consumo de energía del procesador de aplicaciones. Incluye la energía que consume toda la cadena del sensor: el sensor, cualquier circuito de soporte, cualquier sistema de procesamiento de sensores dedicado, etcétera.

Los siguientes tipos de sensores también PUEDEN ser compatibles con una implementación de dispositivo que declare android.hardware.sensor.hifi_sensors, pero si estos tipos de sensores están presentes, DEBEN cumplir con el siguiente requisito mínimo de capacidad de almacenamiento en búfer:

  • SENSOR_TYPE_PROXIMITY: 100 eventos de sensores

7.3.10. Sensor de huellas dactilares

Las implementaciones en dispositivos con pantalla de bloqueo segura DEBEN incluir un sensor de huellas dactilares. Si la implementación de un dispositivo incluye un sensor de huellas dactilares y tiene una API correspondiente para desarrolladores externos, hará lo siguiente:

  • SE DEBE declarar la compatibilidad con la función android.hardware.fingerprint.
  • DEBE implementar completamente la API correspondiente como se describe en la documentación del SDK de Android.
  • DEBE tener una tasa de aceptación falsa no superior al 0.002%.
  • SE RECOMIENDA ENERGMENTE tener una tasa de rechazo falso inferior al 10%, según la medición del dispositivo
  • SE RECOMIENDA ENERGARSE que la latencia sea inferior a 1 segundo, medida desde el momento en que se toca el sensor de huellas dactilares hasta que se desbloquea la pantalla, para un dedo registrado.
  • DEBE limitar los intentos de frecuencia durante al menos 30 segundos después de cinco pruebas falsas para la verificación de huella digital.
  • DEBE tener una implementación de un almacén de claves con copia de seguridad en hardware y realizar la coincidencia de huellas digitales en un entorno de ejecución confiable (TEE) o en un chip con un canal seguro hacia el TEE.
  • Todos los datos identificables de huellas digitales deben estar encriptados y autenticados de manera criptográfica, de modo que no se puedan adquirir, leer ni modificar fuera del entorno de ejecución confiable (TEE) como se documenta en los lineamientos de implementación en el sitio del Proyecto de código abierto de Android.
  • DEBE evitar agregar una huella digital sin primero establecer una cadena de confianza. Para ello, se debe pedirle al usuario que confirme la credencial del dispositivo existente o que agregue una nueva (PIN, patrón o contraseña) protegida por el TEE. la implementación del Proyecto de código abierto de Android proporciona el mecanismo en el framework para hacerlo.
  • NO se DEBE permitir que las aplicaciones de terceros distingan entre huellas digitales individuales.
  • DEBE respetar la marca DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • Cuando se realiza la actualización desde una versión anterior a Android 6.0, SE DEBE migrar o quitar de manera segura los datos de la huella digital para cumplir con los requisitos anteriores.
  • SE DEBE usar el ícono de huella dactilar de Android que se proporciona en el Proyecto de código abierto de Android.

7.3.11. Sensores exclusivos de Android Automotive

Los sensores específicos de Automotive se definen en el android.car.CarSensorManager API .

7.3.11.1. Equipo actual

Las implementaciones de Android Automotive DEBEN proporcionar el equipo actual como SENSOR_TYPE_GEAR.

7.3.11.2. Modo noche día

Las implementaciones de Android Automotive DEBEN admitir el modo diurno/nocturno definido como SENSOR_TYPE_NIGHT. El valor de esta marca DEBE ser coherente con el modo diurno/nocturno del panel y DEBE basarse en la entrada del sensor de luz ambiente. Es posible que el sensor de luz ambiente subyacente sea el mismo que el Fotómetro.

7.3.11.3. Estado de la conducción

Las implementaciones de Android Automotive DEBEN admitir el estado de conducción definido como SENSOR_TYPE_DRIVING_STATUS, con un valor predeterminado de Drive_STATUS_UNRESTRICTED cuando el vehículo esté detenido y estacionado por completo. Es responsabilidad de los fabricantes de dispositivos configurar SENSOR_TYPE_DRIVING_STATUS en cumplimiento de todas las leyes y reglamentaciones que se apliquen a los mercados a los que se envía el producto.

7.3.11.4. Velocidad de las ruedas

Las implementaciones de Android Automotive DEBEN proporcionar la velocidad del vehículo definida como SENSOR_TYPE_CAR_SPEED.

7.3.12. Sensor de postura

Las implementaciones del dispositivo PUEDEN admitir el sensor de poses con 6 grados de libertad. Se RECOMIENDA que los dispositivos portátiles Android sean compatibles con este sensor. Si la implementación de un dispositivo admite el sensor de poses con 6 grados de libertad, hará lo siguiente:

  • SE DEBE implementar y, luego, informar el sensor TYPE_POSE_6DOF.
  • DEBE ser más preciso que el vector de rotación solo.

7.4. Conectividad de datos

7.4.1 Telefonía

El término "Telefonía", tal como utilizan las API de Android, y este documento hace referencia 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 cambiarse de paquetes, se usan para que Android se considere independientemente de cualquier conectividad de datos que se pueda implementar usando la misma red. En otras palabras, la funcionalidad y las APIs de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS NO DEBEN informar sobre la función android.hardware.telephony ni ninguna subfunción, independientemente de si usan una red móvil 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 la implementación de un dispositivo incluye telefonía GSM o CDMA, DEBE implementar compatibilidad total con la API para esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía DEBEN implementar las APIs completas como no-ops.

7.4.1.1. Compatibilidad con bloqueo de números

Las implementaciones en dispositivos de Telefonía de Android DEBEN incluir compatibilidad con el bloqueo de números y lo siguiente:

  • SE DEBE implementar por completo BlockedNumberContract y la API correspondiente, como se describe en la documentación del SDK.
  • DEBES bloquear todas las llamadas y los mensajes provenientes de un número de teléfono en "BlockedNumberProvider". sin ninguna interacción con las apps. La única excepción ocurre cuando se quita temporalmente el bloqueo de números, como se describe en la documentación del SDK.
  • NO DEBE escribir en el proveedor de registros de llamadas de la plataforma para una llamada bloqueada.
  • NO DEBE escribir al proveedor de telefonía para un mensaje bloqueado.
  • DEBES implementar una IU de administración de números bloqueados, que se abre con el intent que muestra el método TelecomManager.createManageBlockedNumbersIntent().
  • NO DEBE permitir que los usuarios secundarios vean o editen los números bloqueados en el dispositivo, ya que la plataforma de Android supone que el usuario principal tiene control total de los servicios de telefonía, una sola instancia, en el dispositivo. Todas las IU relacionadas con el bloqueo DEBEN estar ocultas para los usuarios secundarios, y la lista de entidades bloqueadas DEBE respetarse.
  • SE DEBE migrar los números bloqueados al proveedor cuando un dispositivo se actualiza a Android 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Todas las implementaciones en dispositivos Android DEBEN incluir compatibilidad con una o más formas de 802.11. Si la implementación de un dispositivo incluye compatibilidad con 802.11 y expone la funcionalidad a una aplicación de terceros, DEBE implementar la API de Android correspondiente y lo siguiente:

  • SE DEBE informar la marca de función de hardware android.hardware.wifi.
  • SE DEBE implementar la API de multicast como se describe en la documentación del SDK.
  • DEBE admitir DNS multicast (mDNS) y NO filtrar paquetes de mDNS (224.0.0.251) en ningún momento de la operación, lo que incluye:
    • incluso cuando la pantalla no esté activa.
    • Para implementaciones en dispositivos de Android Television, incluso en estados de energía en espera

7.4.2.1. Wi-Fi directo

Las implementaciones en dispositivos DEBEN incluir compatibilidad con Wi-Fi directo (Wi-Fi entre pares). Si la implementación de un dispositivo incluye compatibilidad con Wi-Fi directo, DEBE implementar la API de Android correspondiente, como se describe en la documentación del SDK. Si la implementación de un dispositivo incluye compatibilidad con Wi-Fi directo, sucederá lo siguiente:

  • SE DEBE informar la función de hardware android.hardware.wifi.direct.
  • DEBE admitir un funcionamiento normal de Wi-Fi.
  • SE RECOMIENDA admitir el funcionamiento simultáneo de Wi-Fi y Wi-Fi directo.

Las implementaciones en dispositivos DEBEN incluir compatibilidad con la Configuración de vínculo directo por túnel Wi-Fi (TDLS), como se describe en la Documentación del SDK de Android. Si la implementación de un dispositivo incluye compatibilidad con TDLS y TDLS, está habilitado por la API de WiFiManager, el dispositivo:

  • DEBE usar TDLS solo cuando sea posible Y beneficioso.
  • SE DEBE tener una heurística y NO usar TDLS cuando su rendimiento podría ser peor que el de pasar por el punto de acceso Wi-Fi.

7.4.3. Bluetooth

Las implementaciones de Android Watch DEBEN ser compatibles con Bluetooth. Las implementaciones de Android Television DEBEN ser compatibles con Bluetooth y Bluetooth LE. Las implementaciones de Android Automotive DEBEN admitir Bluetooth, y DEBEN admitir Bluetooth LE.

Las implementaciones de dispositivos que admiten la función android.hardware.vr.high_performance DEBEN ser compatibles con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE.

Android admite Bluetooth y Bluetooth de bajo consumo. Las implementaciones de dispositivos que incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo DEBEN declarar las funciones relevantes de la plataforma (android.hardware.Bluetooth y android.hardware.bluetooth_le respectivamente) e implementar las APIs de la plataforma. Las implementaciones en dispositivos DEBEN implementar perfiles de Bluetooth relevantes, como A2DP, AVCP, OBEX, etc., según corresponda para el dispositivo.

Las implementaciones de Android Automotive DEBEN admitir el perfil de acceso a los mensajes (MAP). Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles de Bluetooth:

  • Llamadas telefónicas a través del perfil de manos libres (HFP)
  • Reproducción de contenido multimedia a través del perfil de distribución de audio (A2DP)
  • Control de reproducción de contenido multimedia a través del perfil de control remoto (AVRCP).
  • Uso compartido de contactos mediante el perfil de acceso a la agenda telefónica (PBAP)

Implementaciones de dispositivos, incluida la compatibilidad con Bluetooth de bajo consumo:

  • SE DEBE declarar la función de hardware android.hardware.bluetooth_le.
  • DEBE habilitar las APIs de Bluetooth basadas en GATT (perfil de atributos genéricos) como se describe en la documentación del SDK y en android.bluetooth.
  • se recomienda implementar un tiempo de espera de dirección privada resolvable (RPA) de no más de 15 minutos y rotar la dirección en el tiempo de espera para proteger la privacidad del usuario.
  • SE DEBE admitir la transferencia de la lógica de filtrado al chipset de Bluetooth cuando se implementa la API de ScanFilter, y DEBE informar el valor correcto de dónde se implementa la lógica de filtrado cada vez que se realiza una consulta a través del método android.bluetooth.BluetoothAdapter.isOffloadingFilteringSupported().
  • SE DEBE admitir la transferencia del escaneo por lotes al chipset Bluetooth. Sin embargo, si no se admite, DEBE informar "false" cada vez que se realice una consulta a través del método android.bluetooth.BluetoothAdapter.isOffloadingScanBatchingSupported().
  • SE RECOMIENDA admitir anuncios múltiples con al menos 4 espacios. Sin embargo, si no se admite, DEBE informar "false" cada vez que se realice una consulta a través del método android.bluetooth.BluetoothAdapter.isMultipleAdvertisingmentSupported().

7.4.4. Comunicaciones de campo cercano

Las implementaciones en dispositivos DEBEN incluir un transceptor y el hardware relacionado para la comunicación de campo cercano (NFC). Si la implementación de un dispositivo incluye hardware NFC y planea que esté disponible para apps de terceros, entonces:

  • SE DEBE informar la función android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature().
  • DEBE ser capaz de leer y escribir mensajes NDEF a través de los siguientes estándares NFC:
    • DEBE ser capaz de actuar como lector/escritor de NFC Forum (según se define en la especificación técnica NFCForum-TS-DigitalProtocol-1.0 del foro de NFC) mediante los siguientes estándares de NFC:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS X 6319-4)
      • IsoDep (ISO 14443-4)
      • Tipos de etiquetas del foro de NFC 1, 2, 3 y 4 (definidas por NFC Forum)
    • SE RECOMIENDA SER capaz de leer y escribir mensajes NDEF, así como datos sin procesar, a través de los siguientes estándares NFC. Ten en cuenta que, si bien los estándares de NFC que se indican a continuación se indican como MUY RECOMENDADOS, se planea que la definición de compatibilidad para una versión futura cambie a DEBE. Estos estándares son opcionales en esta versión, pero serán obligatorios 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 versiones futuras de la plataforma.
      • NfcV (ISO 15693)
    • SE DEBE poder leer el código de barras y la URL (si están codificados) de los productos Thinfilm NFC Barcode.
    • DEBE ser capaz de transmitir y recibir datos a través de los siguientes estándares y protocolos entre pares:
      • ISO 18092
      • LLCP 1.2 (definida por el foro de NFC)
      • SDP 1.0 (definido por NFC Forum)
      • Protocolo NDEF Push
      • SNEP 1.0 (definido por NFC Forum)
    • DEBE incluir compatibilidad con Android Beam.
    • SE DEBE implementar el servidor predeterminado de SNEP. Los mensajes NDEF válidos recibidos por el servidor SNEP predeterminado DEBEN enviarse a las aplicaciones con el intent android.nfc.ACTION_NDEF_DISCOVERED. Inhabilitar Android Beam en la configuración NO DEBE inhabilitar el envío de mensajes NDEF entrantes.
    • DEBE respetar el intent android.settings.NFCSHARING_d
    • Se DEBE implementar el servidor NPP. Los mensajes recibidos por el servidor NPP DEBEN procesarse del mismo modo que el servidor predeterminado SNEP
    • SE DEBE implementar un cliente SNEP e intentar enviar P2P NDEF saliente al servidor SNEP predeterminado cuando Android Beam está habilitado. Si no se encuentra ningún servidor SNEP predeterminado, el cliente DEBE intentar enviar a un servidor NPP.
    • DEBE permitir que las actividades en primer plano configuren el mensaje NDEF P2P saliente usando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback y android.nfc.NfcAdapter.enableForegroundNdefPush.
    • SE DEBE usar un gesto o una confirmación en pantalla, como “Tocar para transmitir”, antes de enviar mensajes P2P NDEF salientes.
    • SE DEBE habilitar Android Beam de forma predeterminada y DEBE poder enviar y recibir mensajes con Android Beam, incluso cuando otro modo P2p NFC de propiedad está activado.
    • DEBE admitir el traspaso de la conexión NFC a Bluetooth cuando el dispositivo admite el perfil de envío de objetos Bluetooth. Las implementaciones de dispositivos DEBEN admitir el traspaso de la conexión a Bluetooth cuando se usa android.nfc.NfcAdapter.setBeamPushUris. Para ello, deben implementar las especificaciones “Connection Handover versión 1.2” y “Bluetooth Secure Simple Pairing Using NFC version 1.0” del foro de NFC. Dicha implementación DEBE implementar el servicio LLCP de traspaso con el nombre de servicio “urn:nfc:sn:handover” para intercambiar la solicitud de transferencia/seleccionar registros a través de NFC, y DEBE usar el perfil push de objetos Bluetooth para la transferencia de datos Bluetooth. Por motivos heredados (para seguir siendo compatible con dispositivos Android 4.1), la implementación DEBE aceptar solicitudes de SNEP GET para intercambiar la solicitud de transferencia o seleccionar registros a través de NFC. Sin embargo, una implementación por sí misma NO DEBE enviar solicitudes SNEP GET para realizar el traspaso de la conexión.
    • DEBE sondear todas las tecnologías compatibles mientras está en el modo de descubrimiento de NFC.
    • DEBES estar en el modo de descubrimiento de NFC mientras el dispositivo está activo con la pantalla activa y la pantalla bloqueada desbloqueada.

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

Android admite el modo de emulación de tarjeta de host NFC (HCE). Si la implementación de un dispositivo incluye un chipset del controlador NFC capaz de HCE (para NfcA o NfcB) y que admite el enrutamiento de ID de aplicación (AID), entonces:

  • SE DEBE informar la constante de la función android.hardware.nfc.hce.
  • DEBE admitir las APIs de NFC HCE según se define en el SDK de Android.

Si la implementación de un dispositivo incluye un chipset del controlador NFC capaz de HCE para NfcF y, luego, implementa la función para aplicaciones de terceros, entonces:

Además, las implementaciones en dispositivos PUEDEN incluir compatibilidad con lectores/escritores para las siguientes tecnologías MIFARE.

  • MIFARE clásica
  • MIFARE ultraligera
  • NDEF en MIFARE Classic

Ten en cuenta que Android incluye APIs para estos tipos de MIFARE. Si la implementación de un dispositivo admite MIFARE en el rol de lector/escritor, hace lo siguiente:

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

Si la 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() y DEBE implementar la API de NFC de Android como no-op.

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

7.4.5. Capacidad de red mínima

Las implementaciones del dispositivo DEBEN incluir compatibilidad con una o más formas de red de datos. Específicamente, las implementaciones en dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos con capacidad de 200 Kbit/s o superior. Algunos ejemplos de tecnologías que cumplen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet, número PAN Bluetooth, etcétera.

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

ES POSIBLE que los dispositivos implementen más de una forma de conectividad de datos.

Los dispositivos DEBEN incluir una pila de red IPv6 y admitir la comunicación IPv6 a través de las APIs administradas, como java.net.Socket y java.net.URLConnection , además de las APIs nativas, como los sockets AF_INET6. El nivel requerido de compatibilidad con IPv6 depende del tipo de red, de la siguiente manera:

  • Los dispositivos compatibles con redes Wi-Fi DEBEN admitir el funcionamiento de pila doble y solo IPv6 en Wi-Fi.
  • Los dispositivos compatibles con redes Ethernet DEBEN admitir el funcionamiento de pila doble en Ethernet.
  • Los dispositivos compatibles con datos móviles DEBEN admitir la operación de IPv6 (solo IPv6 y, posiblemente, de pila doble) en datos móviles.
  • Cuando un dispositivo se conecta simultáneamente a más de una red (p.ej., Wi-Fi y datos móviles), DEBE cumplir estos requisitos simultáneamente en cada red a la que esté conectado.

IPv6 DEBE estar habilitado de forma predeterminada.

Para garantizar que la comunicación IPv6 sea tan confiable como IPv4, los paquetes IPv6 de unidifusión enviados al dispositivo NO DEBEN perderse, incluso cuando la pantalla no esté en estado activo. Los paquetes IPv6 multidifusión redundantes, como los anuncios de router idénticos repetidos, PUEDEN tener una limitación de frecuencia en hardware o firmware si es necesario para ahorrar energía. En tales casos, el límite de frecuencia NO DEBE provocar que el dispositivo pierda la conectividad IPv6 en ninguna red compatible con IPv6 que utilice ciclos de vida con RA de al menos 180 segundos.

La conectividad IPv6 DEBE mantenerse en modo Descanso.

7.4.6. Configuración de sincronización

Las implementaciones en dispositivos DEBEN tener activada la sincronización automática de la instancia principal de forma predeterminada para que el método getMasterSyncAutomatically() muestre el valor “true”.

7.4.7. Ahorro de datos

SE RECOMIENDA ENERGAR implementaciones en dispositivos con una conexión de uso medido para proporcionar el modo de ahorro de datos.

Si la implementación de un dispositivo proporciona el modo de Ahorro de datos, hará lo siguiente:

  • SE DEBE admitir todas las APIs de la clase ConnectivityManager, como se describe en la documentación del SDK.

  • DEBE proporcionar una interfaz de usuario en la configuración que permita a los usuarios agregar aplicaciones a la lista de entidades permitidas o quitarlas de ella.

Por el contrario, si la implementación de un dispositivo no proporciona el modo de ahorro de datos, hará lo siguiente:

  • SE DEBE mostrar el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().

  • No se DEBE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

  • DEBE tener una actividad que controle el intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, pero PUEDE implementarla como una no-op.

7.5 Cámaras

Las implementaciones en dispositivos DEBEN incluir una cámara posterior y PUEDEN incluir una cámara frontal. Una cámara posterior es una cámara ubicada en el lado del dispositivo opuesto a la pantalla. es decir, captura escenas en el lado más alejado del dispositivo, como una cámara tradicional. La cámara frontal es aquella que está ubicada en el mismo lado del dispositivo que la pantalla. es decir, una cámara que generalmente se usa para generar imágenes del usuario, como para videoconferencias y aplicaciones similares.

Si la implementación de un dispositivo incluye al menos una cámara, DEBE ser posible que una aplicación asigne simultáneamente 3 mapas de bits RGBA_8888 igual al tamaño de las imágenes producidas por el sensor de la cámara de mayor resolución en el dispositivo, mientras la cámara está abierta para obtener una vista previa básica y capturar imágenes.

7.5.1 Cámara posterior

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

  • SE DEBE informar la marca de función android.hardware.camera y android.hardware.camera.any.
  • DEBE tener una resolución de al menos 2 megapíxeles.
  • SE DEBE tener un enfoque automático de hardware o uno de software implementado en el controlador de la cámara (transparente para el software de aplicación).
  • PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
  • PUEDE incluir un destello. Si la Cámara incluye flash, NO DEBE encenderse la lámpara de flash mientras se registra una instancia android.hardware.Camera.PreviewCallback en una superficie de vista previa de la Cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un objeto Camera.Parameters. Ten en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema integrada del dispositivo, sino solo a aplicaciones de terceros que usan Camera.PreviewCallback.

7.5.2. Cámara frontal

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

  • SE DEBE informar la marca de función android.hardware.camera.any y android.hardware.camera.front.
  • DEBE tener una resolución de, al menos, VGA (640 x 480 píxeles).
  • NO DEBES usar una cámara frontal de forma predeterminada para la API de Camera. La API de la cámara en Android tiene compatibilidad específica para cámaras frontales y las implementaciones de dispositivos NO DEBEN configurar la API para que trate a una cámara frontal como la cámara posterior 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 posteriores, según se describe en la sección 7.5.1.
  • DEBE reflejar horizontalmente (es decir, duplicar) la transmisión que muestra una aplicación en CameraPreview de la siguiente manera:
    • Si el usuario puede rotar la implementación del dispositivo (por ejemplo, automáticamente mediante un acelerómetro o de forma manual mediante una entrada del usuario), la vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación actual del dispositivo.
    • Si la aplicación actual solicitó explícitamente que se rote la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation(), la vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación especificada por la aplicación.
    • De lo contrario, la vista previa DEBE reflejarse en el eje horizontal predeterminado del dispositivo.
  • DEBE reflejar la imagen que muestra la imagen postview del mismo modo que la transmisión de imágenes de la vista previa de la cámara. Si la implementación del dispositivo no es compatible con la vista previa, es evidente que este requisito no se aplica.
  • NO DEBE duplicar la imagen estática capturada ni las transmisiones de video finales que se devuelven a las devoluciones de llamada de la aplicación ni las que se confirman en el almacenamiento de medios.

7.5.3 Cámara externa

Las implementaciones de dispositivos PUEDEN incluir compatibilidad con una cámara externa que no necesariamente está conectada siempre. Si un dispositivo admite una cámara externa, hará lo siguiente:

  • SE DEBE declarar las marcas de función de plataforma android.hardware.camera.external y android.hardware camera.any .
  • PUEDE admitir varias cámaras.
  • DEBE admitir la clase de video USB (UVC 1.0 o superior) si la cámara externa se conecta a través del puerto USB.
  • SE RECOMIENDA admitir compresiones de video como MJPEG para permitir la transferencia de transmisiones de alta calidad sin codificación (es decir, transmisiones de imagen sin procesar o comprimidas de forma independiente).
  • PUEDE admitir la codificación de video basada en la cámara. Si es compatible, la implementación del dispositivo DEBE poder acceder a una transmisión MJPEG o sin codificación simultánea (QVGA o superior resolución).

7.5.4. Comportamiento de la API de Camera

Android incluye dos paquetes de API para acceder a la cámara. La nueva API de android.hardware.camera2 expone el control de cámara de nivel inferior a la app, incluidos flujos eficientes de ráfaga o transmisión de copias cero y controles por fotograma de exposición, ganancia, ganancia de balance de blancos, conversión de color, reducción de ruido, nitidez, entre otros.

El paquete de API anterior, android.hardware.Camera, está marcado como obsoleto en Android 5.0. Sin embargo, como debería estar disponible para que las apps usen implementaciones en dispositivos Android, DEBE garantizar la compatibilidad continua de la API como se describe en esta sección y en el SDK de Android.

Las implementaciones en dispositivos DEBEN implementar los siguientes comportamientos para las API relacionadas con la cámara en todas las cámaras disponibles:

  • Si una aplicación nunca llamó a android.hardware.Camera.Parameters.setPreviewFormat(int), el dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para obtener los datos de vista previa que se proporcionan en las devoluciones de llamada de la aplicación.
  • Si una aplicación registra una instancia android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() cuando el formato de vista previa es YCbCr_420_SP, los datos del byte[] pasado a onPreviewFrame() deben estar, además, en el formato de codificación NV21. Es decir, NV21 DEBE ser el predeterminado.
  • Para android.hardware.Camera, las implementaciones en dispositivos DEBEN admitir el formato YV12 (como se indica con la constante android.graphics.ImageFormat.YV12) para las vistas previas de la cámara frontal y posterior. (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxeles nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
  • Para android.hardware.camera2, las implementaciones en dispositivos 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 en dispositivos DEBEN implementar la API de Camera completa incluida en la documentación del SDK de Android, independientemente de que el dispositivo incluya enfoque automático de hardware o alguna otra función. Por ejemplo, las cámaras sin enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no sea relevante para una cámara sin enfoque automático). Ten en cuenta que esto se aplica a las cámaras frontales. por ejemplo, aunque la mayoría de las cámaras frontales no admitan el enfoque automático, las devoluciones de llamada de la API se deben “simular” de todas formas, como se describe.

Las implementaciones en dispositivos DEBEN reconocer y respetar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters si el hardware subyacente admite la función Si el hardware del dispositivo no admite una función, la API debe comportarse según lo documentado. Por el contrario, las implementaciones de dispositivos NO DEBEN respetar 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 en dispositivos DEBEN admitir todos los parámetros estándar de Camera si el hardware lo permite, y NO DEBEN admitir tipos de parámetros personalizados de Camera. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes con técnicas de imágenes de alto rango dinámico (HDR) DEBEN admitir el parámetro de la cámara Camera.SCENE_MODE_HDR.

Como no todas las implementaciones de dispositivos pueden admitir todas las funciones de la API de android.hardware.camera2, estas DEBEN informar el nivel adecuado de compatibilidad con la propiedad android.info.supportedHardwareLevel como se describe en el SDK de Android y de las marcas de funciones del framework correspondientes.

Las implementaciones del dispositivo también DEBEN declarar las capacidades de la cámara individual de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar las marcas de función adecuadas. un dispositivo debe definir la marca de función si alguno de los dispositivos de cámara conectados admite la función.

Las implementaciones del dispositivo DEBEN transmitir el intent Camera.ACTION_NEW_PICTURE cada vez que la cámara toma una foto nueva y la entrada de la imagen se agrega a la tienda de contenido multimedia.

Las implementaciones del dispositivo DEBEN transmitir el intent Camera.ACTION_NEW_VIDEO cada vez que la cámara graba un video nuevo y la entrada de la imagen se agrega a la tienda de contenido multimedia.

7.5.5 Orientación de la cámara

Tanto la cámara frontal como la posterior, si están presentes, DEBEN orientarse de modo que la dimensión larga de la cámara se alinee con la dimensión larga de la pantalla. Es decir, cuando el dispositivo se mantiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo. es decir, se aplica a los dispositivos principales horizontales y verticales.

7.6 Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Los dispositivos Android Television DEBEN tener al menos 4 GB de almacenamiento no volátil disponible para datos privados de las aplicaciones.

La memoria disponible para el kernel y el espacio del usuario en las implementaciones del dispositivo DEBE ser al menos igual o mayor que los valores mínimos especificados en la siguiente tabla. (Consulta la sección 7.1.1 para ver las definiciones de densidad y tamaño de pantalla).

Densidad y tamaño de la pantalla Dispositivo de 32 bits Dispositivo de 64 bits
Dispositivos Android Watch (debido a las pantallas más pequeñas) 416MB No aplicable
  • 280 dpi o menos en pantallas pequeñas o normales
  • mdpi o inferior en pantallas grandes
  • ldpi o inferior en pantallas extragrandes
512 MB 816MB
  • xhdpi o superior en pantallas pequeñas o normales
  • hdpi o más alta en pantallas grandes
  • mdpi o superior en pantallas extragrandes
608MB 944MB
  • 400 dpi o más en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes
896MB 1,280 MB
  • 560 dpi o más en pantallas pequeñas o normales
  • 400 dpi o más en pantallas grandes
  • xhdpi o superior en pantallas extragrandes
1,344 MB 1,824 MB

Los valores mínimos de memoria DEBEN ser adicionales a cualquier espacio de memoria que ya esté dedicado a componentes de hardware, como radio, video, etc., que no esté bajo el control del kernel.

Implementaciones de dispositivos con menos de 512 MB de memoria disponible para el kernel y el espacio del usuario (a menos que se use un Android Watch), DEBEN mostrar el valor "true" para ActivityManager.isLowRamDevice().

Los dispositivos Android Television DEBEN tener 4 GB como mínimo, y otras implementaciones de dispositivos DEBEN tener al menos 3 GB de almacenamiento no volátil disponible para datos privados de la aplicación. Es decir, la partición /data DEBE ser de al menos 4 GB para los dispositivos de televisión de Android y de al menos 3 GB para otras implementaciones de dispositivos. SE RECOMIENDA ENRENDER que las implementaciones en dispositivos que ejecutan Android tengan al menos 4 GB de almacenamiento no volátil para datos privados de las aplicaciones, de modo que puedan actualizarse a las versiones futuras de la plataforma.

Las API de Android incluyen un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos. La implementación del Administrador de descargas DEBE poder descargar archivos individuales de al menos 100 MB de tamaño en la ubicación predeterminada de “caché”.

7.6.2. Almacenamiento compartido de la aplicación

Las implementaciones en dispositivos DEBEN ofrecer almacenamiento compartido para las aplicaciones que también suelen denominarse “almacenamiento externo compartido”.

Las implementaciones en dispositivos DEBEN configurarse con el almacenamiento compartido activado de forma predeterminada y “listo para usar”. Si el almacenamiento compartido no está activado en la ruta de Linux /sdcard, el dispositivo DEBE incluir un vínculo simbólico de Linux desde /sdcard hasta el punto de activación real.

Las implementaciones de dispositivos PUEDEN tener hardware para un almacenamiento extraíble accesible para el usuario, como una ranura de tarjeta Secure Digital (SD). Si esta ranura se usa para cumplir con el requisito de almacenamiento compartido, la implementación del dispositivo hará lo siguiente:

  • DEBE implementar un aviso o una interfaz de usuario emergente que advierta al usuario cuando no hay una tarjeta SD.
  • DEBE incluir una tarjeta SD con formato FAT de 1 GB o más, O mostrar en la caja y otro material disponible en el momento de la compra que se deba comprar por separado.
  • SE DEBE activar la tarjeta SD de forma predeterminada.

Como alternativa, las implementaciones en dispositivos PUEDEN asignar almacenamiento interno (no extraíble) como almacenamiento compartido para las apps, tal como se incluye en el Proyecto de código abierto de Android ascendente. implementaciones de dispositivos DEBEN usar esta configuración e implementación de software. Si la implementación de un dispositivo utiliza almacenamiento interno (no extraíble) para cumplir con el requisito de almacenamiento compartido, mientras que ese almacenamiento PUEDE compartir espacio con los datos privados de la aplicación, DEBE tener al menos 1 GB y estar activado en /sdcard (o /sdcard DEBE ser un vínculo simbólico a la ubicación física si está montado en otro lugar).

Las implementaciones en dispositivos DEBEN ejecutar el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido de manera forzosa, según se documenta. De lo contrario, la aplicación que obtenga ese permiso DEBE poder escribir en el almacenamiento compartido.

Las implementaciones de dispositivos que incluyen varias rutas de acceso de almacenamiento compartido (como una ranura para tarjeta SD y un almacenamiento interno compartido) DEBEN permitir aplicaciones instaladas previamente y aplicaciones para Android privilegiadas con el permiso WRITE_EXTERNAL_STORAGE para escribir en el almacenamiento externo secundario, excepto cuando se escriben en sus directorios específicos del paquete o dentro del URI que se muestra cuando se activa el intent ACTION_OPEN_DOCUMENT_TREE.

Sin embargo, las implementaciones en dispositivos DEBEN exponer el contenido de ambas rutas de almacenamiento de forma transparente a través del servicio de escáner de contenido multimedia de Android y android.provider.MediaStore.

Independientemente de la forma de almacenamiento compartido utilizado, si la implementación del dispositivo tiene un puerto USB compatible con el modo periférico USB, DEBE proporcionar algún mecanismo para acceder al contenido del almacenamiento compartido desde una computadora host. Las implementaciones del dispositivo PUEDEN usar almacenamiento masivo USB, pero DEBEN utilizar el Protocolo de transferencia de medios para cumplir con este requisito. Si la implementación de dispositivos admite el Protocolo de transferencia de medios, hará lo siguiente:

  • DEBE ser compatible con el host de MTP de Android de referencia, Android File Transfer.
  • SE DEBE informar una clase de dispositivo USB de 0x00.
  • SE DEBE informar que la interfaz USB es "MTP".

7.6.3. Almacenamiento adoptable

SE RECOMIENDA LAS implementaciones en dispositivos para implementar el almacenamiento adoptable si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimento de la batería o alguna otra cubierta protectora.

Las implementaciones en dispositivos, como una televisión, PUEDEN permitir la adopción a través de puertos USB, ya que se espera que el dispositivo sea estático y no móvil. Sin embargo, en el caso de otras implementaciones de dispositivos de naturaleza móvil, se recomienda encarecidamente implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlas accidentalmente puede causar pérdida o corrupción de datos.

7.7 USB

Las implementaciones en dispositivos DEBEN admitir el modo de periférico USB y el modo de host USB.

7.7.1 Modo periférico USB

Si la implementación de un dispositivo incluye un puerto USB que admite el modo periférico:

  • El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
  • El puerto DEBE usar el factor de forma de USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
  • El puerto DEBE ubicarse en la parte inferior del dispositivo (según la orientación natural) o permitir la rotación de la pantalla del software para todas las apps (incluida la pantalla principal), de modo que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
  • DEBE permitir que un host USB conectado con el dispositivo Android acceda al contenido del volumen de almacenamiento compartido usando el almacenamiento masivo USB o el Protocolo de transferencia multimedia.
  • DEBE implementar la API de Android Open Accessory (AOA) y la especificación tal como se documenta en la documentación del SDK de Android. Si se trata de un dispositivo portátil de Android, DEBE implementar la API de AOA. Implementaciones de dispositivos que implementan la especificación de AOA:
    • SE DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.accessory.
    • Se DEBE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
    • La clase de almacenamiento masivo USB DEBE incluir la cadena "android". al final de la cadena de descripción de la interfaz iInterface del almacenamiento masivo USB
  • DEBE implementar la compatibilidad para extraer 1.5 A de corriente durante los pitidos y el tráfico de HS, como se especifica en la especificación de la carga de batería USB, revisión 1.2. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
  • Los dispositivos tipo C DEBEN detectar los cargadores de 1.5 A y 3.0 A según el estándar de resistencia tipo C, y deben detectar cambios en el anuncio.
  • Se RECOMIENDA ENERGAR que los dispositivos tipo C que también admiten el modo host USB sean compatibles con Power Delivery para el intercambio de datos y funciones de energía.
  • Los dispositivos Tipo C DEBEN admitir Power Delivery para la carga de alto voltaje y admitir modos alternativos, como visualización de salida.
  • El valor de iSerialNumber en el descriptor de dispositivo estándar USB DEBE ser igual al valor de android.os.Build.SERIAL.
  • Se recomienda que los dispositivos tipo C no sean compatibles con métodos de carga patentados que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o que alteren los roles de receptor o fuente, por lo que podrían generar problemas de interoperabilidad con cargadores o dispositivos compatibles con los métodos estándar de USB Power Delivery. Si bien se dice que esto se recomienda encarecidamente, en versiones futuras de Android es posible que REQUISITOS que todos los dispositivos tipo C sean compatibles con una interoperabilidad completa con cargadores tipo C estándar.

7.7.2. Modo de host USB

Si la implementación de un dispositivo incluye un puerto USB compatible con el modo de host, hará lo siguiente:

  • SE DEBE usar un puerto USB tipo C si la implementación del dispositivo es compatible con USB 3.1.
  • PUEDE utilizar un factor de forma de puerto no estándar, pero, de ser así, DEBES enviarlo con un cable o cables que adapten el puerto a un puerto USB estándar tipo A o tipo C.
  • PUEDES utilizar un puerto USB micro-AB, pero, de ser así, DEBERÍAS enviarlo con uno o varios cables que adapten el puerto a un puerto USB estándar tipo A o tipo C.
  • se RECOMIENDA ENRENDER para implementar la clase de audio USB según se indica en la documentación del SDK de Android.
  • DEBE implementar la API del host de USB de Android como se documenta en el SDK de Android y DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.host.
  • DEBE admitir la carga del dispositivo mientras se está en modo de host. Anunciar una corriente de origen de, al menos, 1.5 A, como se especifica en la sección Parámetros de terminación de [Revisión 1.2 de la especificación del cable y del conector USB tipo C] (http://www.usb.org/developers/docs/usb_31_021517.zip) para los conectores USB tipo C o mediante el uso de las especificaciones de los conectores de carga USB tipo C o el de salida de los puertos de carga USB(CDP) para el rango actual de salidas de los puertos de carga USB y de microcarga, según lo especificado en las especificaciones de la revisión de la batería USB2
  • Se RECOMIENDA que los dispositivos USB tipo C sean compatibles con DisplayPort, DEBEN ser compatibles con las tasas de datos de SuperSpeed de USB, y SE RECOMIENDA ENERCMENTE para admitir Power Delivery para el intercambio de datos y funciones de potencia.
  • Los dispositivos con cualquier puerto tipo A o tipo AB NO DEBEN enviarse con un adaptador que convierta este puerto a un receptáculo tipo C.
  • DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia de medios) conectado de forma remota y permitir el acceso a su contenido a través de los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT, si se admite el framework de acceso al almacenamiento (SAF).
  • DEBES, si usas un puerto USB tipo C e incluyes compatibilidad con el modo periférico, debes implementar la funcionalidad del puerto de rol dual según se define en la especificación de USB tipo C (sección 4.5.1.3.3).
  • SE DEBE implementar el modelo Try.* que sea más apropiado para el factor de forma del dispositivo si se admite la funcionalidad Doble función Puerto. Por ejemplo, un dispositivo de mano DEBE implementar el modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

Las implementaciones de Android Handheld, Watch y Automotive DEBEN incluir un micrófono.

Las implementaciones en dispositivos PUEDEN omitir un micrófono. Sin embargo, si la implementación de un dispositivo omite un micrófono, NO DEBE informar la constante de la función android.hardware.microphone, y DEBE implementar la API de grabación de audio al menos como no-ops, de acuerdo con la sección 7. Por el contrario, las implementaciones en dispositivos que sí poseen un micrófono hacen lo siguiente:

  • SE DEBE informar la constante de función android.hardware.microphone.
  • DEBE cumplir con los requisitos de grabación de audio de la sección 5.4.
  • DEBE cumplir con los requisitos de latencia de audio de la sección 5.6.
  • SE RECOMIENDA COMPLETAMENTE la compatibilidad con la grabación casi ultrasónica, como se describe en la sección 7.8.3.

7.8.2. Salida de audio

Los dispositivos Android Watch PUEDEN incluir una salida de audio.

Implementaciones de dispositivos que incluyen un altavoz o un puerto de salida de audio/multimedia para un periférico de salida de audio, como auriculares o una bocina externa:

  • SE DEBE informar la constante de la función android.hardware.audio.output.
  • DEBE cumplir con los requisitos de reproducción de audio de la sección 5.5.
  • DEBE cumplir con los requisitos de latencia de audio de la sección 5.6.
  • SE RECOMIENDA ENCENDERMENTE la compatibilidad con la reproducción casi ultrasónica, como se describe en la sección 7.8.3.

Por el contrario, si la implementación de un dispositivo no incluye una bocina o un puerto de salida de audio, NO DEBE informar la función de salida android.hardware.audio y, al menos, DEBE implementar las APIs relacionadas con la salida de audio como no-ops.

La implementación de dispositivos de Android Watch PUEDE, pero NO DEBE tener salida de audio, pero otros tipos de implementaciones de dispositivos Android DEBEN tener una salida de audio y declarar android.hardware.audio.output.

7.8.2.1. Puertos de audio analógicos

Para que la implementación de un dispositivo sea compatible con auriculares y otros accesorios de audio mediante el conector de audio de 3.5 mm en todo el ecosistema de Android, al menos uno de estos debe ser un conector de audio de 3.5 mm de 4 conductores. Si la implementación de un dispositivo tiene un conector de audio de 4 conductores de 3,5 mm, hace lo siguiente:

  • DEBE admitir la reproducción de audio en auriculares estéreo y estéreo con micrófono, y DEBE admitir la grabación de audio de auriculares estéreo con un micrófono.
  • DEBE admitir enchufes de audio TRRS con el orden de pines CTIA y DEBERÍA admitir enchufes de audio con el orden de pines OMTP.
  • DEBE admitir la detección del micrófono en el accesorio de audio conectado, si la implementación del dispositivo admite un micrófono, y transmitir el android.intent.action.HEADSET_PLUG con el micrófono de valor adicional establecido en 1.
  • DEBE admitir la detección y la asignación a los códigos de teclas para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
    • 70 ohm o menos : KEYCODE_HEADSETHOOK
    • De 210 a 290 Ohm : KEYCODE_VOLUME_UP
    • 360-680 Ohm : KEYCODE_VOLUME_DOWN
  • SE RECOMIENDA ENERCMENTE detectar y asignar el código de clave para el siguiente rango de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
    • De 110 a 180 Ohm: KEYCODE_VOICE_ASSIST
  • DEBE activar ACTION_HEADSET_PLUG cuando el conector se inserta, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
  • DEBE ser capaz de conducir al menos 150 mV ± 10% del voltaje de salida en una impedancia de la bocina de 32 Ohm.
  • DEBE tener un voltaje de sesgo del micrófono entre 1.8 V y 2.9 V.

7.8.3. Casi ultrasónica

El audio casi ultrasónico está en la banda de entre 18.5 kHz y 20 kHz. Las implementaciones en dispositivos DEBEN informar correctamente la compatibilidad con la capacidad de audio casi ultrasónico a través de la API de AudioManager.getProperty de la siguiente manera:

  • Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASON es "verdadero", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED deben cumplir los siguientes requisitos:
    • La potencia de respuesta promedio del micrófono en la banda de 18.5 kHz a 20 kHz DEBE no superar los 15 dB por debajo de la respuesta a 2 kHz.
    • La relación señal-ruido no ponderada del micrófono superior a 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS no DEBE ser inferior a 50 dB.
  • Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASON es "true", la respuesta media del interlocutor en 18.5 kHz - 20 kHz DEBE no ser inferior a 40 dB por debajo de la respuesta a 2 kHz.

7.9 Realidad virtual

Android incluye API e instalaciones para crear "realidad virtual" (RV), incluidas las experiencias de RV móvil de alta calidad. Las implementaciones en dispositivos DEBEN implementar adecuadamente estas APIs y comportamientos, como se detalla en esta sección.

7.9.1 Modo de realidad virtual

Las implementaciones de dispositivos portátiles Android que admiten un modo para aplicaciones de RV que controla la renderización estereoscópica de notificaciones e inhabilita los componentes monoculares de la IU del sistema mientras una aplicación de RV está enfocada en el usuario DEBEN declarar la función android.software.vr.mode. Los dispositivos que declaren esta función DEBEN incluir una aplicación que implemente android.service.vr.VrListenerService y que las aplicaciones de RV puedan habilitarse a través de android.app.Activity#setVrModeEnabled .

7.9.2. Realidad virtual con alto rendimiento

Las implementaciones en dispositivos de mano de Android DEBEN identificar la compatibilidad con la realidad virtual de alto rendimiento durante períodos más prolongados para los usuarios a través de la marca de función android.hardware.vr.high_performance y cumplir con los siguientes requisitos.

  • Las implementaciones del dispositivo DEBEN tener al menos 2 núcleos físicos.
  • Las implementaciones del dispositivo DEBEN declarar la función android.software.vr.mode.
  • Las implementaciones en dispositivos pueden proporcionar un núcleo exclusivo para la aplicación en primer plano y pueden admitir la API Process.getExternalCores para devolver los números de los núcleos del CPU que son exclusivos de la aplicación en primer plano en la parte superior. Si se admite un núcleo exclusivo, el núcleo DEBE no permitir que se ejecuten otros procesos del espacio del usuario (excepto los controladores de dispositivos que utilice la aplicación), pero PUEDE permitir que se ejecuten algunos procesos de kernel según sea necesario.
  • Las implementaciones del dispositivo DEBEN admitir un modo de rendimiento sostenido.
  • Las implementaciones en dispositivos DEBEN ser compatibles con OpenGL ES 3.2.
  • Las implementaciones en dispositivos DEBEN admitir el nivel de hardware de Vulkan 0, y DEBEN admitir el nivel de hardware de Vulkan 1.
  • Las implementaciones de dispositivos DEBEN implementar EGL_KHR_mutable_render_buffer y EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync y EGL_KHR_wait_sync de modo que puedan usarse para el modo de búfer compartido y que se expongan las extensiones en la lista de extensiones EGL disponibles.
  • La GPU y la pantalla DEBEN poder sincronizar el acceso al búfer frontal compartido, de manera que se muestre la renderización ocular alternativa del contenido de RV a 60 FPS con dos contextos de renderización sin artefactos de seccionamiento visibles.
  • Las implementaciones de dispositivos DEBEN implementar EGL_IMG_context_priority y exponer la extensión en la lista de extensiones EGL disponibles.
  • Las implementaciones del dispositivo DEBEN implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 y GL_OVR_multiview_multisampled_render_to_texture, y exponer las extensiones en la lista de extensiones de GL disponibles.
  • Las implementaciones de dispositivos DEBEN implementar EGL_EXT_protection_content y GL_EXT_protection_textures de modo que puedan usarse para la reproducción segura de video con texturas, y exponer las extensiones en la lista de extensiones EGL y GL disponibles.
  • Las implementaciones del dispositivo DEBEN admitir la decodificación H.264 de al menos 3840 x 2160 a 30 fps-40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-10 Mbps o 2 instancias de 1920 x 1080 a 60 fps-20 Mbps).
  • Las implementaciones del dispositivo DEBEN ser compatibles con HEVC y VP9, DEBEN ser capaces de decodificar al menos 1920 x 1080 a 30 fps-10 Mbps y DEBEN poder decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instancias de 1920 x 1080 fps-10bps).
  • Se RECOMIENDA EJECUTIVAMENTE que las implementaciones en dispositivos sean compatibles con la función android.hardware.sensor.hifi_sensors y que DEBEN cumplir con los requisitos relacionados con el giroscopio, el acelerómetro y el magnetómetro para android.hardware.hifi_sensors.
  • Las implementaciones del dispositivo DEBEN admitir la API de HardwarePropertiesManager.getDeviceTemperatures y devolver valores precisos para la temperatura cutánea.
  • La implementación del dispositivo DEBE tener una pantalla incorporada, y su resolución DEBE ser de al menos FullHD(1080p) y SE RECOMIENDA ESTABLECER QUE sea QuadHD (1440p) o superior.
  • La pantalla DEBE medir entre 4,7 pulgadas y 6" diagonal.
  • La pantalla DEBE actualizar al menos 60 Hz en el modo RV.
  • La latencia de la pantalla en el tiempo de cambio de gris a gris, blanco a negro y negro a blanco DEBE ser ≤ 3 ms.
  • La pantalla DEBE admitir un modo de baja persistencia con una persistencia de ≤5 ms,la persistencia se define como la cantidad de tiempo durante el cual un píxel emite luz.
  • Las implementaciones de dispositivos DEBEN admitir Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE (sección 7.4.3).

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y energía son fundamentales para la experiencia del usuario y afectan las suposiciones de referencia que los desarrolladores tendrían al desarrollar una app. Los dispositivos Android Watch DEBEN y otros tipos de implementaciones de dispositivos DEBEN cumplir con los siguientes criterios.

8.1. Coherencia de la experiencia del usuario

Las implementaciones en dispositivos DEBEN proporcionar una interfaz de usuario fluida, ya que garantizan una velocidad de fotogramas y tiempos de respuesta uniformes para las aplicaciones y los juegos. Las implementaciones en dispositivos DEBEN cumplir con los siguientes requisitos:

  • Latencia de fotogramas coherente . La latencia de fotogramas no es uniforme o un retraso en la renderización de fotogramas NO DEBE tener una frecuencia superior a 5 fotogramas por segundo, y SE DEBE ser inferior a 1 fotograma en un segundo.
  • Latencia de la interfaz de usuario . Las implementaciones del dispositivo DEBEN garantizar una experiencia del usuario de baja latencia desplazando una lista de 10,000 entradas de lista según lo define el Conjunto de pruebas de compatibilidad (CTS) de Android en menos de 36 segundos.
  • Cambio de tareas . Cuando se han iniciado varias aplicaciones, volver a iniciar una aplicación que ya está en ejecución DEBE tardar menos de 1 segundo.

8.2. Rendimiento del acceso a la E/S de archivos

Las implementaciones del dispositivo DEBEN garantizar la coherencia del rendimiento de acceso a los archivos del almacenamiento interno para las operaciones de lectura y escritura.

  • Escritura secuencial . Las implementaciones en dispositivos DEBEN garantizar un rendimiento de escritura secuencial de al menos 5 MB/s para un archivo de 256 MB con un búfer de escritura de 10 MB.
  • Escritura aleatoria . Las implementaciones del dispositivo DEBEN garantizar un rendimiento de escritura aleatorio de al menos 0.5 MB/s para un archivo de 256 MB mediante un búfer de escritura de 4 KB.
  • Lectura secuencial . Las implementaciones en dispositivos DEBEN garantizar un rendimiento de lectura secuencial de al menos 15 MB/s para un archivo de 256 MB con un búfer de escritura de 10 MB.
  • Lectura aleatoria . Las implementaciones del dispositivo DEBEN garantizar un rendimiento de lectura aleatoria de al menos 3.5 MB/s para un archivo de 256 MB mediante un búfer de escritura de 4 KB.

8.3. Modos de ahorro de energía

En Android 6.0, se presentaron los modos de ahorro de energía App Standby y Descanso para optimizar el uso de la batería. Todas las apps exentas de estos modos DEBEN ser visibles para el usuario final. Además, la activación, el mantenimiento, los algoritmos de activación y el uso de la configuración global del sistema de estos modos de ahorro de energía no DEBEN desviarse del Proyecto de código abierto de Android.

Además de los modos de ahorro de energía, las implementaciones de dispositivos Android PUEDEN implementar cualquiera o todos los 4 estados de energía suspendido, según lo define la Interfaz avanzada de configuración e energía (ACPI), pero si implementa los estados de energía S3 y S4, solo puede ingresar estos estados al cerrar una tapa que forma parte físicamente del dispositivo.

8.4. Contabilidad del consumo de energía

Una contabilización e informes más precisos del consumo de energía le proporciona al desarrollador de la app los incentivos y las herramientas para optimizar el patrón de uso de energía de la aplicación. Por lo tanto, las implementaciones en dispositivos tienen las siguientes características:

  • DEBE ser capaz de realizar un seguimiento del uso de energía de los componentes de hardware y atribuir dicho uso a aplicaciones específicas. En particular, las implementaciones tienen las siguientes características:
    • DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual de cada componente de hardware y el consumo aproximado de batería que generan los componentes con el paso del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
    • DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
    • SE DEBE atribuir al componente de hardware si no es posible atribuir el uso de energía de un componente de hardware a una aplicación.
    • SE DEBE informar el consumo de energía de la CPU según el UID de cada proceso. El Proyecto de código abierto de Android cumple con los requisitos a través de la implementación del módulo de kernel uid_cputime.
  • DEBE hacer que este uso de energía esté disponible para el desarrollador de la app a través del comando shell adb shell dumpsys batterystats.
  • DEBE respetar el intent android.intent.action.POWER_USAGE_SUMMARY y mostrar un menú de configuración que indique este uso de energía.

8.5. Rendimiento coherente

El rendimiento puede fluctuar considerablemente en el caso de las apps de alto rendimiento que se ejecutan durante un tiempo prolongado, ya sea debido a que las otras apps se ejecutan en segundo plano o a la limitación de la CPU debido a los límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea compatible, la aplicación en primer plano de la parte superior pueda solicitar que el sistema optimice la asignación de los recursos para abordar esas fluctuaciones.

Las implementaciones en dispositivos DEBEN admitir el Modo de rendimiento sostenido, que puede proporcionar a la aplicación en primer plano un nivel de rendimiento coherente durante un período prolongado cuando se solicita a través del método de la API Window.setSustainedPerformanceMode(). Una implementación de dispositivo DEBE informar con precisión la compatibilidad del Modo de rendimiento sostenido a través del método de la API PowerManager.isSustainedPerformanceModeSupported().

Las implementaciones de dispositivos con dos o más núcleos de CPU DEBEN proporcionar al menos un núcleo exclusivo que la aplicación superior en primer plano pueda reservar. Si se proporcionan, las implementaciones DEBEN cumplir con los siguientes requisitos:

  • Las implementaciones DEBEN informar a través del método de la API Process.getExclusiveCores() los números de ID de los núcleos exclusivos que la aplicación superior en primer plano puede reservar.
  • Las implementaciones del dispositivo NO DEBEN permitir ningún proceso de espacio del usuario, excepto los controladores de dispositivo que usa la aplicación para ejecutarse en núcleos exclusivos, pero PUEDEN permitir que se ejecuten algunos procesos de kernel según sea necesario.

Si la implementación de un dispositivo no admite un núcleo exclusivo, DEBE mostrar una lista vacía a través del método de la API Process.getExclusiveCores().

9. Compatibilidad del modelo de seguridad

Las implementaciones de dispositivos DEBEN implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, tal como se define en el documento de referencia sobre seguridad y permisos de las APIs de la documentación para desarrolladores de Android. Las implementaciones del dispositivo DEBEN admitir la instalación de aplicaciones autofirmadas sin la necesidad de permisos o certificados adicionales de terceros o autoridades. Específicamente, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad descritos en las siguientes subsecciones.

9.1 Permisos

Las implementaciones en dispositivos DEBEN admitir el modelo de permisos de Android según se define en la documentación para desarrolladores de Android. Específicamente, las implementaciones DEBEN hacer cumplir cada permiso definido como se describe en la documentación del SDK. no se puede omitir, alterar ni ignorar ningún permiso. Las implementaciones PUEDEN agregar permisos adicionales, siempre que las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.*.

Los permisos con una protectionLevel de 'PROTECTION_FLAG_PRIVILEGED' solo DEBEN otorgarse a las apps precargadas en las rutas de acceso con privilegios incluidas en la lista de entidades permitidas de la imagen del sistema, como la ruta de acceso system/priv-app en la implementación de AOSP.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Aplicaciones con targetSdkVersion > 22 las solicitan en el tiempo de ejecución. Implementaciones en dispositivos:

  • DEBE mostrar una interfaz dedicada para que el usuario decida si otorga los permisos de tiempo de ejecución solicitados y también proporcionar una interfaz para que el usuario gestione los permisos de tiempo de ejecución.
  • DEBE tener una única implementación de ambas interfaces de usuario.
  • NO se DEBE otorgar permisos de tiempo de ejecución a las apps preinstaladas, a menos que se cumpla lo siguiente:
    • El consentimiento del usuario se puede obtener antes de que la aplicación lo utilice.
    • Los permisos de tiempo de ejecución están asociados con un patrón de intent para el cual la aplicación preinstalada está configurada como controlador predeterminado.

9.2 UID y aislamiento de procesos

Las implementaciones en dispositivos DEBEN admitir el modelo de zona de pruebas de aplicaciones para Android, en el que cada aplicación se ejecuta como un UID único de estilo Unix y en un proceso independiente. Las implementaciones de dispositivos DEBEN admitir la ejecución de varias aplicaciones como el mismo ID de usuario de Linux, siempre que las aplicaciones estén correctamente firmadas y construidas, como se define en la referencia de seguridad y permisos.

9.3 Permisos del sistema de archivos

Las implementaciones del dispositivo DEBEN admitir el modelo de permisos de acceso de archivos de Android según se define en la referencia de seguridad y permisos.

Entornos de ejecución alternativos

Las implementaciones de dispositivos pueden incluir entornos de ejecución que ejecutan aplicaciones con algún otro software o tecnología que el formato ejecutable Dalvik o el código nativo. Sin embargo, dichos entornos de ejecución alternativos NO DEBEN comprometer el modelo de seguridad de Android ni la seguridad de las aplicaciones para Android instaladas, tal como se describe en esta sección.

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

A los entornos de ejecución alternativos NO DEBEN otorgarse acceso a recursos protegidos por permisos no solicitados en el archivo AndroidManifest.xml del entorno de ejecución a través del <uses-permission> de atención.

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

Los tiempos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android. Específicamente, los entornos de ejecución alternativos:

  • SE DEBEN instalar las apps a través de PackageManager en zonas de pruebas independientes de Android (ID de usuario de Linux, etc.).
  • PUEDE proporcionar una única zona de pruebas de Android compartida por todas las aplicaciones que usen el tiempo de ejecución alternativo.
  • Las aplicaciones instaladas con un tiempo de ejecución alternativo NO DEBEN reutilizar la zona de pruebas de ninguna otra aplicación instalada en el dispositivo, excepto a través de los mecanismos estándar de Android de ID de usuario compartido y certificado de firma.
  • NO SE DEBE iniciar con, otorgar ni obtener acceso a las zonas de pruebas correspondientes a otras aplicaciones para Android.
  • NO DEBEN iniciarse con otras aplicaciones, otorgarse ni otorgarse a ellas ningún privilegio del superusuario (raíz) ni de ningún otro ID de usuario.

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

Al instalar aplicaciones, los tiempos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que utiliza la aplicación. Si una aplicación necesita usar un recurso de dispositivo para el que hay un permiso de Android correspondiente (como Cámara, GPS, etc.), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso. Si el entorno de tiempo de ejecución no registra las capacidades de la aplicación de esta manera, DEBE enumerar todos los permisos que tiene el propio tiempo de ejecución cuando se instala cualquier aplicación que usa ese tiempo de ejecución.

9.5 Compatibilidad multiusuario

Esta función es opcional para todos los tipos de dispositivos.

Android admite varios usuarios y admite el aislamiento total de los usuarios. Las implementaciones de dispositivos PUEDEN habilitar a varios usuarios, pero, cuando están habilitadas, DEBEN cumplir con los siguientes requisitos relacionados con la compatibilidad con la función multiusuario:

  • Las implementaciones de dispositivos Android Automotive compatibles con la compatibilidad multiusuario DEBEN incluir una cuenta de invitado que permita todas las funciones proporcionadas por el sistema del vehículo sin que el usuario tenga que acceder.
  • Las implementaciones de dispositivos que no declaran el parámetro de función android.hardware.telephony DEBEN admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que los usuarios adicionales trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
  • Por el contrario, las implementaciones de dispositivos que declaran la marca de función android.hardware.telephony NO DEBEN admitir perfiles restringidos, pero DEBEN alinearse con la implementación de controles de AOSP para permitir o impedir que otros usuarios accedan a las llamadas de voz y los SMS.
  • Para cada usuario, las implementaciones de dispositivos DEBEN implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, tal como se define en el documento de referencia de Seguridad y permisos en las APIs.
  • Cada instancia de usuario en un dispositivo Android DEBE tener directorios de almacenamiento externo separados y aislados. Las implementaciones de dispositivos PUEDEN almacenar las contraseñas de varios usuarios datos en el mismo volumen o sistema de archivos. Sin embargo, la implementación del dispositivo DEBE garantizar que las aplicaciones que pertenecen a un usuario determinado y que se ejecutan en su nombre no puedan enumerar, leer ni escribir en datos que pertenecen a cualquier otro usuario. Ten en cuenta que los medios extraíbles, como las ranuras de tarjetas SD, pueden permitir que un usuario acceda a los datos de otro a través de una PC host. Por este motivo, las implementaciones de dispositivos que usan medios extraíbles para las APIs de almacenamiento externo DEBEN encriptar el contenido de la tarjeta SD si el multiusuario está habilitado mediante una clave almacenada solo en medios no extraíbles al que solo puede acceder el sistema. Como esto hará que el contenido multimedia no sea legible para una PC host, las implementaciones del dispositivo deberán cambiar a MTP o un sistema similar para proporcionarles a las PC host acceso a los datos del usuario actual. Por lo tanto, es posible que las implementaciones en dispositivos NO habiliten la función multiusuario si usan medios extraíbles como almacenamiento externo principal.

9.6 Advertencia de SMS premium

Android incluye compatibilidad con la advertencia de usuarios sobre cualquier mensaje SMS premium saliente. Los SMS premium son mensajes de texto enviados a un servicio registrado con un operador que puede generar un cargo al usuario. Las implementaciones de dispositivos que declaran compatibilidad con android.hardware.telephony DEBEN advertir a los usuarios antes de enviar un mensaje SMS a los números identificados por las expresiones regulares definidas en el archivo /data/misc/sms/codes.xml del dispositivo. El Proyecto de código abierto de Android ascendente proporciona una implementación que cumple con este requisito.

9.7 Funciones de seguridad del kernel

La zona de pruebas de Android incluye funciones que utilizan el sistema de control de acceso obligatorio (MAC) Security-Enhanced Linux (SELinux), la zona de pruebas seccomp y otras funciones de seguridad en el kernel de Linux. SELinux o cualquier otra función de seguridad implementada debajo del framework de Android:

  • DEBE mantener la compatibilidad con las aplicaciones existentes.
  • NO DEBEN tener una interfaz de usuario visible cuando se detecta y bloquea correctamente una infracción de seguridad, pero PUEDE tener una interfaz de usuario visible cuando se produce una infracción de seguridad desbloqueada que dé como resultado un exploit exitoso.
  • NO DEBE ser configurable por el usuario o el desarrollador.

Si alguna API para la configuración de políticas se expone a una aplicación que puede afectar a otra aplicación (como una API de administración de dispositivos), la API NO DEBE permitir configuraciones que rompen la compatibilidad.

Los dispositivos DEBEN implementar SELinux o, en caso de usar un kernel distinto de Linux, un sistema de control de acceso obligatorio equivalente. Los dispositivos también DEBEN cumplir con los siguientes requisitos, que se cumplen con la implementación de referencia del Proyecto de código abierto de Android ascendente.

Implementaciones en dispositivos:

  • DEBE configurar SELinux en el modo de aplicación forzosa global.
  • SE DEBE configurar todos los dominios en modo de aplicación forzosa. No se permiten dominios en modo permisivo, incluidos dominios específicos de un dispositivo o proveedor.
  • NO DEBE modificar, omitir ni reemplazar las reglas de "Neverallow" presentes en la carpeta del sistema o la directiva proporcionada en el Proyecto de código abierto de Android (AOSP) ascendente, y la política DEBE compilar con todas las reglas "Neverallow" presentes, tanto para dominios SELinux del AOSP como para dominios específicos de dispositivos o proveedores.
  • SE DEBE dividir el marco de trabajo de medios en varios procesos para que sea posible otorgar acceso más limitado a cada proceso, como se describe en el sitio del Proyecto de código abierto de Android.

Las implementaciones de dispositivos DEBEN conservar la política SELinux predeterminada que se proporciona en la carpeta del sistema o la política del proyecto de código abierto de Android ascendente y solo agregar esta política para su propia configuración específica del dispositivo. Las implementaciones en dispositivos DEBEN ser compatibles con el Proyecto de código abierto de Android ascendente.

Los dispositivos DEBEN implementar un mecanismo de zona de pruebas de aplicaciones de kernel que permita filtrar llamadas al sistema usando una política configurable de programas con varios subprocesos. El Proyecto de código abierto de Android ascendente cumple este requisito al habilitar seccomp-BPF con sincronización de grupo de subprocesos (TSYNC), como se describe en la sección de configuración de kernel de source.android.com.

9.8 Privacidad

Si el dispositivo implementa funciones en el sistema que captura el contenido que se muestra en la pantalla o graba la transmisión de audio que se reproduce en el dispositivo, DEBE notificar de forma continua al usuario cada vez que esta funcionalidad esté habilitada y esté capturando o grabando de manera activa.

Si la implementación de un dispositivo tiene un mecanismo que enruta el tráfico de datos de red a través de un servidor proxy o una puerta de enlace de VPN de forma predeterminada (por ejemplo, la precarga de un servicio de VPN con android.permission.CONTROL_VPN otorgado), la implementación del dispositivo DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de política de dispositivo habilite esa VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage(). En ese caso, el usuario no necesita otorgar un consentimiento por separado, pero solo DEBE recibir una notificación.

Las implementaciones de dispositivos DEBEN enviarse con un almacén de autoridad certificadora (AC) agregado por el usuario vacío y DEBEN preinstalar los mismos certificados raíz para el almacén de AC de confianza del sistema que se proporcionan en el Proyecto de código abierto de Android ascendente.

Cuando los dispositivos se enrutan a través de una VPN o se instala una AC raíz del usuario, la implementación DEBE mostrar una advertencia que indica que el tráfico de red puede ser supervisado para el usuario.

Si la implementación de un dispositivo tiene un puerto USB compatible con el modo periférico USB, DEBE presentar una interfaz de usuario que solicite el consentimiento del usuario antes de permitir el acceso al contenido del almacenamiento compartido a través del puerto USB.

9.9 Encriptación del almacenamiento de datos

Opcional para las implementaciones en dispositivos Android sin una pantalla de bloqueo segura.

Si la implementación del dispositivo admite una pantalla de bloqueo segura, como se describe en la sección 9.11.1, el dispositivo DEBE admitir la encriptación de almacenamiento de datos privados de la aplicación (partición de datos), así como la partición de almacenamiento compartido de la aplicación (partición de /sdcard) si es una parte permanente del dispositivo no extraíble.

En el caso de las implementaciones de dispositivos que admiten la encriptación de almacenamiento de datos y con un rendimiento criptográfico del Estándar de encriptación avanzada (AES) superior a 50 MiB/s, la encriptación del almacenamiento de datos DEBE estar habilitada de forma predeterminada en el momento en que el usuario completa la experiencia de configuración integrada. Si la implementación de un dispositivo ya se lanzó en una versión anterior de Android con la encriptación inhabilitada de forma predeterminada, ese dispositivo no podrá cumplir con el requisito a través de una actualización de software del sistema y, por lo tanto, PODRÍA estar exento.

Las implementaciones en dispositivos DEBEN cumplir con el requisito de encriptación de almacenamiento de datos anterior mediante la implementación de la encriptación basada en archivos (FBE).

9.9.1 Inicio directo

Todos los dispositivos DEBEN implementar las APIs del modo de inicio directo, incluso si no admiten la encriptación de almacenamiento. En particular, los intents LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED deben transmitirse para indicar a las aplicaciones con reconocimiento de inicio directo que las ubicaciones de almacenamiento con dispositivo encriptado (DE) y con encriptación de credenciales (CE) están disponibles para el usuario.

9.9.2. Encriptación basada en archivos

Implementaciones de dispositivos compatibles con FBE:

  • DEBE iniciarse sin solicitar las credenciales al usuario y permitir que las aplicaciones compatibles con el inicio directo accedan al almacenamiento de dispositivo encriptado (DE) luego de que se emite el mensaje LOCKED_BOOT_COMPLETED.
  • Solo DEBE permitir el acceso al almacenamiento de Credential Encrypted (CE) después de que el usuario haya desbloqueado el dispositivo proporcionando sus credenciales (p. ej., contraseña, PIN, patrón o huella dactilar) y se haya transmitido el mensaje ACTION_USER_UNLOCKED. Las implementaciones en dispositivos NO DEBEN ofrecer ningún método para desbloquear el almacenamiento protegido por CE sin las credenciales proporcionadas por el usuario.
  • DEBE admitir el inicio verificado y asegurarse de que las claves DE estén vinculadas criptográficamente a la raíz de confianza del hardware del dispositivo.
  • DEBE admitir la encriptación de contenido de archivos mediante AES con una longitud de clave de 256 bits en modo XTS.
  • DEBE admitir la encriptación de nombres de archivos mediante AES con una longitud de clave de 256 bits en modo CBC-CTS.
  • PUEDE admitir cifrados, longitudes de clave y modos alternativos para el contenido de los archivos y la encriptación de nombres de archivos, pero DEBE usar los cifrados, las longitudes de clave y los modos admitidos de forma obligatoria de forma predeterminada.
  • SE DEBE permitir que las apps esenciales precargadas (p.ej., Alarma, Teléfono, Messenger) reconozcan el inicio directo.

Claves que protegen las áreas de almacenamiento CE y DE:

  • DEBE vincularse de forma criptográfica a un almacén de claves guardado en hardware. Las claves CE se deben vincular a las credenciales de la pantalla de bloqueo de un usuario. Si el usuario no especificó credenciales para la pantalla de bloqueo, las claves CE DEBEN estar vinculadas a una contraseña predeterminada.
  • DEBE ser única y diferente; en otras palabras, ninguna de las claves CE o DE del usuario puede coincidir con las claves CE o DE de otro usuario.

El proyecto ascendente de código abierto de Android proporciona una implementación preferida de esta función que se basa en la función de encriptación ext4 del kernel de Linux.

9.9.3 Encriptación de disco completo

Implementaciones de dispositivos que admiten la encriptación de disco completo (FDE) SE DEBE usar AES con una clave de 128 bits (o superior) y un modo diseñado para el almacenamiento (por ejemplo, AES-XTS, AES-CBC-ESSIV). La clave de encriptación NO DEBE escribirse en el almacenamiento en ningún momento sin estar encriptada. Excepto cuando se encuentra en uso activo, la clave de encriptación SE DEBE encriptar con AES con las credenciales de la pantalla de bloqueo extendidas mediante un algoritmo de estiramiento lento (por ejemplo, PBKDF2 o scrypt). Si el usuario no especificó las credenciales de la pantalla de bloqueo o inhabilitó el uso de la contraseña para la encriptación, el sistema DEBE usar una contraseña predeterminada para unir la clave de encriptación. Si el dispositivo proporciona un almacén de claves con copia de seguridad en hardware, el algoritmo de ampliación de contraseñas DEBE estar vinculado criptográficamente a ese almacén de claves. La clave de encriptación NO SE DEBE enviar fuera del dispositivo (incluso cuando está unida con la contraseña del usuario o con una clave vinculada al hardware). El proyecto upstream de código abierto de Android proporciona una implementación preferida de esta función según la función dm-crypt del kernel de Linux.

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan que el estado de la integridad del dispositivo sea transparente.

Las implementaciones del dispositivo DEBEN informar correctamente a través del método de la API del sistema PersistentDataBlockManager.getFlashLockState() si el estado de su bootloader permite actualizar la imagen del sistema. El estado FLASH_LOCK_UNKNOWN se reserva para las implementaciones en dispositivos que se actualizan desde una versión anterior de Android en la que no existía este nuevo método de API del sistema.

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si la implementación de un dispositivo admite la función, DEBE:

  • Declara la marca de función de la plataforma android.software.verified_boot.
  • Verifica cada secuencia de inicio.
  • Comienza la verificación desde una clave de hardware inmutable que es la raíz de confianza y avanza hasta la partición del sistema.
  • Implementa cada etapa de verificación para comprobar la integridad y autenticidad de todos los bytes en la siguiente etapa antes de ejecutar el código en la próxima etapa.
  • Usa algoritmos de verificación tan sólidos como las recomendaciones actuales del NIST para los algoritmos de hash (SHA-256) y los tamaños de claves públicas (RSA-2048).
  • NO DEBE permitir que se complete el inicio cuando falla la verificación del sistema, a menos que el usuario dé su consentimiento para intentar iniciar el dispositivo de todos modos, en cuyo caso no se DEBEN usar los datos de bloques de almacenamiento no verificados.
  • NO DEBE permitir que se modifiquen las particiones verificadas en el dispositivo, a menos que el usuario desbloquee explícitamente el cargador de inicio.

El Proyecto de código abierto de Android ascendente ofrece una implementación preferida de esta función según la dm-verity de la función del kernel de Linux.

A partir de Android 6.0, las implementaciones de dispositivos con rendimiento criptográfico del Estándar de encriptación avanzada (AES) por encima de 50 MiB/segundo DEBEN admitir el inicio verificado para la integridad del dispositivo.

Si ya se lanzó la implementación de un dispositivo sin admitir el inicio verificado en una versión anterior de Android, estos dispositivos no podrán admitir esta función con una actualización de software del sistema y, por lo tanto, quedarán exentos del requisito.

9.11. Claves y credenciales

El sistema Android Keystore permite a los desarrolladores de apps almacenar claves criptográficas en un contenedor y usarlas en operaciones criptográficas a través de la API de KeyChain o la API de Keystore.

Todas las implementaciones en dispositivos Android DEBEN cumplir con los siguientes requisitos:

  • No se DEBE limitar la cantidad de claves que se pueden generar y DEBE permitir, al menos, la importación de más de 8,192 claves.
  • La autenticación de la pantalla de bloqueo DEBE limitar los intentos de frecuencia y DEBE tener un algoritmo de retirada exponencial. Si supera los 150 intentos fallidos, la demora DEBE ser de al menos 24 horas por intento.
  • Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, DEBE crear una copia de seguridad de la implementación del almacén de claves con hardware seguro y cumplir con los siguientes requisitos:
    • DEBE tener implementaciones respaldadas por hardware de los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y funciones de hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles con el sistema Android Keystore.
    • DEBE realizar la autenticación de la pantalla de bloqueo en el hardware seguro y solo cuando se permita con éxito el uso de las claves vinculadas a la autenticación. El Proyecto de código abierto de Android ascendente proporciona la capa de abstracción de hardware (HAL) de Gatekeeper que se puede usar para cumplir con este requisito.

Ten en cuenta que, si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, ese dispositivo estará exento del requisito de tener un almacén de claves con copia de seguridad en hardware, a menos que declare la función android.hardware.fingerprint que requiera un almacén de claves con copia de seguridad en hardware.

9.11.1 Pantalla de bloqueo protegida

Las implementaciones de dispositivos PUEDEN agregar o modificar los métodos de autenticación para desbloquear la pantalla de bloqueo, pero DEBEN cumplir con los siguientes requisitos:

  • El método de autenticación, si se basa en un secreto conocido, NO DEBE tratarse como una pantalla de bloqueo segura, a menos que cumpla con todos los siguientes requisitos:
    • La entropía de la longitud más corta permitida de entradas DEBE ser superior a 10 bits.
    • La entropía máxima de todas las entradas posibles DEBE ser superior a 18 bits.
    • No DEBEN reemplazar ninguno de los métodos de autenticación existentes (PIN, patrón, contraseña) implementados y proporcionados en el AOSP.
    • Se DEBE inhabilitar cuando la aplicación del controlador de política de dispositivo (DPC) establece la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_SOMETHING .
  • El método de autenticación, si se basa en un token físico o en la ubicación, NO DEBE tratarse como una pantalla de bloqueo segura a menos que cumpla con todos los siguientes requisitos:
    • DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales que se base en un secreto conocido y cumpla con los requisitos para que se la considere como una pantalla de bloqueo segura.
    • Se DEBE inhabilitar y permitir que la autenticación principal solo desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política con los métodos DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_UNSPECIFIED .
  • El método de autenticación, si se basa en datos biométricos, NO DEBE tratarse como una pantalla de bloqueo segura, a menos que cumpla con todos los siguientes requisitos:
    • DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales que se base en un secreto conocido y cumpla con los requisitos para que se la considere como una pantalla de bloqueo segura.
    • Se DEBE inhabilitar y permitir que la autenticación principal solo desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya configurado la política de funciones de bloqueo de teclado llamando al método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
    • DEBE tener una tasa de aceptación de falsos menor o mayor que la requerida para un sensor de huellas dactilares, tal como se describe en la sección 7.3.10. De lo contrario, DEBE inhabilitarse y permitir que la autenticación principal solo desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • Si el método de autenticación no se puede tratar como una pantalla de bloqueo segura, sucederá lo siguiente:
  • Si el método de autenticación se basa en un token físico, la ubicación o datos biométricos que tienen una tasa de aceptación falsa más alta que la requerida para los sensores de huellas dactilares, como se describe en la sección 7.3.10, sucederá lo siguiente:

9.12. Eliminación de Datos

Los dispositivos DEBEN proporcionar a los usuarios un mecanismo para restablecer la configuración de fábrica que permite la eliminación lógica y física de todos los datos, excepto los siguientes:

  • La imagen del sistema
  • Cualquier archivo del sistema operativo que requiere la imagen del sistema

Todos los datos generados por el usuario DEBEN borrarse. Esto DEBE cumplir con los estándares relevantes de la industria para la eliminación de datos, como NIST SP800-88. Se DEBE usar para la implementación de la API de cleanData() (parte de la API de Android Device Administration) descrita en la sección 3.9 Administración de dispositivos.

ES POSIBLE que los dispositivos proporcionen una limpieza de datos rápida que lleve a cabo una eliminación lógica de datos.

9.13 Modo de inicio seguro

Android proporciona un modo que permite que los usuarios se inicien en un modo en el que solo se permite la ejecución de apps del sistema preinstaladas y se inhabilitan todas las apps de terceros. Este modo, conocido como "modo de inicio seguro", proporciona al usuario la capacidad de desinstalar apps de terceros potencialmente dañinas.

SE RECOMIENDA LAS implementaciones en dispositivos Android para implementar el modo de inicio seguro y cumplir con los siguientes requisitos:

  • Las implementaciones en dispositivos DEBEN brindar al usuario la opción de ingresar al modo de inicio seguro desde el menú de inicio, al que se puede acceder mediante un flujo de trabajo diferente al del inicio normal.

  • Las implementaciones en dispositivos DEBEN brindar al usuario la opción de ingresar al modo de inicio seguro de una manera que las apps de terceros instaladas en el dispositivo no se interrumpan, excepto cuando la app de terceros es un controlador de política de dispositivo y estableció la marca UserManager.DISALLOW_SAFE_BOOT como verdadera.

  • Las implementaciones en dispositivos DEBEN brindar al usuario la posibilidad de desinstalar cualquier app de terceros en el modo seguro.

9.14. Aislamiento de sistemas para vehículos

Se espera que los dispositivos Android Automotive intercambien datos con subsistemas críticos del vehículo, p.ej., usando la HAL del vehículo para enviar y recibir mensajes a través de redes de vehículos, como CAN bus. Las implementaciones en dispositivos de Android Automotive DEBEN implementar funciones de seguridad debajo de las capas del framework de Android para evitar la interacción maliciosa o no intencional entre el framework de Android o las apps de terceros y los subsistemas del vehículo. Estas son las funciones de seguridad:

  • Conservar mensajes de subsistemas del vehículo del framework de Android, p. ej., incluir en la lista de entidades permitidas los tipos de mensajes y las fuentes de mensajes permitidos
  • Perro guardián contra ataques de denegación del servicio desde el framework de Android o apps de terceros. Esto brinda protección contra software malicioso que inunda de tráfico la red del vehículo, lo que puede provocar el mal funcionamiento de los subsistemas del vehículo.

10. Pruebas de compatibilidad de software

Las implementaciones en dispositivos DEBEN superar todas las pruebas que se describen en esta sección.

Sin embargo, ten en cuenta que ningún paquete de prueba de software es completamente completo. Por este motivo, SE RECOMIENDA EJECUTAR a los implementadores de dispositivos realizar la cantidad mínima de cambios posible en la referencia y la implementación preferida de Android a partir del Proyecto de código abierto de Android. Esto minimizará el riesgo de introducir errores que creen incompatibilidades que requieran reelaboración y posibles actualizaciones del dispositivo.

10.1 Conjunto de pruebas de compatibilidad (CTS)

Las implementaciones del dispositivo DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el Proyecto de código abierto de Android con el software de envío final del dispositivo. Además, los implementadores de dispositivos DEBEN utilizar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible, y DEBEN garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier reimplementación de partes del código fuente de referencia.

El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, el CTS puede contener errores. Se realizará un control de versiones del CTS independientemente de esta definición de compatibilidad, y es posible que se publiquen varias revisiones del CTS para Android 7.0. Las implementaciones del dispositivo DEBEN pasar la versión más reciente del CTS disponible en el momento en que se completa el software del dispositivo.

10.2. Verificador del CTS

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

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluidos algunos que son opcionales. Las implementaciones del dispositivo DEBEN superar todas las pruebas de hardware que posean. por ejemplo, si un dispositivo posee un acelerómetro, DEBE ejecutar correctamente el caso de prueba del acelerómetro en el verificador del CTS. PUEDEN omitirse o omitirse los casos de prueba de las funciones indicadas como opcionales en este Documento de definición de compatibilidad.

Todos los dispositivos y las compilaciones DEBEN ejecutar correctamente el verificador del CTS, como se indicó anteriormente. Sin embargo, dado que muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten explícitamente el verificador del CTS en compilaciones que difieren solo de maneras triviales. Específicamente, las implementaciones en dispositivos que difieren de una que aprobó el verificador del CTS solo por el conjunto de configuraciones regionales incluidas, marcas, etc. PUEDEN omitir la prueba del verificador del CTS.

11. Software actualizable

Las implementaciones del dispositivo DEBEN incluir un mecanismo para reemplazar todo el software del sistema. No es necesario que el mecanismo realice actualizaciones “en vivo”, es decir, PUEDE ser necesario reiniciar el dispositivo.

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

  • Descargas “inalámbricas” con actualización sin conexión mediante el reinicio
  • "Conexión mediante dispositivo móvil" se actualiza a través de USB desde una PC host.
  • "Sin conexión" se actualiza a través del reinicio y la actualización desde un archivo en almacenamiento extraíble.

Sin embargo, si la implementación del dispositivo incluye compatibilidad con una conexión de datos no medida, como el perfil 802.11 o Bluetooth PAN (red de área personal), DEBE admitir descargas inalámbricas con actualización sin conexión a través del reinicio.

El mecanismo de actualización utilizado DEBE admitir actualizaciones sin limpiar los datos del usuario. Es decir, el mecanismo de actualización DEBE preservar los datos privados y los datos compartidos de la aplicación. Ten en cuenta que el software upstream de Android incluye un mecanismo de actualización que cumple con este requisito.

Para las implementaciones en dispositivos que se lanzan con Android 7.0 y versiones posteriores, el mecanismo de actualización DEBE admitir la verificación de que la imagen del sistema sea idéntica al resultado esperado después de una actualización inalámbrica. La implementación inalámbrica basada en bloques del Proyecto de código abierto de Android ascendente, agregado a partir de Android 5.1, cumple con este requisito.

Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro de su ciclo de vida razonable del producto que se determina en consulta con el Equipo de compatibilidad de Android para afectar la compatibilidad de aplicaciones de terceros, el implementador de dispositivos DEBE corregir el error a través de una actualización de software disponible que pueda aplicarse al mecanismo descrito anteriormente.

Android incluye funciones que permiten que la app del propietario del dispositivo (si está presente) controle la instalación de actualizaciones del sistema. Para facilitar este proceso, el subsistema de actualización del sistema para dispositivos que informan android.software.device_admin DEBE implementar el comportamiento que se describe en la clase SystemUpdatePolicy.

12. Registro de cambios del documento

Para obtener un resumen de los cambios en la definición de compatibilidad de esta versión, consulta lo siguiente:

Para obtener un resumen de los cambios realizados en las secciones de persona:

  1. Introducción
  2. Tipos de dispositivos
  3. Software
  4. Empaquetado de la aplicación
  5. Multimedia
  6. Herramientas y opciones para desarrolladores
  7. Compatibilidad de hardware
  8. Rendimiento y potencia
  9. Modelo de seguridad
  10. Pruebas de compatibilidad de software
  11. Software actualizable
  12. Registro de cambios del documento
  13. Comunicarte con nosotros

12.1 Sugerencias para ver el registro de cambios

Los cambios se marcan de la siguiente manera:

  • CDD
    Cambios sustanciales en los requisitos de compatibilidad.

  • Documentos
    Cambios estéticos o relacionados con la compilación.

Para una mejor visualización, adjunta los parámetros de URL pretty=full y no-merges a las URLs de tu registro de cambios.

13. Comunícate con nosotros

Puedes unirte al foro de compatibilidad de Android y solicitar aclaraciones o plantear problemas que creas que no se tratan en el documento.