Definición de compatibilidad con Android 14

1. Introducción

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

El uso de “DEBE”, “NO DEBE”, “REQUERIDO”, “DEBE”, “NO DEBE”, “DEBE”, “NO DEBE”, “RECOMENDADO”, “PUEDE” y “OPCIONAL” es según el IETF. estándar definido en RFC2119 .

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

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

Cuando esta definición o las pruebas de software descritas en la sección 10 no dicen nada, son ambiguas o están incompletas, es responsabilidad del implementador del dispositivo garantizar la compatibilidad con las implementaciones existentes.

Por esta razón, el Proyecto de Código Abierto de Android es a la vez la implementación de referencia y preferida de Android. Se RECOMIENDA ENCARECIDAMENTE a los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente "ascendente" disponible en el Proyecto de código abierto de Android. Si bien hipotéticamente algunos componentes pueden reemplazarse con implementaciones alternativas, se RECOMIENDA ENCARECIDAMENTE no seguir esta práctica, ya que pasar las pruebas de software será sustancialmente más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluido y más allá del Compatibility Test Suite. Finalmente, tenga en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

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

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

La Sección 2 contiene todos los requisitos que se aplican a un tipo de dispositivo específico. Cada subsección de la Sección 2 está dedicada a un tipo de dispositivo específico.

Todos los demás requisitos, que se aplican universalmente a cualquier implementación de dispositivo Android, se enumeran en las secciones posteriores a la Sección 2 . Estos requisitos se denominan "Requisitos básicos" en este documento.

1.1.2. ID de requisito

El ID de requisito se asigna a los requisitos MUST.

  • La identificación se asigna únicamente para los requisitos MUST.
  • Los requisitos MUY RECOMENDADOS están marcados como [SR] pero no se asigna una ID.
  • La ID consta de: ID de tipo de dispositivo - ID de condición - ID de requisito (por ejemplo, C-0-1).

Cada ID se define de la siguiente manera:

  • ID de tipo de dispositivo (ver más en 2. Tipos de dispositivos )
    • C: Core (Requisitos que se aplican a todas las implementaciones de dispositivos Android)
    • H: dispositivo portátil Android
    • T: dispositivo de televisión Android
    • R: Implementación de Android Automotive
    • W: implementación de Android Watch
    • Pestaña: Implementación de tableta Android
  • ID de condición
    • Cuando el requisito es incondicional, este ID se establece en 0.
    • Cuando el requisito es condicional, se asigna 1 para la primera condición y el número aumenta en 1 dentro de la misma sección y el mismo tipo de dispositivo.
  • ID de requisito
    • Este ID comienza desde 1 y aumenta en 1 dentro de la misma sección y la misma condición.

1.1.3. ID de requisito en la Sección 2

Los ID de requisitos de la Sección 2 tienen dos partes. El primero corresponde a un ID de sección como se describe anteriormente. La segunda parte identifica el factor de forma y el requisito específico del factor de forma.

ID de sección seguido por el ID de requisito descrito anteriormente.

  • El ID de la Sección 2 consta de: ID de sección/ID de tipo de dispositivo - ID de condición - ID de requisito (por ejemplo, 7.4.3/A-0-1).

2. Tipos de dispositivos

El Proyecto de código abierto de Android proporciona una pila de software que se puede utilizar para una variedad de tipos de dispositivos y factores de forma. Para respaldar la seguridad en los dispositivos, se espera que la pila de software, incluido cualquier sistema operativo de reemplazo o una implementación de kernel alternativa, se ejecute en un entorno seguro como se describe en la sección 9 y en otras partes de este CDD. Hay algunos tipos de dispositivos que tienen un ecosistema de distribución de aplicaciones relativamente mejor establecido.

Esta sección describe esos tipos de dispositivos y los requisitos y recomendaciones adicionales aplicables a cada tipo de dispositivo.

Todas las implementaciones de dispositivos Android que no se ajusten a ninguno de los tipos de dispositivos descritos DEBEN cumplir todos los requisitos de las otras secciones de esta Definición de compatibilidad.

2.1 Configuraciones del dispositivo

Para conocer las principales diferencias en la configuración de hardware por tipo de dispositivo, consulte los requisitos específicos del dispositivo que aparecen a continuación en esta sección.

2.2. Requisitos de mano

Un dispositivo portátil Android se refiere a una implementación de dispositivo Android que normalmente se usa sosteniéndolo en la mano, como un reproductor de mp3, un teléfono o una tableta.

Las implementaciones de dispositivos Android se clasifican como dispositivos portátiles si cumplen con todos los criterios siguientes:

  • Contar con una fuente de energía que proporcione movilidad, como una batería.
  • Tener un tamaño de pantalla diagonal física en el rango de 4 pulgadas , 3,3 pulgadas (o 2,5 pulgadas para implementaciones de dispositivos que se enviaron con el nivel API 29 o anterior) a 8 pulgadas.
  • Tener una interfaz de entrada de pantalla táctil.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos portátiles Android.

Nota: Los requisitos que no se aplican a los dispositivos Tablet Android están marcados con un *.

2.2.1. Hardware

Implementaciones de dispositivos portátiles:

  • [ 7.1 .1.1/H-0-1] DEBE tener al menos una pantalla compatible con Android que cumpla con todos los requisitos descritos en este documento. pantalla que mida al menos 2,2” en el borde corto y 3,4” en el borde largo.
  • [ 7.1 .1.3/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE para brindar a los usuarios la posibilidad de cambiar el tamaño de la pantalla (densidad de la pantalla).

  • [ 7.1 .1.1/H-0-2] DEBE admitir la composición de búferes gráficos de GPU al menos tan grande como la resolución más alta de cualquier pantalla integrada.

Iniciar nuevos requisitos

  • [ 7.1 .1.1/H-0-3]* DEBE asignar cada pantalla UI_MODE_NORMAL disponible para aplicaciones de terceros en un área de pantalla física sin obstáculos que tenga al menos 2,2” pulgadas en el borde corto y 3,4” pulgadas en el borde largo.

  • [ 7.1 .1.3/H-0-1]* DEBE establecer el valor de DENSITY_DEVICE_STABLE para que sea 92% o mayor que la densidad física real de la pantalla correspondiente.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos portátiles admiten la rotación de pantalla del software,:

  • [ 7.1 .1.1/H-1-1]* DEBE hacer que la pantalla lógica que esté disponible para aplicaciones de terceros tenga al menos 2 pulgadas en los bordes cortos y 2,7 ​​pulgadas en los bordes largos. Los dispositivos que se enviaron con el nivel 29 de API de Android o anterior PUEDEN estar exentos de este requisito.

Si las implementaciones de dispositivos portátiles no admiten la rotación de pantalla del software, estas:

  • [ 7.1 .1.1/H-2-1]* DEBE hacer que la pantalla lógica que esté disponible para aplicaciones de terceros tenga al menos 2,7 pulgadas en los bordes cortos. Los dispositivos que se enviaron con el nivel 29 de API de Android o anterior PUEDEN estar exentos de este requisito.

Si las implementaciones de dispositivos portátiles afirman ser compatibles con pantallas de alto rango dinámico a través de Configuration.isScreenHdr() ,:

  • [ 7.1 .4.5/H-1-1] DEBE anunciar soporte para las extensiones EGL_EXT_gl_colorspace_bt2020_pq , EGL_EXT_surface_SMPTE2086_metadata , EGL_EXT_surface_CTA861_3_metadata , VK_EXT_swapchain_colorspace y VK_EXT_hdr_metadata .

Implementaciones de dispositivos portátiles:

  • [ 7.1 .4.6/H-0-1] DEBE informar si el dispositivo admite la capacidad de creación de perfiles de GPU a través de una propiedad del sistema graphics.gpu.profiler.support .

Si las implementaciones de dispositivos portátiles declaran soporte a través de una propiedad del sistema graphics.gpu.profiler.support ,:

Implementaciones de dispositivos portátiles:

  • [ 7.1 .5/H-0-1] DEBE incluir soporte para el modo de compatibilidad de aplicaciones heredadas tal como lo implementa el código fuente abierto de Android. Es decir, las implementaciones de dispositivos NO DEBEN alterar los desencadenantes o umbrales en los que se activa el modo de compatibilidad, y NO DEBEN alterar el comportamiento del modo de compatibilidad en sí.
  • [ 7.2 .1/H-0-1] DEBE incluir soporte para aplicaciones de editor de métodos de entrada (IME) de terceros.
  • [ 7.2 .3/H-0-2] DEBE enviar tanto el evento de pulsación normal como el de pulsación larga de la función Atrás ( KEYCODE_BACK ) a la aplicación de primer plano. Estos eventos NO DEBEN ser consumidos por el sistema y PUEDEN activarse desde fuera del dispositivo Android (por ejemplo, un teclado de hardware externo conectado al dispositivo Android).
  • [ 7.2 .3/H-0-3] DEBE proporcionar la función Inicio en todas las pantallas compatibles con Android que proporcionan la pantalla de inicio.
  • [ 7.2 .3/H-0-4] DEBE proporcionar la función Atrás en todas las pantallas compatibles con Android y la función Recientes en al menos una de las pantallas compatibles con Android.
  • [ 7.2 .4/H-0-1] DEBE admitir la entrada de pantalla táctil.
  • [ 7.2 .4/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE iniciar la aplicación de asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService, o una actividad que maneja ACTION_ASSIST al mantener presionada KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no maneja esos eventos de larga duración.
  • [ 7.3 .1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos portátiles incluyen un acelerómetro de 3 ejes, estos:

  • [ 7.3 .1/H-1-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.

Si las implementaciones de dispositivos portátiles incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través del indicador de función android.hardware.location.gps , estas:

  • [ 7.3 .3/H-2-1] DEBE informar las mediciones GNSS tan pronto como se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.
  • [ 7.3 .3/H-2-2 ] DEBEN informar los pseudodistancias y velocidades de pseudodistancia GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras están estacionarios o en movimiento con menos de 0,2 metros por segundo al cuadrado de aceleración, sean suficientes para calcular posición dentro de los 20 metros y velocidad dentro de los 0,2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos portátiles incluyen un giroscopio de 3 ejes, estos:

  • [ 7.3 .4/H-3-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.
  • [ 7.3.4 /H-3-2] DEBE ser capaz de medir cambios de orientación de hasta 1000 grados por segundo.

Implementaciones de dispositivos portátiles que pueden realizar una llamada de voz e indicar cualquier valor distinto de PHONE_TYPE_NONE en getPhoneType :

  • [ 7.3 .8/H] DEBE incluir un sensor de proximidad.

Implementaciones de dispositivos portátiles:

  • [ 7.3 .11/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir el sensor de pose con 6 grados de libertad.
  • [ 7.4 .3/H] DEBE incluir soporte para Bluetooth y Bluetooth LE.

Si los dispositivos admiten el protocolo WiFi Neighbor Awareness Networking (NAN) al declarar PackageManager.FEATURE_WIFI_AWARE y la ubicación de Wi-Fi (tiempo de ida y vuelta de Wi-Fi - RTT) al declarar PackageManager.FEATURE_WIFI_RTT , entonces:

  • [ 7.4 .2.5/H-1-1] DEBE informar el alcance con precisión dentro de +/-1 metro en un ancho de banda de 160 MHz en el percentil 68 (calculado con la función de distribución acumulativa), +/-2 metros en un ancho de banda de 80 MHz en el percentil 68, +/-4 metros con un ancho de banda de 40 MHz en el percentil 68 y +/-8 metros con un ancho de banda de 20 MHz en el percentil 68 a distancias de 10 cm, 1 m, 3 m y 5 m, como observado a través de la API de Android WifiRttManager#startRanging .

  • [ 7.4 .2.5/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE informar el alcance con precisión dentro de +/-1 metro en un ancho de banda de 160 MHz en el percentil 90 (calculado con la función de distribución acumulativa), +/-2 metros en Ancho de banda de 80 MHz en el percentil 90, +/-4 metros con un ancho de banda de 40 MHz en el percentil 90 y +/-8 metros con un ancho de banda de 20 MHz en el percentil 90 a distancias de 10 cm, como se observa a través de WifiRttManager#startRanging Android API .

Se RECOMIENDA ENCARECIDAMENTE seguir los pasos de configuración de medición especificados en Calibración de presencia .

Si las implementaciones de dispositivos portátiles incluyen una conexión medida,:

  • [ 7.4 .7/H-1-1] DEBE proporcionar el modo de ahorro de datos.

Si las implementaciones de dispositivos portátiles incluyen un dispositivo de cámara lógico que enumera las capacidades que utilizan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ,:

  • [ 7.5 .4/H-1-1] DEBE tener un campo de visión normal (FOV) de forma predeterminada y DEBE estar entre 50 y grados.

Implementaciones de dispositivos portátiles:

  • [ 7.6 .1/H-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").
  • [ 7.6 .1/H-0-2] DEBE devolver "verdadero" para ActivityManager.isLowRamDevice() cuando hay menos de 1 GB de memoria disponible para el kernel y el espacio de usuario.

Si las implementaciones de dispositivos portátiles declaran admitir solo una ABI de 32 bits:

  • [ 7.6 .1/H-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 416 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta qHD (por ejemplo, FWVGA).

  • [ 7.6 .1/H-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 592 MB si la pantalla predeterminada utiliza resoluciones de framebuffer hasta HD+ (por ejemplo, HD, WSVGA).

  • [ 7.6 .1/H-3-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta FHD (por ejemplo, WSXGA+).

  • [ 7.6 .1/H-4-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1344 MB si la pantalla predeterminada utiliza resoluciones de framebuffer hasta QHD (por ejemplo, QWXGA).

Si las implementaciones de dispositivos portátiles declaran compatibilidad con cualquier ABI de 64 bits (con o sin ABI de 32 bits):

  • [ 7.6 .1/H-5-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 816 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta qHD (por ejemplo, FWVGA).

  • [ 7.6 .1/H-6-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta HD+ (por ejemplo, HD, WSVGA).

  • [ 7.6 .1/H-7-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta FHD (por ejemplo, WSXGA+).

  • [ 7.6 .1/H-8-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1824 MB si la pantalla predeterminada utiliza resoluciones de framebuffer hasta QHD (por ejemplo, QWXGA).

Tenga en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior se refiere al espacio de memoria proporcionado además de cualquier memoria ya dedicada a componentes de hardware como radio, video, etc. que no están bajo el control del kernel en las implementaciones del dispositivo.

Si las implementaciones de dispositivos portátiles incluyen menos o igual a 1 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [ 7.6 .1/H-9-1] DEBE declarar el indicador de función android.hardware.ram.low .
  • [ 7.6 .1/H-9-2] DEBE tener al menos 1,1 GB de almacenamiento no volátil para los datos privados de la aplicación (también conocida como partición "/data").

Si las implementaciones de dispositivos portátiles incluyen más de 1 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [ 7.6 .1/H-10-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").
  • DEBE declarar el indicador de función android.hardware.ram.normal .

Si las implementaciones de dispositivos portátiles incluyen 2 GB o más y menos de 4 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [7.6.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir solo espacio de usuario de 32 bits (tanto aplicaciones como código del sistema)

Si las implementaciones de dispositivos portátiles incluyen menos de 2 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [7.6.1/H-1-1] DEBE admitir solo ABI de 32 bits.

Implementaciones de dispositivos portátiles:

  • [ 7.6 .2/H-0-1] NO DEBE proporcionar un almacenamiento compartido de aplicaciones de menos de 1 GiB.
  • [ 7.7 .1/H] DEBE incluir un puerto USB que admita el modo periférico.

Si las implementaciones de dispositivos portátiles incluyen un puerto USB que admite el modo periférico,:

  • [ 7.7 .1/H-1-1] DEBE implementar la API del accesorio abierto de Android (AOA).

Si las implementaciones de dispositivos portátiles incluyen un puerto USB que admite el modo host:

  • [ 7.7 .2/H-1-1] DEBE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.

Implementaciones de dispositivos portátiles:

  • [ 7.8 .1/H-0-1] DEBE incluir un micrófono.
  • [ 7.8 .2/H-0-1] DEBE tener una salida de audio y declarar android.hardware.audio.output .

Si las implementaciones de dispositivos portátiles son capaces de cumplir con todos los requisitos de rendimiento para admitir el modo VR e incluyen soporte para él,:

  • [ 7.9 .1/H-1-1] DEBE declarar el indicador de función android.hardware.vr.high_performance .
  • [ 7.9 .1/H-1-2] DEBE incluir una aplicación que implemente android.service.vr.VrListenerService que las aplicaciones de realidad virtual puedan habilitar a través de android.app.Activity#setVrModeEnabled .

Si las implementaciones de dispositivos portátiles incluyen uno o más puertos USB-C en modo host e implementan (clase de audio USB), además de los requisitos de la sección 7.7.2 ,:

  • [ 7.8 .2.2/H-1-1] DEBE proporcionar el siguiente mapeo de software de códigos HID:
Función Mapeos Contexto Comportamiento
A Página de uso de HID : 0x0C
Uso de HID : 0x0CD
Clave del núcleo : KEY_PLAYPAUSE
Clave de Android : KEYCODE_MEDIA_PLAY_PAUSE
Reproducción multimedia Entrada : pulsación corta
Salida : Reproducir o pausar
Entrada : pulsación larga
Salida : iniciar comando de voz
Envía : android.speech.action.VOICE_SEARCH_HANDS_FREE si el dispositivo está bloqueado o su pantalla está apagada. Envía android.speech.RecognizerIntent.ACTION_WEB_SEARCH de lo contrario
Llamada entrante Entrada : pulsación corta
Salida : Aceptar llamada
Entrada : pulsación larga
Salida : Rechazar llamada
llamada en curso Entrada : pulsación corta
Salida : Finalizar llamada
Entrada : pulsación larga
Salida : Silenciar o reactivar el micrófono
B Página de uso de HID : 0x0C
Uso de HID : 0x0E9
Clave del kernel : KEY_VOLUMEUP
Clave de Android : VOLUME_UP
Reproducción multimedia, llamada en curso Entrada : Pulsación corta o larga
Salida : aumenta el volumen del sistema o de los auriculares.
C Página de uso de HID : 0x0C
Uso de HID : 0x0EA
Clave del núcleo : KEY_VOLUMEDOWN
Clave de Android : VOLUME_DOWN
Reproducción multimedia, llamada en curso Entrada : Pulsación corta o larga
Salida : Disminuye el volumen del sistema o de los auriculares.
D Página de uso de HID : 0x0C
Uso de HID : 0x0CF
Clave del núcleo : KEY_VOICECOMMAND
Clave de Android : KEYCODE_VOICE_ASSIST
Todo. Puede activarse en cualquier caso. Entrada : Pulsación corta o larga
Salida : iniciar comando de voz
  • [ 7.8 .2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG al insertar un enchufe, pero solo después de que las interfaces de audio USB y los puntos finales se hayan enumerado correctamente para identificar el tipo de terminal conectado.

Cuando se detecta el terminal de audio USB tipo 0x0302,:

  • [ 7.8 .2.2/H-2-1] DEBE transmitir el Intent ACTION_HEADSET_PLUG con el "micrófono" adicional establecido en 0.

Cuando se detecta el terminal de audio USB tipo 0x0402,:

  • [ 7.8 .2.2/H-3-1] DEBE transmitir el Intent ACTION_HEADSET_PLUG con el "micrófono" adicional configurado en 1.

Cuando se llama a API AudioManager.getDevices() mientras el periférico USB está conectado:

  • [ 7.8 .2.2/H-4-1] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y la función isSink() si el campo de tipo de terminal de audio USB es 0x0302.

  • [ 7.8 .2.2/H-4-2] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y la función isSink() si el campo de tipo de terminal de audio USB es 0x0402.

  • [ 7.8 .2.2/H-4-3] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y la función isSource() si el campo de tipo de terminal de audio USB es 0x0402.

  • [ 7.8 .2.2/H-4-4] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y la función isSink() si el campo de tipo de terminal de audio USB es 0x603.

  • [ 7.8 .2.2/H-4-5] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y la función isSource() si el campo de tipo de terminal de audio USB es 0x604.

  • [ 7.8 .2.2/H-4-6] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y la función isSink() si el campo de tipo de terminal de audio USB es 0x400.

  • [ 7.8 .2.2/H-4-7] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y la función isSource() si el campo de tipo de terminal de audio USB es 0x400.

  • [ 7.8 .2.2/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE al conectar un periférico de audio USB-C, para realizar una enumeración de descriptores USB, identificar tipos de terminales y transmitir Intent ACTION_HEADSET_PLUG en menos de 1000 milisegundos.

Si las implementaciones de dispositivos portátiles declaran android.hardware.audio.output y android.hardware.microphone ,:

  • [ 5.6 /H-1-1] DEBE tener una latencia media continua de ida y vuelta de 300 milisegundos o menos en 5 mediciones, con una desviación media absoluta inferior a 30 ms , en las siguientes rutas de datos: "altavoz a micrófono", 3,5 mm adaptador de bucle invertido (si es compatible), bucle invertido USB (si es compatible).

  • [ 5.6 /H-1-2] DEBE tener una latencia promedio de toque a tono de 300 milisegundos o menos en al menos 5 mediciones a través de la ruta de datos del altavoz al micrófono.

Si las implementaciones de dispositivos portátiles incluyen al menos un actuador háptico, estos:

Un actuador resonante lineal (LRA) es un sistema de resorte de una sola masa que tiene una frecuencia resonante dominante donde la masa se traslada en la dirección del movimiento deseado.

Si las implementaciones de dispositivos portátiles incluyen al menos un actuador resonante lineal 7.10 de uso general , estos:

Iniciar nuevos requisitos

  • [ 7.10 /H] DEBE colocar el actuador cerca del lugar donde normalmente se sostiene o toca el dispositivo con las manos.

Terminar con nuevos requisitos

  • [ 7.10 /H] DEBE mover el actuador háptico en el eje X (izquierda-derecha) de la orientación vertical natural del dispositivo .

Si las implementaciones de dispositivos portátiles tienen un actuador háptico de uso general que es un actuador resonante lineal (LRA) del eje X,:

  • [ 7.10 /H] DEBE tener la frecuencia de resonancia del LRA del eje X por debajo de 200 Hz.

Si las implementaciones de dispositivos portátiles siguen el mapeo de constantes hápticas,:

2.2.2. Multimedia

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación y decodificación de audio y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.1 /H-0-1] RAM-NB
  • [ 5.1 /H-0-2] AMR-WB
  • [ 5.1 /H-0-3] Perfil MPEG-4 AAC (AAC LC)
  • [ 5.1 /H-0-4] Perfil MPEG-4 HE AAC (AAC+)
  • [ 5.1 /H-0-5] AAC ELD (AAC de bajo retardo mejorado)

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.2 /H-0-1] H.264 AVC
  • [ 5.2 /H-0-2] VP8

Iniciar nuevos requisitos

  • [ 5.2 /H-0-3] AV1

Terminar con nuevos requisitos

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.3 /H-0-1] H.264 AVC
  • [ 5.3 /H-0-2] H.265 HEVC
  • [ 5.3 /H-0-3] MPEG-4 SP
  • [ 5.3 /H-0-4] VP8
  • [ 5.3 /H-0-5] VP9

Iniciar nuevos requisitos

  • [ 5.3 /H-0-6] AV1

Terminar con nuevos requisitos

2.2.3. Software

Implementaciones de dispositivos portátiles:

  • [ 3.2.3.1 /H-0-1] DEBE tener una aplicación que maneje las intenciones ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT , ACTION_OPEN_DOCUMENT_TREE y ACTION_CREATE_DOCUMENT como se describe en los documentos del SDK, y proporcione al usuario la posibilidad de acceder a los datos del proveedor de documentos mediante la API DocumentsProvider .
  • [ 3.2.3.1 /H-0-2]* DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .
  • [ 3.2.3.1 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar una aplicación de correo electrónico que pueda manejar ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE intentos para enviar un correo electrónico.
  • [ 3.4 .1/H-0-1] DEBE proporcionar una implementación completa de la API android.webkit.Webview .
  • [ 3.4 .2/H-0-1] DEBE incluir una aplicación de navegador independiente para la navegación web del usuario general.
  • [ 3.8.1 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un iniciador predeterminado que admita la fijación de accesos directos, widgets y funciones de widgets en la aplicación.
  • [ 3.8 .1/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE implementar un iniciador predeterminado que proporcione acceso rápido a los accesos directos adicionales proporcionados por aplicaciones de terceros a través de la API ShortcutManager .
  • [ 3.8 .1/H-SR-3] Se RECOMIENDA ENCARECIDAMENTE incluir una aplicación de inicio predeterminada que muestre insignias para los íconos de las aplicaciones.
  • [ 3.8 .2/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE para admitir widgets de aplicaciones de terceros.
  • [ 3.8 .3/H-0-1] DEBE permitir que aplicaciones de terceros notifiquen a los usuarios sobre eventos notables a través de las clases API Notification y NotificationManager .
  • [ 3.8 .3/H-0-2] DEBE admitir notificaciones enriquecidas.
  • [ 3.8 .3/H-0-3] DEBE admitir notificaciones de aviso.
  • [ 3.8 .3/H-0-4] DEBE incluir un tono de notificación, que brinde al usuario la capacidad de controlar directamente (por ejemplo, responder, posponer, descartar, bloquear) las notificaciones a través de las posibilidades del usuario, como los botones de acción o el panel de control, según se implemente. en la AOSP.
  • [ 3.8 .3/H-0-5] DEBE mostrar las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el tono de notificación.
  • [ 3.8 .3/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar la primera opción proporcionada a través de RemoteInput.Builder setChoices() en el tono de notificación sin interacción adicional del usuario.
  • [ 3.8 .3/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE mostrar todas las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el tono de notificación cuando el usuario expande todas las notificaciones en el tono de notificación.
  • [ 3.8 .3.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar acciones para las cuales Notification.Action.Builder.setContextual está configurado como true en línea con las respuestas mostradas por Notification.Remoteinput.Builder.setChoices .
  • [ 3.8.4 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para manejar la acción de Asistencia .

Si las implementaciones de dispositivos portátiles admiten notificaciones MediaStyle :

  • [ 3.8 .3.1/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE proporcionar una opción para el usuario (por ejemplo, un conmutador de salida) a la que se accede desde la interfaz de usuario del sistema y que permite a los usuarios cambiar entre las rutas de medios disponibles apropiadas (por ejemplo, dispositivos Bluetooth y rutas proporcionadas para MediaRouter2Manager ) cuando una aplicación publica una notificación MediaStyle con un token MediaSession .

Iniciar nuevos requisitos

Si las implementaciones del dispositivo, incluida la tecla de navegación de la función reciente, como se detalla en la sección 7.2.3 , alteran la interfaz:

  • [ 3.8 .3/H-1-1] DEBE implementar el comportamiento de fijación de pantalla y proporcionar al usuario un menú de configuración para alternar la función.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos portátiles admiten la acción de asistencia, estas:

  • [ 3.8.4 /H-SR-2] Se RECOMIENDA ENCARECIDAMENTE utilizar una pulsación prolongada de la tecla HOME como interacción designada para iniciar la aplicación de asistencia como se describe en la sección 7.2.3 . DEBE iniciar la aplicación de asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que maneje la intención ACTION_ASSIST .

Si las implementaciones de dispositivos portátiles admiten conversation notifications y las agrupan en una sección separada de las alertas y las notificaciones silenciosas que no son de conversación,:

  • [ 3.8 .4/H-1-1]* DEBE mostrar las notificaciones de conversación antes que las notificaciones que no son de conversación, con la excepción de las notificaciones de servicio en primer plano en curso y las notificaciones de importancia: alta .

Si las implementaciones de dispositivos portátiles Android admiten una pantalla de bloqueo,:

  • [ 3.8 .10/H-1-1] DEBE mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación de medios.

Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura,:

Si las implementaciones de dispositivos portátiles incluyen soporte para ControlsProviderService y Control API y permiten que aplicaciones de terceros publiquen controles de dispositivos , entonces:

  • [ 3.8 .16/H-1-1] DEBE declarar el indicador de función android.software.controls y establecerlo en true .
  • [ 3.8 .16/H-1-2] DEBE proporcionar al usuario la posibilidad de agregar, editar, seleccionar y operar los controles del dispositivo favorito del usuario desde los controles registrados por las aplicaciones de terceros a través de ControlsProviderService y las API Control . .
  • [ 3.8 .16/H-1-3] DEBE proporcionar acceso a esta posibilidad de usuario dentro de tres interacciones desde un iniciador predeterminado.
  • [ 3.8 .16/H-1-4] DEBE representar con precisión en esta prestación de usuario el nombre y el icono de cada aplicación de terceros que proporciona controles a través de la API ControlsProviderService , así como cualquier campo especificado proporcionado por las API Control .

  • [ 3.8 .16/H-1-5] DEBE proporcionar al usuario la posibilidad de optar por no participar en los controles de dispositivos triviales de autenticación designados por la aplicación de los controles registrados por las aplicaciones de terceros a través de ControlsProviderService y la API Control Control.isAuthRequired .

Iniciar nuevos requisitos

  • [ 3.8 .16/H-1-6] Las implementaciones de dispositivos DEBEN ofrecer con precisión las posibilidades del usuario de la siguiente manera:
    • Si el dispositivo ha configurado config_supportsMultiWindow=true y la aplicación declara los metadatos META_DATA_PANEL_ACTIVITY en la declaración ControlsProviderService , incluido el ComponentName de una actividad válida (según lo definido por la API), entonces la aplicación DEBE incorporar dicha actividad en esta posibilidad de usuario.
    • Si la aplicación no declara metadatos META_DATA_PANEL_ACTIVITY , DEBE representar los campos especificados proporcionados por la API ControlsProviderService , así como cualquier campo especificado proporcionado por las API de control .
  • [ 3.8 .16/H-1-7] Si la aplicación declara los metadatos META_DATA_PANEL_ACTIVITY , DEBE pasar el valor de la configuración definida en [3.8.16/H-1-5] usando EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS al iniciar la actividad integrada.

Terminar con nuevos requisitos

Por el contrario, si las implementaciones de dispositivos portátiles no implementan dichos controles,:

Si las implementaciones de dispositivos portátiles no se ejecutan en modo de tarea de bloqueo , cuando el contenido se copia al portapapeles:

  • [3.8.17/H-1-1] DEBE presentar una confirmación al usuario de que los datos se han copiado al portapapeles (por ejemplo, una miniatura o alerta de “Contenido copiado”). Además, incluya aquí una indicación si los datos del portapapeles se sincronizarán entre dispositivos.

Implementaciones de dispositivos portátiles:

  • [ 3.10 /H-0-1] DEBE admitir servicios de accesibilidad de terceros.
  • [ 3.10 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad Switch Access y TalkBack (para idiomas admitidos por el motor de texto a voz preinstalado) según lo dispuesto en el proyecto de código abierto talkback .
  • [ 3.11 /H-0-1] DEBE admitir la instalación de motores TTS de terceros.
  • [ 3.11 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor TTS que admita los idiomas disponibles en el dispositivo.
  • [ 3.13 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un componente de interfaz de usuario de Configuración rápida.

Si las implementaciones de dispositivos portátiles Android declaran compatibilidad con FEATURE_BLUETOOTH o FEATURE_WIFI ,:

  • [ 3.16 /H-1-1] DEBE admitir la función de emparejamiento de dispositivos complementarios.

Si la función de navegación se proporciona como una acción en pantalla basada en gestos:

  • [ 7.2 .3/H] La zona de reconocimiento de gestos para la función Inicio no DEBE tener más de 32 dp de altura desde la parte inferior de la pantalla.

Si las implementaciones de dispositivos portátiles proporcionan una función de navegación como un gesto desde cualquier lugar de los bordes izquierdo y derecho de la pantalla:

  • [ 7.2 .3/H-0-1] El área de gestos de la función de navegación DEBE tener menos de 40 dp de ancho en cada lado. El área de gesto DEBE tener 24 dp de ancho de forma predeterminada.

Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura y tienen 2 GB o más de memoria disponible para el kernel y el espacio de usuario,:

  • [3.9/H-1-2] DEBE declarar la compatibilidad con perfiles administrados a través del indicador de función android.software.managed_users .

Si las implementaciones de dispositivos portátiles Android declaran la compatibilidad con la cámara a través de android.hardware.camera.any :

Si la aplicación de configuración de implementación del dispositivo implementa una funcionalidad dividida mediante la incrustación de actividades, entonces:

Iniciar nuevos requisitos

Si las implementaciones de dispositivos permiten a los usuarios realizar llamadas de cualquier tipo,

Terminar con nuevos requisitos

2.2.4. Rendimiento y potencia

  • [ 8.1 /H-0-1] Latencia de fotogramas consistente . La latencia de fotogramas inconsistente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia de 5 fotogramas por segundo, y DEBEN ser inferiores a 1 fotograma por segundo.
  • [ 8.1 /H-0-2] Latencia de la interfaz de usuario . Las implementaciones de dispositivos DEBEN garantizar una experiencia de usuario de baja latencia al desplazarse por una lista de 10.000 entradas de lista según lo definido por Android Compatibility Test Suite (CTS) en menos de 36 segundos.
  • [ 8.1 /H-0-3] Cambio de tarea . Cuando se han iniciado varias aplicaciones, volver a iniciar una aplicación que ya se está ejecutando después de haberla iniciado DEBE tardar menos de 1 segundo.

Implementaciones de dispositivos portátiles:

  • [ 8.2 /H-0-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 5 MB/s.
  • [ 8.2 /H-0-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 0,5 MB/s.
  • [ 8.2 /H-0-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 15 MB/s.
  • [ 8.2 /H-0-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 3,5 MB/s.

Si las implementaciones de dispositivos portátiles incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o amplían las funciones que se incluyen en AOSP, estas:

  • [ 8.3 /H-1-1] DEBE proporcionar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.
  • [ 8.3 /H-1-2] DEBE proporcionar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.

Implementaciones de dispositivos portátiles:

  • [ 8.4 /H-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [ 8.4 /H-0-2] DEBE informar todos los valores de consumo de energía en miliamperios hora (mAh).
  • [ 8.4 /H-0-3] DEBE informar el consumo de energía de la CPU por el UID de cada proceso. El proyecto de código abierto de Android cumple con el requisito mediante la implementación del módulo del kernel uid_cputime .
  • [ 8.4 /H-0-4] DEBE hacer que este uso de energía esté disponible a través del comando adb shell dumpsys batterystats shell para el desarrollador de la aplicación.
  • [ 8.4 /H] DEBE atribuirse al propio componente de hardware si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

Si las implementaciones de dispositivos portátiles incluyen una pantalla o salida de video,:

Implementaciones de dispositivos portátiles:

  • [ 8.5 /H-0-1] DEBE proporcionar al usuario una opción en el menú Configuración para ver todas las aplicaciones con servicios en primer plano activos o trabajos iniciados por el usuario, incluida la duración de cada uno de estos servicios desde que se inició, como se describe en el documento SDK. . y la capacidad de detener una aplicación que ejecuta un servicio en primer plano o un trabajo iniciado por el usuario. con la capacidad de detener una aplicación que está ejecutando un servicio en primer plano y mostrar todas las aplicaciones que tienen servicios en primer plano activos y la duración de cada uno de estos servicios desde que se inició, como se describe en el documento SDK .
    • Algunas aplicaciones PUEDEN estar exentas de ser detenidas o incluidas en una lista de opciones para el usuario como se describe en el documento SDK .

Iniciar nuevos requisitos

  • [ 8.5 /H-0-2]DEBE proporcionar al usuario la posibilidad de detener una aplicación que esté ejecutando un servicio en primer plano o un trabajo iniciado por el usuario.

Terminar con nuevos requisitos

2.2.5. Modelo de seguridad

Implementaciones de dispositivos portátiles:

  • [9/H-0-1] DEBE declarar la característica android.hardware.security.model.compatible .
  • [ 9.1 /H-0-1] DEBE permitir que aplicaciones de terceros accedan a las estadísticas de uso a través del permiso android.permission.PACKAGE_USAGE_STATS y proporcionar un mecanismo accesible para el usuario para otorgar o revocar el acceso a dichas aplicaciones en respuesta a android.settings.ACTION_USAGE_ACCESS_SETTINGS intención.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony ,:

  • [ 9.5 /H-1-1] NO DEBE establecer UserManager.isHeadlessSystemUserMode en true .

Terminar con nuevos requisitos

Implementaciones de dispositivos portátiles:

  • [ 9.11 /H-0-2] DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
  • [ 9.11 /H-0-3] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de las familias MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos admitidos del sistema Android Keystore en un área segura. aislado del código que se ejecuta en el kernel y superiores. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [ 9.11 /H-0-4] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislada y solo cuando tenga éxito, permita que se utilicen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El proyecto de código abierto de Android proporciona la capa de abstracción de hardware Gatekeeper (HAL) y Trusty, que se pueden utilizar para satisfacer este requisito.
  • [ 9.11 /H-0-5] DEBE admitir la atestación de clave donde la clave de firma de la atestación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad suficiente de dispositivos para evitar que se utilicen como identificadores de dispositivos. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Cuando las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura,:

  • [ 9.11 /H-1-1] DEBE permitir al usuario elegir el tiempo de espera más corto, es decir, un tiempo de transición del estado desbloqueado al estado bloqueado, de 15 segundos o menos.
  • [ 9.11 /H-1-2] DEBE brindar al usuario la posibilidad de ocultar notificaciones y deshabilitar todas las formas de autenticación, excepto la autenticación primaria descrita en 9.11.1 Pantalla de bloqueo seguro . El AOSP cumple con el requisito como modo de bloqueo.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza, que implementan la API del sistema TrustAgentService , ellos:

  • [ 9.11.1 /H-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (por ejemplo, PIN, patrón, contraseña) con más frecuencia que una vez cada 72 horas.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos portátiles incluyen varios usuarios y no declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /H-2-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

Si las implementaciones de dispositivos portátiles incluyen varios usuarios y declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /H-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir o deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos portátiles configuran UserManager.isHeadlessSystemUserMode en true ,

  • [ 9.5 /H-4-1] NO DEBE incluir soporte para eUICC ni para eSIM con capacidad de llamada.
  • [ 9.5 /H-4-2] NO DEBE declarar soporte para android.hardware.telephony .

Terminar con nuevos requisitos

Android, a través de la API del sistema VoiceInteractionService, admite un mecanismo para la detección segura de palabras activas siempre activas sin indicación de acceso al micrófono y la detección de consultas siempre activas, sin indicación de acceso al micrófono o a la cámara.

Si las implementaciones de dispositivos portátiles admiten System API HotwordDetectionService u otro mecanismo para la detección de palabras activas sin indicación de acceso al micrófono,:

  • [9.8/H-1-1] DEBE asegurarse de que el servicio de detección de palabras activas solo pueda transmitir datos al sistema, ContentCaptureService o al servicio de reconocimiento de voz en el dispositivo creado por SpeechRecognizer#createOnDeviceSpeechRecognizer() .
  • [9.8/H-1-2] DEBE asegurarse de que el servicio de detección de palabras activas solo pueda transmitir datos de audio del micrófono o datos derivados de él al servidor del sistema a través de la API HotwordDetectionService , o a ContentCaptureService a través de la API ContentCaptureManager .
  • [9.8/H-1-3] NO DEBE suministrar audio de micrófono que dure más de 30 segundos para una solicitud individual activada por hardware al servicio de detección de palabras activas.
  • [9.8/H-1-4] NO DEBE proporcionar audio de micrófono almacenado en búfer de más de 8 segundos para una solicitud individual al servicio de detección de palabras activas.
  • [9.8/H-1-5] NO DEBE suministrar audio de micrófono almacenado en buffer de más de 30 segundos al servicio de interacción de voz o entidad similar.
  • [9.8/H-1-6] NO DEBE permitir que se transmitan más de 100 bytes de datos (excluyendo secuencias de audio) fuera del servicio de detección de palabras activas en cada resultado exitoso de palabra activa.
  • [9.8/H-1-7] NO DEBE permitir que se transmitan más de 5 bits de datos fuera del servicio de detección de palabras activas en cada resultado negativo de palabra activa.
  • [9.8/H-1-8] DEBE permitir únicamente la transmisión de datos fuera del servicio de detección de palabras activas en una solicitud de validación de palabras activas del servidor del sistema.
  • [9.8/H-1-9] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección de palabras activas.
  • [9.8/H-1-10] NO DEBE aparecer en la interfaz de usuario datos cuantitativos sobre el uso del micrófono por parte del servicio de detección de palabras activas.
  • [9.8/H-1-11] DEBE registrar la cantidad de bytes incluidos en cada transmisión desde el servicio de detección de palabras activas para permitir la inspeccionabilidad por parte de los investigadores de seguridad.
  • [9.8/H-1-12] DEBE admitir un modo de depuración que registre el contenido sin procesar de cada transmisión desde el servicio de detección de palabras activas para permitir la inspeccionabilidad por parte de los investigadores de seguridad.
  • [9.8/H-1-13] DEBE reiniciar el proceso que aloja el servicio de detección de palabras activas al menos una vez cada hora o cada 30 eventos de activación de hardware, lo que ocurra primero.
  • [9.8/H-1-14] DEBE mostrar el indicador del micrófono, como se describe en la sección 9.8.2 , cuando se transmite un resultado exitoso de una palabra activa al servicio de interacción de voz o entidad similar.

Iniciar nuevos requisitos

  • [9.8/H-1-15] DEBE garantizar que los flujos de audio proporcionados cuando se obtienen resultados exitosos de palabras activas se transmitan en un sentido desde el servicio de detección de palabras activas al servicio de interacción de voz.

Terminar con nuevos requisitos

  • [9.8/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE notificar a los usuarios antes de configurar una aplicación como proveedor del servicio de detección de palabras activas.
  • [9.8/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE no permitir la transmisión de datos no estructurados fuera del servicio de detección de palabras activas.

Si las implementaciones del dispositivo incluyen una aplicación que utiliza la API del sistema HotwordDetectionService o un mecanismo similar para la detección de palabras activas sin indicación de uso del micrófono, la aplicación:

  • [9.8/H-2-1] DEBE proporcionar un aviso explícito al usuario para cada frase de palabra activa admitida.
  • [9.8/H-2-2] NO DEBE conservar datos de audio sin procesar, ni datos derivados de ellos, a través del servicio de detección de palabras activas.
  • [9.8/H-2-3] NO DEBE transmitir desde el servicio de detección de palabras clave, datos de audio, datos que puedan usarse para reconstruir (total o parcialmente) el audio, o contenidos de audio no relacionados con la palabra clave en sí, excepto al ContentCaptureService o Servicio de reconocimiento de voz en el dispositivo.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos portátiles admiten la API del sistema VisualQueryDetectionService u otro mecanismo para la detección de consultas sin indicación de acceso al micrófono o la cámara,:

  • [9.8/H-3-1] DEBE asegurarse de que el servicio de detección de consultas solo pueda transmitir datos al Sistema, o ContentCaptureService , o al servicio de reconocimiento de voz en el dispositivo (creado por SpeechRecognizer#createOnDeviceSpeechRecognizer() ).
  • [9.8/H-3-2] NO DEBE permitir que se transmita ninguna información de audio o video fuera de VisualQueryDetectionService , excepto a ContentCaptureService o al servicio de reconocimiento de voz en el dispositivo.
  • [9.8/H-3-3] DEBE mostrar un aviso de usuario en la interfaz de usuario del sistema cuando el dispositivo detecta la intención del usuario de interactuar con la aplicación de asistente digital (por ejemplo, detectando la presencia del usuario a través de la cámara).
  • [9.8/H-3-4] DEBE mostrar un indicador de micrófono y mostrar la consulta del usuario detectada en la interfaz de usuario inmediatamente después de que se detecta la consulta del usuario.
  • [9.8/H-3-5] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección visual de consultas.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos portátiles declaran android.hardware.microphone ,:

  • [ 9.8.2 /H-4-1] DEBE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede HotwordDetectionService , SOURCE_HOTWORD , ContentCaptureService o aplicaciones que desempeñan los roles mencionados en la sección 9.1 con identificador CDD [C-4-X].
  • [ 9.8.2 /H-4-2] DEBE mostrar la lista de aplicaciones recientes y activas que usan el micrófono según lo devuelto por PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.
  • [ 9.8.2 /H-4-3] No DEBE ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
  • [ 9.8.2 /H-4-4] DEBE mostrar la lista de aplicaciones recientes y activas que usan el micrófono tal como se devuelve desde PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.

Si las implementaciones de dispositivos portátiles declaran android.hardware.camera.any ,:

  • [ 9.8.2 /H-5-1] DEBE mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando solo acceden a la cámara las aplicaciones que desempeñan las funciones mencionadas en la sección 9.1 con el identificador CDD. [C-4-X].
  • [ 9.8.2 /H-5-2] DEBE mostrar las aplicaciones recientes y activas que usan la cámara tal como se devuelven desde PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.
  • [ 9.8.2 /H-5-3] No DEBE ocultar el indicador de la cámara para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

2.2.6. Compatibilidad de opciones y herramientas de desarrollador

Implementaciones de dispositivos portátiles (* No aplicable para tableta):

  • [ 6.1 /H-0-1]* DEBE admitir el comando de shell cmd testharness .

Implementaciones de dispositivos portátiles (* No aplicable para tableta):

  • perfecto
    • [ 6.1 /H-0-2]* DEBE exponer un binario /system/bin/perfetto al usuario del shell cuyo cmdline cumpla con la documentación de perfetto .
    • [ 6.1 /H-0-3]* El binario perfetto DEBE aceptar como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [ 6.1 /H-0-4]* El binario perfetto DEBE escribir como salida una traza de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [ 6.1 /H-0-5]* DEBE proporcionar, a través del binario perfetto, al menos las fuentes de datos descritas en la documentación de perfetto .
    • [ 6.1 /H-0-6]* El demonio rastreado de perfetto DEBE estar habilitado de forma predeterminada (propiedad del sistema persist.traced.enable ).

2.2.7. Clase de rendimiento de medios portátiles

Consulte la Sección 7.11 para conocer la definición de clase de rendimiento del medio.

2.2.7.1. Medios de comunicación

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

Iniciar nuevos requisitos

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

  • [5.1/H-1-1] DEBE anunciar el número máximo de sesiones de decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() .
  • [5.1/H-1-2] DEBE admitir 6 instancias de sesiones de decodificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, ​​AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con 3 sesiones con una resolución de 1080p a 30 fps y 3 sesiones a resolución 4k a 30 fps, a menos que AV1. Los códecs AV1 solo son necesarios para admitir una resolución de 1080p, pero aún así deben admitir 6 instancias a 1080p30fps.
  • [5.1/H-1-3] DEBE anunciar el número máximo de sesiones de codificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() .
  • [5.1/H-1-4] DEBE admitir 6 instancias de sesiones de codificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, ​​AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con 4 sesiones con una resolución de 1080p a 30 fps y 2 sesiones a resolución 4k a 30 fps, a menos que AV1. Los códecs AV1 solo son necesarios para admitir una resolución de 1080p, pero aún así deben admitir 6 instancias a 1080p30fps.
  • [5.1/H-1-5] DEBE anunciar el número máximo de sesiones de codificador y decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() .
  • [5.1/H-1-6] DEBE admitir 6 instancias de sesiones de decodificador de video por hardware (SDR) y codificador de video por hardware (AVC, HEVC, VP9, ​​AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con 3 sesiones en 4K Resolución de @30 fps (a menos que AV1), de las cuales como máximo 2 son sesiones de codificador y 3 sesiones con una resolución de 1080p. Los códecs AV1 solo son necesarios para admitir una resolución de 1080p, pero aún así deben admitir 6 instancias a 1080p30fps.
  • [5.1/H-1-19] DEBE admitir 3 instancias de sesiones de decodificador de video por hardware (HDR) y codificador de video por hardware (AVC, HEVC, VP9, ​​AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con una resolución de 4K a 30 fps. (a menos que AV1) de las cuales como máximo 1 es una sesión de codificador, que podría configurarse en formato de entrada RGBA_1010102 a través de una superficie GL. No se requiere la generación de metadatos HDR por parte del codificador si se codifica desde la superficie GL. Las sesiones de códec AV1 solo son necesarias para admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
  • [5.1/H-1-7] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de codificación de video de 1080p o menor para todos los codificadores de video de hardware cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de solo video de 1080p a 720p utilizando códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p. Para el códec Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
  • [5.1/H-1-8] DEBE tener una latencia de inicialización de códec de 30 ms o menos para una sesión de codificación de audio con una velocidad de bits de 128 kbps o inferior para todos los codificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de solo video de 1080p a 720p utilizando códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p.
  • [5.1/H-1-9] DEBE admitir 2 instancias de sesiones seguras de decodificador de video por hardware (AVC, HEVC, VP9, ​​AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con una resolución de 4k a 30 fps (a menos que AV1) para ambos 8- bits (SDR) y contenido HDR de 10 bits. Las sesiones de códec AV1 solo son necesarias para admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
  • [5.1/H-1-10] DEBE admitir 3 instancias de sesiones de decodificador de video de hardware no seguro junto con 1 instancia de sesión de decodificador de video de hardware seguro (4 instancias en total) (AVC, HEVC, VP9, ​​AV1 o posterior) en cualquier códec combinación que se ejecuta simultáneamente con 3 sesiones con resolución 4K a 30 fps (a menos que AV1) que incluye una sesión de decodificador seguro y 1 sesión nn-segura con resolución 1080p a 30 fps donde como máximo 2 sesiones pueden ser en HDR de 10 bits. Las sesiones de códec AV1 solo son necesarias para admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
  • [5.1/H-1-11] DEBE admitir un decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 o AV1 en el dispositivo.
  • [5.1/H-1-12] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de decodificación de video de 1080p o menor para todos los decodificadores de video de hardware cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de solo video de 1080p a 720p utilizando códecs de video de hardware junto con la inicialización de reproducción de audio y video de 1080p. Para el códec Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
  • [5.1/H-1-13] DEBE tener una latencia de inicialización del códec de 30 ms o menos para una sesión de decodificación de audio con una velocidad de bits de 128 kbps o inferior para todos los decodificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de solo video de 1080p a 720p utilizando códecs de video de hardware junto con la inicialización de reproducción de audio y video de 1080p.
  • [5.1/H-1-14] DEBE admitir el decodificador de hardware AV1 Main 10, nivel 4.1 y grano de película.
  • [5.1/H-1-15] DEBE tener al menos 1 decodificador de video de hardware compatible con 4K60.
  • [5.1/H-1-16] DEBE tener al menos 1 codificador de video de hardware compatible con 4K60.
  • [5.3/H-1-1] NO DEBE perder más de 1 fotograma en 10 segundos (es decir, menos del 0,167 por ciento de pérdida de fotogramas) para una sesión de vídeo 4K a 60 fps bajo carga.
  • [5.3/H-1-2] NO DEBE perder más de 1 cuadro en 10 segundos durante un cambio de resolución de video en una sesión de video de 60 fps bajo carga para una sesión de 4K.
  • [5.6/H-1-1] DEBE tener una latencia de pulsación para tono de 80 milisegundos o menos usando la prueba de pulsación para tono de CTS Verifier.
  • [5.6/H-1-2] DEBE tener una latencia de audio de ida y vuelta de 80 milisegundos o menos en al menos una ruta de datos admitida.
  • [5.6/H-1-3] DEBE admitir >= audio de 24 bits para salida estéreo a través de conectores de audio de 3,5 mm si están presentes y a través de audio USB si es compatible con toda la ruta de datos para configuraciones de transmisión y baja latencia. Para la configuración de baja latencia, la aplicación debe utilizar AAudio en modo de devolución de llamada de baja latencia. Para la configuración de transmisión, la aplicación debe utilizar Java AudioTrack. Tanto en la configuración de baja latencia como en la de transmisión, el receptor de salida HAL debe aceptar AUDIO_FORMAT_PCM_24_BIT , AUDIO_FORMAT_PCM_24_BIT_PACKED , AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT para su formato de salida de destino.
  • [5.6/H-1-4] DEBE admitir >= dispositivos de audio USB de 4 canales (esto lo utilizan los controladores de DJ para obtener una vista previa de las canciones).
  • [5.6/H-1-5] DEBE admitir dispositivos MIDI compatibles con su clase y declarar el indicador de función MIDI.
  • [5.6/H-1-9] DEBE admitir al menos 12 canales de mezcla. Esto implica la capacidad de abrir una AudioTrack con máscara de canal 7.1.4 y espacializar o mezclar adecuadamente todos los canales a estéreo.
  • [5.6/H-SR] Se RECOMIENDA ENCARECIDAMENTE admitir mezcla de 24 canales con al menos soporte para máscaras de 9.1.6 y 22.2 canales.
  • [5.7/H-1-2] DEBE admitir MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con las siguientes capacidades de descifrado de contenido.
Tamaño mínimo de muestra 4 MB
Número mínimo de submuestras: H264 o HEVC 32
Número mínimo de submuestras - VP9 9
Número mínimo de submuestras - AV1 288
Tamaño mínimo del búfer de submuestra 1 MB
Tamaño mínimo del búfer criptográfico genérico 500 KiB
Número mínimo de sesiones simultáneas 30
Número mínimo de claves por sesión 20
Número total mínimo de claves (todas las sesiones) 80
Número total mínimo de claves DRM (todas las sesiones) 6
Tamaño del mensaje 16 KiB
Cuadros descifrados por segundo 60 fps
  • [5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes de hardware compatible con AVIF Baseline Profile.
  • [5.1/H-1-18] DEBE admitir el codificador AV1 que puede codificar una resolución de hasta 480p a 30 fps y 1 Mbps.
  • [5.12/H-1-1] DEBE [5.12/H-SR] Se recomienda encarecidamente para admitir la función Feature_HdrEditing para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
  • [5.12/H-1-2] DEBE admitir el formato de color RGBA_1010102 para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
  • [5.12/H-1-3] DEBE anunciar soporte para la extensión EXT_YUV_target para muestrear texturas YUV tanto en 8 como en 10 bits.
  • [7.1.4/H-1-1] DEBE tener al menos 6 superposiciones de hardware en el compositor de hardware (HWC) de la unidad de procesamiento de datos (DPU), y al menos 2 de ellas capaces de mostrar contenido de video de 10 bits.

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e incluyen soporte para un codificador de hardware AVC o HEVC, entonces:

Terminar con nuevos requisitos

2.2.7.2. Cámara

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

Iniciar nuevos requisitos

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

  • [ 7.5 /H-1-1] DEBE tener una cámara trasera principal con una resolución de al menos 12 megapíxeles que admita captura de video a 4k@30fps. La cámara trasera principal es la cámara trasera con el ID de cámara más bajo.
  • [ 7.5 /H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 6 megapíxeles y admitir captura de video a 1080p@30fps. La cámara frontal principal es la cámara frontal con el ID de cámara más bajo.
  • [ 7.5 /H-1-3] DEBE admitir la propiedad android.info.supportedHardwareLevel como COMPLETA o mejor para ambas cámaras principales.
  • [ 7.5 /H-1-4] DEBE admitir CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para ambas cámaras principales.
  • [ 7.5 /H-1-5] DEBE tener una latencia de captura JPEG de la cámara 2 < 1000 900 ms para una resolución de 1080p según lo medido por la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000K) para ambas cámaras principales.
  • [ 7.5 /H-1-6] DEBE tener una latencia de inicio de la cámara 2 (cámara abierta al primer fotograma de vista previa) < 500 ms, según lo medido por la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000 K) para ambas cámaras principales.
  • [ 7.5 /H-1-8] DEBE admitir CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW y android.graphics.ImageFormat.RAW_SENSOR para la cámara trasera principal.
  • [ 7.5 /H-1-9] DEBE tener una cámara principal orientada hacia atrás que admita 720p o 1080p a 240 fps.
  • [ 7.5 /H-1-10] DEBE tener ZOOM_RATIO mínimo < 1.0 para las cámaras principales si hay una cámara RGB ultra ancha orientada en la misma dirección.
  • [ 7.5 /H-1-11] DEBE implementar transmisión simultánea de adelante hacia atrás en las cámaras principales.
  • [ 7.5 /H-1-12] DEBE admitir CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION tanto para la cámara frontal principal como para la cámara trasera principal.
  • [ 7.5 /H-1-13] DEBE admitir la capacidad LOGICAL_MULTI_CAMERA para la cámara trasera principal si hay más de 1 cámara trasera RGB.
  • [ 7.5 /H-1-14] DEBE admitir la capacidad STREAM_USE_CASE tanto para la cámara frontal principal como para la trasera principal.
  • [ 7.5 /H-1-15] DEBE admitir extensiones de modo Bokeh y nocturno a través de las extensiones CameraX y Camera2 para las cámaras principales.
  • [ 7.5 /H-1-16] DEBE admitir la capacidad DYNAMIC_RANGE_TEN_BIT para las cámaras principales.
  • [ 7.5 /H-1-17] DEBE admitir CONTROL_SCENE_MODE_FACE_PRIORITY y detección de rostros ( STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL ) para las cámaras principales.

Terminar con nuevos requisitos

2.2.7.3. Hardware

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

Iniciar nuevos requisitos

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

  • [7.1.1.1/H-2-1] DEBE tener una resolución de pantalla de al menos 1080p.
  • [7.1.1.3/H-2-1] DEBE tener una densidad de pantalla de al menos 400 ppp.
  • [7.1.1.3/H-3-1] DEBE tener una pantalla HDR que admita al menos 1000 nits en promedio.
  • [7.6.1/H-2-1] DEBE tener al menos 8 GB de memoria física.

Terminar con nuevos requisitos

2.2.7.4. Actuación

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

Iniciar nuevos requisitos

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:

  • [8.2/H-1-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 150 MB/s.
  • [8.2/H-1-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 10 MB/s.
  • [8.2/H-1-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 250 MB/s.
  • [8.2/H-1-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 100 MB/s.
  • [8.2/H-1-5] DEBE garantizar un rendimiento de lectura y escritura secuencial paralela con un rendimiento de lectura 2x y escritura 1x de al menos 50 MB/s.

Terminar con nuevos requisitos

2.3. Requisitos de televisión

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

Las implementaciones de dispositivos Android se clasifican como Televisión si cumplen con todos los criterios siguientes:

  • Han proporcionado un mecanismo para controlar de forma remota la interfaz de usuario representada en la pantalla que podría estar a tres metros de distancia del usuario.
  • Tener una pantalla integrada con una longitud diagonal superior a 24 pulgadas O incluir un puerto de salida de video, como VGA, HDMI, DisplayPort o un puerto inalámbrico para visualización.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos Android Television.

2.3.1. Hardware

Implementaciones de dispositivos de televisión:

  • [ 7.2 .2/T-0-1] DEBE admitir D-pad .
  • [ 7.2 .3/T-0-1] DEBE proporcionar las funciones Inicio y Atrás.
  • [ 7.2 .3/T-0-2] DEBE enviar tanto el evento de pulsación normal como el de pulsación larga de la función Atrás ( KEYCODE_BACK ) a la aplicación de primer plano.
  • [ 7.2 .6.1/T-0-1] DEBE incluir soporte para controladores de juegos y declarar el indicador de función android.hardware.gamepad .
  • [ 7.2.7 /T] DEBE proporcionar un control remoto desde el cual los usuarios puedan acceder a la navegación no táctil y a las entradas de las teclas de navegación principales .

Si las implementaciones de dispositivos de televisión incluyen un giroscopio de 3 ejes, estos:

  • [ 7.3 .4/T-1-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.
  • [ 7.3.4 /T-1-2] DEBE ser capaz de medir cambios de orientación de hasta 1000 grados por segundo.

Implementaciones de dispositivos de televisión:

  • [ 7.4 .3/T-0-1] DEBE admitir Bluetooth y Bluetooth LE.
  • [ 7.6 .1/T-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").

Si las implementaciones de dispositivos de televisión incluyen un puerto USB que admite el modo host,:

  • [ 7.5 .3/T-1-1] DEBE incluir soporte para una cámara externa que se conecta a través de este puerto USB pero que no necesariamente está siempre conectada.

Si las implementaciones de dispositivos de TV son de 32 bits:

  • [ 7.6 .1/T-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si se utiliza cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes

Si las implementaciones de dispositivos de TV son de 64 bits:

  • [ 7.6 .1/T-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se utiliza cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes

Tenga en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior se refiere al espacio de memoria proporcionado además de cualquier memoria ya dedicada a componentes de hardware como radio, video, etc. que no están bajo el control del kernel en las implementaciones del dispositivo.

Implementaciones de dispositivos de televisión:

  • [ 7.8 .1/T] DEBE incluir un micrófono.
  • [ 7.8 .2/T-0-1] DEBE tener una salida de audio y declarar android.hardware.audio.output .

2.3.2. Multimedia

Las implementaciones de dispositivos de televisión DEBEN admitir los siguientes formatos de codificación y decodificación de audio y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.1 /T-0-1] Perfil MPEG-4 AAC (AAC LC)
  • [ 5.1 /T-0-2] Perfil MPEG-4 HE AAC (AAC+)
  • [ 5.1 /T-0-3] AAC ELD (AAC de bajo retardo mejorado)

Las implementaciones de dispositivos de televisión DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.2 /T-0-1] H.264
  • [ 5.2 /T-0-2] VP8

Iniciar nuevos requisitos

  • [ 5.2 /T-0-3] AV1

Terminar con nuevos requisitos

Implementaciones de dispositivos de televisión:

  • [ 5.2 .2/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir la codificación H.264 de vídeos con resolución de 720p y 1080p a 30 fotogramas por segundo.

Las implementaciones de dispositivos de televisión DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:

Iniciar nuevos requisitos

Terminar con nuevos requisitos

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación MPEG-2, como se detalla en la Sección 5.3.1, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.1 /T-1-1] HD 1080p a 29,97 cuadros por segundo con perfil principal de alto nivel.
  • [ 5.3.1 /T-1-2] HD 1080i a 59,94 cuadros por segundo con perfil principal de alto nivel. DEBEN desentrelazar el vídeo MPEG-2 entrelazado y ponerlo a disposición de aplicaciones de terceros.

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación H.264, como se detalla en la Sección 5.3.4, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.4 /T-1-1] HD 1080p a 60 cuadros por segundo con Baseline Profile
  • [ 5.3.4 /T-1-2] HD 1080p a 60 fotogramas por segundo con perfil principal
  • [ 5.3.4 /T-1-3] HD 1080p a 60 cuadros por segundo con High Profile Level 4.2

Las implementaciones de dispositivos de televisión con decodificadores de hardware H.265 DEBEN admitir la decodificación H.265, como se detalla en la Sección 5.3.5, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.5 /T-1-1] HD 1080p a 60 fotogramas por segundo con perfil principal nivel 4.1

Si las implementaciones de dispositivos de televisión con decodificadores de hardware H.265 admiten la decodificación H.265 y el perfil de decodificación UHD,:

  • [ 5.3.5 /T-2-1] DEBE admitir el perfil de decodificación UHD a 60 cuadros por segundo con el perfil Main10 Nivel 5 Main Tier

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación VP8, como se detalla en la Sección 5.3.6, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.6 /T-1-1] Perfil de decodificación HD 1080p a 60 fotogramas por segundo

Las implementaciones de dispositivos de televisión con decodificadores de hardware VP9 DEBEN admitir la decodificación VP9, ​​como se detalla en la Sección 5.3.7, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.7 /T-1-1] HD 1080p a 60 fotogramas por segundo con perfil 0 (profundidad de color de 8 bits)

Si las implementaciones de dispositivos de televisión con decodificadores de hardware VP9 admiten la decodificación VP9 y el perfil de decodificación UHD,:

  • [ 5.3.7 /T-2-1] DEBE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil 0 (profundidad de color de 8 bits).
  • [ 5.3.7 /T-SR1] Se RECOMIENDA ENCARECIDAMENTE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil 2 (profundidad de color de 10 bits).

Implementaciones de dispositivos de televisión:

  • [ 5.5 /T-0-1] DEBE incluir soporte para el volumen maestro del sistema y la atenuación del volumen de salida de audio digital en las salidas admitidas, excepto para la salida de paso de audio comprimido (donde no se realiza ninguna decodificación de audio en el dispositivo).

Si las implementaciones de dispositivos de televisión no tienen una pantalla incorporada, pero admiten una pantalla externa conectada a través de HDMI,:

  • [ 5.8 /T-0-1] DEBE configurar el modo de salida HDMI en la resolución más alta para el formato SDR o HDR elegido que funcione con una frecuencia de actualización de 50 Hz o 60 Hz para la pantalla externa. DEBE configurar el modo de salida HDMI para seleccionar la resolución máxima que puede admitirse con una frecuencia de actualización de 50 Hz o 60 Hz.
  • [ 5.8 /T-SR-1] Se RECOMIENDA ENCARECIDAMENTE proporcionar un selector de frecuencia de actualización HDMI configurable por el usuario.
  • [ 5.8 ] DEBE configurar la frecuencia de actualización del modo de salida HDMI en 50 Hz o 60 Hz, dependiendo de la frecuencia de actualización de video para la región en la que se vende el dispositivo.

Si las implementaciones de dispositivos de televisión no tienen una pantalla incorporada, pero admiten una pantalla externa conectada a través de HDMI,:

  • [ 5.8 /T-1-1] DEBE ser compatible con HDCP 2.2.

Si las implementaciones de dispositivos de televisión no admiten la decodificación UHD, pero admiten una pantalla externa conectada a través de HDMI,:

  • [ 5.8 /T-2-1] DEBE ser compatible con HDCP 1.4

2.3.3. Software

Implementaciones de dispositivos de televisión:

  • [ 3 /T-0-1] DEBE declarar las funciones android.software.leanback y android.hardware.type.television .
  • [ 3.2.3.1 /T-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .
  • [ 3.4 .1/T-0-1] DEBE proporcionar una implementación completa de la API android.webkit.Webview .

Si las implementaciones de dispositivos Android Television admiten una pantalla de bloqueo,:

  • [ 3.8 .10/T-1-1] DEBE mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación de medios.

Implementaciones de dispositivos de televisión:

  • [ 3.8 .14/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir el modo de ventana múltiple de imagen en imagen (PIP).
  • [ 3.10 /T-0-1] DEBE admitir servicios de accesibilidad de terceros.
  • [ 3.10 /T-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad Switch Access y TalkBack (para idiomas admitidos por el motor de texto a voz preinstalado) según lo dispuesto en el proyecto de código abierto talkback .

Si las implementaciones de dispositivos de televisión informan la función android.hardware.audio.output ,:

  • [ 3.11 /T-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor TTS que admita los idiomas disponibles en el dispositivo.
  • [ 3.11 /T-1-1] DEBE admitir la instalación de motores TTS de terceros.

Implementaciones de dispositivos de televisión:

  • [ 3.12 /T-0-1] DEBE admitir el marco de entrada de TV.

2.3.4. Rendimiento y potencia

  • [ 8.1 /T-0-1] Latencia de fotogramas consistente . La latencia de fotogramas inconsistente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia de 5 fotogramas por segundo, y DEBEN ser inferiores a 1 fotograma por segundo.
  • [ 8.2 /T-0-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 5 MB/s.
  • [ 8.2 /T-0-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 0,5 MB/s.
  • [ 8.2 /T-0-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 15 MB/s.
  • [ 8.2 /T-0-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 3,5 MB/s.

Si las implementaciones de dispositivos de televisión incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o amplían las funciones que se incluyen en AOSP, estas:

  • [ 8.3 /T-1-1] DEBE proporcionar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.

Si las implementaciones de dispositivos de televisión no tienen batería:

Si las implementaciones de dispositivos de televisión tienen batería:

  • [ 8.3 /T-1-3] DEBE proporcionar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.

Implementaciones de dispositivos de televisión:

  • [ 8.4 /T-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [ 8.4 /T-0-2] DEBE informar todos los valores de consumo de energía en miliamperios hora (mAh).
  • [ 8.4 /T-0-3] DEBE informar el consumo de energía de la CPU por el UID de cada proceso. El proyecto de código abierto de Android cumple con el requisito mediante la implementación del módulo del kernel uid_cputime .
  • [ 8.4 /T] DEBE atribuirse al propio componente de hardware si no se puede atribuir el uso de energía del componente de hardware a una aplicación.
  • [ 8.4 /T-0-4] DEBE hacer que este uso de energía esté disponible a través del comando adb shell dumpsys batterystats shell para el desarrollador de la aplicación.

2.3.5. Modelo de seguridad

Implementaciones de dispositivos de televisión:

  • [9/T-0-1] DEBE declarar la característica android.hardware.security.model.compatible .
  • [ 9.11 /T-0-1] DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
  • [ 9.11 /T-0-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de las familias MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos admitidos del sistema Android Keystore en un área que esté aislada de forma segura. del código que se ejecuta en el kernel y superior. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [ 9.11 /T-0-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislada y solo cuando tenga éxito, permita que se utilicen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El proyecto de código abierto de Android proporciona la capa de abstracción de hardware Gatekeeper (HAL) y Trusty, que se pueden utilizar para satisfacer este requisito.
  • [ 9.11 /T-0-4] DEBE admitir la atestación de clave donde la clave de firma de atestación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad suficiente de dispositivos para evitar que se utilicen como identificadores de dispositivos. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Si las implementaciones de dispositivos de televisión admiten una pantalla de bloqueo segura,:

  • [ 9.11 /T-1-1] DEBE permitir al usuario elegir el tiempo de espera para la transición del estado desbloqueado al estado bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos o menos.

Si las implementaciones de dispositivos de televisión incluyen varios usuarios y no declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /T-2-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

Si las implementaciones de dispositivos de televisión incluyen varios usuarios y declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /T-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir/deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

Si las implementaciones de dispositivos de televisión declaran android.hardware.microphone ,:

  • [ 9.8.2 /T-4-1] DEBE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o aplicaciones que desempeñan los roles mencionados en Sección 9.1 Permisos con identificador CDD C-3-X].
  • [ 9.8.2 /T-4-2] No DEBE ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

Si las implementaciones de dispositivos de televisión declaran android.hardware.camera.any ,:

  • [ 9.8.2 /T-5-1] DEBE mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando solo acceden a la cámara las aplicaciones que desempeñan las funciones mencionadas en la Sección 9.1 Permisos con CDD identificador [C-3-X].
  • [ 9.8.2 /T-5-2] No DEBE ocultar el indicador de la cámara para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

2.3.6. Compatibilidad de opciones y herramientas de desarrollador

Implementaciones de dispositivos de televisión:

2.4. Requisitos del reloj

Un dispositivo Android Watch se refiere a una implementación de dispositivo Android destinada a usarse en el cuerpo, tal vez en la muñeca.

Las implementaciones de dispositivos Android se clasifican como Watch si cumplen con todos los criterios siguientes:

  • Tener una pantalla con una longitud diagonal física en el rango de 1,1 a 2,5 pulgadas.
  • Disponer de un mecanismo para llevar en el cuerpo.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos Android Watch.

2.4.1. Hardware

Ver implementaciones de dispositivos:

  • [ 7.1 .1.1/W-0-1] DEBE tener una pantalla con un tamaño diagonal físico en el rango de 1,1 a 2,5 pulgadas.

  • [ 7.2 .3/W-0-1] DEBE tener la función Inicio disponible para el usuario y la función Atrás excepto cuando está en UI_MODE_TYPE_WATCH .

  • [ 7.2 .4/W-0-1] DEBE admitir la entrada de pantalla táctil.

  • [ 7.3 .1/W-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos Watch incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través del indicador de función android.hardware.location.gps , estas:

  • [ 7.3 .3/W-1-1] DEBE informar las mediciones GNSS tan pronto como se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.
  • [ 7.3 .3/W-1-2 ] DEBE informar los pseudodistancias y velocidades de pseudodistancia GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras está estacionario o en movimiento con menos de 0,2 metros por segundo al cuadrado de aceleración, sean suficientes para calcular posición dentro de los 20 metros y velocidad dentro de los 0,2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones del dispositivo Watch incluyen un giroscopio de 3 ejes,:

  • [ 7.3.4 /W-2-1] DEBE ser capaz de medir cambios de orientación de hasta 1000 grados por segundo.

Ver implementaciones de dispositivos:

  • [ 7.4 .3/W-0-1] DEBE ser compatible con Bluetooth.

  • [ 7.6 .1/W-0-1] DEBE tener al menos 1 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").

  • [ 7.6 .1/W-0-2] DEBE tener al menos 416 MB de memoria disponible para el kernel y el espacio de usuario.

  • [ 7.8 .1/W-0-1] DEBE incluir un micrófono.

  • [ 7.8.2 /W] PUEDE tener salida de audio.

2.4.2. Multimedia

Sin requisitos adicionales.

2.4.3. Software

Ver implementaciones de dispositivos:

  • [ 3 /W-0-1] DEBE declarar la característica android.hardware.type.watch .
  • [ 3 /W-0-2] DEBE admitir uiMode = UI_MODE_TYPE_WATCH .
  • [ 3.2.3.1 /W-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .

Ver implementaciones de dispositivos:

  • [ 3.8 .4/W-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para manejar la acción de asistencia .

Observe las implementaciones de dispositivos que declaran el indicador de función android.hardware.audio.output :

  • [ 3.10 /W-1-1] DEBE admitir servicios de accesibilidad de terceros.
  • [ 3.10 /W-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad Switch Access y TalkBack (para idiomas admitidos por el motor de texto a voz preinstalado) según lo dispuesto en el proyecto de código abierto talkback .

Si las implementaciones de dispositivos Watch informan la función android.hardware.audio.output,:

  • [ 3.11 /W-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor TTS que admita los idiomas disponibles en el dispositivo.

  • [ 3.11 /W-0-1] DEBE admitir la instalación de motores TTS de terceros.

2.4.4. Rendimiento y potencia

Si las implementaciones de dispositivos Watch incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o amplían las funciones que se incluyen en AOSP, estas:

  • [ 8.3 /W-SR-1] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.
  • [ 8.3 /W-SR-2] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.

Ver implementaciones de dispositivos:

  • [ 8.4 /W-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [ 8.4 /W-0-2] DEBE informar todos los valores de consumo de energía en miliamperios hora (mAh).
  • [ 8.4 /W-0-3] DEBE informar el consumo de energía de la CPU por el UID de cada proceso. El proyecto de código abierto de Android cumple con el requisito mediante la implementación del módulo del kernel uid_cputime .
  • [ 8.4 /W-0-4] DEBE hacer que este uso de energía esté disponible a través del comando adb shell dumpsys batterystats shell para el desarrollador de la aplicación.
  • [ 8.4 /W] DEBE atribuirse al propio componente de hardware si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

2.4.5. Modelo de seguridad

Ver implementaciones de dispositivos:

  • [9/W-0-1] DEBE declarar la característica android.hardware.security.model.compatible .

Si las implementaciones de dispositivos Watch incluyen varios usuarios y no declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /W-1-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

Si las implementaciones de dispositivos Watch incluyen varios usuarios y declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /W-2-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir o deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza, que implementan la API del sistema TrustAgentService , ellos:

  • [ 9.11.1 /W-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (por ejemplo, PIN, patrón, contraseña) con más frecuencia que una vez cada 72 horas.

Terminar con nuevos requisitos

2.5. Requisitos automotrices

La implementación de Android Automotive se refiere a la unidad principal de un vehículo que ejecuta Android como sistema operativo para parte o la totalidad del sistema y/o la funcionalidad de infoentretenimiento.

Las implementaciones de dispositivos Android se clasifican como automotrices si declaran la característica android.hardware.type.automotive o cumplen con todos los criterios siguientes.

  • Están integrados como parte de un vehículo automotor o se pueden conectar a él.
  • Están utilizando una pantalla en la fila del asiento del conductor como pantalla principal.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos Android Automotive.

2.5.1. Hardware

Implementaciones de dispositivos automotrices:

  • [ 7.1 .1.1/A-0-1] DEBE tener una pantalla de al menos 6 pulgadas de tamaño diagonal físico.
  • [ 7.1 .1.1/A-0-2] DEBE tener un diseño de tamaño de pantalla de al menos 750 dp x 480 dp.
  • [ 7.2 .3/A-0-1] DEBE proporcionar la función Inicio y PUEDE proporcionar funciones Atrás y Recientes.
  • [ 7.2 .3/A-0-2] DEBE enviar tanto el evento de pulsación normal como el de pulsación larga de la función Atrás ( KEYCODE_BACK ) a la aplicación de primer plano.
  • [ 7.3 /A-0-1] DEBE implementar e informar GEAR_SELECTION , NIGHT_MODE , PERF_VEHICLE_SPEED y PARKING_BRAKE_ON .
  • [ 7.3 /A-0-2] El valor del indicador NIGHT_MODE DEBE ser consistente con el modo día/noche del tablero y DEBE basarse en la entrada del sensor de luz ambiental. El sensor de luz ambiental subyacente PUEDE ser el mismo que el fotómetro .
  • [ 7.3 /A-0-3] DEBE proporcionar el campo de información adicional del sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor proporcionado.
  • [ 7.3 /A-SR1] PUEDE ubicación por estima fusionando GPS/GNSS con sensores adicionales. Si se considera la ubicación , se RECOMIENDA ENCARECIDAMENTE implementar e informar los tipos de sensores correspondientes y/o las identificaciones de propiedad del vehículo utilizadas.
  • [ 7.3 /A-0-4] La ubicación solicitada a través de LocationManager#requestLocationUpdates() NO DEBE coincidir con el mapa.

  • [ 7.3 .1/A-0-4] DEBE cumplir con el sistema de coordenadas del sensor del automóvil de Android.

  • [ 7.3 /A-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes y un giroscopio de 3 ejes.

  • [ 7.3 /A-SR-2] Está MUY_RECOMENDADO implementar e informar el sensor TYPE_HEADING .

Si las implementaciones de dispositivos automotrices son compatibles con OpenGL ES 3.1,:

  • [ 7.1 .4.1/A-0-1] DEBE declarar OpenGL ES 3.1 o superior.
  • [ 7.1 .4.1/A-0-2] DEBE ser compatible con Vulkan 1.1.
  • [ 7.1 .4.1/A-0-3] DEBE incluir el cargador Vulkan y exportar todos los símbolos.

Si las implementaciones de dispositivos automotrices incluyen un acelerómetro,:

  • [ 7.3 .1/A-1-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes,:

  • [ 7.3 .1/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto para acelerómetro de ejes limitados.

Si las implementaciones de dispositivos automotrices incluyen un acelerómetro con menos de 3 ejes, estos:

  • [ 7.3 .1/A-1-3] DEBE implementar e informar el sensor TYPE_ACCELEROMETER_LIMITED_AXES .
  • [ 7.3.1 /A-1-4] DEBE implementar e informar el sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED .

Si las implementaciones de dispositivos automotrices incluyen un giroscopio,:

  • [ 7.3 .4/A-2-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.
  • [ 7.3.4 /A-2-3] DEBE ser capaz de medir cambios de orientación de hasta 250 grados por segundo.
  • [ 7.3 .4/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE configurar el rango de medición del giroscopio en +/-250 dps para maximizar la resolución posible.

Si las implementaciones de dispositivos automotrices incluyen un giroscopio de 3 ejes,:

  • [ 7.3 .4/A-SR-2] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto para giroscopio de ejes limitados.

Si las implementaciones de dispositivos automotrices incluyen un giroscopio con menos de 3 ejes, estos:

  • [ 7.3.4 /A-4-1] DEBE implementar e informar el sensor TYPE_GYROSCOPE_LIMITED_AXES .
  • [ 7.3.4 /A-4-2] DEBE implementar e informar el sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED .

Si las implementaciones de dispositivos automotrices incluyen un receptor GPS/GNSS, pero no incluyen conectividad de datos basada en red celular,:

  • [ 7.3 .3/A-3-1] DEBE determinar la ubicación la primera vez que se enciende el receptor GPS/GNSS o después de más de 4 días dentro de 60 segundos.
  • [ 7.3 .3/A-3-2] DEBE cumplir con los criterios de tiempo para la primera localización como se describe en 7.3.3/C-1-2 y 7.3.3/C-1-6 para todas las demás solicitudes de ubicación ( es decir, solicitudes que no son la primera vez o después de más de 4 días). El requisito 7.3.3/C-1-2 normalmente se cumple en vehículos sin conectividad de datos basada en red celular, mediante el uso de predicciones de órbita GNSS calculadas en el receptor, o utilizando la última ubicación conocida del vehículo junto con la capacidad de estimar al menos al menos 60 segundos con una precisión de posición que satisfaga 7.3.3/C-1-3 , o una combinación de ambos.

Si las implementaciones de dispositivos automotrices incluyen un sensor TYPE_HEADING ,:

  • [ 7.3 .4/A-4-3] DEBE poder informar eventos con una frecuencia de al menos 1 Hz.
  • [ 7.3 .4/A-SR-3] MUY RECOMENDADO informar eventos con una frecuencia de al menos 10 Hz.
  • DEBE estar en referencia al norte verdadero.
  • DEBE estar disponible incluso cuando el vehículo esté quieto.
  • DEBE tener una resolución de al menos 1 grado.

Implementaciones de dispositivos automotrices:

  • [ 7.4 .3/A-0-1] DEBE admitir Bluetooth y DEBE admitir Bluetooth LE.
  • [ 7.4 .3/A-0-2] Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles de Bluetooth:
    • Llamadas telefónicas a través del perfil manos libres (HFP).
    • Reproducción de medios a través del perfil de distribución de audio (A2DP).
    • Control de reproducción multimedia a través del perfil de control remoto (AVRCP).
    • Compartir contactos mediante el perfil de acceso a la agenda telefónica (PBAP).
  • [ 7.4 .3/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir el perfil de acceso a mensajes (MAP).

  • [ 7.4.5 /A] DEBE incluir soporte para conectividad de datos basada en redes celulares.

  • [ 7.4.5 /A] PUEDE usar la constante API del sistema NetworkCapabilities#NET_CAPABILITY_OEM_PAID para redes que deberían estar disponibles para las aplicaciones del sistema.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos incluyen soporte para transmisiones de radio AM/FM y exponen la funcionalidad a cualquier aplicación, estas:

  • [ 7.4 .10 /A-0-1] DEBE declarar soporte para FEATURE_BROADCAST_RADIO .

Terminar con nuevos requisitos

Una cámara de visión exterior es una cámara que captura escenas fuera de la implementación del dispositivo, como la cámara de visión trasera.

Implementaciones de dispositivos automotrices:

  • DEBE incluir una o más cámaras de visión exterior.

Si las implementaciones de dispositivos automotrices incluyen una cámara de visión exterior, para dicha cámara:

  • [ 7.5 /A-1-1] NO DEBEN tener cámaras de visión exterior accesibles a través de las API de cámara de Android , a menos que cumplan con los requisitos básicos de la cámara.
  • [ 7.5 /A-SR-1] Se RECOMIENDA ENCARECIDAMENTE no rotar ni reflejar horizontalmente la vista previa de la cámara.

  • [ 7.5 /A-SR-2] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de al menos 1,3 megapíxeles.

  • DEBE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).

  • PUEDE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara.

Si las implementaciones de dispositivos automotrices incluyen una o más cámaras de visión exterior y cargan el servicio del Sistema de visión exterior (EVS), entonces, para dicha cámara:

  • [ 7.5 /A-2-1] NO DEBE rotar ni reflejar horizontalmente la vista previa de la cámara.

Implementaciones de dispositivos automotrices:

  • PUEDE incluir una o más cámaras que estén disponibles para aplicaciones de terceros.

Si las implementaciones de dispositivos automotrices incluyen al menos una cámara y la ponen a disposición de aplicaciones de terceros, entonces:

  • [ 7.5 /A-3-1] DEBE informar el indicador de función android.hardware.camera.any .
  • [ 7.5 /A-3-2] No DEBE declarar la cámara como una cámara de sistema .
  • PUEDE admitir cámaras externas descritas en la sección 7.5.3 .
  • PUEDE incluir funciones (como enfoque automático, etc.) disponibles para las cámaras orientadas hacia atrás como se describe en la sección 7.5.1 .

Iniciar nuevos requisitos

Una cámara orientada hacia atrás significa una cámara orientada hacia el mundo que puede ubicarse en cualquier lugar del vehículo y está orientada hacia el exterior de la cabina del vehículo; es decir, capta escenas en el lado más alejado de la carrocería del vehículo, como la cámara de visión trasera.

Una cámara frontal significa una cámara orientada al usuario que puede ubicarse en cualquier lugar del vehículo y está orientada hacia el interior de la cabina del vehículo; es decir, imágenes del usuario, como para videoconferencias y aplicaciones similares.

Implementaciones de dispositivos automotrices:

  • [7.5/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir una o más cámaras orientadas al mundo.
  • PUEDE incluir una o más cámaras orientadas al usuario.
  • [7.5/A-SR-2] Se RECOMIENDAN ENCARECIDAMENTE para admitir la transmisión simultánea de múltiples cámaras.

Si las implementaciones de dispositivos automotrices incluyen al menos una cámara orientada al mundo, entonces, para dicha cámara:

  • [7.5/A-1-1] DEBE orientarse de modo que la dimensión larga de la cámara se alinee con el plano XY de los ejes de los sensores automotrices de Android.
  • [7.5/A-SR-3] Se RECOMIENDA ENCARECIDAMENTE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
  • [7.5/A-1-2] DEBE tener la cámara principal orientada al mundo como la cámara orientada al mundo con el ID de cámara más bajo.

Si las implementaciones de dispositivos automotrices incluyen al menos una cámara orientada al usuario, entonces, para dicha cámara:

  • [7.5/A-2-1] La cámara principal orientada al usuario DEBE ser la cámara orientada al usuario con la ID de cámara más baja.
  • PUEDE orientarse de modo que la dimensión larga de la cámara se alinee con el plano XY de los ejes de los sensores automotrices de Android.

Si las implementaciones de dispositivos automotrices incluyen una cámara a la que se puede acceder a través de la API android.hardware.Camera o android.hardware.camera2 , entonces:

  • [7.5/A-3-1] DEBE cumplir con los requisitos básicos de la cámara en la sección 7.5.

Si las implementaciones de dispositivos automotrices incluyen una cámara a la que no se puede acceder a través de la API android.hardware.Camera o android.hardware.camera2 , entonces:

  • [7.5/A-4-1] DEBE ser accesible a través del servicio Extended View System.

Si las implementaciones de dispositivos automotrices incluyen una o más cámaras accesibles a través del Servicio de sistema de vista extendida, para dicha cámara:

  • [7.5/A-5-1] NO DEBE girar ni reflejar horizontalmente la vista previa de la cámara.
  • [7.5/A-SR-4] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de al menos 1,3 megapíxeles.

Si las implementaciones de dispositivos automotrices incluyen una o más cámaras a las que se puede acceder a través del Servicio de sistema de vista extendida y de la API android.hardware.Camera o android.hardware.Camera2 , entonces, para dicha cámara:

  • [7.5/A-6-1] DEBE informar la misma ID de cámara.

Si las implementaciones de dispositivos automotrices proporcionan una API de cámara patentada,:

  • [7.5/A-7-1] DEBE implementar dicha API de cámara utilizando la API android.hardware.camera2 o la API del sistema de vista extendida.

Terminar con nuevos requisitos

Implementaciones de dispositivos automotrices:

  • [ 7.6 .1/A-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").

  • [ 7.6 .1/A] DEBE formatear la partición de datos para ofrecer un mejor rendimiento y longevidad en el almacenamiento flash, por ejemplo, utilizando el sistema de archivos f2fs .

Si las implementaciones de dispositivos automotrices proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble,:

  • [ 7.6 .1/A-SR-1] Se RECOMIENDAN ENCARECIDAMENTE para reducir la sobrecarga de E/S en las operaciones realizadas en el almacenamiento externo, por ejemplo, mediante el uso SDCardFS .

Si las implementaciones de dispositivos automotrices son de 64 bits:

  • [ 7.6 .1/A-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 816 MB si se utiliza cualquiera de las siguientes densidades:

    • 280 ppp o menos en pantallas pequeñas/normales
    • ldpi o inferior en pantallas extra grandes
    • mdpi o inferior en pantallas grandes
  • [ 7.6 .1/A-2-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si se utiliza cualquiera de las siguientes densidades:

    • xhdpi o superior en pantallas pequeñas/normales
    • hdpi o superior en pantallas grandes
    • mdpi o superior en pantallas extra grandes
  • [ 7.6 .1/A-2-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se utiliza cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes
  • [ 7.6 .1/A-2-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1824 MB si se utiliza cualquiera de las siguientes densidades:

    • 560 ppp o más en pantallas pequeñas/normales
    • 400 ppp o más en pantallas grandes
    • xhdpi o superior en pantallas extra grandes

Tenga en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior se refiere al espacio de memoria proporcionado además de cualquier memoria ya dedicada a componentes de hardware como radio, video, etc. que no están bajo el control del kernel en las implementaciones del dispositivo.

Implementaciones de dispositivos automotrices:

  • [ 7.7 .1/A] DEBE incluir un puerto USB que admita el modo periférico.

Implementaciones de dispositivos automotrices:

  • [ 7.8 .1/A-0-1] DEBE incluir un micrófono.

Implementaciones de dispositivos automotrices:

  • [ 7.8 .2/A-0-1] DEBE tener una salida de audio y declarar android.hardware.audio.output .

2.5.2. Multimedia

Las implementaciones de dispositivos automotrices DEBEN admitir los siguientes formatos de codificación y decodificación de audio y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.1 /A-0-1] Perfil MPEG-4 AAC (AAC LC)
  • [ 5.1 /A-0-2] Perfil MPEG-4 HE AAC (AAC+)
  • [ 5.1 /A-0-3] AAC ELD (AAC de bajo retardo mejorado)

Las implementaciones de dispositivos automotrices DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.2 /A-0-1] H.264 AVC
  • [ 5.2 /A-0-2] VP8

Las implementaciones de dispositivos automotrices DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.3 /A-0-1] H.264 AVC
  • [ 5.3 /A-0-2] MPEG-4 SP
  • [ 5.3 /A-0-3] VP8
  • [ 5.3 /A-0-4] VP9

Se RECOMIENDA ENCARECIDAMENTE que las implementaciones de dispositivos automotrices admitan la siguiente decodificación de video:

  • [ 5.3 /A-SR-1] H.265 HEVC

2.5.3. Software

Implementaciones de dispositivos automotrices:

  • [ 3 /A-0-1] DEBE declarar la característica android.hardware.type.automotive .

  • [ 3 /A-0-2] DEBE admitir uiMode = UI_MODE_TYPE_CAR .

  • [ 3 /A-0-3] DEBE admitir todas las API públicas en el espacio de nombres android.car.* .

Si las implementaciones de dispositivos automotrices proporcionan una API patentada mediante android.car.CarPropertyManager con android.car.VehiclePropertyIds ,:

  • [ 3 /A-1-1] NO DEBE otorgar privilegios especiales al uso de estas propiedades por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros utilicen estas propiedades.
  • [ 3 /A-1-2] NO DEBE replicar una propiedad del vehículo que ya existe en el SDK .

Implementaciones de dispositivos automotrices:

  • [ 3.2 .1/A-0-1] DEBE admitir y hacer cumplir todas las constantes de permisos según lo documentado en la página de referencia de permisos automotrices .

  • [ 3.2.3.1 /A-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .

  • [ 3.4 .1/A-0-1] DEBE proporcionar una implementación completa de la API android.webkit.Webview .

Iniciar nuevos requisitos

  • [ 3.8 /A-0-1] NO DEBE permitir que usuarios secundarios completos que no sean el usuario de primer plano actual inicien actividades y tengan acceso a la interfaz de usuario en ninguna pantalla.

Terminar con nuevos requisitos

  • [ 3.8 .3/A-0-1] DEBE mostrar notificaciones que utilicen la API Notification.CarExtender cuando las soliciten aplicaciones de terceros.

  • [ 3.8 .4/A-SR-1] Se recomienda encarecidamente implementar un asistente en el dispositivo para manejar la acción de asistencia .

Si las implementaciones de dispositivos automotrices incluyen un botón de pulsar para hablar,:

  • [ 3.8 .4/A-1-1] DEBE utilizar una pulsación breve del botón pulsar para hablar como interacción designada para iniciar la aplicación de asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService .

Implementaciones de dispositivos automotrices:

  • [ 3.8.3.1 /A-0-1] DEBE representar correctamente los recursos como se describe en la documentación Notifications on Automotive OS .
  • [ 3.8.3.1 /A-0-2] DEBE mostrar PLAY y MUTE para las acciones de notificación en lugar de las proporcionadas a través de Notification.Builder.addAction()
  • [ 3.8.3.1 /A] DEBE restringir el uso de tareas de administración enriquecidas, como controles por canal de notificación. PUEDE utilizar la disponibilidad de UI por aplicación para reducir los controles.

Si las implementaciones de dispositivos automotrices admiten propiedades HAL de usuario, estas:

Implementaciones de dispositivos automotrices:

Si las implementaciones de dispositivos automotrices incluyen una aplicación de inicio predeterminada, estas:

Implementaciones de dispositivos automotrices:

  • [ 3.8 /A] PUEDE restringir las solicitudes de la aplicación para ingresar al modo de pantalla completa como se describe en immersive documentation .
  • [ 3.8 /A] PUEDE mantener la barra de estado y la barra de navegación visibles en todo momento.
  • [ 3.8 /A] PUEDE restringir las solicitudes de la aplicación para cambiar los colores detrás de los elementos de la interfaz de usuario del sistema, para garantizar que esos elementos sean claramente visibles en todo momento.

2.5.4. Rendimiento y potencia

Implementaciones de dispositivos automotrices:

  • [ 8.2 /A-0-1] DEBE informar la cantidad de bytes leídos y escritos en el almacenamiento no volátil por UID de cada proceso para que las estadísticas estén disponibles para los desarrolladores a través de la API del sistema android.car.storagemonitoring.CarStorageMonitoringManager . El proyecto de código abierto de Android cumple con el requisito a través del módulo del kernel uid_sys_stats .
  • [ 8.3 /A-1-3] DEBE admitir el modo Garaje .
  • [ 8.3 /A] DEBE estar en Modo Garaje durante al menos 15 minutos después de cada viaje, a menos que:
    • La batería está agotada.
    • No se programan trabajos inactivos.
    • El conductor sale del modo garaje.
  • [ 8.4 /A-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [ 8.4 /A-0-2] DEBE informar todos los valores de consumo de energía en miliamperios hora (mAh).
  • [ 8.4 /A-0-3] DEBE informar el consumo de energía de la CPU por el UID de cada proceso. El proyecto de código abierto de Android cumple con el requisito mediante la implementación del módulo del kernel uid_cputime .
  • [ 8.4 /A] DEBE atribuirse al propio componente de hardware si no se puede atribuir el uso de energía del componente de hardware a una aplicación.
  • [ 8.4 /A-0-4] DEBE hacer que este uso de energía esté disponible a través del comando adb shell dumpsys batterystats shell para el desarrollador de la aplicación.

2.5.5. Modelo de seguridad

Si las implementaciones de dispositivos automotrices admiten varios usuarios, estos:

Iniciar nuevos requisitos

Si las implementaciones de dispositivos automotrices declaran android.hardware.microphone ,:

  • [ 9.8.2 /A-1-1] DEBE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede HotwordDetectionService , SOURCE_HOTWORD , ContentCaptureService o aplicaciones que desempeñan los roles mencionados en la sección 9.1 con identificador CDD [C-4-X].
  • [ 9.8.2 /A-1-2] No DEBE ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
  • [ 9.8.2 /A-1-3] DEBE proporcionar al usuario la posibilidad de alternar el micrófono en la aplicación Configuración.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos automotrices declaran android.hardware.camera.any , entonces:

  • [ 9.8.2 /A-2-1] DEBE mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando solo acceden a la cámara las aplicaciones que desempeñan las funciones definidas en la Sección 9.1 Permisos. con identificador CDD [C-4-X] [C-3-X] .
  • [ 9.8.2 /A-2-2] No DEBE ocultar el indicador de la cámara para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

Iniciar nuevos requisitos

  • [ 9.8.2 /A-2-3] DEBE proporcionar al usuario la posibilidad de alternar la cámara en la aplicación Configuración.
  • [ 9.8.2 /A-2-4] DEBE mostrar las aplicaciones recientes y activas que usan la cámara tal como se devuelven desde PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.

Terminar con nuevos requisitos

Implementaciones de dispositivos automotrices:

  • [9/A-0-1] DEBE declarar la característica android.hardware.security.model.compatible .
  • [ 9.11 /A-0-1] DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
  • [ 9.11 /A-0-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de las familias MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos admitidos del sistema Android Keystore en un área que esté aislada de forma segura. del código que se ejecuta en el kernel y superior. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [ 9.11 /A-0-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislada y solo cuando tenga éxito, permita que se utilicen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El proyecto de código abierto de Android proporciona la capa de abstracción de hardware Gatekeeper (HAL) y Trusty, que se pueden utilizar para satisfacer este requisito.
  • [ 9.11 /A-0-4] DEBE admitir la atestación de clave donde la clave de firma de la atestación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad suficiente de dispositivos para evitar que se utilicen como identificadores de dispositivos. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza, que implementan la API del sistema TrustAgentService , ellos:

  • [ 9.11.1 /A-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (por ejemplo, PIN, patrón, contraseña) con más frecuencia que una vez cada 336 horas.

Terminar con nuevos requisitos

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Implementaciones de dispositivos automotrices:

  • [ 9.14 /A-0-1] DEBE controlar los mensajes de los subsistemas del vehículo del marco Android, por ejemplo, enumerando los tipos de mensajes permitidos y las fuentes de mensajes.
  • [ 9.14 /A-0-2] DEBE vigilar los ataques de denegación de servicio desde el marco de Android o aplicaciones de terceros. Esto protege contra software malicioso que inunda la red del vehículo con tráfico, lo que puede provocar un mal funcionamiento de los subsistemas del vehículo.

2.5.6. Compatibilidad de opciones y herramientas de desarrollador

Implementaciones de dispositivos automotrices:

2.6. Requisitos de la tableta

Un dispositivo tableta Android se refiere a una implementación de dispositivo Android que normalmente cumple con todos los criterios siguientes:

  • Se utiliza sosteniéndolo con ambas manos.
  • No tiene configuración tipo clamshell o convertible.
  • Las implementaciones de teclado físico utilizadas con el dispositivo se conectan mediante una conexión estándar (por ejemplo, USB, Bluetooth).
  • Tiene una fuente de energía que proporciona movilidad, como una batería.

  • Tiene un tamaño de pantalla mayor a 7” y menor a 18”, medida en diagonal.

Las implementaciones de dispositivos de tableta tienen requisitos similares a los de las implementaciones de dispositivos portátiles. Las excepciones se indican con un * en esa sección y se anotan como referencia en esta sección.

2.6.1. Hardware

Giroscopio

Si las implementaciones de dispositivos Tablet incluyen un giroscopio de 3 ejes,:

  • [ 7.3 .4/Tab-1-1] DEBE ser capaz de medir cambios de orientación de hasta 1000 grados por segundo.

Memoria y almacenamiento mínimos (Sección 7.6.1)

Las densidades de pantalla enumeradas para pantallas pequeñas/normales en los requisitos del dispositivo portátil no se aplican a las tabletas.

Modo periférico USB (Sección 7.7.1)

Si las implementaciones de dispositivos de tableta incluyen un puerto USB que admite el modo periférico:

  • [ 7.7.1 /Tab] PUEDE implementar la API del accesorio abierto de Android (AOA).

Modo de realidad virtual (Sección 7.9.1)

Realidad virtual de alto rendimiento (Sección 7.9.2)

Los requisitos de realidad virtual no se aplican a las tabletas.

2.6.2. Modelo de seguridad

Claves y Credenciales (Sección 9.11)

Consulte la Sección [ 9.11 ].

Si las implementaciones de dispositivos Tablet incluyen varios usuarios y no declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /T-1-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

Si las implementaciones de dispositivos Tablet incluyen varios usuarios y declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /T-2-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir/deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

2.6.2. Software

  • [ 3.2.3.1 /Tab-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .

3.software

3.1. Compatibilidad de API administrada

El entorno de ejecución de bytecode administrado de Dalvik es el vehículo principal para las aplicaciones de Android. La interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma Android expuestas a aplicaciones que se ejecutan en el entorno de ejecución administrado.

Implementaciones de dispositivos:

  • [C-0-1] DEBE 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 de Android.

  • [C-0-2] DEBE admitir/preservar todas las clases, métodos y elementos asociados marcados por la anotación TestApi (@TestApi).

  • [C-0-3] NO DEBE omitir ninguna API administrada, alterar las interfaces o firmas de la API, desviarse del comportamiento documentado ni incluir operaciones no operativas, excepto donde lo permita específicamente esta Definición de compatibilidad.

  • [C-0-4] DEBE mantener las API presentes y comportarse de manera razonable, incluso cuando se omiten algunas funciones de hardware para las cuales Android incluye API. Consulte la sección 7 para conocer los requisitos específicos para este escenario.

  • [C-0-5] NO DEBE permitir que aplicaciones de terceros utilicen interfaces que no sean SDK, que se definen como métodos y campos en los paquetes de lenguaje Java que se encuentran en la ruta de clase de inicio en AOSP y que no forman parte del SDK público. Esto incluye las API decoradas con la anotación @hide pero no con @SystemAPI , como se describe en los documentos del SDK y los miembros de clase privados y de paquete privado.

  • [C-0-6] DEBE enviarse con todas y cada una de las interfaces que no sean SDK en las mismas listas restringidas que se proporcionan a través de los indicadores de lista provisional y denegada en la ruta prebuilts/runtime/appcompat/hiddenapi-flags.csv para la rama de nivel de API adecuada en la AOSP.

  • [C-0-7] DEBE admitir el mecanismo de actualización dinámica de configuración firmada para eliminar interfaces que no son SDK de una lista restringida mediante la incorporación de configuración firmada en cualquier APK, utilizando las claves públicas existentes presentes en AOSP.

    Sin embargo ellos:

    • MAYO, si una API oculta está ausente o se implementa de manera diferente en la implementación del dispositivo, mueva la API oculta a la lista de rechazados u omítala de todas las listas restringidas.
    • MAYO, si aún no existe una API oculta en el AOSP, agregue la API oculta a cualquiera de las listas restringidas.

Iniciar nuevos requisitos

  • [C-0-8] NO DEBE admitir la instalación de aplicaciones dirigidas a un nivel API inferior a 23.

Terminar con nuevos requisitos

3.1.1. Extensiones de Android

Android admite la extensión de la superficie de API administrada de un nivel de API en particular actualizando la versión de extensión para ese nivel de API. La API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) devuelve la versión de extensión del apiLevel proporcionado, si hay extensiones para ese nivel de API.

Implementaciones de dispositivos Android:

  • [C-0-1] DEBE precargar la implementación AOSP tanto de la biblioteca compartida ExtShared como de los servicios ExtServices con versiones mayores o iguales a las versiones mínimas permitidas por cada nivel de API. Por ejemplo, las implementaciones de dispositivos Android 7.0 que ejecutan el nivel API 24 DEBEN incluir al menos la versión 1.

  • [C-0-2] DEBE devolver únicamente un número de versión de extensión válido que haya sido definido por el AOSP.

  • [C-0-3] DEBE admitir todas las API definidas por las versiones de extensión devueltas por android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la misma manera que se admiten otras API administradas, siguiendo los requisitos de la sección 3.1 .

3.1.2. Biblioteca de Android

Debido a la obsolescencia del cliente HTTP Apache , implementaciones de dispositivos:

  • [C-0-1] NO DEBE colocar la biblioteca org.apache.http.legacy en bootclasspath.
  • [C-0-2] DEBE agregar la biblioteca org.apache.http.legacy al classpath de la aplicación solo cuando la aplicación satisface una de las siguientes condiciones:
    • Apunta al nivel API 28 o inferior.
    • Declara en su manifiesto que necesita la biblioteca configurando el atributo android:name de <uses-library> en org.apache.http.legacy .

La implementación de AOSP cumple con estos requisitos.

3.2. Compatibilidad de API suave

Además de las API administradas de la sección 3.1 , Android también incluye una importante API "suave" solo en tiempo de ejecución, en forma de intenciones, permisos y aspectos similares de las aplicaciones de Android que no se pueden aplicar en el momento de la compilación de la aplicación.

3.2.1. Permisos

  • [C-0-1] Los implementadores de dispositivos DEBEN admitir y hacer cumplir todas las constantes de permisos según lo documentado en la página de referencia de permisos . Tenga en cuenta que la sección 9 enumera requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de construcción

Las API de Android incluyen una serie de constantes en la clase android.os.Build cuyo objetivo es describir el dispositivo actual.

  • [C-0-1] Para proporcionar valores coherentes y significativos en todas las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que DEBEN ajustarse las implementaciones de dispositivos.
Parámetro Detalles
VERSIÓN.LIBERACIÓN La versión del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en Cadenas de versión permitidas para Android 14 .
VERSIÓN.SDK La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 14, este campo DEBE tener el valor entero 14_INT.
VERSIÓN.SDK_INT La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 14, este campo DEBE tener el valor entero 14_INT.
VERSIÓN.INCREMENTAL Un valor elegido por el implementador del dispositivo que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO DEBE reutilizarse para diferentes compilaciones disponibles para los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de fuente se utilizó para generar la compilación. El valor de este campo DEBE poder codificarse como ASCII imprimible de 7 bits y coincidir con la expresión regular “^[^ :\/~]+$”.
JUNTA Un valor elegido por el implementador del dispositivo que identifica el hardware interno específico utilizado por el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
MARCA Un valor que refleja la marca asociada con el dispositivo tal como la conocen los usuarios finales. DEBE estar en formato legible por humanos y DEBE representar al fabricante del dispositivo o la marca de la empresa bajo la cual se comercializa el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad de API nativa .
SOPORTE_32_BIT_ABIS El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad de API nativa .
SOPORTE_64_BIT_ABIS El nombre del segundo conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad de API nativa .
CPU_ABI El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad de API nativa .
CPU_ABI2 El nombre del segundo conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad de API nativa .
DISPOSITIVO Un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre del código que identifica la configuración de las características del hardware y el diseño industrial del dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este dispositivo NO DEBE cambiar durante la vida útil del producto.
HUELLA DACTILAR Una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla:

$(MARCA)/$(PRODUCTO)/
$(DISPOSITIVO):$(VERSIÓN.LIBERACIÓN)/$(ID)/$(VERSIÓN.INCREMENTAL):$(TIPO)/$(TAGS)

Por ejemplo:

cima/miproducto/
mi dispositivo: 14/LMYXX/3359: userdebug/test-keys

La huella digital NO DEBE incluir espacios en blanco. El valor de este campo DEBE poder codificarse como ASCII de 7 bits.

HARDWARE El nombre del hardware (de la línea de comando del kernel o /proc). DEBE ser razonablemente legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ANFITRIÓN Una cadena que identifica de forma única el host en el que se creó la compilación, en formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
IDENTIFICACIÓN Un identificador elegido por el implementador del dispositivo para hacer referencia a una versión específica, en formato legible por humanos. Este campo puede ser el mismo que android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE El nombre comercial del fabricante de equipos originales (OEM) del producto. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
SOC_MANUFACTURADOR El nombre comercial del fabricante del sistema primario en chip (SOC) utilizado en el producto. Los dispositivos con el mismo fabricante de SOC deben utilizar el mismo valor constante. Pregunte al fabricante del SOC cuál es la constante correcta a utilizar. El valor de este campo DEBE poder codificarse como ASCII de 7 bits, DEBE coincidir con la expresión regular “^([0-9A-Za-z ]+)”, NO DEBE comenzar ni terminar con espacios en blanco y NO DEBE ser igual a “ desconocido". Este campo NO DEBE cambiar durante la vida útil del producto.
SOC_MODEL El nombre del modelo del sistema primario en un chip (SOC) utilizado en el producto. Los dispositivos con el mismo modelo de SOC deben utilizar el mismo valor constante. Pregunte al fabricante del SOC cuál es la constante correcta a utilizar. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^([0-9A-Za-z ._/+-]+)$”, NO DEBE comenzar ni terminar con espacios en blanco, y DEBE NO ser igual a “desconocido”. Este campo NO DEBE cambiar durante la vida útil del producto.
MODELO Un valor elegido por el implementador del dispositivo que contiene el nombre del dispositivo tal como lo conoce el usuario final. Este DEBE ser el mismo nombre con el que se comercializa y vende el dispositivo a los usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
PRODUCTO Un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre en código del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente está destinado a ser visto por usuarios finales. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este producto NO DEBE cambiar durante la vida útil del producto.
ODM_SKU Un valor opcional elegido por el implementador del dispositivo que contiene SKU (Unidad de mantenimiento de stock) utilizado para rastrear configuraciones específicas del dispositivo, por ejemplo, cualquier periférico incluido con el dispositivo cuando se vende. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “[0-9A-Za-z.,_-])"
DE SERIE DEBE devolver "DESCONOCIDO".
ETIQUETAS Una lista de etiquetas separadas por comas elegidas por el implementador del dispositivo que distingue aún más la compilación. Las etiquetas DEBEN poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+” y DEBEN tener uno de los valores correspondientes a las tres configuraciones de firma típicas de la plataforma Android: lanzamiento- claves, claves de desarrollo y claves de prueba.
TIEMPO Un valor que representa la marca de tiempo de cuando ocurrió la compilación.
TIPO Un valor elegido por el implementador del dispositivo que especifica la configuración de tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: usuario, usuariodebug o eng.
USUARIO Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
PARCHE_SEGURIDAD Un valor que indica el nivel del parche de seguridad de una compilación. DEBE significar que la compilación no es de ninguna manera vulnerable a ninguno de los problemas descritos en el Boletín de Seguridad Pública de Android designado. DEBE tener el formato [AAAA-MM-DD] y coincidir 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".
SO_BASE Un valor que representa el parámetro FINGERPRINT de la compilación que, por lo demás, 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 dicha compilación no existe, informar una cadena vacía ("").
CARGADOR DE ARRANQUE Un valor elegido por el implementador del dispositivo que identifica la versión específica del gestor de arranque interno utilizada en el dispositivo, en formato legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
obtenerVersiónRadio() DEBE (ser o devolver) un valor elegido por el implementador del dispositivo que identifique la versión interna específica de radio/módem utilizada en el dispositivo, en formato legible por humanos. Si un dispositivo no tiene ninguna radio/módem interno, DEBE devolver NULL. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.
obtener serie() DEBE (ser o devolver) 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 DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9]+$”.

3.2.3. Compatibilidad de intenciones

3.2.3.1. Intenciones de aplicación comunes

Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidad de otros componentes de Android. El proyecto ascendente de Android incluye una lista de aplicaciones que implementan varios patrones de intención para realizar acciones comunes.

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicaciones enumeradas aquí y proporcionar cumplimiento, es decir, cumplir con las expectativas del desarrollador para estas intenciones de aplicación comunes como se describe en el SDK.

Consulte la Sección 2 para conocer las intenciones de aplicación obligatorias para cada tipo de dispositivo.

3.2.3.2. Resolución de intención
  • [C-0-1] Como Android es una plataforma extensible, las implementaciones de dispositivos DEBEN permitir que cada patrón de intención al que se hace referencia en la sección 3.2.3.1 , excepto la Configuración, sea anulado por aplicaciones de terceros. La implementación de código abierto de Android permite esto de forma predeterminada.

  • [C-0-2] Los implementadores de dispositivos NO DEBEN otorgar privilegios especiales al uso de estos patrones de intención por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros se vinculen y asuman el control de estos patrones. Esta prohibición incluye específicamente, entre otras, la desactivación de la interfaz de usuario "Selector" que permite al usuario seleccionar entre múltiples aplicaciones que manejan el mismo patrón de intención.

  • [C-0-3] Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario para que los usuarios modifiquen la actividad predeterminada para los intents.

  • Sin embargo, las implementaciones de dispositivos PUEDEN proporcionar actividades predeterminadas para patrones de URI específicos (por ejemplo, http://play.google.com) cuando la actividad predeterminada proporciona un atributo más específico para el URI de datos. Por ejemplo, un patrón de filtro de intención que especifica el URI de datos “http://www.android.com” es más específico que el patrón de intención principal del navegador para “http://”.

Android también incluye un mecanismo para que las aplicaciones de terceros declaren un comportamiento de vinculación de aplicaciones predeterminado autorizado para ciertos tipos de intenciones de URI web. Cuando dichas declaraciones autorizadas se definen en los patrones de filtro de intención de una aplicación, las implementaciones del dispositivo:

  • [C-0-4] DEBE intentar validar cualquier filtro de intención realizando los pasos de validación definidos en la especificación de Enlaces de activos digitales implementada por el Administrador de paquetes en el Proyecto de código abierto de Android ascendente.
  • [C-0-5] DEBE intentar la validación de los filtros de intención durante la instalación de la aplicación y configurar todos los filtros de intención de URI validados correctamente como controladores de aplicaciones predeterminados para sus URI.
  • PUEDE establecer filtros de intención de URI específicos como controladores de aplicaciones predeterminados para sus URI, si se verifican correctamente pero otros filtros de URI candidatos no superan 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 enlaces de aplicaciones por aplicación en Configuración de la siguiente manera:
    • [C-0-6] El usuario DEBE poder anular de manera integral el comportamiento predeterminado de los enlaces de aplicaciones para que una aplicación esté: siempre abierta, siempre preguntando o nunca abierta, lo que debe aplicarse a todos los filtros de intención de URI candidatos por igual.
    • [C-0-7] El usuario DEBE poder ver una lista de los filtros de intención de URI candidatos.
    • La implementación del dispositivo PUEDE proporcionar al usuario la capacidad de anular filtros de intención de URI candidatos específicos que se verificaron con éxito, por filtro por intención.
    • [C-0-8] La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intención de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros de intención de URI candidatos tengan éxito en la verificación mientras que otros pueden fallar.
3.2.3.3. Espacios de nombres de intención
  • [C-0-1] Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier intención nueva o patrón de intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena de clave en el espacio de nombres android.* o com.android.*.
  • [C-0-2] Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier intención nueva o patrón de intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete que pertenece a otra organización.
  • [C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni ampliar ninguno de los patrones de intención enumerados en la sección 3.2.3.1 .
  • Las implementaciones de dispositivos PUEDEN incluir patrones de intención que utilizan espacios de nombres asociados clara y obviamente con su propia organización. Esta prohibición es análoga a la especificada para las clases de lenguaje Java en la sección 3.6 .
3.2.3.4. Intenciones de transmisión

Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intentos de notificarles sobre cambios en el entorno de hardware o software.

Implementaciones de dispositivos:

  • [C-0-1] DEBE transmitir las intenciones de transmisión pública enumeradas aquí en respuesta a los eventos apropiados del sistema, como se describe en la documentación del SDK. Tenga en cuenta que este requisito no entra en conflicto con la sección 3.5, ya que la limitación para aplicaciones en segundo plano también se describe en la documentación del SDK. Además, ciertos intentos de transmisión están condicionados a la compatibilidad con el hardware; si el dispositivo admite el hardware necesario, DEBEN transmitir los intentos y proporcionar el comportamiento en línea con la documentación del SDK.
3.2.3.5. Intenciones de aplicación condicional

Android incluye configuraciones que brindan a los usuarios una manera fácil de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla de inicio o SMS.

Cuando tenga sentido, las implementaciones de dispositivos DEBEN proporcionar un menú de configuración similar y ser compatibles con el patrón de filtro de intención y los métodos API que se describen en la documentación del SDK como se muestra a continuación.

Si las implementaciones de dispositivos informan android.software.home_screen ,:

  • [C-1-1] DEBE respetar la intención de android.settings.HOME_SETTINGS de mostrar un menú de configuración de aplicación predeterminado para la pantalla de inicio.

Si las implementaciones de dispositivos informan android.hardware.telephony.calling ,:

Si las implementaciones de dispositivos informan android.hardware.nfc.hce ,:

  • [C-3-1] DEBE respetar la intención de android.settings.NFC_PAYMENT_SETTINGS de mostrar un menú de configuración de aplicación predeterminado para pagos sin contacto.
  • [C-3-2] DEBE respetar la intención de android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT de mostrar una actividad que abre un cuadro de diálogo para solicitar al usuario que cambie el servicio de emulación de tarjetas predeterminado para una determinada categoría, como se describe en el SDK.

Si las implementaciones de dispositivos informan android.hardware.nfc ,:

Si las implementaciones de dispositivos informan android.hardware.bluetooth ,:

Si las implementaciones de dispositivos admiten la función DND,:

  • [C-6-1] DEBE implementar una actividad que responda a la intención ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS , que para implementaciones con UI_MODE_TYPE_NORMAL DEBE ser una actividad en la que el usuario pueda otorgar o denegar a la aplicación el acceso a las configuraciones de la política DND.

Si las implementaciones del dispositivo permiten a los usuarios utilizar métodos de entrada de terceros en el dispositivo, ellos:

  • [C-7-1] DEBE proporcionar un mecanismo accesible para el usuario para agregar y configurar métodos de entrada de terceros en respuesta a la intención de android.settings.INPUT_METHOD_SETTINGS .

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, estos:

  • [C-8-1] DEBE respetar la intención de android.settings.ACCESSIBILITY_SETTINGS de proporcionar un mecanismo accesible al usuario para habilitar y deshabilitar los servicios de accesibilidad de terceros junto con los servicios de accesibilidad precargados.

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Easy Connect y exponen la funcionalidad a aplicaciones de terceros, estos:

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos, ellas: * [C-10-1] DEBEN proporcionar una interfaz de usuario en la configuración, que maneje la intención Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS , permitiendo a los usuarios agregar o eliminar aplicaciones de la lista permitida.

Si las implementaciones de dispositivos no proporcionan el modo de ahorro de datos,:

Si las implementaciones de dispositivos declaran compatibilidad con la cámara a través de android.hardware.camera.any ,:

Si las implementaciones de dispositivos informan android.software.device_admin ,:

Si las implementaciones de dispositivos declaran el indicador de función android.software.autofill ,:

Si las implementaciones de dispositivos incluyen una aplicación preinstalada o desean permitir que aplicaciones de terceros accedan a las estadísticas de uso, estas:

  • Se RECOMIENDA ENCARECIDAMENTE que [C-SR-2] proporcione un mecanismo accesible para el usuario para otorgar o revocar el acceso a las estadísticas de uso en respuesta a la intención android.settings.ACTION_USAGE_ACCESS_SETTINGS para aplicaciones que declaran el permiso android.permission.PACKAGE_USAGE_STATS .

Si las implementaciones de dispositivos tienen la intención de impedir que cualquier aplicación, incluidas las aplicaciones preinstaladas, acceda a las estadísticas de uso, estas:

  • [C-15-1] DEBE aún tener una actividad que maneje el patrón de intención android.settings.ACTION_USAGE_ACCESS_SETTINGS pero DEBE implementarla como no operativa, es decir, para tener un comportamiento equivalente a cuando se rechaza el acceso del usuario.

Si las implementaciones de dispositivos muestran enlaces a las actividades especificadas por AutofillService_passwordsActivity en Configuración o enlaces a contraseñas de usuarios a través de un mecanismo similar,:

  • [C-16-1] DEBE mostrar dichos enlaces para todos los servicios de autocompletar instalados.

Si las implementaciones de dispositivos admiten VoiceInteractionService y tienen más de una aplicación que utiliza esta API instalada a la vez, estas:

Si las implementaciones de dispositivos informan la función android.hardware.audio.output ,:

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE respetar los intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA y android.speech.tts.engine.GET_SAMPLE_TEXT tienen una actividad para proporcionar cumplimiento a estos intents como descrito en el SDK aquí .

Android incluye soporte para salvapantallas interactivos, anteriormente conocidos 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 acoplado a una base de escritorio. Implementaciones de dispositivos:

  • DEBE incluir soporte para protectores de pantalla y proporcionar una opción de configuración para que los usuarios configuren protectores de pantalla en respuesta a la intención de android.settings.DREAM_SETTINGS .

Iniciar nuevos requisitos

Si las implementaciones de dispositivos informan android.hardware.nfc.uicc o android.hardware.nfc.ese ,:

Terminar con nuevos requisitos

3.2.4. Actividades en pantallas secundarias/múltiples

Si las implementaciones de dispositivos permiten iniciar actividades normales de Android en más de una pantalla, estas:

  • [C-1-1] DEBE configurar el indicador de función android.software.activities_on_secondary_displays .
  • [C-1-2] DEBE garantizar la compatibilidad de API similar a una actividad que se ejecuta en la pantalla principal.
  • [C-1-3] DEBE aterrizar la nueva actividad en la misma pantalla que la actividad que la inició, cuando la nueva actividad se inicia sin especificar una pantalla de destino a través de la API ActivityOptions.setLaunchDisplayId() .
  • [C-1-4] DEBE destruir todas las actividades cuando se elimina una pantalla con el indicador Display.FLAG_PRIVATE .
  • [C-1-5] DEBE ocultar de forma segura el contenido en todas las pantallas cuando el dispositivo está bloqueado con una pantalla de bloqueo segura, a menos que la aplicación opte por mostrarse en la parte superior de la pantalla de bloqueo usando la API Activity#setShowWhenLocked() .
  • DEBE tener android.content.res.Configuration que corresponda a esa pantalla para poder mostrarse, funcionar correctamente y mantener la compatibilidad si se inicia una actividad en la pantalla secundaria.

Si las implementaciones del dispositivo permiten iniciar actividades normales de Android en pantallas secundarias y una pantalla secundaria tiene el indicador android.view.Display.FLAG_PRIVATE :

  • [C-3-1] Solo el propietario de esa pantalla, el sistema y las actividades que ya están en esa pantalla DEBEN poder iniciarla. Todos pueden iniciar una pantalla que tenga el indicador android.view.Display.FLAG_PUBLIC .

3.3. Compatibilidad API nativa

La compatibilidad del código nativo es un desafío. Por este motivo, los implementadores de dispositivos son:

  • [C-SR-1] RECOMIENDA ENCARECIDAMENTE utilizar las implementaciones de las bibliotecas que se enumeran a continuación del proyecto de código abierto de Android.

3.3.1. Interfaces binarias de aplicaciones

El código de bytes de Dalvik administrado puede llamar al código nativo proporcionado en el archivo .apk de la aplicación como un archivo ELF .so compilado para la arquitectura de hardware del dispositivo adecuada. Como el código nativo depende en gran medida de la tecnología del procesador subyacente, Android define una serie de interfaces binarias de aplicaciones (ABI) en el NDK de Android.

Implementaciones de dispositivos:

  • [C-0-1] DEBE ser compatible con una o más ABI de NDK de Android definidas.
  • [C-0-2] DEBE incluir soporte para el código que se ejecuta en el entorno administrado para llamar al código nativo, utilizando la semántica estándar de la interfaz nativa de Java (JNI).
  • [C-0-3] DEBE ser compatible con el código fuente (es decir, compatible con el encabezado) y con el sistema binario (para ABI) con cada biblioteca requerida en la lista siguiente.
  • [C-0-5] DEBE informar con precisión la interfaz binaria de aplicación (ABI) nativa admitida por el dispositivo, a través de los parámetros android.os.Build.SUPPORTED_ABIS , android.os.Build.SUPPORTED_32_BIT_ABIS y android.os.Build.SUPPORTED_64_BIT_ABIS , cada una de las cuales es una lista separada por comas de ABI ordenadas del más al menos preferido.
  • [C-0-6] DEBE informar, a través de los parámetros anteriores, un subconjunto de la siguiente lista de ABI y NO DEBE informar ninguna ABI que no esté en la lista.

  • [C-0-7] DEBE hacer que todas las siguientes bibliotecas, que proporcionan API nativas, estén disponibles para aplicaciones que incluyen código nativo:

    • libaaudio.so (soporte de audio nativo de AAudio)
    • libamidi.so (soporte MIDI nativo, si se reclama la función android.software.midi como se describe en la Sección 5.9)
    • libandroid.so (soporte de actividad nativo de Android)
    • libc (biblioteca C)
    • libcamera2ndk.so
    • libdl (enlazador dinámico)
    • libEGL.so (gestión de superficie nativa 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 (soporte de API de medios nativos)
    • libm (biblioteca de matemáticas)
    • libneuralnetworks.so (API de redes neuronales)
    • libOpenMAXAL.so (soporte para OpenMAX AL 1.0.1)
    • libOpenSLES.so (soporte de audio OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (soporte mínimo para C++)
    • libvulkan.so (Vulkan)
    • libz (compresión Zlib)
    • interfaz JNI
  • [C-0-8] NO DEBE agregar ni eliminar las funciones públicas para las bibliotecas nativas enumeradas anteriormente.

  • [C-0-9] DEBE enumerar bibliotecas adicionales que no sean AOSP expuestas directamente a aplicaciones de terceros en /vendor/etc/public.libraries.txt .

  • [C-0-10] NO DEBE exponer ninguna otra biblioteca nativa, implementada y proporcionada en AOSP como bibliotecas del sistema, a aplicaciones de terceros orientadas al nivel API 24 o superior, ya que están reservadas.

  • [C-0-11] DEBE exportar todos los símbolos de función de OpenGL ES 3.1 y Android Extension Pack , tal como se define en el NDK, a través de la biblioteca libGLESv3.so . Tenga en cuenta que si bien todos los símbolos DEBEN estar presentes, la sección 7.1.4.1 describe con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.

  • [C-0-12] DEBE exportar símbolos de funciones para los símbolos de funciones principales de Vulkan 1.0 Vulkan 1.1 , así como las extensiones VK_KHR_surface , VK_KHR_android_surface , VK_KHR_swapchain , VK_KHR_maintenance1 y VK_KHR_get_physical_device_properties2 a través de la biblioteca libvulkan.so . Tenga en cuenta que si bien todos los símbolos DEBEN estar presentes, la sección 7.1.4.2 describe con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.

  • DEBE construirse utilizando el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android.

Tenga en cuenta que las versiones futuras de Android pueden incorporar compatibilidad con ABI adicionales.

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

Si las implementaciones de dispositivos informan que son compatibles con la ABI armeabi , estas:

  • [C-3-1] También DEBE admitir armeabi-v7a e informar su compatibilidad, ya que armeabi solo es compatible con aplicaciones anteriores.

Si las implementaciones de dispositivos informan que admiten la ABI armeabi-v7a , para las aplicaciones que usan esta ABI:

  • [C-2-1] DEBE incluir las siguientes líneas en /proc/cpuinfo y NO DEBE alterar los valores en el mismo dispositivo, incluso cuando otros ABI los leen.

    • Features: , seguido de una lista de las funciones opcionales de la CPU ARMv7 admitidas por el dispositivo.
    • CPU architecture: , seguido de un número entero que describe la arquitectura ARM más compatible del dispositivo (por ejemplo, "8" para dispositivos ARMv8).
  • [C-2-2] DEBE mantener siempre disponibles las siguientes operaciones, incluso en el caso de que la ABI esté implementada en una arquitectura ARMv8, ya sea mediante soporte nativo de CPU o mediante emulación de software:

    • Instrucciones SWP y SWPB.
    • Operaciones de barrera CP15ISB, CP15DSB y CP15DMB.
  • [C-2-3] DEBE incluir soporte para la extensión Advanced SIMD (también conocida como NEON).

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

Si las implementaciones de dispositivos proporcionan una implementación completa de la API android.webkit.Webview , estas:

  • [C-1-1] DEBE informar android.software.webview .
  • [C-1-2] DEBE utilizar la compilación del Proyecto Chromium del Proyecto de código abierto de Android en la rama de Android 14 para la implementación de la API android.webkit.WebView .
  • [C-1-3] La cadena del agente de usuario reportada por WebView DEBE tener este formato:

    Mozilla/5.0 (Linux; Android $(VERSIÓN); [$(MODELO)] [Compilación/$(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 valor de android.os.Build.VERSION.RELEASE.
    • La cadena $(MODEL) PUEDE estar vacía, pero si no está vacía DEBE tener el mismo valor que android.os.Build.MODEL.
    • "Build/$(BUILD)" PUEDE omitirse, pero si está presente, la cadena $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID.
    • El valor de la cadena $(CHROMIUM_VER) DEBE ser la versión de Chromium en el proyecto de código abierto de Android ascendente.
    • Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del agente de usuario.
  • El componente WebView DEBE incluir soporte para tantas funciones HTML5 como sea posible y, si es compatible, la función DEBE ajustarse a la especificación HTML5 .

  • [C-1-4] DEBE representar el contenido proporcionado o el contenido de la URL remota en un proceso que sea distinto de la aplicación que crea una instancia de WebView. Específicamente, el proceso de renderizado separado DEBE tener privilegios inferiores, ejecutarse como una ID de usuario separada, no tener acceso al directorio de datos de la aplicación, no tener acceso directo a la red y solo tener acceso a los servicios mínimos requeridos del sistema a través de Binder. La implementación AOSP de WebView cumple con este requisito.

Tenga en cuenta que si las implementaciones de dispositivos son de 32 bits o declaran el indicador de función android.hardware.ram.low , están exentas de C-1-3.

3.4.2. Compatibilidad del navegador

Si las implementaciones de dispositivos incluyen una aplicación de navegador independiente para la navegación web general, estas:

  • [C-1-1] DEBE admitir cada una de estas API asociadas con HTML5:
  • [C-1-2] DEBE admitir la API de almacenamiento web HTML5/W3C y DEBE admitir la API IndexedDB HTML5/W3C. Tenga en cuenta que a medida que los organismos de estándares de desarrollo web están haciendo la transición para favorecer IndexedDB sobre el almacenamiento web, se espera que IndexedDB se convierta en un componente requerido en una versión futura de Android.
  • PUEDE enviar una cadena de agente de usuario personalizada en la aplicación de navegador independiente.
  • DEBE implementar soporte para la mayor cantidad de HTML5 posible en la aplicación de navegador independiente (ya sea basada en la aplicación de navegador WebKit anterior o en un reemplazo de terceros).

Sin embargo, si las implementaciones de dispositivos no incluyen una aplicación de navegador independiente, estas:

  • [C-2-1] DEBE seguir siendo compatible con los patrones de intención pública como se describe en la sección 3.2.3.1 .

3.5. Compatibilidad de comportamiento de API

Implementaciones de dispositivos:

  • [C-0-9] DEBE garantizar que se aplique la compatibilidad de comportamiento de API para todas las aplicaciones instaladas, a menos que estén restringidas como se describe en la Sección 3.5.1 .
  • [C-0-10] NO DEBE implementar el enfoque de lista blanca que garantiza la compatibilidad del comportamiento de API solo para aplicaciones seleccionadas por los implementadores de dispositivos.

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

  • [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento o la semántica de una intención estándar.
  • [C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida o la semántica del ciclo de vida de un tipo particular de componente del sistema (como Servicio, Actividad, Proveedor de contenido, etc.).
  • [C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
  • Los dispositivos NO DEBEN alterar las limitaciones impuestas a las aplicaciones en segundo plano. Más específicamente, para aplicaciones en segundo plano:
    • [C-0-4] DEBEN dejar de ejecutar devoluciones de llamada registradas por la aplicación para recibir resultados de GnssMeasurement y GnssNavigationMessage .
    • [C-0-5] DEBEN limitar la frecuencia de las actualizaciones que se proporcionan a la aplicación a través de la clase API LocationManager o el método WifiManager.startScan() .
    • [C-0-6] si la aplicación tiene como objetivo el nivel API 25 o superior, NO DEBEN permitir registrar receptores de transmisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la aplicación, a menos que la intención de transmisión requiera una "signature" o "signatureOrSystem" permiso protectionLevel o están en la lista de exenciones .
    • [C-0-7] si la aplicación tiene como objetivo el nivel API 25 o superior, DEBEN detener los servicios en segundo plano de la aplicación, como si la aplicación hubiera llamado al método stopSelf() de los servicios, a menos que la aplicación se coloque en una lista de permitidos temporal. para manejar una tarea que es visible para el usuario.
    • [C-0-8] si la aplicación tiene como objetivo el nivel API 25 o superior, DEBEN liberar los wakelocks que contiene la aplicación.
  • [C-0-11] Los dispositivos DEBEN devolver los siguientes proveedores de seguridad como los primeros siete valores de matriz del método Security.getProviders() , en el orden dado y con los nombres dados (según lo devuelto por Provider.getName() ) y clases , a menos que la aplicación haya modificado la lista mediante insertProviderAt() o removeProvider() . Los dispositivos PUEDEN devolver proveedores adicionales después de la lista de proveedores especificada a continuación.
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. antes de Cristo - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. ArmoníaJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. Restricción de aplicación

Si las implementaciones de dispositivos implementan un mecanismo propietario para restringir aplicaciones (por ejemplo, cambiar o restringir los comportamientos de API que se describen en el SDK) y ese mecanismo es más restrictivo que el Restricted App Standby Bucket , ellos:

  • [C-1-1] DEBE permitir al usuario ver la lista de aplicaciones restringidas.
  • [C-1-2] DEBE brindar al usuario la posibilidad de activar o desactivar todas estas restricciones de propiedad en cada aplicación.
  • [C-1-3] NO DEBE aplicar automáticamente estas restricciones de propiedad sin evidencia de un comportamiento deficiente de la salud del sistema, pero PUEDE aplicar las restricciones a las aplicaciones al detectar un comportamiento deficiente de la salud del sistema, como wakelocks atascados, servicios de larga duración y otros criterios. Los criterios PUEDEN ser determinados por los implementadores del dispositivo, pero DEBEN estar relacionados con el impacto de la aplicación en el estado del sistema. Otros criterios que no estén puramente relacionados con el estado del sistema, como la falta de popularidad de la aplicación en el mercado, NO DEBEN utilizarse como criterios.

  • [C-1-4] NO DEBE aplicar automáticamente estas restricciones de propiedad para aplicaciones cuando un usuario ha desactivado las restricciones de aplicaciones manualmente, y PUEDE sugerir al usuario que aplique estas restricciones de propiedad.

  • [C-1-5] DEBE informar a los usuarios si estas restricciones de propiedad se aplican a una aplicación automáticamente. Dicha información DEBE proporcionarse en el período de 24 horas anterior a la aplicación de estas restricciones de propiedad.

  • [C-1-6] DEBE devolver verdadero para el método ActivityManager.isBackgroundRestricted() para cualquier llamada API desde una aplicación.

  • [C-1-7] NO DEBE restringir la aplicación de primer plano superior que el usuario utiliza explícitamente.

  • [C-1-8] DEBE suspender estas restricciones de propiedad en una aplicación cada vez que un usuario comienza a usarla explícitamente, convirtiéndola en la aplicación de primer plano.

  • [C-1-9] DEBE informar todos estos eventos de restricciones de propiedad a través de UsageStats.

  • [C-1-10] DEBE proporcionar un documento o sitio web público y claro que describa cómo se aplican las restricciones de propiedad. Este documento o sitio web DEBE poder vincularse desde los documentos del SDK de Android y DEBE incluir:

    • Condiciones desencadenantes de restricciones de propiedad.
    • Qué y cómo se puede restringir una aplicación.
    • Cómo se puede eximir a una aplicación de tales restricciones.
    • Cómo una aplicación puede solicitar una exención de restricciones de propiedad, si admite dicha exención para las aplicaciones que el usuario puede instalar.

Si una aplicación está preinstalada en el dispositivo y un usuario nunca la ha utilizado explícitamente durante más de 30 días, [C-1-3] [C-1-5] están exentos.

Si las implementaciones de dispositivos amplían las restricciones de las aplicaciones implementadas en AOSP, estas:

  • [C-2-1]DEBE seguir la implementación descrita en este documento .

3.5.2. Hibernación de aplicaciones

Si las implementaciones de dispositivos incluyen la hibernación de aplicaciones incluida en AOSP o amplían la función incluida en AOSP, entonces:

  • [C-1-1] DEBE cumplir con todos los requisitos de la sección 3.5.1 excepto [C-1-6] y [C-1-3].
  • [C-1-2] Solo DEBE aplicar la restricción en la aplicación para un usuario cuando hay evidencia de que el usuario no ha utilizado la aplicación durante algún período de tiempo. Se RECOMIENDA ENCARECIDAMENTE que esta duración sea de un mes o más. El uso DEBE definirse mediante la interacción explícita del usuario a través de la API UsageStats#getLastTimeVisible() o cualquier cosa que pueda causar que una aplicación abandone el estado de detención forzada, incluidos enlaces de servicios, enlaces de proveedores de contenido, transmisiones explícitas, etc., que serán rastreados. mediante una nueva API UsageStats#getLastTimeAnyComponentUsed().
  • [C-1-3] Solo DEBE aplicar restricciones que afecten a todos los usuarios del dispositivo cuando haya evidencia de que el paquete no ha sido utilizado por NINGÚN usuario durante algún período de tiempo. Se RECOMIENDA ENCARECIDAMENTE que esta duración sea de un mes o más.
  • [C-1-4] NO DEBE hacer que la aplicación no pueda responder a intentos de actividad, enlaces de servicios, solicitudes de proveedores de contenido o transmisiones explícitas.

La hibernación de aplicaciones en AOSP cumple con los requisitos anteriores.

3.6. Espacios de nombres API

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

Es decir, ellos:

  • [C-0-1] NO DEBE modificar las API expuestas públicamente en la plataforma Android cambiando ningún método o firma de clase, ni eliminando clases o campos de clase.
  • [C-0-2] NO DEBE agregar ningún elemento expuesto públicamente (como clases o interfaces, o campos o métodos a clases o interfaces existentes) o API de prueba o sistema a las API en los espacios de nombres anteriores. Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide" como se usa en el código fuente de Android.

Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las API, pero dichas modificaciones:

  • [C-0-3] NO DEBE afectar el comportamiento indicado ni la firma en lenguaje Java de ninguna API expuesta públicamente.
  • [C-0-4] NO DEBE publicitarse ni exponerse de otro modo a los desarrolladores.

Sin embargo, los implementadores de dispositivos PUEDEN agregar API personalizadas fuera del espacio de nombres estándar de Android, pero las API personalizadas:

  • [C-0-5] NO DEBE estar en un espacio de nombres que sea propiedad de otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar API al espacio de nombres com.google.* o similar: solo Google puede hacerlo. De manera similar, Google NO DEBE agregar API a los espacios de nombres de otras empresas.
  • [C-0-6] DEBE empaquetarse en una biblioteca compartida de Android para que solo las aplicaciones que las usan explícitamente (a través del mecanismo <uses-library>) se vean afectadas por el mayor uso de memoria de dichas API.

Los implementadores de dispositivos PUEDEN agregar API personalizadas en idiomas nativos, fuera de las API del NDK, pero las API personalizadas:

  • [C-1-1] NO DEBE estar en una biblioteca del NDK o en una biblioteca propiedad de otra organización como se describe aquí .

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

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

3.7. Compatibilidad en tiempo de ejecución

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir el formato Dalvik Executable (DEX) completo y la especificación y semántica del código de bytes de Dalvik .

  • [C-0-2] DEBE configurar los tiempos de ejecución de Dalvik para asignar memoria de acuerdo con la plataforma Android ascendente y como se especifica en la siguiente tabla. (Consulte la sección 7.1.1 para conocer las definiciones de tamaño y densidad de pantalla).

  • DEBE utilizar Android RunTime (ART), la implementación ascendente de referencia del formato ejecutable Dalvik y el sistema de gestión de paquetes de la implementación de referencia.

  • DEBE ejecutar pruebas difusas en varios modos de ejecución y arquitecturas de destino para garantizar la estabilidad del tiempo de ejecución. Consulte JFuzz y DexFuzz en el sitio web del Proyecto de código abierto de Android.

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

Diseño de pantalla Densidad de la pantalla Memoria mínima de aplicación
Reloj Android 120 ppp (ldpi) 32MB
140 ppp (140 ppp)
160 ppp (mppp)
180 ppp (180 ppp)
200 ppp (200 ppp)
213 ppp (TV ppp)
220 ppp (220 ppp) 36MB
240 ppp (alta resolución)
280 ppp (280 ppp)
320 ppp (xhdpi) 48MB
360 ppp (360 ppp)
400 ppp (400 ppp) 56MB
420 ppp (420 ppp) 64MB
480 ppp (xxhdpi) 88MB
560 ppp (560 ppp) 112MB
640 ppp (xxxhdpi) 154MB
pequeño/normal 120 ppp (ldpi) 32MB
140 ppp (140 ppp)
160 ppp (mppp)
180 ppp (180 ppp) 48MB
200 ppp (200 ppp)
213 ppp (TV ppp)
220 ppp (220 ppp)
240 ppp (alta resolución)
280 ppp (280 ppp)
320 ppp (xhdpi) 80MB
360 ppp (360 ppp)
400 ppp (400 ppp) 96MB
420 ppp (420 ppp) 112MB
480 ppp (xxhdpi) 128MB
560 ppp (560 ppp) 192MB
640 ppp (xxxhdpi) 256MB
grande 120 ppp (ldpi) 32MB
140 ppp (140 ppp) 48MB
160 ppp (mppp)
180 ppp (180 ppp) 80MB
200 ppp (200 ppp)
213 ppp (TV ppp)
220 ppp (220 ppp)
240 ppp (alta resolución)
280 ppp (280 ppp) 96MB
320 ppp (xhdpi) 128MB
360 ppp (360 ppp) 160MB
400 ppp (400 ppp) 192MB
420 ppp (420 ppp) 228MB
480 ppp (xxhdpi) 256MB
560 ppp (560 ppp) 384MB
640 ppp (xxxhdpi) 512MB
extra grande 120 ppp (ldpi) 48MB
140 ppp (140 ppp) 80MB
160 ppp (mppp)
180 ppp (180 ppp) 96MB
200 ppp (200 ppp)
213 ppp (TV ppp)
220 ppp (220 ppp)
240 ppp (alta resolución)
280 ppp (280 ppp) 144MB
320 ppp (xhdpi) 192MB
360 ppp (360 ppp) 240MB
400 ppp (400 ppp) 288MB
420 ppp (420 ppp) 336MB
480 ppp (xxhdpi) 384MB
560 ppp (560 ppp) 576MB
640 ppp (xxxhdpi) 768MB

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Lanzador (pantalla de inicio)

Android incluye una aplicación de inicio (pantalla de inicio) y soporte para aplicaciones de terceros para reemplazar el iniciador del dispositivo (pantalla de inicio).

Si las implementaciones del dispositivo permiten que aplicaciones de terceros reemplacen la pantalla de inicio del dispositivo, estas:

  • [C-1-1] DEBE declarar la característica de la plataforma android.software.home_screen .
  • [C-1-2] DEBE devolver el objeto AdaptiveIconDrawable cuando la aplicación de terceros usa la etiqueta <adaptive-icon> para proporcionar su ícono y se llama a los métodos PackageManager para recuperar íconos.

Si las implementaciones de dispositivos incluyen un iniciador predeterminado que admite la fijación de accesos directos en la aplicación,:

Por el contrario, si las implementaciones de dispositivos no admiten la fijación de accesos directos en la aplicación, estas:

Si las implementaciones de dispositivos implementan un iniciador predeterminado que brinda acceso rápido a los accesos directos adicionales proporcionados por aplicaciones de terceros a través de la API ShortcutManager ,:

  • [C-4-1] DEBE admitir todas las funciones de acceso directo documentadas (por ejemplo, accesos directos estáticos y dinámicos, accesos directos de fijación) e implementar completamente las API de la clase API ShortcutManager .

Si las implementaciones de dispositivos incluyen una aplicación de inicio predeterminada que muestra insignias para los íconos de las aplicaciones, estas:

  • [C-5-1] DEBE respetar el método API NotificationChannel.setShowBadge() . En otras palabras, muestre una prestación visual asociada con el ícono de la aplicación si el valor está establecido como true y no muestre ningún esquema de insignias del ícono de la aplicación cuando todos los canales de notificación de la aplicación hayan establecido el valor como false .
  • PUEDE anular las insignias de íconos de aplicaciones con su esquema de insignias patentado cuando las aplicaciones de terceros indican compatibilidad con el esquema de insignias patentadas mediante el uso de API patentadas, pero DEBE usar los recursos y valores proporcionados a través de las API de insignias de notificación descritas en el SDK , como la API Notification.Builder.setNumber() y Notification.Builder.setBadgeIconType() .

Si las implementaciones de dispositivos admiten íconos monocromáticos , estos íconos:

  • [C-6-1] DEBE usarse solo cuando un usuario los habilita explícitamente (por ejemplo, a través de Configuración o del menú de selección de fondo de pantalla).

3.8.2. widgets

Android admite widgets de aplicaciones de terceros al definir un tipo de componente y la API y el ciclo de vida correspondientes que permiten a las aplicaciones exponer un "AppWidget" al usuario final.

Si las implementaciones de dispositivos admiten widgets de aplicaciones de terceros, estos:

  • [C-1-1] DEBE declarar compatibilidad con la función de plataforma android.software.app_widgets .
  • [C-1-2] DEBE incluir soporte integrado para AppWidgets y exponer las posibilidades de la interfaz de usuario para agregar, configurar, ver y eliminar AppWidgets

  • [C-1-3] DEBE ser capaz de representar widgets de 4 x 4 en el tamaño de cuadrícula estándar. Consulte las pautas de diseño de widgets de aplicaciones en la documentación del SDK de Android para obtener más detalles.

  • PUEDE admitir widgets de aplicaciones en la pantalla de bloqueo.

Si las implementaciones de dispositivos admiten widgets de aplicaciones de terceros y fijación de accesos directos en la aplicación,:

3.8.3. Notificaciones

Android incluye API Notification y NotificationManager que permiten a los desarrolladores de aplicaciones de terceros notificar a los usuarios sobre eventos notables y atraer la atención de los usuarios utilizando los componentes de hardware (p. ej., sonido, vibración y luz) y funciones de software (p. ej., pantalla de notificación, barra del sistema) del dispositivo. .

3.8.3.1. Presentación de Notificaciones

Si las implementaciones de dispositivos permiten que aplicaciones de terceros notifiquen a los usuarios sobre eventos importantes , estas:

  • [C-1-1] DEBE admitir notificaciones que utilizan funciones de hardware, como se describe en la documentación del SDK, y en la medida de lo posible con el hardware de implementación del dispositivo. Por ejemplo, si la implementación de un dispositivo incluye un vibrador, DEBE implementar correctamente las API de vibración. Si la implementación de un dispositivo carece de hardware, las API correspondientes DEBEN implementarse como no operativas. Este comportamiento se detalla más en la sección 7 .
  • [C-1-2] DEBEN representar correctamente todos los recursos (iconos, archivos de animación, etc.) proporcionados en las API o en la guía de estilo de iconos de la barra de estado/sistema, aunque PUEDEN proporcionar una experiencia de usuario alternativa para las notificaciones. proporcionado por la implementación de código abierto de Android de referencia.
  • [C-1-3] DEBE respetar e implementar adecuadamente los comportamientos descritos para que las API actualicen, eliminen y agrupen notificaciones.
  • [C-1-4] DEBE proporcionar el comportamiento completo de la API NotificationChannel documentada en el SDK.
  • [C-1-5] DEBE proporcionar al usuario la posibilidad de bloquear y modificar la notificación de una determinada aplicación de terceros por cada canal y nivel de paquete de aplicación.
  • [C-1-6] También DEBE proporcionar al usuario la posibilidad de mostrar canales de notificación eliminados.
  • [C-1-7] DEBE representar correctamente todos los recursos (imágenes, pegatinas, íconos, etc.) proporcionados a través de Notification.MessagingStyle junto con el texto de notificación sin interacción adicional del usuario. Por ejemplo, DEBE mostrar todos los recursos, incluidos los íconos proporcionados a través de android.app.Person , en una conversación grupal configurada a través de setGroupConversation .

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE proporcionar una posibilidad para que el usuario controle las notificaciones que están expuestas a las aplicaciones a las que se les ha otorgado el permiso de escucha de notificaciones. La granularidad DEBE ser tal que el usuario pueda controlar para cada uno de estos oyentes de notificaciones qué tipos de notificaciones se conectan a este oyente. Los tipos DEBEN incluir notificaciones de "conversaciones", "alertas", "silenciosas" y "importantes en curso".

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE brindar a los usuarios la posibilidad de especificar aplicaciones para excluirlas de la notificación a cualquier oyente de notificaciones específico.

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE mostrar automáticamente la posibilidad de que un usuario bloquee la notificación de una determinada aplicación de terceros por cada canal y nivel de paquete de aplicación después de que el usuario descarte esa notificación varias veces.

  • DEBE admitir notificaciones enriquecidas.

  • DEBE presentar algunas notificaciones de mayor prioridad como notificaciones de aviso.

  • DEBE tener la posibilidad de que el usuario posponga las notificaciones.

  • PUEDE solo administrar la visibilidad y el momento en que las aplicaciones de terceros pueden notificar a los usuarios sobre eventos notables para mitigar problemas de seguridad como la distracción del conductor.

Android 11 presenta soporte para notificaciones de conversaciones, que son notificaciones que usan MessagingStyle y proporcionan una ID de acceso directo de personas publicada.

Implementaciones de dispositivos:

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE agrupar y mostrar conversation notifications antes de las notificaciones que no son de conversación, con la excepción de las notificaciones de servicio en primer plano en curso y importance:high .

Si las implementaciones de dispositivos admiten conversation notifications y la aplicación proporciona los datos necesarios para bubbles , estas:

  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE mostrar esta conversación como una burbuja. La implementación de AOSP cumple con estos requisitos con la interfaz de usuario, la configuración y el iniciador del sistema predeterminados.

Si las implementaciones de dispositivos admiten notificaciones enriquecidas, estas:

  • [C-2-1] DEBE utilizar los recursos exactos proporcionados a través de la clase API Notification.Style y sus subclases para los elementos de recursos presentados.
  • DEBE presentar todos y cada uno de los elementos de recurso (por ejemplo, icono, título y texto de resumen) definidos en la clase API Notification.Style y sus subclases.

Las notificaciones emergentes son notificaciones que se presentan al usuario a medida que llegan, independientemente de la superficie en la que se encuentre. Si las implementaciones de dispositivos admiten notificaciones automáticas, entonces:

  • [C-3-1] DEBE utilizar la vista de notificación de aviso y los recursos como se describe en la clase API Notification.Builder cuando se presentan notificaciones de aviso.
  • [C-3-2] DEBE mostrar las acciones proporcionadas a través de Notification.Builder.addAction() junto con el contenido de la notificación sin interacción adicional del usuario como se describe en el SDK .
3.8.3.2. Servicio de escucha de notificaciones

Android incluye las API NotificationListenerService que permiten que las aplicaciones (una vez habilitadas explícitamente por el usuario) reciban una copia de todas las notificaciones a medida que se publican o actualizan.

Implementaciones de dispositivos:

  • [C-0-1] DEBE actualizar correcta y rápidamente las notificaciones 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.
  • [C-0-2] DEBE respetar la llamada a la API snoozeNotification() , descartar la notificación y realizar una devolución de llamada después de la duración de la repetición establecida en la llamada a la API.

Si las implementaciones de dispositivos permiten al usuario posponer notificaciones, estas:

  • [C-1-1] DEBE reflejar correctamente el estado de notificación pospuesta a través de las API estándar, como NotificationListenerService.getSnoozedNotifications() .
  • [C-1-2] DEBE hacer que esta opción de usuario esté disponible para posponer notificaciones de cada aplicación de terceros instalada, a menos que sean de servicios persistentes/en primer plano.
3.8.3.3. DND (No molestar) / Modo de prioridad

Si las implementaciones de dispositivos admiten la función DND (también llamada modo de prioridad),:

  • [C-1-1] DEBE, cuando la implementación del dispositivo ha proporcionado un medio para que el usuario conceda o deniegue el acceso a aplicaciones de terceros a la configuración de la política DND, mostrar las reglas DND automáticas creadas por las aplicaciones junto con las reglas creadas por el usuario y previas. -reglas definidas.
  • [C-1-3] DEBE respetar los valores suppressedVisualEffects pasados ​​a lo largo de NotificationManager.Policy y si una aplicación ha configurado cualquiera de los indicadores SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEBE indicar al usuario que los efectos visuales están suprimidos en el menú de configuración DND.

3.8.4. Ayudar a las API

Android incluye las API de asistencia para permitir que las aplicaciones elijan cuánta información del contexto actual se comparte con el asistente en el dispositivo.

Si las implementaciones de dispositivos admiten la acción de asistencia, estas:

  • [C-2-1] DEBE indicar claramente al usuario final cuándo se comparte el contexto, ya sea por:
    • Cada vez que la aplicación de asistencia accede al contexto, muestra una luz blanca alrededor de los bordes de la pantalla que iguala o supera la duración y el brillo de la implementación del Proyecto de código abierto de Android.
    • Para la aplicación de asistencia preinstalada, proporcionar al usuario posibilidades a menos de dos navegaciones de la entrada de voz predeterminada y el menú de configuración de la aplicación de asistente , y solo compartir el contexto cuando el usuario invoca explícitamente la aplicación de asistencia a través de una palabra activa o la entrada de una tecla de navegación de asistencia.
  • [C-2-2] La interacción designada para iniciar la aplicación de asistencia como se describe en la sección 7.2.3 DEBE iniciar la aplicación de asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que maneje la intención ACTION_ASSIST .

3.8.5. Alertas y Brindis

Las aplicaciones pueden usar la API Toast para mostrar cadenas cortas no modales al usuario final que desaparecen después de un breve período de tiempo, y usar la API de tipo de ventana TYPE_APPLICATION_OVERLAY para mostrar ventanas de alerta como una superposición sobre otras aplicaciones.

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] DEBE proporcionar al usuario la posibilidad de bloquear una aplicación para que no muestre ventanas de alerta que utilicen TYPE_APPLICATION_OVERLAY . La implementación de AOSP cumple con este requisito al tener controles en el tono de notificación.

  • [C-1-2] DEBE respetar la API de Toast y mostrar Toast desde las aplicaciones a los usuarios finales de alguna manera muy visible.

3.8.6. Temas

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

Android incluye una familia de temas "Holo" y "Material" como un conjunto de estilos definidos para que los utilicen los desarrolladores de aplicaciones si desean igualar la apariencia del tema Holo según lo definido por el SDK de Android.

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] NO DEBE alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones.
  • [C-1-2] DEBE admitir la familia de temas “Material” y NO DEBE alterar ninguno de los atributos del tema Material ni sus activos expuestos a las aplicaciones.
  • [C-1-3] DEBE configurar la familia de fuentes "sans-serif" en la versión 2.x de Roboto para los idiomas que admite Roboto, o proporcionar al usuario la posibilidad de cambiar la fuente utilizada para la familia de fuentes "sans-serif" a Roboto versión 2.x para los idiomas que admite Roboto.

  • [C-1-4] DEBE generar paletas tonales de colores dinámicas como se especifica en la documentación de AOSP de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.system_palette y android.theme.customization.theme_style ).

  • [C-1-5] DEBE generar paletas tonales de colores dinámicas utilizando los estilos de tema de color enumerados en la documentación Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulte android.theme.customization.theme_styles ), a saber, TONAL_SPOT , VIBRANT , EXPRESSIVE , SPRITZ , RAINBOW , FRUIT_SALAD y MONOCHROMATIC . .

    El "color de origen" se utiliza para generar paletas tonales de colores dinámicas cuando se envía con android.theme.customization.system_palette (como se documenta en Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ).

  • [C-1-6] DEBE tener un valor de croma CAM16 de 5 o mayor.

    • DEBE derivarse del fondo de pantalla a través de com.android.systemui.monet.ColorScheme#getSeedColors , que proporciona múltiples colores de origen válidos para elegir uno.

    • DEBE utilizar el valor 0xFF1B6EF3 , si ninguno de los colores proporcionados cumple con el requisito de color de origen anterior.

Android también incluye una familia de temas "Predeterminado del dispositivo" como un conjunto de estilos definidos para que los utilicen los desarrolladores de aplicaciones si desean igualar la apariencia del tema del dispositivo según lo definido por el implementador del dispositivo.

Android admite una variante del tema con barras de sistema translúcidas, que permite a los desarrolladores de aplicaciones llenar el área detrás de la barra de estado y navegación con el contenido de su aplicación. Para permitir una experiencia de desarrollador consistente en esta configuración, es importante que el estilo del ícono de la barra de estado se mantenga en diferentes implementaciones de dispositivos.

Si las implementaciones de dispositivos incluyen una barra de estado del sistema, estas:

  • [C-2-1] DEBE usar blanco para los íconos de estado del sistema (como la intensidad de la señal y el nivel de la batería) y las notificaciones emitidas por el sistema, a menos que el ícono indique un estado problemático o una aplicación solicite una barra de estado luminosa usando WindowInsetsController# Bandera APPEARANCE_LIGHT_STATUS_BARS .
  • [C-2-2] Las implementaciones de dispositivos Android DEBEN cambiar el color de los íconos de estado del sistema a negro (para obtener más detalles, consulte R.style ) cuando una aplicación solicita una barra de estado iluminada.

3.8.7. Fondos de pantalla vivos

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

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

  • Las implementaciones de dispositivos capaces de ejecutar fondos de pantalla en vivo de manera confiable, como se describe anteriormente, DEBEN implementar fondos de pantalla en vivo.

Si las implementaciones de dispositivos implementan fondos de pantalla en vivo, estos:

  • [C-1-1] DEBE informar el indicador de función de la plataforma android.software.live_wallpaper.

3.8.8. Cambio de actividad

El código fuente de Android incluye la pantalla de descripción general , una interfaz de usuario a nivel de sistema para cambiar de tarea y mostrar actividades y tareas a las que se accedió recientemente utilizando una imagen en miniatura del estado gráfico de la aplicación en el momento en que el usuario abandonó la aplicación por última vez.

Las implementaciones del dispositivo, incluida la tecla de navegación de la función reciente, como se detalla en la sección 7.2.3 , PUEDEN alterar la interfaz.

Si las implementaciones del dispositivo, incluida la tecla de navegación de la función reciente, como se detalla en la sección 7.2.3 , alteran la interfaz:

  • [C-1-1] DEBE admitir al menos hasta 7 actividades mostradas.
  • DEBE mostrar al menos el título de 4 actividades a la vez.

  • DEBE mostrar el color de resaltado, el ícono y el título de la pantalla en los últimos tiempos.
  • DEBE mostrar una opción de cierre ("x") pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas.
  • DEBE implementar un atajo para cambiar fácilmente a la actividad anterior.
  • DEBE activar la acción de cambio rápido entre las dos aplicaciones utilizadas más recientemente, cuando se toca dos veces la tecla de función reciente.
  • DEBE activar el modo de ventana múltiple de pantalla dividida, si es compatible, cuando se presiona prolongadamente la tecla de funciones recientes.
  • PUEDE mostrar los últimos afiliados como un grupo que se mueve en conjunto.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE utilizar la interfaz de usuario de Android (o una interfaz similar basada en miniaturas) para la pantalla de descripción general.

3.8.9. Gestión de entradas

Android incluye soporte para administración de entradas y soporte para editores de métodos de entrada de terceros.

Si las implementaciones del dispositivo permiten a los usuarios utilizar métodos de entrada de terceros en el dispositivo, ellos:

  • [C-1-1] DEBE declarar la característica de la plataforma android.software.input_methods y admitir API de IME como se define en la documentación del SDK de Android.

3.8.10. Control de medios de pantalla de bloqueo

La API del cliente de control remoto está obsoleta en Android 5.0 en favor de la plantilla de notificación multimedia que permite que las aplicaciones multimedia se integren con los controles de reproducción que se muestran en la pantalla de bloqueo.

3.8.11. Salvapantallas (anteriormente Dreams)

Consulte la sección 3.2.3.5 para conocer las configuraciones destinadas a configurar los protectores de pantalla.

3.8.12. Ubicación

Si las implementaciones del dispositivo incluyen un sensor de hardware (por ejemplo, GPS) que es capaz de proporcionar las coordenadas de ubicación,

3.8.13. Unicode y fuente

Android incluye soporte para los caracteres emoji definidos en Unicode 10.0 .

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] DEBE ser capaz de representar estos caracteres emoji en glifos de color.
  • [C-1-2] DEBE incluir soporte para:
    • Fuente Roboto 2 con diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para los idiomas disponibles en dispositivo.
    • Cobertura completa de Unicode 7.0 de latín, griego y cirílico, incluidos los rangos de latín extendido A, B, C y D, y todos los glifos en el bloque de símbolos de moneda de Unicode 7.0.
  • [C-1-3] NO DEBE eliminar ni modificar NotoColorEmoji.tff en la imagen del sistema. (Es aceptable agregar una nueva fuente de emoji para anular los emoji en NotoColorEmoji.tff)
  • DEBE admitir el tono de piel y diversos emojis familiares como se especifica en el Informe técnico de Unicode n.° 51 .

Si las implementaciones de dispositivos incluyen un IME,:

  • DEBE proporcionar un método de entrada al usuario para estos caracteres emoji.

Android incluye soporte para representar fuentes de Myanmar. Myanmar tiene varias fuentes que no son compatibles con Unicode, comúnmente conocidas como “Zawgyi”, para representar idiomas de Myanmar.

Si las implementaciones de dispositivos incluyen soporte para birmano, estos:

  • [C-2-1] DEBE representar el texto con una fuente compatible con Unicode de forma predeterminada; La fuente que no sea compatible con Unicode NO DEBE establecerse como fuente predeterminada a menos que el usuario la elija en el selector de idioma.
  • [C-2-2] DEBE admitir una fuente Unicode y una fuente que no sea compatible con Unicode si el dispositivo admite una fuente que no es compatible con Unicode. La fuente que no es compatible con Unicode NO DEBE eliminar ni sobrescribir la fuente Unicode.
  • [C-2-3] DEBE representar texto con una fuente que no sea compatible con Unicode SÓLO SI se especifica un código de idioma con código de escritura Qaag (por ejemplo, my-Qaag). No se puede utilizar ningún otro código de región o idioma ISO (ya sea asignado, no asignado o reservado) para hacer referencia a fuentes que no sean compatibles con Unicode para Myanmar. Los desarrolladores de aplicaciones y autores de páginas web pueden especificar my-Qaag como código de idioma designado como lo harían con cualquier otro idioma.

3.8.14. Ventanas múltiples

Si las implementaciones de dispositivos tienen la capacidad de mostrar múltiples actividades al mismo tiempo:

  • [C-1-1] DEBE implementar dichos modos de ventanas múltiples de acuerdo con los comportamientos de las aplicaciones y las API descritos en la documentación de soporte del modo de ventanas múltiples del SDK de Android y cumplir con los siguientes requisitos:
  • [C-1-2] DEBE respetar android:resizeableActivity configurada por una aplicación en el archivo AndroidManifest.xml como se describe en este SDK .
  • [C-1-3] NO DEBE ofrecer modo de pantalla dividida o de forma libre si la altura de la pantalla es inferior a 440 dp y el ancho de la pantalla es inferior a 440 dp.
  • [C-1-4] NO SE DEBE cambiar el tamaño de una actividad a un tamaño inferior a 220 ppp en modos de ventanas múltiples que no sean Imagen en imagen.
  • Las implementaciones de dispositivos con tamaño de pantalla xlarge DEBEN admitir el modo de forma libre.

Si las implementaciones de dispositivos admiten modos de ventanas múltiples y el modo de pantalla dividida,:

  • [C-2-2] DEBE recortar la actividad acoplada de una ventana múltiple de pantalla dividida, pero DEBE mostrar parte de su contenido, si la aplicación Iniciador es la ventana enfocada.
  • [C-2-3] DEBE respetar los valores declarados AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight de la aplicación de inicio de terceros y no anular estos valores mientras muestra algún contenido de la actividad acoplada.

Si las implementaciones de dispositivos admiten modos de ventanas múltiples y el modo de ventanas múltiples Imagen en imagen,:

  • [C-3-1] DEBE iniciar actividades en modo de ventanas múltiples de imagen en imagen cuando la aplicación: * Tiene como objetivo el nivel de API 26 o superior y declara android:supportsPictureInPicture * Tiene como objetivo el nivel de API 25 o inferior y declara ambos android:resizeableActivity y android:supportsPictureInPicture .
  • [C-3-2] DEBE exponer las acciones en su SystemUI según lo especificado por la actividad PIP actual a través de la API setActions() .
  • [C-3-3] DEBE admitir relaciones de aspecto mayores o iguales a 1:2,39 y menores o iguales a 2,39:1, según lo especificado por la actividad PIP a través de la API setAspectRatio() .
  • [C-3-4] DEBE usar KeyEvent.KEYCODE_WINDOW para controlar la ventana PIP; Si el modo PIP no está implementado, la clave DEBE estar disponible para la actividad en primer plano.
  • [C-3-5] DEBE proporcionar al usuario la posibilidad de bloquear la visualización de una aplicación en modo PIP; la implementación de AOSP cumple con este requisito al tener controles en el tono de notificación.
  • [C-3-6] DEBE asignar el siguiente ancho y alto mínimos para la ventana PIP cuando una aplicación no declara ningún valor para AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight :

    • Los dispositivos con Configuration.uiMode configurado de manera distinta a UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho y alto mínimos de 108 dp.
    • Los dispositivos con Configuration.uiMode configurado en UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.

3.8.15. Recorte de pantalla

Android admite un recorte de pantalla como se describe en el documento del SDK. La API DisplayCutout define un área en el borde de la pantalla que puede no ser funcional para una aplicación debido a un corte en la pantalla o una pantalla curva en los bordes.

Si las implementaciones de dispositivos incluyen recortes de pantalla, estos:

  • [C-1-5] NO DEBE tener recortes si la relación de aspecto del dispositivo es 1,0 (1:1).
  • [C-1-2] NO DEBE tener más de un corte por borde.
  • [C-1-3] DEBE respetar los indicadores de corte de pantalla establecidos por la aplicación a través de la API WindowManager.LayoutParams como se describe en el SDK.
  • [C-1-4] DEBE informar los valores correctos para todas las métricas de recorte definidas en la API DisplayCutout .

3.8.16. Controles del dispositivo

Android incluye ControlsProviderService y Control API para permitir que aplicaciones de terceros publiquen controles de dispositivos para obtener estados y acciones rápidas para los usuarios.

Consulte la Sección 2_2_3 para conocer los requisitos específicos del dispositivo.

3.8.17. Portapapeles

Implementaciones de dispositivos:

  • [C-0-1] NO DEBE enviar datos del portapapeles a ningún componente, actividad, servicio o a través de cualquier conexión de red, sin una acción explícita del usuario (por ejemplo, presionar un botón en la superposición), excepto para los servicios mencionados en 9.8.6 Contenido Captura y búsqueda de aplicaciones .

Si las implementaciones de dispositivos generan una vista previa visible para el usuario cuando el contenido se copia al portapapeles para cualquier elemento ClipData donde ClipData.getDescription().getExtras() contenga android.content.extra.IS_SENSITIVE ,:

  • [C-1-1] DEBE redactar la vista previa visible del usuario

La implementación de referencia de AOSP satisface estos requisitos del portapapeles.

3.9. Administración de dispositivos

Android incluye funciones que permiten que las aplicaciones conscientes de la seguridad realicen funciones de administración de dispositivos a nivel del sistema, como aplicar políticas de contraseña o realizar un borrado remoto, a través de la API de administración de dispositivos Android .

Si las implementaciones de dispositivos implementan toda la gama de políticas de administración de dispositivos definidas en la documentación del SDK de Android, estas:

  • [C-1-1] DEBE declarar android.software.device_admin .
  • [C-1-2] DEBE admitir el aprovisionamiento del propietario del dispositivo como se describe en la sección 3.9.1 y la sección 3.9.1.1 .

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

Si las implementaciones de dispositivos declaran android.software.device_admin ,:

  • [C-1-1] DEBE admitir la inscripción de un Cliente de Política de Dispositivo (DPC) como una aplicación de Propietario del Dispositivo como se describe a continuación:
    • Cuando la implementación del dispositivo no tiene usuarios ni datos de usuario configurados:
      • [C-1-5] DEBE inscribir la aplicación DPC como la aplicación Propietario del dispositivo o habilitar la aplicación DPC para elegir si desea convertirse en Propietario del dispositivo o Propietario del perfil, si el dispositivo declara compatibilidad con comunicaciones de campo cercano (NFC) a través de la función. marca android.hardware.nfc y recibe un mensaje NFC que contiene un registro con tipo MIME MIME_TYPE_PROVISIONING_NFC .
      • [C-1-8] DEBE enviar la intención ACTION_GET_PROVISIONING_MODE después de que se active el aprovisionamiento del propietario del dispositivo para que la aplicación DPC pueda elegir si desea convertirse en propietario del dispositivo o propietario del perfil, según los valores de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES , a menos que se puede determinar a partir del contexto que solo hay una opción válida.
      • [C-1-9] DEBE enviar la intención ACTION_ADMIN_POLICY_COMPLIANCE a la aplicación del propietario del dispositivo si se establece un propietario del dispositivo durante el aprovisionamiento, independientemente del método de aprovisionamiento utilizado. El usuario no debe poder continuar con el Asistente de configuración hasta que finalice la aplicación Propietario del dispositivo.
    • Cuando la implementación del dispositivo tenga usuarios o datos de usuarios:
      • [C-1-7] Ya no DEBE inscribir ninguna aplicación DPC como la aplicación del propietario del dispositivo.
  • [C-1-2] DEBE mostrar un aviso de divulgación apropiado ( como el mencionado en AOSP ) y obtener el consentimiento afirmativo del usuario final antes de configurar una aplicación como Propietario del dispositivo, a menos que el dispositivo esté configurado mediante programación para el Modo de demostración minorista antes de interacción en pantalla con el usuario final. Si las implementaciones de dispositivos declaran android.software.device_admin , pero también incluyen una solución de administración de dispositivos patentada y proporcionan un mecanismo para promover una aplicación configurada en su solución como un "propietario de dispositivo equivalente" al "propietario de dispositivo" estándar reconocido por el estándar Android. Las API de DevicePolicyManager :

  • [C-2-1] DEBE contar con un proceso para verificar que la aplicación específica que se promociona pertenece a una solución de administración de dispositivos empresariales legítima y se ha configurado en la solución propietaria para tener los derechos equivalentes a los de "Propietario del dispositivo".

  • [C-2-2] DEBE mostrar la misma divulgación de consentimiento del propietario del dispositivo AOSP que el flujo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de inscribir la aplicación DPC como "Propietario del dispositivo".

  • [C-2-3] NO DEBE codificar el consentimiento ni impedir el uso de otras aplicaciones del propietario del dispositivo.

3.9.1.2 Aprovisionamiento de perfil administrado

Si las implementaciones de dispositivos declaran android.software.managed_users ,:

  • [C-1-1] DEBE implementar las API que permiten que una aplicación de Controlador de políticas de dispositivos (DPC) se convierta en propietaria de un nuevo perfil administrado .

  • [C-1-2] El proceso de aprovisionamiento de perfil administrado (el flujo iniciado por el DPC usando android.app.action.PROVISION_MANAGED_PROFILE ) o por la plataforma), la pantalla de consentimiento y la experiencia del usuario DEBEN alinearse con la implementación de AOSP.

  • [C-1-3] DEBE proporcionar las siguientes posibilidades de usuario dentro de la Configuración para indicarle cuando el Controlador de política de dispositivos (DPC) ha desactivado una función particular del sistema:

    • Un ícono consistente u otra opción para el usuario (por ejemplo, el ícono de información de AOSP ascendente) para representar cuando un administrador de dispositivo restringe una configuración particular.
    • Un breve mensaje de explicación, proporcionado por el administrador del dispositivo a través de setShortSupportMessage .
    • El icono de la aplicación DPC.
  • [C-1-4] DEBE iniciar el controlador para la intención ACTION_PROVISIONING_SUCCESSFUL en el perfil de trabajo si se establece un propietario del perfil cuando la intención android.app.action.PROVISION_MANAGED_PROFILE inicia el aprovisionamiento y el DPC ha implementado el controlador.

  • [C-1-5] DEBE enviar la transmisión ACTION_PROFILE_PROVISIONING_COMPLETE al DPC del perfil de trabajo cuando el intent android.app.action.PROVISION_MANAGED_PROFILE inicia el aprovisionamiento.

  • [C-1-6] DEBE enviar la intención ACTION_GET_PROVISIONING_MODE después de que se activa el aprovisionamiento del propietario del perfil para que la aplicación DPC pueda elegir si desea convertirse en propietario del dispositivo o propietario del perfil, excepto cuando el aprovisionamiento se activa mediante la intención android.app.action.PROVISION_MANAGED_PROFILE .

  • [C-1-7] DEBE enviar la intención ACTION_ADMIN_POLICY_COMPLIANCE al perfil de trabajo cuando se establece un propietario del perfil durante el aprovisionamiento, independientemente del método de aprovisionamiento que se utilice, excepto cuando el aprovisionamiento lo activa la intención android.app.action.PROVISION_MANAGED_PROFILE . El usuario no debe poder continuar con el asistente de configuración hasta que finalice la aplicación Propietario del perfil.

  • [C-1-8] DEBE enviar la transmisión ACTION_MANAGED_PROFILE_PROVISIONED al DPC del perfil personal cuando se establece un propietario del perfil, independientemente del método de aprovisionamiento utilizado.

3.9.2 Soporte de perfil administrado

Si las implementaciones de dispositivos declaran android.software.managed_users ,:

  • [C-1-1] DEBE admitir perfiles administrados a través de las API android.app.admin.DevicePolicyManager .
  • [C-1-2] DEBE permitir la creación de un solo perfil administrado .
  • [C-1-3] DEBE usar una insignia de icono (similar a la insignia de trabajo ascendente de AOSP) para representar las aplicaciones y widgets administrados y otros elementos de la interfaz de usuario con insignias, como Recientes y Notificaciones.
  • [C-1-4] DEBE mostrar un ícono de notificación (similar a la insignia de trabajo ascendente de AOSP) para indicar cuando el usuario está dentro de una aplicación de perfil administrado.
  • [C-1-5] DEBE mostrar un brindis que indique que el usuario está en el perfil administrado siempre y cuando el dispositivo se active (ACTION_USER_PRESENT) y la aplicación en primer plano esté dentro del perfil administrado.
  • [C-1-6] Cuando exista un perfil administrado, DEBE mostrar una opción visual en el 'Selector' de intención para permitir al usuario reenviar la intención desde el perfil administrado al usuario principal o viceversa, si lo habilita la Política del dispositivo. Controlador.
  • [C-1-7] Cuando exista un perfil administrado, DEBE exponer las siguientes posibilidades de usuario tanto para el usuario principal como para el perfil administrado:
    • Contabilidad separada para el uso de batería, ubicación, datos móviles y almacenamiento para el usuario principal y el perfil administrado.
    • Gestión independiente de aplicaciones VPN instaladas dentro del usuario principal o perfil administrado.
    • Gestión independiente de aplicaciones instaladas dentro del usuario principal o perfil administrado.
    • Gestión independiente de cuentas dentro del usuario principal o perfil administrado.
  • [C-1-8] DEBE garantizar que las aplicaciones de marcador, contactos y mensajería preinstaladas puedan buscar y consultar la información de la persona que llama desde el perfil administrado (si existe) junto con la del perfil principal, si el Controlador de políticas de dispositivos lo permite.
  • [C-1-9] DEBE garantizar que cumple con todos los requisitos de seguridad aplicables para un dispositivo con múltiples usuarios habilitados (consulte la sección 9.5 ), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.

Iniciar nuevos requisitos

  • [C-1-10] DEBE garantizar que los datos de la captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se captura una captura de pantalla con una ventana topActivity que tiene el foco (aquel con el que el usuario interactuó en último lugar entre todas las actividades) y pertenece a un perfil de trabajo. aplicación .
  • [C-1-11] NO DEBE capturar ningún otro contenido de la pantalla (barra del sistema, notificaciones o cualquier contenido del perfil personal) excepto la ventana/ventanas de la aplicación del perfil de trabajo al guardar una captura de pantalla en el perfil de trabajo (para garantizar que los datos del perfil personal estén no guardado en el perfil de trabajo).

Terminar con nuevos requisitos

Si las implementaciones de dispositivos declaran android.software.managed_users y android.software.secure_lock_screen ,:

  • [C-2-1] DEBE admitir la capacidad de especificar una pantalla de bloqueo separada que cumpla con los siguientes requisitos para otorgar acceso a aplicaciones que se ejecutan en un perfil administrado únicamente.
    • Las implementaciones de dispositivos DEBEN respetar la intención DevicePolicyManager.ACTION_SET_NEW_PASSWORD y mostrar una interfaz para configurar una credencial de pantalla de bloqueo separada para el perfil administrado.
    • Las credenciales de la pantalla de bloqueo del perfil administrado DEBEN utilizar los mismos mecanismos de administración y almacenamiento de credenciales que el perfil principal, como se documenta en el sitio del proyecto de código abierto de Android .
    • Las políticas de contraseña de DPC DEBEN aplicarse únicamente a las credenciales de la pantalla de bloqueo del perfil administrado, a menos que se soliciten en la instancia DevicePolicyManager devuelta por getParentProfileInstance .
  • Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la interfaz de usuario de llamadas entrantes, las notificaciones de llamadas en curso y perdidas, los contactos y las aplicaciones de mensajería, DEBEN tener la misma insignia que se usa para indicar las aplicaciones del perfil administrado.

3.9.3 Soporte de usuario administrado

Si las implementaciones de dispositivos declaran android.software.managed_users ,:

  • [C-1-1] DEBE proporcionar al usuario la posibilidad de cerrar la sesión del usuario actual y volver al usuario principal en una sesión de múltiples usuarios cuando isLogoutEnabled devuelve true . Se DEBE poder acceder a las prestaciones del usuario desde la pantalla de bloqueo sin desbloquear el dispositivo.

Si las implementaciones de dispositivos declaran android.software.device_admin y brindan al usuario en el dispositivo la posibilidad de agregar usuarios secundarios adicionales, estos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar las mismas divulgaciones de consentimiento del propietario del dispositivo AOSP que se mostraron en el flujo iniciado por android.app.action.PROVISION_MANAGED_DEVICE , antes de permitir que se agreguen cuentas en el nuevo usuario secundario, para que los usuarios comprendan que se gestiona el dispositivo.

3.9.4 Requisitos de la función de administración de políticas de dispositivos

Si las implementaciones de dispositivos informan android.software.device_admin o android.software.managed_users , entonces:

  • [C-1-1] DEBE admitir la función de administración de políticas de dispositivos como se define en la sección 9.1 . La aplicación que tiene la función de administración de políticas del dispositivo PUEDE definirse configurando config_devicePolicyManagement en el nombre del paquete. El nombre del paquete DEBE ir seguido de : y el certificado de firma, a menos que la aplicación esté precargada.

Si no se define un nombre de paquete para config_devicePolicyManagement como se describe arriba:

Si se define un nombre de paquete para config_devicePolicyManagement como se describe arriba:

  • [C-3-1] La aplicación DEBE estar instalada en todos los perfiles de un usuario .
  • [C-3-2] Las implementaciones de dispositivos PUEDEN definir una aplicación que actualice el titular de la función de administración de políticas del dispositivo antes del aprovisionamiento configurando config_devicePolicyManagementUpdater .

Si se define un nombre de paquete para config_devicePolicyManagementUpdater como se describe arriba:

  • [C-4-1] La aplicación DEBE estar preinstalada en el dispositivo.
  • [C-4-2] La aplicación DEBE implementar un filtro de intención que resuelva android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

Iniciar nuevos requisitos

3.9.5 Marco de resolución de políticas de dispositivos

Si las implementaciones de dispositivos informan android.software.device_admin o android.software.managed_users , entonces:

Terminar con nuevos requisitos

3.10. Accesibilidad

Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos más fácilmente. Además, Android proporciona API de plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamadas para eventos del usuario y del sistema y generen mecanismos de retroalimentación alternativos, como texto a voz, retroalimentación háptica y navegación con trackball/d-pad.

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, estos:

  • [C-1-1] DEBE proporcionar una implementación del marco de accesibilidad de Android como se describe en la documentación del SDK de las API de accesibilidad .
  • [C-1-2] DEBE generar eventos de accesibilidad y entregar el AccessibilityEvent apropiado a todas las implementaciones registradas AccessibilityService como se documenta en el SDK.
  • [C-1-4] DEBE proporcionar al usuario la posibilidad de controlar los servicios de accesibilidad que declaran AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Tenga en cuenta que para las implementaciones de dispositivos con una barra de navegación del sistema, DEBEN permitir al usuario tener la opción de un botón en la barra de navegación del sistema para controlar estos servicios.

Si las implementaciones de dispositivos incluyen servicios de accesibilidad preinstalados, estos:

  • [C-2-1] DEBE implementar estos servicios de accesibilidad preinstalados como aplicaciones Direct Boot Aware cuando el almacenamiento de datos está cifrado con cifrado basado en archivos (FBE).
  • DEBE proporcionar un mecanismo en el flujo de configuración listo para usar para que los usuarios habiliten servicios de accesibilidad relevantes, así como opciones para ajustar el tamaño de fuente, el tamaño de visualización y los gestos de ampliación.

3.11. Texto a voz

Android incluye API que permiten que las aplicaciones utilicen servicios de texto a voz (TTS) y permite a los proveedores de servicios proporcionar implementaciones de servicios TTS.

Si las implementaciones de dispositivos informan la función android.hardware.audio.output,:

Si las implementaciones de dispositivos admiten la instalación de motores TTS de terceros, estos:

  • [C-2-1] DEBE proporcionar al usuario posibilidades para permitirle seleccionar un motor TTS para su uso a nivel del sistema.

3.12. Marco de entrada de TV

Android Television Input Framework (TIF) simplifica la entrega de contenido en vivo a dispositivos Android Television. TIF proporciona una API estándar para crear módulos de entrada que controlan dispositivos Android Television.

Si las implementaciones de dispositivos admiten TIF, estas:

  • [C-1-1] DEBE declarar la característica de la plataforma android.software.live_tv .
  • [C-1-2] DEBE admitir todas las API TIF, de modo que se pueda instalar y utilizar en el dispositivo una aplicación que utilice estas API y el servicio de entradas de terceros basado en TIF .

3.13. Ajustes rápidos

Android proporciona un componente de interfaz de usuario de Configuración rápida que permite un acceso rápido a acciones utilizadas con frecuencia o que se necesitan con urgencia.

Si las implementaciones de dispositivos incluyen un componente de interfaz de usuario de Configuración rápida y admiten configuraciones rápidas de terceros, estas:

  • [C-1-1] DEBE permitir al usuario agregar o eliminar los mosaicos proporcionados a través de las API quicksettings desde una aplicación de terceros.
  • [C-1-2] NO DEBE agregar automáticamente un mosaico desde una aplicación de terceros directamente a la Configuración rápida.
  • [C-1-3] DEBE mostrar todos los mosaicos agregados por el usuario desde aplicaciones de terceros junto con los mosaicos de configuración rápida proporcionados por el sistema.

3.14. Interfaz de usuario multimedia

Si las implementaciones del dispositivo incluyen aplicaciones no activadas por voz (las Aplicaciones) que interactúan con aplicaciones de terceros a través de MediaBrowser o MediaSession , las Aplicaciones:

  • [C-1-2] DEBE mostrar claramente los iconos obtenidos mediante getIconBitmap() o getIconUri() y los títulos obtenidos mediante getTitle() como se describe en MediaDescription . Puede acortar los títulos para cumplir con las normas de seguridad (por ejemplo, distracción del conductor).

  • [C-1-3] DEBE mostrar el ícono de la aplicación de terceros siempre que muestre contenido proporcionado por esta aplicación de terceros.

  • [C-1-4] DEBE permitir al usuario interactuar con toda la jerarquía MediaBrowser . PUEDE restringir el acceso a parte de la jerarquía para cumplir con las normas de seguridad (por ejemplo, distracción del conductor), pero NO DEBE dar un trato preferencial basado en el contenido o el proveedor de contenido.

  • [C-1-5] DEBE considerar el doble toque de KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent .

3.15. Aplicaciones instantáneas

Si las implementaciones de dispositivos admiten aplicaciones instantáneas, DEBEN satisfacer los siguientes requisitos:

  • [C-1-1] Las aplicaciones instantáneas solo DEBEN recibir permisos que tengan android:protectionLevel configurado en "instant" .
  • [C-1-2] Las aplicaciones instantáneas NO DEBEN interactuar con las aplicaciones instaladas mediante intenciones implícitas a menos que se cumpla una de las siguientes condiciones:
    • El filtro de patrón de intención del componente está expuesto y tiene CATEGORY_BROWSABLE
    • La acción es una de ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • El objetivo está expuesto explícitamente con android:visibleToInstantApps
  • [C-1-3] Las aplicaciones instantáneas NO DEBEN interactuar explícitamente con las aplicaciones instaladas a menos que el componente esté expuesto a través de android:visibleToInstantApps.
  • [C-1-4] Las aplicaciones instaladas NO DEBEN ver detalles sobre las Instant Apps en el dispositivo a menos que la Instant App se conecte explícitamente a la aplicación instalada.
  • Las implementaciones de dispositivos DEBEN proporcionar las siguientes posibilidades de usuario para interactuar con Instant Apps. El AOSP cumple con los requisitos con la interfaz de usuario, la configuración y el iniciador del sistema predeterminados. Implementaciones de dispositivos:

    • [C-1-5] DEBE proporcionar al usuario la posibilidad de ver y eliminar aplicaciones instantáneas almacenadas en caché localmente para cada paquete de aplicaciones individual.
    • [C-1-6] DEBE proporcionar una notificación de usuario persistente que se pueda contraer mientras se ejecuta una aplicación instantánea en primer plano. Esta notificación al usuario DEBE incluir que las aplicaciones instantáneas no requieren instalación y brindan una opción para el usuario que lo dirige a la pantalla de información de la aplicación en Configuración. Para las aplicaciones instantáneas iniciadas a través de intenciones web, según se define mediante el uso de una intención con acción establecida en Intent.ACTION_VIEW y con un esquema de "http" o "https", una opción de usuario adicional DEBE permitir que el usuario no inicie la aplicación instantánea y ejecute el enlace asociado con el navegador web configurado, si hay un navegador disponible en el dispositivo.
    • [C-1-7] DEBE permitir el acceso a la ejecución de aplicaciones instantáneas desde la función Recientes si la función Recientes está disponible en el dispositivo.
  • [C-1-8] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones para las intenciones enumeradas en el SDK aquí y hacer que las intenciones sean visibles para las aplicaciones instantáneas.

3.16. Emparejamiento de dispositivos complementarios

Android incluye soporte para el emparejamiento de dispositivos complementarios para administrar de manera más efectiva la asociación con dispositivos complementarios y proporciona la API CompanionDeviceManager para que las aplicaciones accedan a esta función.

Si las implementaciones de dispositivos admiten la función de emparejamiento de dispositivos complementarios,:

  • [C-1-1] DEBE declarar el indicador de función FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEBE garantizar que las API del paquete android.companion estén completamente implementadas.
  • [C-1-3] DEBE proporcionar posibilidades al usuario para que seleccione/confirme que un dispositivo complementario está presente y operativo.

3.17. Aplicaciones pesadas

Si las implementaciones de dispositivos declaran la característica FEATURE_CANT_SAVE_STATE , entonces:

  • [C-1-1] DEBE tener solo una aplicación instalada que especifique cantSaveState ejecutándose en el sistema a la vez. Si el usuario abandona dicha aplicación sin salir explícitamente de ella (por ejemplo, presionando Inicio mientras abandona una actividad activa del sistema, en lugar de presionar Atrás sin que queden actividades activas en el sistema), entonces las implementaciones del dispositivo DEBEN priorizar esa aplicación en la RAM a medida que hacer para otras cosas que se espera que sigan ejecutándose, como los servicios en primer plano. Mientras una aplicación de este tipo esté en segundo plano, el sistema aún puede aplicarle funciones de administración de energía, como limitar el acceso a la CPU y a la red.
  • [C-1-2] DEBE proporcionar una interfaz de usuario para elegir la aplicación que no participará en el mecanismo de guardar/restaurar el estado normal una vez que el usuario inicie una segunda aplicación declarada con el atributo cantSaveState .
  • [C-1-3] NO DEBE aplicar otros cambios en la política a las aplicaciones que especifican cantSaveState , como cambiar el rendimiento de la CPU o cambiar la priorización de la programación.

Si las implementaciones de dispositivos no declaran la característica FEATURE_CANT_SAVE_STATE , entonces:

  • [C-1-1] DEBE ignorar el atributo cantSaveState establecido por las aplicaciones y NO DEBE cambiar el comportamiento de la aplicación en función de ese atributo.

3.18. Contactos

Android incluye API Contacts Provider para permitir que las aplicaciones administren la información de contacto almacenada en el dispositivo. Los datos de contacto que se ingresan directamente en el dispositivo generalmente se sincronizan con un servicio web, pero los datos PUEDEN residir solo localmente en el dispositivo. Los contactos que sólo se almacenan en el dispositivo se denominan contactos locales.

Los contactos sin procesar están "asociados con" o "almacenados en" una cuenta cuando las columnas ACCOUNT_NAME y ACCOUNT_TYPE de los contactos sin procesar coinciden con los campos Account.name y Account.type correspondientes de la cuenta.

Cuenta local predeterminada : una cuenta para contactos sin procesar que solo se almacenan en el dispositivo y no están asociados con una cuenta en AccountManager , que se crean con valores nulos para las columnas ACCOUNT_NAME y ACCOUNT_TYPE .

Cuenta local personalizada : una cuenta para contactos sin procesar que solo se almacenan en el dispositivo y no están asociados con una cuenta en AccountManager, que se crean con al menos un valor no nulo para las columnas ACCOUNT_NAME y ACCOUNT_TYPE .

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE no crear cuentas locales personalizadas .

Si las implementaciones de dispositivos utilizan una cuenta local personalizada :

  • [C-1-1] El ACCOUNT_NAME de la cuenta local personalizada DEBE ser devuelto por ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] El ACCOUNT_TYPE de la cuenta local personalizada DEBE ser devuelto por ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] Los contactos sin procesar que se insertan mediante aplicaciones de terceros con la cuenta local predeterminada (es decir, estableciendo valores nulos para ACCOUNT_NAME y ACCOUNT_TYPE ) DEBEN insertarse en la cuenta local personalizada .
  • [C-1-4] Los contactos sin procesar insertados en la cuenta local personalizada NO DEBEN eliminarse cuando se agregan o eliminan cuentas.
  • [C-1-5] Las operaciones de eliminación realizadas en la cuenta local personalizada DEBEN dar como resultado que los contactos sin procesar se purguen inmediatamente (como si el parámetro CALLER_IS_SYNCADAPTER estuviera configurado en verdadero), incluso si el parámetro CALLER\_IS\_SYNCADAPTER estuviera configurado en falso o no especificado.

4. Compatibilidad del embalaje de la aplicación

Implementaciones de dispositivos:

  • [C-0-1] DEBE ser capaz de instalar y ejecutar archivos “.apk” de Android generados por la herramienta “aapt” incluida en el SDK oficial de Android .

    • Como el requisito anterior puede ser un desafío, se RECOMIENDA que las implementaciones de dispositivos utilicen el sistema de administración de paquetes de la implementación de referencia de AOSP.
  • [C-0-2] DEBE admitir la verificación de archivos “.apk” utilizando el esquema de firma APK v3.1, el esquema de firma APK v3 , el esquema de firma APK v2 y la firma JAR .

  • [C-0-3] NO DEBE extender los formatos .apk , Android Manifest , Dalvik bytecode o RenderScript de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.

  • [C-0-4] NO DEBE permitir que aplicaciones que no sean el "instalador de registro" actual del paquete desinstalen silenciosamente la aplicación sin ninguna confirmación del usuario, como se documenta en el SDK para el permiso DELETE_PACKAGE . Las únicas excepciones son la aplicación de verificación de paquetes del sistema que maneja la intención PACKAGE_NEEDS_VERIFICATION y la aplicación de administrador de almacenamiento que maneja la intención ACTION_MANAGE_STORAGE .

  • [C-0-5] DEBE tener una actividad que maneje la intención android.settings.MANAGE_UNKNOWN_APP_SOURCES .

  • [C-0-6] NO DEBE instalar paquetes de aplicaciones de fuentes desconocidas, a menos que la aplicación que solicita la instalación cumpla con todos los siguientes requisitos:

    • DEBE declarar el permiso REQUEST_INSTALL_PACKAGES o tener android:targetSdkVersion configurado en 24 o menos.
    • El usuario DEBE haber recibido permiso para instalar aplicaciones de fuentes desconocidas.
  • DEBE proporcionar al usuario la posibilidad de otorgar/revocar el permiso para instalar aplicaciones de fuentes desconocidas por aplicación, pero PUEDE elegir implementar esto como una opción no operativa y devolver RESULT_CANCELED para startActivityForResult() , si la implementación del dispositivo no desea permitir a los usuarios tener esta opción. Sin embargo, incluso en tales casos, DEBEN indicar al usuario por qué no se presenta dicha opción.

  • [C-0-7] DEBE mostrar un cuadro de diálogo de advertencia con la cadena de advertencia que se proporciona a través de la API del sistema PackageManager.setHarmfulAppWarning al usuario antes de iniciar una actividad en una aplicación que ha sido marcada por la misma API del sistema PackageManager.setHarmfulAppWarning como potencialmente dañino.

  • DEBE proporcionar al usuario la posibilidad de elegir desinstalar o iniciar una aplicación en el cuadro de diálogo de advertencia.

  • [C-0-8] DEBE implementar soporte para el sistema de archivos incremental como se documenta aquí .

  • [C-0-9] DEBE admitir la verificación de archivos .apk utilizando el esquema de firma APK v4 y el esquema de firma APK v4.1.

5. Compatibilidad multimedia

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir los formatos de medios, codificadores, decodificadores, tipos de archivos y formatos de contenedor definidos en la sección 5.1 para todos y cada uno de los códecs declarados por MediaCodecList .
  • [C-0-2] DEBE declarar e informar el soporte de los codificadores y decodificadores disponibles para aplicaciones de terceros a través de MediaCodecList .
  • [C-0-3] DEBE poder decodificar correctamente y poner a disposición de aplicaciones de terceros todos los formatos que puede codificar. Esto incluye todos los flujos de bits que generan sus codificadores y los perfiles informados en su CamcorderProfile .

Implementaciones de dispositivos:

  • DEBEN aspirar a una latencia mínima del códec; en otras palabras,
    • NO DEBE consumir ni almacenar buffers de entrada y devolver buffers de entrada solo una vez procesados.
    • NO DEBE retener los buffers decodificados por más tiempo del especificado por el estándar (por ejemplo, SPS).
    • NO DEBE conservar los buffers codificados más tiempo del requerido por la estructura del Partido Republicano.

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

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

5.1. Códecs multimedia

5.1.1. Codificación de audio

Ver más detalles en 5.1.3. Detalles de códecs de audio .

Si las implementaciones de dispositivos declaran android.hardware.microphone , DEBEN admitir la codificación de los siguientes formatos de audio y ponerlos a disposición de aplicaciones de terceros:

  • [C-1-1] PCM/ONDA
  • [C-1-2] FLAC
  • [C-1-3] Obra

Todos los codificadores de audio DEBEN admitir:

5.1.2. Decodificación de audio

Ver más detalles en 5.1.3. Detalles de códecs de audio .

Si las implementaciones de dispositivos declaran admitir la función android.hardware.audio.output , deben admitir la decodificación de los siguientes formatos de audio:

  • [C-1-1] Perfil MPEG-4 AAC (AAC LC)
  • [C-1-2] Perfil MPEG-4 HE AAC (AAC+)
  • [C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ mejorado)
  • [C-1-4] AAC ELD (AAC de bajo retardo mejorado)
  • [C-1-11] xHE-AAC (perfil HE AAC extendido ISO/IEC 23003-3, que incluye el perfil base USAC y el perfil de control de rango dinámico ISO/IEC 23003-4)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7]MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE que incluye formatos de audio de alta resolución de hasta 24 bits, frecuencia de muestreo de 192 kHz y 8 canales. Tenga en cuenta que este requisito es solo para decodificación y que un dispositivo puede reducir la resolución y la mezcla durante la fase de reproducción.
  • [C-1-10] Obra

Si las implementaciones de dispositivos admiten la decodificación de buffers de entrada AAC de transmisiones multicanal (es decir, más de dos canales) a PCM a través del decodificador de audio AAC predeterminado en la API android.media.MediaCodec , DEBE admitirse lo siguiente:

  • [C-2-1] La decodificación DEBE realizarse sin mezcla (por ejemplo, un flujo 5.0 AAC debe decodificarse en cinco canales de PCM, un flujo 5.1 AAC debe decodificarse en seis canales de PCM).
  • [C-2-2] Los metadatos del rango dinámico DEBEN ser los definidos en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3, y las claves android.media.MediaFormat DRC para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves AAC DRC se introdujeron en 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 .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que todos los decodificadores de audio AAC cumplan los requisitos C-2-1 y C-2-2 anteriores.

Al decodificar audio USAC, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] Los metadatos de sonoridad y DRC DEBEN interpretarse y aplicarse de acuerdo con el perfil de control de rango dinámico MPEG-D DRC Nivel 1.
  • [C-3-2] El decodificador DEBE comportarse de acuerdo con la configuración establecida con las siguientes claves android.media.MediaFormat : KEY_AAC_DRC_TARGET_REFERENCE_LEVEL y KEY_AAC_DRC_EFFECT_TYPE .

Decodificadores de perfil MPEG-4 AAC, HE AAC y HE AACv2:

  • PUEDE admitir el control de volumen y rango dinámico utilizando el perfil de control de rango dinámico ISO/IEC 23003-4.

Si se admite ISO/IEC 23003-4 y si los metadatos de ISO/IEC 23003-4 e ISO/IEC 14496-3 están presentes en un flujo de bits decodificado, entonces:

  • Los metadatos ISO/IEC 23003-4 TIENEN prioridad.

Todos los decodificadores de audio DEBEN admitir la salida:

Si las implementaciones de dispositivos admiten la decodificación de buffers de entrada AAC de transmisiones multicanal (es decir, más de dos canales) a PCM a través del decodificador de audio AAC predeterminado en la API android.media.MediaCodec , entonces DEBE admitirse lo siguiente:

  • [C-7-1] DEBE poder ser configurado por la aplicación usando la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se mezcla a estéreo (cuando se usa un valor de 2) o se emite usando el número nativo de canales ( cuando se utiliza un valor igual o mayor a ese número). Por ejemplo, un valor de 6 o más configuraría un decodificador para generar 6 canales cuando se alimenta con contenido 5.1.
  • [C-7-2] Al decodificar, el decodificador DEBE anunciar la máscara de canal que se utiliza en el formato de salida con la clave KEY_CHANNEL_MASK , utilizando las constantes android.media.AudioFormat (ejemplo: CHANNEL_OUT_5POINT1 ).

Si las implementaciones de dispositivos admiten decodificadores de audio distintos del decodificador de audio AAC predeterminado y son capaces de emitir audio multicanal (es decir, más de 2 canales) cuando se alimentan con contenido multicanal comprimido, entonces:

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que la aplicación pueda configurar el decodificador usando la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se mezcla a estéreo (cuando se usa un valor de 2) o se emite usando el número nativo de canales (cuando se utiliza un valor igual o mayor a ese número). Por ejemplo, un valor de 6 o más configuraría un decodificador para generar 6 canales cuando se alimenta con contenido 5.1.
  • [C-SR-3] Al decodificar, se RECOMIENDA ENCARECIDAMENTE que el descodificador anuncie la máscara de canal que se utiliza en el formato de salida con la clave KEY_CHANNEL_MASK , utilizando las constantes android.media.AudioFormat (ejemplo: CHANNEL_OUT_5POINT1 ).

5.1.3. Detalles de códecs de audio

Formato/Códec Detalles Tipos de archivos/formatos de contenedor que se admitirán
Perfil MPEG-4 AAC
(AAC LC)
Compatibilidad con contenido mono/estéreo/5.0/5.1 con frecuencias de muestreo estándar de 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS AAC sin formato (.aac, ADIF no compatible)
  • MPEG-TS (.ts, no buscable, solo decodificación)
  • Matroska (.mkv, solo decodificar)
Perfil MPEG-4 HE AAC (AAC+) Compatibilidad con contenido mono/estéreo/5.0/5.1 con frecuencias de muestreo estándar de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2
Perfil (AAC+ mejorado)
Compatibilidad con contenido mono/estéreo/5.0/5.1 con frecuencias de muestreo estándar de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC de bajo retardo mejorado) Soporte para contenido mono/estéreo con frecuencias de muestreo estándar de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Soporte para contenido mono/estéreo con frecuencias de muestreo estándar de 7,35 a 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75 a 12,2 kbps muestreados a 8 kHz 3GPP (.3gp)
AMR-WB 9 velocidades de 6,60 kbit/s a 23,85 kbit/s muestreadas a 16 kHz, según se define en AMR-WB, multivelocidad adaptativa: códec de voz de banda ancha 3GPP (.3gp)
FLAC Tanto para el codificador como para el decodificador: DEBEN ser compatibles al menos los modos Mono y Estéreo. DEBEN admitirse frecuencias de muestreo de hasta 192 kHz; DEBE ser compatible con resoluciones de 16 y 24 bits. El manejo de datos de audio FLAC de 24 bits DEBE estar disponible con configuración de audio de punto flotante.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv, solo decodificar)
MP3 Mono/estéreo 8-320 Kbps constante (CBR) o tasa de bits variable (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv, solo decodificar)
midi MIDI Tipo 0 y 1. DLS Versión 1 y 2. XMF y XMF móvil. Compatibilidad con formatos de tonos de llamada RTTTL/RTX, OTA e iMelody
  • Tipo 0 y 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelodía (.imy)
Vorbis
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/ONDA El códec PCM DEBE admitir PCM lineal de 16 bits y flotante de 16 bits. El extractor WAVE debe admitir PCM lineal de 16 bits, 24 bits, 32 bits y flotante de 32 bits (velocidades hasta el límite del hardware). Las velocidades de muestreo DEBEN ser compatibles entre 8 kHz y 192 kHz. ONDA (.wav)
Opus Decodificación: Soporte para contenido mono, estéreo, 5.0 y 5.1 con frecuencias de muestreo de 8000, 12000, 16000, 24000 y 48000 Hz.
Codificación: Soporte para contenido mono y estéreo con frecuencias de muestreo de 8000, 12000, 16000, 24000 y 48000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv)
  • Webm (.webm)

5.1.4. Codificación de imágenes

Ver más detalles en 5.1.6. Detalles de códecs de imagen .

Las implementaciones de dispositivos DEBEN admitir la codificación de la siguiente imagen:

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

Iniciar nuevos requisitos

  • [C-0-4] AVIF
    • Los dispositivos deben admitir BITRATE_MODE_CQ y Baseline Profile.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos admiten la codificación HEIC a través de android.media.MediaCodec para el tipo de medio MIMETYPE_IMAGE_ANDROID_HEIC ,:

  • [C-1-1] DEBE proporcionar un códec codificador HEVC acelerado por hardware que admita el modo de control de velocidad de bits BITRATE_MODE_CQ , el perfil HEVCProfileMainStill y un tamaño de fotograma de 512 x 512 px.

5.1.5. Decodificación de imágenes

Ver más detalles en 5.1.6. Detalles de códecs de imagen .

Las implementaciones de dispositivos DEBEN admitir la decodificación de la siguiente codificación de imágenes:

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Sin procesar
  • [C-0-7] AVIF (Perfil de referencia)

Si las implementaciones de dispositivos admiten la decodificación de video HEVC, estas: * [C-1-1] DEBEN admitir la decodificación de imágenes HEIF (HEIC).

Decodificadores de imágenes que admiten un formato de alta profundidad de bits (más de 9 bits por canal):

  • [C-2-1] DEBE admitir la salida de un formato equivalente de 8 bits si lo solicita la aplicación, por ejemplo, a través de la configuración ARGB_8888 de android.graphics.Bitmap .

5.1.6. Detalles de códecs de imagen

Formato/Códec Detalles Tipos de archivos/formatos de contenedor admitidos
JPEG Base+progresiva JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Crudo ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 ( .rw2), SRW (.srw)
HEIF Imagen, Colección de imágenes, Secuencia de imágenes HEIF (.heif), HEIC (.heic)
AVIF (Perfil de referencia) Imagen, colección de imágenes, secuencia de imágenes Perfil de referencia Contenedor HEIF (.avif)

Codificador y decodificadores de imágenes expuestos a través de la API MediaCodec

  • [C-1-1] DEBE admitir el formato de color flexible YUV420 8:8:8 ( COLOR_FormatYUV420Flexible ) a través de CodecCapabilities .

  • [C-SR-1] SE RECOMIENDA ENCARECIDAMENTE admitir el formato de color RGB888 para el modo Superficie de entrada.

  • [C-1-3] DEBE admitir al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar ) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar ). Se RECOMIENDA ENCARECIDAMENTE que apoyen a ambos.

5.1.7. Códecs de vídeo

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

Si las implementaciones del dispositivo incluyen un decodificador o codificador de video:

  • [C-1-1] Los códecs de video DEBEN admitir tamaños de búfer de bytes de entrada y salida que se adapten al cuadro comprimido y sin comprimir más grande posible según lo dicta el estándar y la configuración, pero tampoco sobreasignar.

  • [C-1-2] Los codificadores y decodificadores de video DEBEN admitir formatos de color flexibles YUV420 8:8:8 ( COLOR_FormatYUV420Flexible ) a través de CodecCapabilities .

  • [C-1-3] Los codificadores y decodificadores de video DEBEN admitir al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar ) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar ). Se RECOMIENDA ENCARECIDAMENTE que apoyen a ambos.

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que los codificadores y decodificadores de video admitan al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar optimizado por hardware (YV12, NV12, NV21 o un formato optimizado por el proveedor equivalente).

  • [C-1-5] Los decodificadores de video que admiten un formato de alta profundidad de bits (más de 9 bits por canal) DEBEN admitir la salida de un formato equivalente de 8 bits si lo solicita la aplicación. Esto DEBE reflejarse al admitir un formato de color YUV420 8:8:8 a través de android.media.MediaCodecInfo .

Si las implementaciones de dispositivos anuncian compatibilidad con perfiles HDR a través de Display.HdrCapabilities ,:

  • [C-2-1] DEBE admitir el análisis y manejo de metadatos estáticos HDR.

Si las implementaciones de dispositivos anuncian compatibilidad con actualización interna a través de FEATURE_IntraRefresh en la clase MediaCodecInfo.CodecCapabilities ,:

  • [C-3-1] DEBE admitir períodos de actualización en el rango de 10 a 60 cuadros y operar con precisión dentro del 20 % del período de actualización configurado.

A menos que la aplicación especifique lo contrario utilizando la clave de formato KEY_COLOR_FORMAT , las implementaciones del decodificador de vídeo:

  • [C-4-1] DEBE tener el formato de color predeterminado optimizado para la visualización del hardware si se configura utilizando la salida de superficie.
  • [C-4-2] DEBE tener por defecto un formato de color YUV420 8:8:8 optimizado para lectura de CPU si está configurado para no usar salida Surface.

5.1.8. Lista de códecs de vídeo

Formato/Códec Detalles Tipos de archivos/formatos de contenedor que se admitirán
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, solo decodificar)
H.264 AVC Consulte las secciones 5.2 y 5.3 para obtener más detalles.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, no buscable)
  • Matroska (.mkv, solo decodificar)
H.265 HEVC Consulte la sección 5.3 para obtener más detalles.
  • MPEG-4 (.mp4)
  • Matroska (.mkv, solo decodificar)
MPEG-2 Perfil principal
  • MPEG2-TS (.ts, no buscable)
  • MPEG-4 (.mp4, solo decodificar)
  • Matroska (.mkv, solo decodificar)
MPEG-4SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, solo decodificar)
VP8 Consulte las secciones 5.2 y 5.3 para obtener más detalles.
VP9 Consulte la sección 5.3 para obtener más detalles.
AV1 Consulte la sección 5.2 y la sección 5.3 para obtener más detalles.
  • MPEG-4 (.mp4)
  • Matroska (.mkv, solo decodificar)

5.1.9. Seguridad del códec multimedia

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad del códec multimedia como se describe a continuación.

Android incluye soporte para OMX, una API de aceleración multimedia multiplataforma, así como Codec 2.0, una API de aceleración multimedia de bajo costo.

Si las implementaciones de dispositivos admiten multimedia,:

  • [C-1-1] DEBE brindar soporte para códecs multimedia a través de API OMX o Codec 2.0 (o ambos) como en el Proyecto de código abierto de Android y no deshabilitar ni eludir las protecciones de seguridad. Esto no significa específicamente que cada códec DEBE utilizar la API OMX o Codec 2.0, solo que el soporte para al menos una de estas API DEBE estar disponible, y el soporte para las API disponibles DEBE incluir las protecciones de seguridad presentes.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir soporte para la API Codec 2.0.

Si las implementaciones de dispositivos no son compatibles con la API Codec 2.0, estas:

  • [C-2-1] DEBE incluir el códec de software OMX correspondiente del Proyecto de código abierto de Android (si está disponible) para cada formato y tipo de medio (codificador o decodificador) admitido por el dispositivo.
  • [C-2-2] Códecs que tienen nombres que comienzan con "OMX.google". DEBE basarse en el código fuente del Proyecto de código abierto de Android.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que los códecs de software OMX se ejecuten en un proceso de códec que no tenga acceso a controladores de hardware que no sean asignadores de memoria.

Si las implementaciones de dispositivos admiten la API Codec 2.0, estas:

  • [C-3-1] DEBE incluir el códec de software Codec 2.0 correspondiente del Proyecto de código abierto de Android (si está disponible) para cada formato y tipo de medio (codificador o decodificador) admitido por el dispositivo.
  • [C-3-2] DEBE albergar los códecs de software Codec 2.0 en el proceso de códec de software según lo dispuesto en el Proyecto de código abierto de Android para permitir otorgar acceso más restringido a los códecs de software.
  • [C-3-3] Códecs que tienen nombres que comienzan con "c2.android". DEBE basarse en el código fuente del Proyecto de código abierto de Android.

5.1.10. Caracterización del códec multimedia

Si las implementaciones de dispositivos admiten códecs multimedia,:

  • [C-1-1] DEBE devolver valores correctos de caracterización de códec de medios a través de la API MediaCodecInfo .

En particular:

  • [C-1-2] Códecs con nombres que comienzan con "OMX". DEBE utilizar las API de OMX y tener nombres que cumplan con las pautas de nomenclatura de OMX IL.
  • [C-1-3] Códecs con nombres que comienzan con "c2". DEBE utilizar la API del Codec 2.0 y tener nombres que cumplan con las pautas de nomenclatura del Codec 2.0 para Android.
  • [C-1-4] Códecs con nombres que comienzan con "OMX.google". o "c2.android". NO DEBE caracterizarse como proveedor o acelerado por hardware.
  • [C-1-5] Los códecs que se ejecutan en un proceso de códec (proveedor o sistema) que tienen acceso a controladores de hardware distintos de asignadores y asignadores de memoria NO DEBEN caracterizarse como software únicamente.
  • [C-1-6] Los códecs que no están presentes en el proyecto de código abierto de Android o que no están basados ​​en el código fuente de ese proyecto DEBEN caracterizarse como proveedores.
  • [C-1-7] Los códecs que utilizan aceleración de hardware DEBEN caracterizarse como acelerados por hardware.
  • [C-1-8] Los nombres de los códecs NO DEBEN ser engañosos. Por ejemplo, los códecs denominados "decodificadores" DEBEN admitir la decodificación, y los denominados "codificadores" DEBEN admitir la codificación. Los códecs con nombres que contienen formatos multimedia DEBEN admitir esos formatos.

Si las implementaciones de dispositivos admiten códecs de vídeo:

  • [C-2-1] Todos los códecs de video DEBEN publicar datos de velocidad de fotogramas alcanzables para los siguientes tamaños si el códec lo admite:
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD
Resolución de video
  • 176 x 144 píxeles (H263, MPEG2, MPEG4)
  • 352 x 288 píxeles (codificador MPEG4, H263, MPEG2)
  • 320 x 180 píxeles (VP8, VP8)
  • 320 x 240 píxeles (otro)
  • 704 x 576 píxeles (H263)
  • 640 x 360 píxeles (VP8, VP9)
  • 640 x 480 píxeles (codificador MPEG4)
  • 720 x 480 px (otro, AV1 )
  • 1408 x 1152 píxeles (H263)
  • 1280 x 720 px (otro, AV1 )
1920 x 1080 px (distinto de MPEG4, AV1 ) 3840 x 2160 píxeles (HEVC, VP9, ​​AV1 )
  • [C-2-2] Los códecs de video que se caracterizan como acelerados por hardware DEBEN publicar información de puntos de rendimiento. Cada uno DEBE enumerar todos los puntos de rendimiento estándar admitidos (enumerados en la API PerformancePoint ), a menos que estén cubiertos por otro punto de rendimiento estándar admitido.
  • Además, DEBEN publicar puntos de rendimiento ampliados si admiten un rendimiento de vídeo sostenido distinto de uno de los estándar enumerados.

5.2. Codificación de vídeo

Si las implementaciones de dispositivos admiten cualquier codificador de vídeo y lo ponen a disposición de aplicaciones de terceros:

  • NO DEBE ser, en dos ventanas deslizantes, más del 15% sobre la tasa de bits entre intervalos intracuadro (I-frame).
  • NO DEBE superar el 100 % de la tasa de bits en una ventana deslizante de 1 segundo.

Iniciar nuevos requisitos

Si las implementaciones del dispositivo admiten cualquier codificador de video y lo ponen a disposición de aplicaciones de terceros, y configuran el
MediaFormat.KEY_BITRATE_MODE a BITRATE_MODE_VBR para que el codificador funcione en modo de tasa de bits variable, luego, siempre que no afecte el piso mínimo de calidad , la tasa de bits codificada:

  • [C-5-1] NO DEBE ser, en una ventana deslizante, más del 15% de la tasa de bits entre intervalos intracuadro (I-frame).
  • [C-5-2] NO DEBE superar el 100% de la tasa de bits en una ventana deslizante de 1 segundo.

Si las implementaciones del dispositivo admiten cualquier codificador de video y lo ponen a disposición de aplicaciones de terceros y configuran MediaFormat.KEY_BITRATE_MODE en BITRATE_MODE_CBR para que el codificador funcione en modo de tasa de bits constante, entonces la tasa de bits codificada:

  • [C-6-1] DEBE [C-SR-2] SE RECOMIENDA ENCARECIDAMENTE NO exceder más del 15% de la tasa de bits objetivo durante una ventana deslizante de 1 segundo.

Terminar con nuevos requisitos

Si las implementaciones del dispositivo incluyen una pantalla integrada con una longitud diagonal de al menos 2,5 pulgadas o incluyen un puerto de salida de video o declaran la compatibilidad con una cámara a través del indicador de función android.hardware.camera.any , ellos:

  • [C-1-1] DEBE incluir el soporte de al menos uno de los codificadores de video VP8 o H.264 y ponerlo a disposición de aplicaciones de terceros.
  • DEBE admitir codificadores de vídeo VP8 y H.264 y ponerlos a disposición de aplicaciones de terceros.

Si las implementaciones de dispositivos admiten cualquiera de los codificadores de video H.264, VP8, VP9 o HEVC y lo ponen a disposición de aplicaciones de terceros,:

  • [C-2-1] DEBE admitir velocidades de bits configurables dinámicamente.
  • DEBE admitir velocidades de cuadro variables, donde el codificador de video DEBE determinar la duración instantánea del cuadro en función de las marcas de tiempo de los buffers de entrada y asignar su depósito de bits en función de la duración de ese cuadro.

Si las implementaciones de dispositivos admiten el codificador de vídeo MPEG-4 SP y lo ponen a disposición de aplicaciones de terceros, estas:

  • DEBE admitir velocidades de bits configurables dinámicamente para el codificador admitido.

Si las implementaciones de dispositivos proporcionan codificadores de imágenes o videos acelerados por hardware y admiten una o más cámaras de hardware conectadas o conectables expuestas a través de las API android.camera :

  • [C-4-1] todos los codificadores de imágenes y video acelerados por hardware DEBEN admitir cuadros de codificación de las cámaras de hardware.
  • DEBE admitir la codificación de fotogramas desde las cámaras de hardware a través de todos los codificadores de vídeo o imágenes.

Si las implementaciones de dispositivos proporcionan codificación HDR, estas:

  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] proporcionar un complemento para la API de transcodificación perfecta para convertir del formato HDR al formato SDR.

5.2.1. H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y lo ponen a disposición de aplicaciones de terceros, estos:

  • [C-1-1] DEBE admitir la resolución QCIF (176 x 144) utilizando el nivel de perfil básico 45. La resolución SQCIF es opcional.
  • DEBE admitir velocidades de bits configurables dinámicamente para el codificador admitido.

5.2.2. H.264

Si las implementaciones de dispositivos admiten el códec H.264,:

  • [C-1-1] DEBE admitir el nivel 3 del perfil de referencia. Sin embargo, el soporte para ASO (ordenación de sectores arbitrarios), FMO (ordenamiento de macrobloques flexible) y RS (porciones redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no utilicen ASO, FMO y RS para Baseline Profile.
  • [C-1-2] DEBE admitir los perfiles de codificación de video SD (definición estándar) en la siguiente tabla.
  • DEBE admitir el nivel 4 del perfil principal.
  • DEBE admitir los perfiles de codificación de vídeo HD (alta definición) como se indica en la siguiente tabla.

Si las implementaciones de dispositivos informan que admiten la codificación H.264 para videos con resolución de 720p o 1080p a través de las API de medios,:

  • [C-2-1] DEBE admitir los perfiles de codificación en la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 240 píxeles 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 20 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 384 Kbps 2Mbps 4Mbps 10Mbps

5.2.3. VP8

Si las implementaciones de dispositivos admiten el códec VP8,:

  • [C-1-1] DEBE admitir los perfiles de codificación de video SD.
  • DEBE admitir los siguientes perfiles de codificación de video HD (alta definición).
  • [C-1-2] DEBE admitir la escritura de archivos Matroska WebM.
  • DEBE proporcionar un códec de hardware VP8 que cumpla con los requisitos de codificación de hardware RTC del proyecto WebM , para garantizar una calidad aceptable de transmisión de video web y servicios de videoconferencia.

Si las implementaciones de dispositivos informan que admiten la codificación VP8 para videos con resolución de 720p o 1080p a través de las API de medios,:

  • [C-2-1] DEBE admitir los perfiles de codificación en la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 180 píxeles 640 x 360 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 800 kbps 2Mbps 4Mbps 10Mbps

5.2.4. VP9

Si las implementaciones de dispositivos admiten el códec VP9,:

  • [C-1-2] DEBE admitir el Perfil 0 Nivel 3.
  • [C-1-1] DEBE admitir la escritura de archivos Matroska WebM.
  • [C-1-3] DEBE generar datos CodecPrivate .
  • DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] admitir los perfiles de decodificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
Dakota del Sur alta definición 720p alta definición 1080p HD
Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 1,6Mbps 4Mbps 5Mbps 20Mbps

Si las implementaciones de dispositivos afirman admitir el Perfil 2 o el Perfil 3 a través de las API de medios:

  • El soporte para formato de 12 bits es OPCIONAL.

5.2.5. H.265

Si las implementaciones de dispositivos admiten el códec H.265,:

  • [C-1-1] DEBE admitir perfil principal nivel 3 con una resolución de hasta 512 x 512 .
  • DEBE admitir los perfiles de codificación HD como se indica en la siguiente tabla.
  • Se RECOMIENDA ENCARECIDAMENTE que [C-SR-1] admita el perfil SD de 720 x 480 y los perfiles de codificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
Dakota del Sur alta definición 720p alta definición 1080p HD
Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 1,6Mbps 4Mbps 5Mbps 20Mbps

Iniciar nuevos requisitos

5.2.6. AV1

Si las implementaciones de dispositivos admiten el códec AV1, entonces:

  • [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.
  • [C-1-2] DEBE publicar datos de rendimiento, es decir, informar datos de rendimiento a través de las API getSupportedFrameRatesFor() o getSupportedPerformancePoints() para las resoluciones admitidas en la siguiente tabla.

  • [C-1-3] DEBE aceptar metadatos HDR y enviarlos al flujo de bits

Si el codificador AV1 está acelerado por hardware, entonces:

  • [C-2-1] DEBE admitir hasta el perfil de codificación HD1080p incluido de la siguiente tabla:
Dakota del Sur alta definición 720p alta definición 1080p HD
Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 5Mbps 8Mbps 16Mbps 50Mbps

Terminar con nuevos requisitos

5.3. Decodificación de vídeo

Si las implementaciones de dispositivos admiten los códecs VP8, VP9, ​​H.264 o H.265,:

  • [C-1-1] DEBE admitir resolución de video dinámica y 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 del dispositivo.

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2,:

  • [C-1-1] DEBE admitir el nivel alto del perfil principal.

5.3.2. H.263

Si las implementaciones de dispositivos admiten decodificadores H.263,:

  • [C-1-1] DEBE admitir el nivel de perfil de referencia 30 (resoluciones CIF, QCIF y SQCIF a 30 fps 384 kbps) y el nivel 45 (resoluciones QCIF y SQCIF a 30 fps 128 kbps) .

5.3.3. MPEG-4

Si se implementan dispositivos con decodificadores MPEG-4, estos:

  • [C-1-1] DEBE admitir perfil simple nivel 3.

5.3.4. H.264

Si las implementaciones de dispositivos admiten decodificadores H.264,:

  • [C-1-1] DEBE admitir el nivel de perfil principal 3.1 y el perfil de referencia. La compatibilidad con ASO (ordenación de cortes arbitrarios), FMO (ordenación de macrobloques flexibles) y RS (cortes redundantes) es OPCIONAL.
  • [C-1-2] DEBE ser capaz de decodificar videos con los perfiles SD (definición estándar) enumerados en la siguiente tabla y codificados con el perfil de referencia y el perfil principal nivel 3.1 (incluido 720p30).
  • DEBE ser capaz de decodificar vídeos con perfiles HD (alta definición) como se indica en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, las implementaciones del dispositivo:

  • [C-2-1] DEBE admitir los perfiles de decodificación de video HD 720p en la siguiente tabla.
  • [C-2-2] DEBE admitir los perfiles de decodificación de video HD 1080p en la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 240 píxeles 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 60 fps 30 fps ( Televisión de 60 fps)
Bitrate de vídeo 800 kbps 2Mbps 8Mbps 20Mbps

5.3.5. H.265 (HEVC)

Si las implementaciones de dispositivos admiten el códec H.265,:

  • [C-1-1] DEBE admitir el nivel principal de perfil principal nivel 3 y los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
  • [C-1-2] DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla si hay un decodificador de hardware.

Si la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, entonces:

  • [C-2-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones H.265 o VP9 de los perfiles 720, 1080 y UHD.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD
Resolución de video 352 x 288 píxeles 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30/60 fps ( Televisión de 60 fps con decodificación de hardware H.265 ) 60 fps
Bitrate de vídeo 600 kbps 1,6Mbps 4Mbps 5Mbps 20Mbps

Si las implementaciones de dispositivos afirman admitir un perfil HDR a través de las API de medios:

  • [C-3-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos HDR requeridos de la aplicación, así como también admitir la extracción y salida de los metadatos HDR requeridos desde el flujo de bits y/o el contenedor.
  • [C-3-2] Las implementaciones de dispositivos DEBEN mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).

5.3.6. VP8

Si las implementaciones de dispositivos admiten el códec VP8,:

  • [C-1-1] DEBE admitir los perfiles de decodificación SD en la siguiente tabla.
  • DEBE utilizar un códec de hardware VP8 que cumpla con los requisitos .
  • DEBE admitir los perfiles de decodificación HD en la siguiente tabla.

Si la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, entonces:

  • [C-2-1] Las implementaciones de dispositivos DEBEN admitir perfiles de 720p en la siguiente tabla.
  • [C-2-2] Las implementaciones de dispositivos DEBEN admitir perfiles de 1080p en la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 180 píxeles 640 x 360 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps ( Televisión de 60 fps) 30 ( Televisión de 60 fps)
Bitrate de vídeo 800 kbps 2Mbps 8Mbps 20Mbps

5.3.7. VP9

Si las implementaciones de dispositivos admiten el códec VP9,:

  • [C-1-1] DEBE admitir los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.

Si las implementaciones de dispositivos admiten el códec VP9 y un decodificador de hardware:

  • [C-2-1] DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.

Si la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, entonces:

  • [C-3-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones VP9 o H.265 de los perfiles 720, 1080 y UHD.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD
Resolución de video 320 x 180 píxeles 640 x 360 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps ( Televisión de 60 fps con decodificación de hardware VP9 ) 60 fps
Bitrate de vídeo 600 kbps 1,6Mbps 4Mbps 5Mbps 20Mbps

Si las implementaciones de dispositivos afirman admitir VP9Profile2 o VP9Profile3 a través de las API de medios 'CodecProfileLevel' :

  • El soporte para formato de 12 bits es OPCIONAL.

Si las implementaciones de dispositivos afirman admitir un perfil HDR ( VP9Profile2HDR , VP9Profile2HDR10Plus , VP9Profile3HDR , VP9Profile3HDR10Plus ) a través de las API de medios:

  • [C-4-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos HDR requeridos ( KEY_HDR_STATIC_INFO para todos los perfiles HDR, así como 'KEY_HDR10_PLUS_INFO' para los perfiles HDR10Plus) de la aplicación. También DEBEN admitir la extracción y salida de los metadatos HDR requeridos desde el flujo de bits y/o el contenedor.
  • [C-4-2] Las implementaciones de dispositivos DEBEN mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).

5.3.8. Visión Dolby

Si las implementaciones de dispositivos declaran compatibilidad con el decodificador Dolby Vision a través de HDR_TYPE_DOLBY_VISION ,:

  • [C-1-1] DEBE proporcionar un extractor compatible con Dolby Vision.
  • [C-1-2] DEBE mostrar correctamente el contenido Dolby Vision en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).
  • [C-1-3] DEBE establecer el índice de pista de las capas base compatibles con versiones anteriores (si están presentes) para que sea el mismo que el índice de pista de la capa Dolby Vision combinada.

5.3.9. AV1

Si las implementaciones de dispositivos admiten el códec AV1,:

  • [C-1-1] DEBE admitir el perfil 0, incluido el contenido de 10 bits.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos admiten el códec AV1 y lo ponen a disposición de aplicaciones de terceros:

  • [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.

Si las implementaciones de dispositivos brindan soporte para el códec AV1 con un decodificador acelerado por hardware, entonces:

  • [C-2-1] DEBE poder decodificar al menos los perfiles de decodificación de video HD 720p de la siguiente tabla cuando la altura informada por el método Display.getSupportedModes() es igual o mayor que 720p.
  • [C-2-2] DEBE poder decodificar al menos los perfiles de decodificación de video HD 1080p de la siguiente tabla cuando la altura informada por el método Display.getSupportedModes() es igual o mayor que 1080p.
Dakota del Sur alta definición 720p alta definición 1080p HD
Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 5Mbps 8Mbps 16Mbps 50Mbps

Si las implementaciones de dispositivos admiten el perfil HDR a través de las API de medios, entonces:

  • [C-3-1] DEBE admitir la extracción y salida de metadatos HDR desde el flujo de bits y/o el contenedor.
  • [C-3-2] DEBE mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).

Terminar con nuevos requisitos

5.4. Grabación de audio

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

5.4.1. Información de micrófono y captura de audio sin procesar

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • [C-1-1] DEBE permitir la captura de contenido de audio sin procesar para cualquier flujo AudioRecord o AAudio INPUT que se abra correctamente. Como mínimo, DEBEN admitirse las siguientes características:

  • DEBE permitir la captura de contenido de audio sin procesar con las siguientes características:

    • Formato : PCM lineal, 16 bits y 24 bits
    • Frecuencias de muestreo : 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • Canales : Tantos canales como micrófonos tenga el dispositivo
  • [C-1-2] DEBE capturar a las frecuencias de muestreo anteriores sin muestreo ascendente.

  • [C-1-3] DEBE incluir un filtro antialiasing apropiado cuando las frecuencias de muestreo indicadas anteriormente se capturan con muestreo descendente.

  • DEBE permitir la captura de contenido de audio sin procesar con calidad de radio AM y DVD, lo que significa las siguientes características:

    • Formato : PCM lineal, 16 bits
    • Frecuencias de muestreo : 22050, 48000 Hz
    • Canales : Estéreo
  • [C-1-4] DEBE respetar la API MicrophoneInfo y completar correctamente la información de los micrófonos disponibles en el dispositivo accesible para aplicaciones de terceros a través de la API AudioManager.getMicrophones() , para AudioRecord activo usando MediaRecorder.AudioSources DEFAULT , MIC , CAMCORDER , VOICE_RECOGNITION , VOICE_COMMUNICATION , UNPROCESSED o VOICE_PERFORMANCE . Si las implementaciones de dispositivos permiten la captura con calidad de radio AM y DVD de contenido de audio sin procesar, estos:

  • [C-2-1] DEBE capturar sin muestreo ascendente en cualquier proporción superior a 16000:22050 o 44100:48000.

  • [C-2-2] DEBE incluir un filtro anti-aliasing apropiado para cualquier muestreo ascendente o descendente.

5.4.2. Captura para reconocimiento de voz

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • [C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION en una de las frecuencias de muestreo, 44100 y 48000.
  • [C-1-2] DEBE, de forma predeterminada, desactivar cualquier procesamiento de audio de reducción de ruido al grabar una secuencia de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION .
  • [C-1-3] DEBE, de forma predeterminada, desactivar cualquier control automático de ganancia al grabar una secuencia de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION .

  • DEBE exhibir características de amplitud versus frecuencia aproximadamente planas en el rango de frecuencia media: específicamente ±3 dB de 100 Hz a 4000 Hz para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio de reconocimiento de voz.

  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] exhibir niveles de amplitud en el rango de baja frecuencia: específicamente de ±20 dB de 30 Hz a 100 Hz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos utilizados para grabar el audio de reconocimiento de voz. fuente.

  • [C-SR-2] se RECOMIENDA ENCARECIDAMENTE exhibir niveles de amplitud en el rango de frecuencia alta: específicamente desde ±30 dB de 4000 Hz a 22 KHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos utilizados para grabar el audio de reconocimiento de voz. fuente.

  • DEBE configurar la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz reproducida a un nivel de presión sonora (SPL) de 90 dB (medido a una distancia de 30 cm al lado del micrófono) produzca una respuesta ideal de 2500 RMS dentro de un rango de 1770 y 3530 para muestras de 16 bits (o -22,35 db ±3dB de escala completa para muestras de punto flotante/doble precisión) para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio de reconocimiento de voz.

  • DEBE grabar el flujo de audio del reconocimiento de voz de modo que los niveles de amplitud PCM sigan linealmente los cambios de SPL de entrada en al menos un rango de 30 dB de -18 dB a +12 dB re 90 dB SPL en el micrófono.

  • DEBE grabar el flujo de audio de reconocimiento de voz con una distorsión armónica total (THD) inferior al 1% durante 1 kHz a un nivel de entrada SPL de 90 dB en el micrófono.

Si las implementaciones de dispositivos declaran tecnologías android.hardware.microphone y de supresión (reducción) de ruido optimizadas para el reconocimiento de voz, estas:

  • [C-2-1] DEBE permitir que este efecto de audio sea controlable con la API android.media.audiofx.NoiseSuppressor .
  • [C-2-2] DEBE identificar de forma única cada implementación de tecnología de supresión de ruido a través del campo AudioEffect.Descriptor.uuid .

5.4.3. Captura para redirigir la reproducción

La clase android.media.MediaRecorder.AudioSource incluye la fuente de audio REMOTE_SUBMIX .

Si las implementaciones de dispositivos declaran tanto android.hardware.audio.output como android.hardware.microphone ,:

  • [C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX para que cuando una aplicación use la API android.media.AudioRecord para grabar desde esta fuente de audio, capture una mezcla de todas las transmisiones de audio excepto las siguientes:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelador de eco acústico

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • DEBE implementar una tecnología de cancelación de eco acústico (AEC) sintonizada para la comunicación de voz y aplicada a la ruta de captura al capturar utilizando AudioSource.VOICE_COMMUNICATION .

Si las implementaciones del dispositivo proporcionan un cancelador de eco acústico que se inserta en la ruta de captura de audio cuando se selecciona AudioSource.VOICE_COMMUNICATION ,:

5.4.5. Captura simultánea

Si las implementaciones de dispositivos declaran android.hardware.microphone , DEBEN implementar la captura simultánea como se describe en este documento . Específicamente:

  • [C-1-1] DEBE permitir el acceso simultáneo al micrófono mediante un servicio de accesibilidad que capture con AudioSource.VOICE_RECOGNITION y al menos una aplicación que capture con cualquier AudioSource .
  • [C-1-2] DEBE permitir el acceso simultáneo al micrófono mediante una aplicación preinstalada que tenga una función de Asistente y al menos una aplicación que capture con cualquier AudioSource , excepto AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER .
  • [C-1-3] DEBE silenciar la captura de audio para cualquier otra aplicación, excepto para un servicio de accesibilidad, mientras una aplicación captura con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER . Sin embargo, cuando una aplicación captura a través de AudioSource.VOICE_COMMUNICATION , otra aplicación puede capturar la llamada de voz si es una aplicación privilegiada (preinstalada) con permiso CAPTURE_AUDIO_OUTPUT .
  • [C-1-4] Si dos o más aplicaciones están capturando simultáneamente y ninguna de las aplicaciones tiene una interfaz de usuario en la parte superior, la que comenzó a capturar más recientemente recibe el audio.

5.5. Reproducción de audio

Android incluye soporte para permitir que las aplicaciones reproduzcan audio a través del periférico de salida de audio como se define en la sección 7.8.2.

5.5.1. Reproducción de audio sin procesar

Si las implementaciones de dispositivos declaran android.hardware.audio.output ,:

  • [C-1-1] DEBE permitir la reproducción de contenido de audio sin formato con las siguientes características:

    • Formatos de origen : PCM lineal, 16 bits, 8 bits, flotante
    • Canales : Mono, Estéreo, configuraciones multicanal válidas con hasta 8 canales
    • Frecuencias de muestreo (en Hz) :
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 en las configuraciones de canales enumeradas anteriormente
      • 96000 en mono y estéreo

5.5.2. Efectos de audio

Android proporciona una API para efectos de audio para implementaciones de dispositivos.

Si las implementaciones de dispositivos declaran la función android.hardware.audio.output ,:

  • [C-1-1] DEBE admitir las implementaciones EFFECT_TYPE_EQUALIZER y EFFECT_TYPE_LOUDNESS_ENHANCER controlables a través de las subclases AudioEffect Equalizer y LoudnessEnhancer .
  • [C-1-2] DEBE admitir la implementación de la API del visualizador, controlable a través de la clase Visualizer .
  • [C-1-3] DEBE admitir la implementación EFFECT_TYPE_DYNAMICS_PROCESSING controlable a través de la subclase AudioEffect DynamicsProcessing .

Iniciar nuevos requisitos

  • [C-1-4] DEBE admitir efectos de audio con entrada y salida de punto flotante.
  • [C-1-5] DEBE asegurarse de que los efectos de audio admitan múltiples canales hasta el recuento de canales del mezclador, también conocido como FCC_LIMIT.

Terminar con nuevos requisitos

  • DEBE admitir las implementaciones EFFECT_TYPE_BASS_BOOST , EFFECT_TYPE_ENV_REVERB , EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER controlables a través de las subclases AudioEffect BassBoost , EnvironmentalReverb , PresetReverb y Virtualizer .
  • [C-SR-1] Se RECOMIENDAN ENCARECIDAMENTE para admitir efectos en punto flotante y multicanal.

5.5.3. Volumen de salida de audio

Implementaciones de dispositivos automotrices:

  • DEBE permitir ajustar el volumen de audio por separado para cada transmisión de audio utilizando el tipo de contenido o uso definido por AudioAttributes y el uso de audio del automóvil definido públicamente en android.car.CarAudioManager .

5.5.4. Descarga de audio

Si las implementaciones de dispositivos admiten la reproducción de descarga de audio , estas:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE recortar el contenido de audio reproducido sin espacios entre dos clips con el mismo formato cuando lo especifica la API AudioTrack sin espacios y el contenedor multimedia para MediaPlayer.

5.6. Latencia de audio

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

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

  • latencia de salida . El intervalo entre el momento en que una aplicación escribe un cuadro de datos codificados en PCM y el momento en que el sonido correspondiente se presenta al entorno en un transductor del dispositivo o la señal sale del dispositivo a través de un puerto y se puede observar externamente.
  • Latencia de salida en frío . El tiempo entre el inicio de un flujo de salida y el tiempo de presentación del primer fotograma según las marcas de tiempo, cuando el sistema de salida de audio estuvo inactivo y apagado antes de la solicitud.
  • Latencia de salida continua . La latencia de salida para fotogramas posteriores, después de que el dispositivo esté reproduciendo audio.
  • latencia de entrada . El intervalo entre el momento en que el entorno presenta un sonido al dispositivo en un transductor del dispositivo o la señal ingresa al dispositivo a través de un puerto y el momento en que una aplicación lee el cuadro correspondiente de datos codificados en PCM.
  • entrada perdida . La porción inicial de una señal de entrada que no se puede utilizar o no está disponible.
  • Latencia de entrada en frío . El tiempo entre el inicio de la transmisión y el momento en que se recibe la primera trama válida, cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
  • Latencia de entrada continua . La latencia de entrada para fotogramas posteriores, mientras el dispositivo captura audio.

  • Latencia continua de ida y vuelta . 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 le da tiempo a la aplicación para procesar la señal y tiempo para que la aplicación mitigue la diferencia de fase entre los flujos de entrada y salida.

  • API de cola de búfer OpenSL ES PCM . El conjunto de API de OpenSL ES relacionadas con PCM dentro del NDK de Android .

  • API de audio nativo de AAudio . El conjunto de API de AAudio dentro del NDK de Android .

  • Marca de tiempo . Un par que consta de una posición relativa del fotograma dentro de una secuencia y el tiempo estimado en que ese fotograma entra o sale del canal de procesamiento de audio en el punto final asociado. Véase también AudioTimestamp .

  • falla . Una interrupción temporal o un valor de muestra incorrecto en la señal de audio, generalmente causado por una insuficiencia de datos del búfer de salida, un desbordamiento del búfer de entrada o cualquier otra fuente de ruido digital o analógico.

  • desviación media absoluta . El promedio del valor absoluto de las desviaciones de la media para un conjunto de valores.

  • latencia de toque para tono . El tiempo entre el momento en que se toca la pantalla y el momento en que se escucha en el altavoz un tono generado como resultado de ese toque.

Si las implementaciones de dispositivos declaran android.hardware.audio.output , DEBEN cumplir o superar los siguientes requisitos:

  • [C-1-1] La marca de tiempo de salida devuelta por AudioTrack.getTimestamp y AAudioStream_getTimestamp tiene una precisión de +/- 2 ms.
  • [C-1-2] Latencia de salida en frío de 500 milisegundos o menos.

  • [C-1-3] Abrir un flujo de salida usando AAudioStreamBuilder_openStream() DEBE tomar menos de 1000 milisegundos.

Si las implementaciones de dispositivos declaran android.hardware.audio.output , se RECOMIENDA ENCARECIDAMENTE que cumplan o superen los siguientes requisitos:

  • [C-SR-1] Latencia de salida en frío de 100 milisegundos o menos en la ruta de datos del altavoz.
  • [C-SR-2] Latencia de pulsación para tono de 80 milisegundos o menos.

  • [C-SR-4] La marca de tiempo de salida devuelta por AudioTrack.getTimestamp y AAudioStream_getTimestamp tiene una precisión de +/- 1 ms.

Iniciar nuevos requisitos

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE que las latencias de ida y vuelta calculadas basadas en las marcas de tiempo de entrada y salida devueltas por AAudioStream_getTimestamp estén dentro de los 30 ms de la latencia de ida y vuelta medida para AAUDIO_PERFORMANCE_MODE_NONE y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para parlantes y auriculares con cable e inalámbricos.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos cumplen con los requisitos anteriores, después de cualquier calibración inicial, cuando se utiliza la API de audio nativa AAudio, para latencia de salida continua y latencia de salida en frío en al menos un dispositivo de salida de audio compatible, son:

Si las implementaciones de dispositivos no cumplen con los requisitos de audio de baja latencia a través de la API de audio nativa AAudio,:

  • [C-2-1] NO DEBE informar soporte para audio de baja latencia.

Si las implementaciones del dispositivo incluyen android.hardware.microphone , DEBEN cumplir con estos requisitos de audio de entrada:

  • [C-3-1] Limite el error en las marcas de tiempo de entrada, según lo devuelto por AudioRecord.getTimestamp o AAudioStream_getTimestamp , a +/- 2 ms. "Error" aquí significa la desviación del valor correcto.
  • [C-3-2] Latencia de entrada en frío de 500 milisegundos o menos.
  • [C-3-3] Abrir un flujo de entrada usando AAudioStreamBuilder_openStream() DEBE tomar menos de 1000 milisegundos.

Si las implementaciones del dispositivo incluyen android.hardware.microphone , se RECOMIENDA ENCARECIDAMENTE que cumplan con estos requisitos de audio de entrada:

  • [C-SR-8] Latencia de entrada fría de 100 milisegundos o menos en la ruta de datos del micrófono.

  • [C-SR-11] Limite el error en las marcas de tiempo de entrada, según lo devuelto por AudioRecord.getTimestamp o AAudioStream_getTimestamp , a +/- 1 ms.

Si las implementaciones de dispositivos declaran android.hardware.audio.output y android.hardware.microphone ,:

  • [C-SR-12] Se RECOMIENDA ENCARECIDAMENTE tener una latencia media continua de ida y vuelta de 50 milisegundos o menos en 5 mediciones, con una desviación media absoluta inferior a 10 ms, en al menos una ruta admitida.

5.7. Protocolos de red

Las implementaciones de dispositivos DEBEN admitir los protocolos de red de medios para la reproducción de audio y video como se especifica en la documentación del SDK de Android.

Para cada códec y formato de contenedor que se requiere que admita una implementación de dispositivo, la implementación del dispositivo:

  • [C-1-1] DEBE admitir ese códec o contenedor a través de HTTP y HTTPS.

  • [C-1-2] DEBE admitir los formatos de segmentos de medios correspondientes como se muestra en la tabla de formatos de segmentos de medios a continuación sobre el borrador del protocolo HTTP Live Streaming, Versión 7 .

  • [C-1-3] DEBE admitir los formatos de carga útil RTSP correspondientes como se muestra en la tabla RTSP a continuación. Para conocer las excepciones, consulte las notas a pie de página de la tabla en la sección 5.1 .

Formatos de segmentos de medios

Formatos de segmento Referencia(s) Soporte de códec requerido
Flujo de transporte MPEG-2 ISO 13818 Códecs de vídeo:
  • H264 AVC
  • MPEG-4SP
  • MPEG-2
Consulte la sección 5.1.8 para obtener detalles sobre H264 AVC, MPEG2-4 SP,
y MPEG-2.

Códecs de audio:

  • CAA
Consulte la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
AAC con marco ADTS y etiquetas ID3 ISO 13818-7 Consulte la sección 5.1.1 para obtener detalles sobre AAC y sus variantes.
WebVTT WebVTT

RTSP (RTP, SDP)

Nombre de perfil Referencia(s) Soporte de códec requerido
H264 AVC RFC 6184 Consulte la sección 5.1.8 para obtener detalles sobre H264 AVC.
MP4A-LATM RFC 6416 Consulte la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
H263-1998 RFC 3551
RFC 4629
RFC 2190
Consulte la sección 5.1.8 para obtener detalles sobre H263.
H263-2000 RFC 4629 Consulte la sección 5.1.8 para obtener detalles sobre H263.
RAM RFC 4867 Consulte la sección 5.1.3 para obtener detalles sobre AMR-NB.
AMR-WB RFC 4867 Consulte la sección 5.1.3 para obtener detalles sobre AMR-WB.
MP4V-ES RFC 6416 Consulte la sección 5.1.8 para obtener detalles sobre MPEG-4 SP.
mpeg4-genérico RFC 3640 Consulte la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
MP2T RFC 2250 Consulte MPEG-2 Transport Stream debajo de HTTP Live Streaming para obtener más detalles.

5.8. Medios seguros

Si las implementaciones de dispositivos admiten salida de video segura y son capaces de admitir superficies seguras,:

  • [C-1-1] DEBE declarar soporte para Display.FLAG_SECURE .

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y admiten el protocolo de visualización inalámbrica,:

  • [C-2-1] DEBE asegurar el enlace con un mecanismo criptográficamente fuerte como HDCP 2.x o superior para las pantallas conectadas a través de protocolos inalámbricos como Miracast.

Si las implementaciones de dispositivos declaran soporte para Display.FLAG_SECURE y admiten pantalla externa cableada, ellos:

  • [C-3-1] DEBE admitir HDCP 1.2 o superior para todas las pantallas externas conectadas a través de un puerto cableado accesible para el usuario.

5.9. Interfaz digital para instrumentos musicales (MIDI)

Si las implementaciones de dispositivos informan que admiten la función android.software.midi a través de la clase android.content.pm.PackageManager ,:

  • [C-1-1] DEBE admitir MIDI en todos los transportes de hardware con capacidad MIDI para los cuales proporcionen conectividad genérica no MIDI, donde dichos transportes sean:

  • [C-1-2] DEBE admitir el transporte de software MIDI entre aplicaciones (dispositivos MIDI virtuales)

  • [C-1-3] DEBE incluir libamidi.so (soporte MIDI nativo)

  • DEBE admitir el modo periférico MIDI a través de USB, sección 7.7

5.10. Audio profesional

Si las implementaciones de dispositivos informan que son compatibles con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager ,:

  • [C-1-1] DEBE informar la compatibilidad con la función android.hardware.audio.low_latency .
  • [C-1-2] DEBE tener una latencia de audio continua de ida y vuelta, como se define en la sección 5.6 Latencia de audio, de 25 milisegundos o menos en al menos una ruta admitida.
  • [C-1-3] DEBE incluir un puerto USB que admita el modo host USB y el modo periférico USB.
  • [C-1-4] DEBE informar la compatibilidad con la función android.software.midi .
  • [C-1-5] DEBE cumplir con las latencias y los requisitos de audio USB utilizando la API de audio nativa AAudio y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
  • [C-1-6] DEBE tener una latencia de salida en frío de 200 milisegundos o menos.
  • [C-1-7] DEBE tener una latencia de entrada en frío de 200 milisegundos o menos.
  • [C-1-8] DEBE tener una latencia promedio de toque a tono de 80 milisegundos o menos en al menos 5 mediciones a través de la ruta de datos del altavoz al micrófono.

  • [C-SR-1] Se RECOMIENDAN ENCARECIDAMENTE cumplir con las latencias definidas en la sección 5.6 Latencia de audio , de 20 milisegundos o menos, en 5 mediciones con una desviación absoluta media inferior a 5 milisegundos en la ruta del altavoz al micrófono.

  • [C-SR-2] Se RECOMIENDAN ENCARECIDAMENTE para cumplir con los requisitos de Pro Audio para latencia de audio de ida y vuelta continua, latencia de entrada fría y latencia de salida fría y requisitos de audio USB utilizando la API de audio nativa AAudio a través de la ruta MMAP.

  • [C-SR-3] Se RECOMIENDAN ENCARECIDAMENTE para proporcionar un nivel constante de rendimiento de la CPU mientras el audio está activo y la carga de la CPU varía. Esto debe probarse utilizando la aplicación de Android SynthMark . SynthMark utiliza un sintetizador de software que se ejecuta en un marco de audio simulado que mide el rendimiento del sistema. Consulte la documentación de SynthMark para obtener una explicación de los puntos de referencia. La aplicación SynthMark debe ejecutarse utilizando la opción "Prueba automatizada" y lograr los siguientes resultados:

    • marca de voz.90 >= 32 voces
    • latencymark.fixed.little <= 15 ms
    • latencymark.dynamic.little <= 50 ms
  • DEBE minimizar la inexactitud del reloj de audio y la desviación en relación con la hora estándar.

  • DEBE minimizar la deriva del reloj de audio en relación con la CPU CLOCK_MONOTONIC cuando ambos están activos.

  • DEBE minimizar la latencia de audio sobre los transductores del dispositivo.

  • DEBE minimizar la latencia de audio a través del audio digital USB.

  • DEBE documentar las mediciones de latencia de audio en todas las rutas.

  • DEBE minimizar la fluctuación 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.

  • DEBE proporcionar cero fallos de audio en condiciones de uso normal y con la latencia informada.

  • DEBE proporcionar cero diferencia de latencia entre canales.

  • DEBE minimizar la latencia media MIDI en todos los transportes.

  • DEBE minimizar la variabilidad de la latencia MIDI bajo carga (jitter) en todos los transportes.

  • DEBE proporcionar marcas de tiempo MIDI precisas en todos los transportes.

  • DEBE minimizar el ruido de la señal de audio en los transductores del dispositivo, incluido el período inmediatamente posterior al arranque en frío.

  • DEBE proporcionar una diferencia de reloj de audio cero entre los lados de entrada y salida de los puntos finales correspondientes, cuando ambos están activos. Ejemplos de puntos finales correspondientes incluyen el micrófono y el altavoz del dispositivo, o la entrada y salida del conector de audio.

  • DEBE manejar devoluciones de llamada de finalización del búfer de audio para los lados de entrada y salida de los puntos finales correspondientes en el mismo hilo cuando ambos están activos, e ingresar la devolución de llamada de salida inmediatamente después del retorno de la devolución de llamada de entrada. O si no es factible manejar las devoluciones de llamada en el mismo subproceso, ingrese 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 consistente de los lados de entrada y salida.

  • DEBE minimizar la diferencia de fase entre el almacenamiento en búfer de audio HAL para los lados de entrada y salida de los puntos finales correspondientes.

  • DEBE minimizar la latencia táctil.

  • DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).

Si las implementaciones de dispositivos cumplen con todos los requisitos anteriores,:

  • [C-SR-4] RECOMENDAMOS ENCARECIDAMENTE informar la compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager .

Si las implementaciones del dispositivo incluyen un conector de audio de 3,5 mm de 4 conductores,:

Si las implementaciones del dispositivo omiten un conector de audio de 3,5 mm de 4 conductores e incluyen un puerto USB que admite el modo de host USB,:

  • [C-3-1] DEBE implementar la clase de audio USB.
  • [C-3-2] DEBE tener una latencia de audio de ida y vuelta continua media de 25 milisegundos o menos, en 5 mediciones con una desviación absoluta media inferior a 5 milisegundos a través del puerto en modo host USB utilizando la clase de audio USB. (Esto se puede medir utilizando un adaptador USB de 3,5 mm y un dongle de bucle invertido de audio, o utilizando una interfaz de audio USB con cables de conexión que conectan las entradas a las salidas).
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE admitir E/S simultáneas de hasta 8 canales en cada dirección, frecuencia de muestreo de 96 kHz y profundidad de 24 o 32 bits, cuando se utilizan con periféricos de audio USB que también admiten estos requisitos.
  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE cumplir con este grupo de requisitos utilizando la API de audio nativa AAudio a través de la ruta MMAP.

Si las implementaciones de dispositivos incluyen un puerto HDMI,:

  • DEBE admitir salida en estéreo y ocho canales a una profundidad de 20 o 24 bits y 192 kHz sin pérdida de profundidad de bits ni remuestreo, en al menos una configuración.

5.11. Captura para sin procesar

Android incluye soporte para la grabación de audio sin procesar a través de la fuente de audio android.media.MediaRecorder.AudioSource.UNPROCESSED . En OpenSL ES, se puede acceder a él con el registro preestablecido SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Si las implementaciones de dispositivos pretenden admitir fuentes de audio no procesadas y ponerlas a disposición de aplicaciones de terceros, deben:

  • [C-1-1] DEBE informar el soporte a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED .

  • [C-1-2] DEBE exhibir características de amplitud versus frecuencia aproximadamente planas en el rango de frecuencia media: específicamente ±10 dB de 100 Hz a 7000 Hz para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-3] 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 para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-4] DEBE exhibir niveles de amplitud en el rango de frecuencia alta: específicamente desde ±30 dB de 7000 Hz a 22 KHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-5] DEBE configurar la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz reproducida a un nivel de presión sonora (SPL) de 94 dB produzca una respuesta con RMS de 520 para muestras de 16 bits (o -36 dB de escala completa para muestras de punto flotante/doble precisión) para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-6] DEBE tener una relación señal-ruido (SNR) de 60 dB o superior para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar. (mientras que la SNR se mide como la diferencia entre 94 dB SPL y el SPL equivalente de ruido propio, ponderado A).

  • [C-1-7] DEBE tener una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de 90 dB SPL en todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-8] No DEBE tener ningún otro procesamiento de señal (por ejemplo, control automático de ganancia, filtro de paso alto o cancelación de eco) en la ruta que no sea un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:

    • [C-1-9] Si algún procesamiento de señal está presente en la arquitectura por algún motivo, DEBE desactivarse e introducir efectivamente un retraso cero o latencia adicional en la ruta de la señal.
    • [C-1-10] El multiplicador de nivel, aunque se le permite estar en la ruta, NO DEBE introducir retraso o latencia en la ruta de la señal.

Todas las mediciones de SPL se realizan directamente al lado del micrófono bajo prueba. Para configuraciones de múltiples micrófonos, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone pero no admiten fuentes de audio sin procesar, estas:

  • [C-2-1] DEBE devolver null para el método API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) , para indicar correctamente la falta de soporte.
  • [C-SR-1] siguen siendo ENCARECIDAMENTE RECOMENDADOS para satisfacer la mayor cantidad posible de requisitos de ruta de señal para la fuente de grabación sin procesar.

5.12. Vídeo HDR

Android 13 es compatible con las tecnologías HDR como se describe en un próximo documento.

Formato de píxeles

Si un descodificador de vídeo anuncia compatibilidad con COLOR_FormatYUVP010, entonces:

  • [C-1-1] DEBE admitir el formato P010 para lectura de CPU (ImageReader, MediaImage, ByteBuffer). En Android 13, P010 está relajado para permitir un paso arbitrario para los planos Y y UV.

  • [C-1-2] La GPU DEBE poder muestrear el búfer de salida P010 (cuando se asigna con el uso de GPU_SAMPLING). Esto permite la composición de GPU y el mapeo de tonos personalizado por aplicaciones.

Si un descodificador de vídeo anuncia compatibilidad con COLOR_Format32bitABGR2101010,:

  • [C-2-1] DEBE admitir el formato RGBA_1010102 para la superficie de salida y legible por la CPU (salida ByteBuffer).

Si un codificador de vídeo anuncia compatibilidad con COLOR_FormatYUVP010,:

  • [C-3-1] DEBE admitir el formato P010 para la superficie de entrada y la entrada grabable por CPU (ImageWriter, MediaImage, ByteBuffer).

Si un codificador de vídeo anuncia compatibilidad con COLOR_Format32bitABGR2101010,:

  • [C-4-1] DEBE admitir el formato RGBA_1010102 para la superficie de entrada y la entrada grabable por CPU (ImageWriter, ByteBuffer). Nota: NO se requiere la conversión entre varias curvas de transferencia para los codificadores.

Requisitos de captura HDR

Para todos los codificadores de video que admiten perfiles HDR, implementaciones de dispositivos:

  • [C-5-1] NO DEBE asumir que los metadatos HDR son precisos. Por ejemplo, el cuadro codificado podría tener píxeles más allá del nivel máximo de luminancia o el histograma podría no ser representativo del cuadro.

  • DEBEN agregar metadatos dinámicos HDR para generar metadatos estáticos HDR apropiados para transmisiones codificadas, y deben generarlos al final de cada sesión de codificación.

Si las implementaciones de dispositivos admiten la captura HDR mediante las API CamcorderProfile, entonces:

  • [C-6-1] También DEBE admitir la captura HDR a través de las API de Camera2.

  • [C-6-2] DEBE admitir al menos un codificador de video acelerado por hardware para cada tecnología HDR admitida.

  • [C-6-3] DEBE admitir (como mínimo) la captura de HLG.

  • [C-6-4] DEBE admitir la escritura de metadatos HDR (si corresponde a la tecnología HDR) en el archivo de video capturado. Para AV1, HEVC y DolbyVision, esto significa incluir los metadatos en el flujo de bits codificado.

  • [C-6-5] DEBE admitir P010 y COLOR_FormatYUVP010.

  • [C-6-6] DEBE admitir la asignación de tonos HDR a SDR en el decodificador acelerado por hardware predeterminado para el perfil capturado. En otras palabras, si un dispositivo puede capturar HDR10+ HEVC, el decodificador HEVC predeterminado DEBE poder decodificar la transmisión capturada en SDR.

Requisitos de edición HDR

Si las implementaciones de dispositivos incluyen codificadores de video que admiten la edición HDR, entonces:

  • DEBE utilizar una latencia mínima para generar los metadatos HDR cuando no están presentes, y DEBE manejar con elegancia situaciones en las que los metadatos están presentes para algunos fotogramas y no para otros. Estos metadatos DEBEN ser precisos (por ejemplo, representar la luminancia máxima real y el histograma del cuadro).

Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, entonces esos códecs:

  • [C-7-1] DEBE admitir al menos un perfil HDR.

  • [C-7-2] DEBE admitir FEATURE_HdrEditing para todos los perfiles HDR anunciados por ese códec. En otras palabras, DEBEN admitir la generación de metadatos HDR cuando no están presentes para todos los perfiles HDR admitidos que utilizan metadatos HDR.

  • [C-7-3] DEBE admitir los siguientes formatos de entrada del codificador de video que preservan completamente la señal decodificada HDR:

    • RGBA_1010102 (ya en la curva de transferencia de destino) tanto para la superficie de entrada como para ByteBuffer y DEBE anunciar soporte para COLOR_Format32bitABGR2101010.

Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, entonces el dispositivo:

  • [C-7-4] DEBE anunciar soporte para la extensión EXT_YUV_target OpenGL.

6. Compatibilidad de opciones y herramientas de desarrollador

6.1. Herramientas de desarrollo

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir las herramientas de desarrollo de Android proporcionadas en el SDK de Android.
  • Puente de depuración de Android (adb)

    • [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y los comandos de shell proporcionados en AOSP, que pueden ser utilizados por los desarrolladores de aplicaciones, incluidas cmd stats dumpsys .
    • [C-0-11] DEBE admitir el comando de shell cmd testharness . La actualización de implementaciones de dispositivos desde una versión anterior de Android sin un bloque de datos persistente PUEDE estar exenta de C-0-11.
    • [C-0-3] NO DEBE alterar el formato o el contenido de los eventos del sistema del dispositivo (batterystats, diskstats, huella digital, gráficosstats, netstats, notificación, procstats) registrados mediante el comando dumpsys.
    • [C-0-10] DEBE registrar, sin omisión, y hacer que los siguientes eventos sean accesibles y estén disponibles para el comando cmd stats shell y la clase API del sistema StatsManager .
      • ActividadForegroundStateCambiado
      • Anomalía detectada
      • AppBreadcrumbReportado
      • Se produjo un bloqueo de la aplicación
      • Inicio de aplicación ocurrido
      • Nivel de batería cambiado
      • Estado del modo de ahorro de batería cambiado
      • BleScanResultReceived
      • BleScanStateCambiado
      • Estado de carga cambiado
      • DispositivoIdleModeStateCambiado
      • Estado de servicio en primer plano cambiado
      • GpsScanStateCambiado
      • Estado del trabajo cambiado
      • EstadoEnchufadoCambiado
      • Estado del trabajo programado cambiado
      • Estado de pantalla cambiado
      • Estado de sincronización cambiado
      • Sistema transcurrido en tiempo real
      • UidProcessStateCambiado
      • WakelockStateCambió
      • DespertarAlarmaOcurrida
      • WifiLockStateCambiado
      • WifiMulticastLockStateCambiado
      • WifiScanStateCambiado
    • [C-0-4] DEBE tener el demonio adb del lado del dispositivo inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar el Puente de depuración de Android.
    • [C-0-5] DEBE admitir adb seguro. Android incluye soporte para adb seguro. Secure adb habilita adb en hosts autenticados conocidos.
    • [C-0-6] DEBE proporcionar un mecanismo que permita conectar adb desde una máquina host. Específicamente:

    Si las implementaciones de dispositivos sin puerto USB admiten el modo periférico,:

    • [C-3-1] DEBE implementar adb a través de una red de área local (como Ethernet o Wi-Fi).
    • [C-3-2] DEBE proporcionar controladores para Windows 7, 8 y 10, lo que permite a los desarrolladores conectarse al dispositivo mediante el protocolo adb.

    Si las implementaciones de dispositivos admiten conexiones adb a una máquina host a través de Wi-Fi o Ethernet, estas:

    • [C-4-1] DEBE que el método AdbManager#isAdbWifiSupported() devuelva true .

    Si las implementaciones de dispositivos admiten conexiones adb a una máquina host a través de Wi-Fi o Ethernet e incluyen al menos una cámara, estas:

    • [C-5-1] DEBE que el método AdbManager#isAdbWifiQrSupported() devuelva true .
  • Servicio de monitorización de depuración de Dalvik (ddms)

    • [C-0-7] DEBE admitir todas las funciones de ddms según lo documentado en el SDK de Android. Como ddms usa adb, la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.
  • SysTrace

    • [C-0-9] DEBE admitir la herramienta systrace como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar Systrace.
  • perfecto

    • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE exponer un binario /system/bin/perfetto al usuario del shell cuyo cmdline cumpla con la documentación de perfetto .
    • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que el binario perfetto acepte como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE que el binario perfetto escriba como salida un seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE proporcionar, a través del binario perfetto, al menos las fuentes de datos descritas en la documentación de perfetto .
  • Asesino de poca memoria

    • [C-0-12] DEBE escribir un átomo LMK_KILL_OCCURRED_FIELD_NUMBER en el registro de estadísticas cuando Low Memory Killer finaliza una aplicación.
  • Modo de prueba de arnés Si las implementaciones de dispositivos admiten el comando de shell cmd testharness y ejecutan cmd testharness enable ,:

  • Información de trabajo de la GPU

    Implementaciones de dispositivos:

    • [C-0-13] DEBE implementar el comando de shell dumpsys gpu --gpuwork para mostrar los datos de trabajo de GPU agregados devueltos por el punto de seguimiento del kernel power/gpu_work_period , o no mostrar datos si el punto de seguimiento no es compatible. La implementación de AOSP es frameworks/native/services/gpuservice/gpuwork/ .

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o superior a través de los indicadores de función android.hardware.vulkan.version , ellos:

  • [C-1-1] DEBE proporcionar una posibilidad para que el desarrollador de la aplicación habilite/deshabilite las capas de depuración de GPU.
  • [C-1-2] DEBE, cuando las capas de depuración de GPU están habilitadas, enumerar las capas en bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte de la plataforma o paquete de aplicación) que se encuentran en el directorio base de las aplicaciones depurables para admitir vkEnumerateInstanceLayerProperties() y vkCreateInstance () Métodos API.

6.2. Opciones de desarrollador

Android incluye soporte para que los desarrolladores configuren ajustes relacionados con el desarrollo de aplicaciones.

Las implementaciones de dispositivos DEBEN proporcionar una experiencia consistente para las Opciones de Desarrollador, ellas:

  • [C-0-1] DEBE respetar la intención de android.settings.APPLICATION_DEVELOPMENT_SETTINGS de mostrar la configuración relacionada con el desarrollo de aplicaciones. La implementación ascendente de Android oculta el menú Opciones de desarrollador de forma predeterminada y permite a los usuarios iniciar Opciones de desarrollador después de presionar siete (7) veces en el elemento de menú Configuración > Acerca del dispositivo > Número de compilación .
  • [C-0-2] DEBE ocultar las Opciones de desarrollador de forma predeterminada.
  • [C-0-3] DEBE proporcionar un mecanismo claro que no dé trato preferencial a una aplicación de terceros frente a otra para habilitar las Opciones de desarrollador. DEBE proporcionar un documento o sitio web visible públicamente que describa cómo habilitar las Opciones de desarrollador. Este documento o sitio web DEBE poder vincularse desde los documentos del SDK de Android.
  • DEBE tener una notificación visual continua para el usuario cuando las Opciones de desarrollador estén habilitadas y la seguridad del usuario sea motivo de preocupación.
  • PUEDE limitar temporalmente el acceso al menú Opciones de desarrollador, ocultando o deshabilitando visualmente el menú, para evitar distracciones en escenarios en los que la seguridad del usuario es preocupante.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware particular que tiene una API correspondiente para desarrolladores externos:

  • [C-0-1] La implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android.

Si una API en el SDK interactúa con un componente de hardware que se declara opcional y la implementación del dispositivo no posee ese componente:

  • [C-0-2] Aún DEBEN presentarse definiciones de clases completas (según lo documentado por el SDK) para las API de los componentes.
  • [C-0-3] Los comportamientos de la API DEBEN implementarse como no operativos de alguna manera razonable.
  • [C-0-4] Los métodos API DEBEN devolver valores nulos cuando lo permita la documentación del SDK.
  • [C-0-5] Los métodos API DEBEN devolver implementaciones no operativas de clases donde la documentación del SDK no permite valores nulos.
  • [C-0-6] Los métodos API NO DEBEN generar excepciones no documentadas en la documentación del SDK.
  • [C-0-7] Las implementaciones de dispositivos DEBEN informar constantemente información precisa de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella digital de compilación.

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

7.1. Pantalla y gráficos

Android incluye funciones que ajustan automáticamente los activos de las aplicaciones y los diseños de la interfaz de usuario de manera apropiada para el dispositivo para garantizar que las aplicaciones de terceros se ejecuten bien en una variedad de configuraciones de hardware . variedad de pantallas y configuraciones de hardware. Una pantalla compatible con Android es una pantalla que implementa todos los comportamientos y API descritos en Desarrolladores de Android: descripción general de compatibilidad de pantalla , esta sección (7.1) y sus subsecciones, así como cualquier comportamiento adicional específico del tipo de dispositivo documentado en la sección 2 de este CDD. En las pantallas compatibles con Android donde se pueden ejecutar todas las aplicaciones de terceros compatibles con Android, las implementaciones de dispositivos DEBEN implementar correctamente estas API y comportamientos, como se detalla en esta sección.

Iniciar nuevos requisitos

Implementaciones de dispositivos:

  • [C-0-1] DEBE, de forma predeterminada, representar aplicaciones de terceros solo en pantallas compatibles con Android.

Terminar con nuevos requisitos

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

  • Tamaño diagonal físico . La distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
  • Densidad de puntos por pulgada (ppp) . El número de píxeles abarcados por un intervalo lineal horizontal o vertical de 1” , expresado como píxeles por pulgada (ppi o ppp) . Cuando se enumeran valores de ppp , ppp y ppp , tanto los ppp horizontales como los verticales deben estar dentro del rango indicado .
  • relación de aspecto . La relación entre los píxeles de la dimensión más larga y la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480x854 píxeles sería 854/480 = 1,779, o aproximadamente “16:9”.
  • Píxel independiente de la densidad (dp) . La unidad de píxeles virtuales normalizada a una pantalla de 160 ppp tiene una densidad de pantalla de 160. Para una densidad d y un número de píxeles p, el número de píxeles independientes de la densidad dp se calcula como: píxeles = dps * (densidad/160) dp = (160/d) * p .

7.1.1. Configuración de pantalla

7.1.1.1. Tamaño y forma de la pantalla

El marco de la interfaz de usuario de Android admite una variedad de tamaños de diseño de pantalla lógicos diferentes y permite que las aplicaciones consulten el tamaño del diseño de pantalla de la configuración actual a través de Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK y Configuration.smallestScreenWidthDp .

Implementaciones de dispositivos:

  • [C-0-1] DEBE informar el tamaño de diseño correcto para Configuration.screenLayout como se define en la documentación del SDK de Android. Específicamente, las implementaciones de dispositivos DEBEN informar las dimensiones correctas de la pantalla de píxeles (dp) independientes de la densidad lógica como se muestra a continuación:

    • Los dispositivos con Configuration.uiMode configurado con cualquier valor distinto de UI_MODE_TYPE_WATCH y que informan un tamaño small para Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
    • Los dispositivos que informan un tamaño normal para Configuration.screenLayout DEBEN tener al menos 480 dp x 320 dp.
    • Los dispositivos que informan un tamaño large para Configuration.screenLayout DEBEN tener al menos 640 dp x 480 dp.
    • Los dispositivos que informan un tamaño xlarge para Configuration.screenLayout DEBEN tener al menos 960 dp x 720 dp.
  • [C-0-2] DEBE respetar correctamente la compatibilidad indicada de las aplicaciones para tamaños de pantalla a través del atributo supports-screens en AndroidManifest.xml, como se describe en la documentación del SDK de Android.

  • PUEDE tener pantallas compatibles con Android con esquinas redondeadas.

Si las implementaciones de dispositivos admiten pantallas con capacidad de configuración de tamaño UI_MODE_TYPE_NORMAL e incluyen pantallas físicas compatibles con Android con esquinas redondeadas para representar estas pantallas , estas:

  • [C-1-1] DEBE garantizar que se cumpla al menos uno de los siguientes requisitos para cada una de estas pantallas :

    • El radio de las esquinas redondeadas es menor o igual a 38 dp.
    • Cuando un cuadro de 15 dp por 15 dp está anclado en cada esquina de la pantalla lógica, al menos un píxel de cada cuadro es visible en la pantalla.
  • DEBE incluir la posibilidad de que el usuario cambie al modo de visualización con las esquinas rectangulares.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos solo son capaces de configurar el teclado NO_KEYS y tienen la intención de informar soporte para la configuración del modo UI_MODE_TYPE_NORMAL ,:

  • [C-4-1] DEBE tener un tamaño de diseño, excluyendo cualquier recorte de pantalla, de al menos 596 dp x 384 dp o más.

Terminar con nuevos requisitos

Si las implementaciones de dispositivos incluyen una pantalla compatible con Android que es plegable o incluye una bisagra plegable entre varios paneles de pantalla y hace que dichas pantallas estén disponibles para representar aplicaciones de terceros, estas:

Si las implementaciones de dispositivos incluyen una pantalla compatible con Android que es plegable o incluye una bisagra plegable entre varios paneles de pantalla y si la bisagra o el pliegue cruza una ventana de aplicación de pantalla completa,:

  • [C-3-1] DEBE informar a la aplicación la posición, los límites y el estado de la bisagra o plegado a través de extensiones o API de sidecar.

Para obtener detalles sobre la implementación correcta de las API de extensión o sidecar, consulte la documentación pública de Window Manager Jetpack .

Iniciar nuevos requisitos

Si las implementaciones de dispositivos incluyen una o más áreas de visualización compatibles con Android que son plegables, o incluyen una bisagra plegable entre múltiples áreas de paneles de visualización compatibles con Android y ponen dichas áreas de visualización a disposición de las aplicaciones, estas:

  • [C-4-1] DEBE implementar la versión correcta del nivel API de Extensiones de Window Manager como se describe en Extensiones de WindowManager .

Terminar con nuevos requisitos

7.1.1.2. Relación de aspecto de pantalla

Si bien no existe ninguna restricción en cuanto a la relación de aspecto de la pantalla física para las pantallas compatibles con Android, la relación de aspecto de la pantalla lógica donde se representan aplicaciones de terceros, que se puede derivar de los valores de alto y ancho informados a través de Las API view.Display y las API de configuración DEBEN cumplir con los siguientes requisitos:

  • [C-0-1] Las implementaciones de dispositivos con Configuration.uiMode configurado en UI_MODE_TYPE_NORMAL DEBEN tener un valor de relación de aspecto menor o igual a 1,86 (aproximadamente 16:9), a menos que la aplicación cumpla una de las siguientes condiciones:

    • La aplicación ha declarado que admite una relación de aspecto de pantalla más grande a través del valor de metadatos android.max_aspect .
    • La aplicación declara que se puede cambiar de tamaño mediante el atributo android:resizeableActivity .
    • La aplicación tiene como objetivo el nivel API 24 o superior y no declara un android:maxAspectRatio que restringiría la relación de aspecto permitida.
  • [C-0-3] Las implementaciones de dispositivos con Configuration.uiMode configurado como UI_MODE_TYPE_WATCH DEBEN tener un valor de relación de aspecto establecido como 1,0 (1:1).

7.1.1.3. Densidad de la pantalla

El marco de la interfaz de usuario de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientar los recursos de la aplicación.

Implementaciones de dispositivos:

  • [C-0-1] De forma predeterminada, las implementaciones de dispositivos DEBEN informar solo una de las densidades del marco de trabajo de Android que se enumeran en DisplayMetrics a través de la API DENSITY_DEVICE_STABLE y este valor debe ser un valor estático para cada pantalla física. NO DEBE cambiar en ningún momento; sin embargo , el dispositivo PUEDE informar una densidad arbitraria diferente DisplayMetrics.density según los cambios de configuración de pantalla realizados por el usuario (por ejemplo, tamaño de pantalla) establecidos después del arranque inicial.

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

Iniciar nuevos requisitos

  • Debería definir la densidad de marco de Android estándar que está numéricamente más cercana a la densidad física de la pantalla, o un valor que se asignaría a las mismas mediciones equivalentes del campo de visión angular equivalente de un dispositivo portátil.

Finalizar los nuevos requisitos

Si las implementaciones de dispositivos proporcionan, hay la posibilidad de cambiar el tamaño de visualización del dispositivo , ellos :

  • [C-1-1] El tamaño de la pantalla no debe escalar, no debe escalar la pantalla mayor de 1.5 veces DENSITY_DEVICE_STABLE densidad nativa o producir una dimensión de pantalla mínima efectiva menor que 320dp (equivalente al calificador de recursos SW320DP), lo cual es lo primero.
  • [C-1-2] El tamaño de la pantalla no debe escalarse, no debe escalar la pantalla menor de 0.85 veces la densidad nativa DENSITY_DEVICE_STABLE .
  • Para garantizar una buena usabilidad y tamaños de fuente consistentes, se RECOMIENDA que se proporcione la siguiente escala de opciones de visualización nativa (cumpliendo con los límites especificados anteriormente)
    • Pequeño: 0,85x
    • Valor predeterminado: 1x (escala de visualización nativa)
    • Grande: 1,15x
    • Más grande: 1,3x
    • Mayor 1,45x

7.1.2. Mostrar métricas

Si las implementaciones de dispositivos incluyen pantallas compatibles con Android o salida de video a pantallas compatibles con Android, estas:

  • [C-1-1] DEBE informar los valores correctos para todas las métricas de visualización compatibles con Android definidas en la API android.util.DisplayMetrics .

Si las implementaciones del dispositivo no incluyen una pantalla integrada o una salida de video, ellos:

  • [C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android tal como se define en la API android.util.DisplayMetrics para la view.Display predeterminada emulada.Display .

7.1.3. Orientación de la pantalla

Implementaciones de dispositivos:

  • [C-0-1] DEBE informar qué orientaciones de pantalla admiten ( android.hardware.screen.portrait y/o android.hardware.screen.landscape ) y DEBE informar al menos una orientación admitida. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como un televisor o una computadora portátil, DEBE informar solo android.hardware.screen.landscape .
  • [C-0-2] DEBE informar el valor correcto para la orientación actual del dispositivo, siempre que se realice una consulta a través de android.content.res.Configuration.orientation , android.view.Display.getOrientation() u otras API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla,:

  • [C-1-1] DEBE admitir la orientación dinámica mediante aplicaciones en orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una orientación de pantalla específica.
  • [C-1-2] NO DEBE cambiar el tamaño o la densidad de la pantalla informados al cambiar la orientación.
  • PUEDE seleccionar la orientación vertical u horizontal como opción predeterminada.

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

7.1.4.1 OpenGL ES

Implementaciones de dispositivos:

  • [C-0-1] DEBE identificar correctamente las versiones de OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) a través de las API administradas (como a través del método GLES10.getString() ) y las API nativas.
  • [C-0-2] DEBE incluir el soporte para todas las API administradas y API nativas correspondientes para cada versión de OpenGL ES que identificaron para admitir.

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, como se incluye y detalla en la documentación del SDK de Android .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que sean compatibles con OpenGL ES 3.1.
  • DEBE admitir OpenGL ES 3.2.

Las pruebas OpenGL ES dEQP se dividen en varias listas de pruebas, cada una con un número de fecha/versión asociado. Estos se encuentran en el árbol de fuentes de Android en external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt . Un dispositivo que admite OpenGL ES en un nivel autoinformado indica que puede pasar las pruebas dEQP en todas las listas de pruebas de este nivel y anteriores.

Si las implementaciones de dispositivos admiten cualquiera de las versiones de OpenGL ES, estas:

  • [C-2-1] DEBEN informar a través de las API administradas de OpenGL ES y las API nativas sobre cualquier otra extensión de OpenGL ES que hayan implementado y, a la inversa, NO DEBEN informar cadenas de extensión que no admiten.
  • [C-2-2] DEBE admitir EGL_KHR_image , EGL_KHR_image_base , EGL_ANDROID_image_native_buffer , EGL_ANDROID_get_native_client_buffer , EGL_KHR_wait_sync , EGL_KHR_get_all_proc_addresses , EGL_ANDROID_presentation_time , EGL_KHR_swap_buffers_with_damage Extensiones , EGL_ANDROID_recordable y EGL_ANDROID_GLES_layers .
  • [C-2-3] DEBE informar la versión máxima de las pruebas OpenGL ES dEQP admitidas a través del indicador de función android.software.opengles.deqp.level .
  • [C-2-4] DEBE ser al menos compatible con la versión 132383489 (desde el 1 de marzo de 2020) como se informa en el indicador de función android.software.opengles.deqp.level .
  • [C-2-5] DEBE pasar todas las pruebas dEQP de OpenGL ES en las listas de pruebas entre la versión 132383489 y la versión especificada en el indicador de función android.software.opengles.deqp.level , para cada versión de OpenGL ES compatible.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE admitir las extensiones EGL_KHR_partial_update y OES_EGL_image_external .
  • DEBE informar con precisión a través del método getString() , cualquier formato de compresión de texturas que admitan, que normalmente es específico del proveedor.

  • DEBE admitir las extensiones EGL_IMG_context_priority y EGL_EXT_protected_content .

Si las implementaciones de dispositivos declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2,:

  • [C-3-1] DEBE exportar los símbolos de función correspondientes para esta versión además de los símbolos de función de OpenGL ES 2.0 en la biblioteca libGLESv2.so.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE admitir la extensión OES_EGL_image_external_essl3 .

Si las implementaciones de dispositivos son compatibles con OpenGL ES 3.2,:

  • [C-4-1] DEBE admitir el paquete de extensión de Android OpenGL ES en su totalidad.

Si las implementaciones de dispositivos son compatibles con OpenGL ES Android Extension Pack en su totalidad,:

  • [C-5-1] DEBE identificar el soporte a través del indicador de función android.hardware.opengles.aep .

Si las implementaciones de dispositivos exponen la compatibilidad con la extensión EGL_KHR_mutable_render_buffer ,:

  • [C-6-1] También DEBE admitir la extensión EGL_ANDROID_front_buffer_auto_refresh .
7.1.4.2 Vulcano

Android incluye soporte para Vulkan , una API multiplataforma de bajo costo para gráficos 3D de alto rendimiento.

Si las implementaciones de dispositivos son compatibles con OpenGL ES 3.1,:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir soporte para Vulkan 1.3.
  • [C-4-1] NO DEBE admitir una versión variante de Vulkan (es decir, la parte variante de la versión principal de Vulkan DEBE ser cero).

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE incluir soporte para Vulkan 1.3.

Las pruebas de Vulkan dEQP se dividen en varias listas de pruebas, cada una con una fecha/versión asociada. Estos se encuentran en el árbol de fuentes external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt . Un dispositivo que admite Vulkan en un nivel autoinformado indica que puede pasar las pruebas dEQP en todas las listas de pruebas de este nivel y anteriores.

Si las implementaciones de dispositivos incluyen soporte para Vulkan 1.0 o superior , ellos:

  • [C-1-1] DEBE informar el valor entero correcto con los indicadores de función android.hardware.vulkan.level y android.hardware.vulkan.version .
  • [C-1-2] DEBE enumerar al menos un VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] debe implementar completamente las API Vulkan 1.0 Vulkan 1.1 para cada VkPhysicalDevice enumerado.
  • [C-1-4] DEBE enumerar las capas contenidas en bibliotecas nativas denominadas libVkLayer*.so en el directorio de la biblioteca nativa del paquete de la aplicación, a través de las API nativas de Vulkan vkEnumerateInstanceLayerProperties() y vkEnumerateDeviceLayerProperties() .
  • [C-1-5] no deben enumerar las capas proporcionadas por bibliotecas fuera del paquete de aplicación, o proporcionar otras formas de rastrear o interceptar la API Vulkan, a menos que la aplicación tenga el atributo android:debuggable establecido como true o los metadatos com.android.graphics.injectLayers.enable establecer en true .
  • [C-1-6] DEBEN informar todas las cadenas de extensión que admiten a través de las API nativas de Vulkan y, a la inversa, NO DEBEN informar las cadenas de extensión que no admiten correctamente.
  • [C-1-7] DEBE admitir las extensiones VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain y VK_KHR_incremental_present.
  • [C-1-8] DEBE informar la versión máxima de las pruebas Vulkan dEQP admitidas a través del indicador de función android.software.vulkan.deqp.level .
  • [C-1-9] DEBE ser al menos compatible con la versión 132317953 (desde el 1 de marzo de 2019) como se informa en el indicador de función android.software.vulkan.deqp.level .
  • [C-1-10] DEBE pasar todas las pruebas de Vulkan dEQP en las listas de pruebas entre la versión 132317953 y la versión especificada en el indicador de función android.software.vulkan.deqp.level .
  • [C-1-11] NO DEBE enumerar la compatibilidad con las extensiones VK_KHR_video_queue, VK_KHR_video_decode_queue o VK_KHR_video_encode_queue.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE admitir las extensiones VK_KHR_driver_properties y VK_GOOGLE_display_timing .

  • DEBE admitir VkPhysicalDeviceProtectedMemoryFeatures y VK_EXT_global_priority .

  • [C-1-12] NO DEBE enumerar la compatibilidad con la extensión VK_KHR_Performance_query.

Iniciar nuevos requisitos

Finalizar los nuevos requisitos

Iniciar nuevos requisitos

  • [C-SR-5] se recomienda encarecidamente admitir VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory y VK_EXT_global_priority .

  • [C-SR-6] se recomienda encarecidamente usar SkiaVk con HWUI.

Finalizar los nuevos requisitos

Si las implementaciones de dispositivos no incluyen soporte para Vulkan 1.0,:

  • [C-2-1] NO DEBE declarar ninguna de las características de Vulkan (por ejemplo, android.hardware.vulkan.level , android.hardware.vulkan.version ).
  • [C-2-2] NO DEBE enumerar ningún VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .

Si las implementaciones del dispositivo incluyen soporte para Vulkan 1.1 y declaran cualquiera de los indicadores de características de Vulkan descritos aquí , ellos:

  • [C-3-1] DEBE exponer la compatibilidad con el semáforo externo SYNC_FD y los tipos de identificador y la extensión VK_ANDROID_external_memory_android_hardware_buffer .

Iniciar nuevos requisitos

  • [C-SR-7] se recomienda encarecidamente que la extensión VK_KHR_external_fence_fd esté disponible para aplicaciones de terceros y habilite la aplicación para exportar la carga útil de la cerca y importar la carga útil de la cerca de los descriptores de archivos POSIX como se describe aquí .

Finalizar los nuevos requisitos

7.1.4.3 Representar script
  • [C-0-1] Las implementaciones de dispositivos DEBEN admitir Android RenderScript , como se detalla en la documentación del SDK de Android.
7.1.4.4 Aceleración de gráficos 2D

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D en el nivel de Aplicación, Actividad, Ventana o Vista mediante el uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas API directas.

Implementaciones de dispositivos:

  • [C-0-1] DEBE habilitar la aceleración de hardware de forma predeterminada y DEBE deshabilitar la aceleración de hardware si el desarrollador así lo solicita configurando android:hardwareAccelerated="false” o deshabilitando la aceleración de hardware directamente a través de las API de Android View.
  • [C-0-2] DEBE exhibir un comportamiento consistente con la documentación del SDK de Android sobre aceleración de hardware .

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas OpenGL ES aceleradas por hardware como objetivos de renderizado en una jerarquía de interfaz de usuario.

Implementaciones de dispositivos:

  • [C-0-3] DEBE admitir la API TextureView y DEBE exhibir un comportamiento consistente con la implementación de Android.
7.1.4.5 Pantallas de amplia gama

Si las implementaciones de dispositivos afirman ser compatibles con pantallas de gama amplia a través de Configuration.isScreenWideColorGamut() ,:

  • [C-1-1] DEBE tener una pantalla con color calibrado.
  • [C-1-2] DEBE tener una pantalla cuya gama cubra completamente la gama de colores sRGB en el espacio CIE 1931 xyY.
  • [C-1-3] DEBE tener una pantalla cuya gama tenga un área de al menos el 90 % de DCI-P3 en el espacio CIE 1931 xyY.
  • [C-1-4] DEBE admitir OpenGL ES 3.1 o 3.2 e informarlo correctamente.
  • [C-1-5] DEBE anunciar soporte para EGL_KHR_no_config_context , EGL_EXT_pixel_format_float , EGL_KHR_gl_colorspace , EGL_EXT_gl_colorspace_scrgb , EGL_EXT_gl_colorspace_scrgb_linear , EGL_EXT_gl_colorspace_display_p3 , EGL_EXT_gl_colorspace_display_p3_linear extensiones play_p3_linear y EGL_EXT_gl_colorspace_display_p3_passthrough .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que sean compatibles con GL_EXT_sRGB .

Por el contrario, si las implementaciones de dispositivos no admiten pantallas de gama amplia, estas:

  • [C-2-1] DEBE cubrir el 100 % o más de sRGB en el espacio CIE 1931 xyY, aunque la gama de colores de la pantalla no está definida.

7.1.5. Modo de compatibilidad de aplicaciones heredadas

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

7.1.6. Tecnología de pantalla

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

Todas las pantallas compatibles con Android de la implementación de un dispositivo:

  • [C-0-1] DEBE ser capaz de reproducir gráficos en color de 16 bits.
  • DEBE admitir pantallas con capacidad para gráficos en color de 24 bits.
  • [C-0-2] DEBE ser capaz de renderizar animaciones.
  • [C-0-3] DEBE tener una relación de aspecto de píxeles (PAR) entre 0,9 y 1,15. Es decir, la relación de aspecto de los píxeles DEBE ser casi cuadrada (1,0) con una tolerancia del 10 al 15 %.

7.1.7. Pantallas secundarias

Android incluye soporte para pantallas secundarias compatibles con Android para permitir capacidades de intercambio de medios y API de desarrollador para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa, ya sea a través de una conexión de pantalla adicional cableada, inalámbrica o incorporada,:

  • [C-1-1] DEBE implementar el servicio del sistema DisplayManager y la API como se describe en la documentación del SDK de Android.

7.2. Los dispositivos de entrada

Implementaciones de dispositivos:

7.2.1. Teclado

Si las implementaciones de dispositivos incluyen soporte para aplicaciones de editor de métodos de entrada (IME) de terceros, estas:

Implementaciones de dispositivos: * [C-0-1] NO DEBE incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.keyboard (QWERTY o 12 teclas). * DEBE incluir implementaciones adicionales de teclado virtual. * PUEDE incluir un teclado de hardware.

7.2.2. Navegación no táctil

Android incluye soporte para d-pad, trackball y rueda como mecanismos para navegación no táctil.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos carecen de navegación no táctil, estas:

  • [C-1-1] DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición de texto, compatible con los motores de gestión de entrada. La implementación de código abierto de Android incluye un mecanismo de selección adecuado para su uso con dispositivos que carecen de entradas de navegación no táctiles.

7.2.3. Teclas de navegación

Las funciones Inicio , Recientes y Atrás , que generalmente se brindan a través de una interacción con un botón físico dedicado o una parte distinta de la pantalla táctil, son esenciales para el paradigma de navegación de Android y, por lo tanto, para las implementaciones de dispositivos:

  • [C-0-1] DEBE proporcionar al usuario la posibilidad de iniciar aplicaciones instaladas que tengan una actividad con el <intent-filter> configurado con ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para implementaciones de dispositivos de televisión. La función Inicio DEBE ser el mecanismo para esta prestación al usuario.
  • DEBE proporcionar botones para la función Recientes y Atrás.

Si se proporcionan las funciones Inicio, Recientes o Atrás, estas:

  • [C-1-1] DEBE ser accesible con una sola acción (por ejemplo, toque, doble clic o gesto) cuando cualquiera de ellos sea accesible.
  • [C-1-2] DEBE proporcionar una indicación clara de qué acción única desencadenaría cada función. Tener un ícono visible impreso en el botón, mostrar un ícono de software en la parte de la barra de navegación de la pantalla o guiar al usuario a través de un flujo de demostración guiado paso a paso durante la experiencia de configuración inmediata son ejemplos de tal indicación.

Implementaciones de dispositivos:

  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] no proporcionar el mecanismo de entrada para la función Menú , ya que está obsoleto en favor de la barra de acciones desde Android 4.0.

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE proporcionar todas las funciones de navegación como cancelables. 'Cancelable' se define como la capacidad del usuario para evitar que se ejecute la función de navegación (por ejemplo, ir a casa, regresar, etc.) si el deslizamiento no se libera más allá de un cierto umbral.

Si las implementaciones de dispositivos proporcionan la función Menú, estas:

  • [C-2-1] DEBE mostrar el botón de desbordamiento de acciones siempre que el menú emergente de desbordamiento de acciones no esté vacío y la barra de acciones esté visible.
  • [C-2-2] NO DEBE modificar la posición de la ventana emergente de desbordamiento de acción que se muestra al seleccionar el botón de desbordamiento en la barra de acciones, pero PUEDE mostrar la ventana emergente de desbordamiento de acción en una posición modificada en la pantalla cuando se muestra seleccionando el Menú función.

Si las implementaciones del dispositivo no proporcionan la función Menú, para compatibilidad con versiones anteriores: * [C-3-1] DEBEN hacer que la función Menú esté disponible para las aplicaciones cuando targetSdkVersion sea inferior a 10, ya sea mediante un botón físico, una clave de software o gestos. Esta función de menú debe ser accesible a menos que esté oculta junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función Asistencia , estas:

  • [C-4-1] DEBE hacer que la función Asistencia sea accesible con una sola acción (por ejemplo, tocar, hacer doble clic o hacer un gesto) cuando se pueda acceder a otras teclas de navegación.
  • [C-SR-3] RECOMIENDA ENCARECIDAMENTE utilizar una pulsación prolongada en la función INICIO como esta interacción designada.

Si las implementaciones de dispositivos utilizan una parte distinta de la pantalla para mostrar las teclas de navegación,:

  • [C-5-1] Las teclas de navegación DEBEN utilizar una parte distinta de la pantalla, no disponible para las aplicaciones, y NO DEBEN oscurecer ni interferir de otro modo con la parte de la pantalla disponible para las aplicaciones.
  • [C-5-2] DEBE 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 .
  • [C-5-3] DEBE respetar las banderas establecidas por la aplicación a través del método API View.setSystemUiVisibility() , de modo que esta parte distinta de la pantalla (también conocida como la barra de navegación) esté correctamente oculta como se documenta en el SDK.

Si la función de navegación se proporciona como una acción en pantalla basada en gestos:

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() DEBE usarse solo para informar el área de reconocimiento de gestos de Inicio.
  • [C-6-2] Los gestos que comienzan dentro de un rectángulo de exclusión proporcionado por la aplicación de primer plano a través de View#setSystemGestureExclusionRects() , pero fuera de WindowInsets#getMandatorySystemGestureInsets() , NO DEBEN ser interceptados para la función de navegación siempre que el rectángulo de exclusión está permitido dentro del límite máximo de exclusión como se especifica en la documentación de View#setSystemGestureExclusionRects() .
  • [C-6-3] DEBE enviar a la aplicación de primer plano un evento MotionEvent.ACTION_CANCEL una vez que los toques comienzan a ser interceptados por un gesto del sistema, si a la aplicación de primer plano se le envió previamente un evento MotionEvent.ACTION_DOWN .
  • [C-6-4] DEBE proporcionar al usuario la posibilidad de cambiar a una navegación en pantalla basada en botones (por ejemplo, en Configuración).
  • DEBE proporcionar la función Inicio deslizando el dedo hacia arriba desde el borde inferior de la orientación actual de la pantalla.
  • DEBE proporcionar la función Recientes deslizando hacia arriba y manteniendo presionado antes de soltarlo, desde la misma área que el gesto de Inicio.
  • Los gestos que comienzan dentro de WindowInsets#getMandatorySystemGestureInsets() NO DEBEN verse afectados por las rectificaciones de exclusión proporcionadas por la aplicación de primer plano a través de View#setSystemGestureExclusionRects() .

Si se proporciona una función de navegación desde cualquier lugar de los bordes izquierdo y derecho de la orientación actual de la pantalla:

  • [C-7-1] La función de navegación DEBE ser Atrás y proporcionarse al deslizar el dedo desde los bordes izquierdo y derecho de la orientación actual de la pantalla.
  • [C-7-2] Si se proporcionan paneles de sistema deslizables personalizados en los bordes izquierdo o derecho, DEBEN colocarse dentro del tercio superior de la pantalla con una indicación visual clara y persistente de que arrastrar invocaría los paneles antes mencionados. y por lo tanto no Atrás. Un usuario PUEDE configurar un panel del sistema de manera que quede debajo del tercio superior de los bordes de la pantalla, pero el panel del sistema NO DEBE usar más de 1/3 de los bordes.
  • [C-7-3] Cuando la aplicación de primer plano tiene las banderas View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE configuradas, deslizar el dedo desde los bordes DEBE comportarse como se implementa en AOSP, que está documentado en el SDK .
  • [C-7-4] Cuando la aplicación de primer plano tiene las banderas View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE configuradas, los paneles del sistema deslizables personalizados DEBEN estar ocultos hasta que el usuario los introduzca o los desaten. el barras del sistema (también conocidas como barra de navegación y estado) tal como se implementan en AOSP.

Si se proporciona la función de navegación hacia atrás y el usuario cancela el gesto hacia atrás, entonces:

  • [C-8-1] Se DEBE llamar OnBackInvokedCallback.onBackCancelled() .
  • [C-8-2] NO SE DEBE llamar OnBackInvokedCallback.onBackInvoked() .
  • [C-8-3] El evento KEYCODE_BACK NO DEBE enviarse.

Si se proporciona la función de navegación hacia atrás pero la aplicación en primer plano NO tiene un OnBackInvokedCallback registrado, entonces:

  • El sistema DEBE proporcionar una animación para la aplicación en primer plano que sugiera que el usuario está regresando, según lo dispuesto en AOSP.

Si las implementaciones de dispositivos brindan soporte para la API del sistema setNavBarMode para permitir que cualquier aplicación del sistema con permiso android.permission.STATUS_BAR configure el modo de la barra de navegación, entonces:

  • [C-9-1] DEBE brindar soporte para íconos aptos para niños o navegación basada en botones según lo dispuesto en el código AOSP.

7.2.4. Entrada de pantalla táctil

Android incluye soporte para una variedad de sistemas de entrada de puntero, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basados ​​en pantalla táctil están asociadas con una pantalla de manera que el usuario tiene la impresión de manipular directamente elementos en la pantalla. Dado que el usuario toca directamente la pantalla, el sistema no requiere ningún elemento adicional para indicar los objetos que se están manipulando.

Implementaciones de dispositivos:

  • DEBE tener un sistema de entrada de puntero de algún tipo (ya sea tipo mouse o táctil).
  • DEBE admitir punteros con seguimiento totalmente independiente.

Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor) en una pantalla principal compatible con Android,:

  • [C-1-1] DEBE informar TOUCHSCREEN_FINGER para el campo API Configuration.touchscreen .
  • [C-1-2] DEBE informar los indicadores de funciones android.hardware.touchscreen y android.hardware.faketouch .

Si las implementaciones de dispositivos incluyen una pantalla táctil que puede rastrear más de un toque en una pantalla principal compatible con Android,:

  • [C-2-1] DEBE informar los indicadores de características apropiados android.hardware.touchscreen.multitouch , android.hardware.touchscreen.multitouch.distinct , android.hardware.touchscreen.multitouch.jazzhand correspondiente al tipo de pantalla táctil específica en el dispositivo.

Si las implementaciones de dispositivos dependen de un dispositivo de entrada externo, como un mouse o trackball (es decir, que no tocan directamente la pantalla) para la entrada en una pantalla principal compatible con Android y cumplen con los requisitos de toque falso en la sección 7.2.5 ,:

  • [C-3-1] NO DEBE informar ningún indicador de función que comience con android.hardware.touchscreen .
  • [C-3-2] DEBE informar solo android.hardware.faketouch .
  • [C-3-3] DEBE informar TOUCHSCREEN_NOTOUCH para el campo API Configuration.touchscreen .

7.2.5. Entrada táctil falsa

La interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un subconjunto de capacidades de la pantalla táctil. Por ejemplo, un mouse o control remoto que controla un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o enfoque y luego haga clic. Numerosos dispositivos de entrada como el mouse, el trackpad, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el trackpad multitáctil pueden admitir interacciones táctiles falsas. Android incluye la característica constante android.hardware.faketouch, que corresponde a un dispositivo de entrada no táctil (basado en puntero) de alta fidelidad, como un mouse o trackpad, que puede emular adecuadamente la entrada táctil (incluida la compatibilidad con gestos básicos), y indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil.

Si las implementaciones de dispositivos no incluyen una pantalla táctil pero incluyen otro sistema de entrada de puntero que desean que esté disponible, ellos:

  • DEBE declarar soporte para el indicador de función android.hardware.faketouch .

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch ,:

  • [C-1-1] DEBE informar las posiciones absolutas X e Y de la ubicación del puntero en la pantalla y mostrar un puntero visual en la pantalla.
  • [C-1-2] DEBE informar el evento táctil con el código de acción que especifica el cambio de estado que ocurre en el puntero que sube o baja en la pantalla .
  • [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba sobre un objeto en la pantalla, lo que permite a los usuarios emular el toque de un objeto en la pantalla.
  • [C-1-4] DEBE admitir puntero hacia abajo, puntero hacia arriba, puntero hacia abajo y luego puntero hacia arriba en el mismo lugar de un objeto en la pantalla dentro de un umbral de tiempo, lo que permite a los usuarios emular un doble toque en un objeto en la pantalla.
  • [C-1-5] DEBE admitir un puntero hacia abajo en un punto arbitrario de la pantalla, un puntero que se mueve a cualquier otro punto arbitrario de la pantalla, seguido de un puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
  • [C-1-6] 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 arrojar un objeto a la pantalla.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct ,:

  • [C-2-1] DEBE declarar soporte para android.hardware.faketouch .
  • [C-2-2] DEBE admitir un seguimiento distinto de dos o más entradas de puntero independientes.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.jazzhand ,:

  • [C-3-1] DEBE declarar soporte para android.hardware.faketouch .
  • [C-3-2] DEBE admitir un seguimiento distinto de 5 (seguimiento de una mano de dedos) o más entradas de puntero de forma totalmente independiente.

7.2.6. Soporte de controlador de juego

7.2.6.1. Asignaciones de botones

Implementaciones de dispositivos:

  • [C-1-1] DEBE ser capaz de asignar eventos HID a las constantes InputEvent correspondientes como se enumeran en las tablas siguientes. La implementación ascendente de Android satisface este requisito.

Si las implementaciones de dispositivos incorporan un controlador o se envían con un controlador separado en la caja que proporcionaría medios para ingresar todos los eventos enumerados en las tablas a continuación,:

  • [C-2-1] DEBE declarar el indicador de función android.hardware.gamepad
Botón Uso de HID 2 Botón Android
un 1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B 1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 _ 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y 1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
pad direccional arriba 1
Control 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 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Botón del hombro derecho 1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic 1 con el joystick izquierdo 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic con el joystick derecho 1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Atrás 1 0x0c 0x0224 CÓDIGO CLAVE_VOLVER (4)

1 evento clave

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

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

4 evento de movimiento

Controles analógicos 1 Uso de HID Botón Android
Gatillo izquierdo 0x02 0x00C5 AXIS_LTRIGGER
Gatillo derecho 0x02 0x00C4 AXIS_RTRIGGER
Palanca izquierda 0x01 0x0030
0x01 0x0031
EJE_X
EJE_Y
Palanca derecha 0x01 0x0032
0x01 0x0035
EJE_Z
EJE_RZ

1 evento de movimiento

7.2.7. Control remoto

Consulte la Sección 2.3.1 para conocer los requisitos específicos del dispositivo.

7.3. Sensores

Si las implementaciones de dispositivos incluyen 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 la documentación de código abierto de Android sobre sensores .

Implementaciones de dispositivos:

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

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, ellos:

  • [C-1-1] DEBE informar todas las mediciones de los sensores utilizando los valores pertinentes del Sistema Internacional de Unidades (métrico) para cada tipo de sensor, tal como se define en la documentación del SDK de Android.
  • [C-1-2] DEBE informar datos del sensor con una latencia máxima de 100 milisegundos + 2 * sample_time para el caso de un flujo de sensor con una latencia máxima solicitada de 0 ms cuando el procesador de aplicaciones está activo. Este retraso no incluye ningún retraso en el filtrado.
  • [C-1-3] DEBE informar la primera muestra del sensor dentro de los 400 milisegundos + 2 * sample_time de la activación del sensor. Es aceptable que esta muestra tenga una precisión de 0.
  • [C-1-4] Para que cualquier API indicada en la documentación del SDK de Android sea un sensor continuo , las implementaciones del dispositivo DEBEN proporcionar continuamente muestras de datos periódicas que DEBEN tener una fluctuación inferior al 3%, donde la fluctuación se define como la desviación estándar de la diferencia. de los valores de marca de tiempo informados entre eventos consecutivos.
  • [C-1-5] DEBE garantizar que el flujo de eventos del sensor NO DEBE impedir que la CPU del dispositivo entre en un estado de suspensión o se despierte de un estado de suspensión.
  • [C-1-6] 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().
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE tener un error de sincronización de marca de tiempo inferior a 100 milisegundos, y DEBE tener un error de sincronización de marca de tiempo inferior a 1 milisegundo.
  • Cuando se activan varios sensores, el consumo de energía NO DEBE exceder la suma del consumo de energía informado de cada sensor individual.

La lista anterior no es exhaustiva; el comportamiento documentado del SDK de Android y la documentación de código abierto de Android sobre sensores debe considerarse autorizado.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, ellos:

  • [C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores e informar el valor a través del método API Sensor.getResolution() .

Algunos tipos de sensores son compuestos, lo que significa que pueden derivarse de datos proporcionados por uno o más sensores. (Los ejemplos incluyen el sensor de orientación y el sensor de aceleración lineal).

Implementaciones de dispositivos:

  • DEBE implementar estos tipos de sensores, cuando incluyen los sensores físicos prerrequisitos como se describe en tipos de sensores .

Si las implementaciones de dispositivos incluyen un sensor compuesto,:

  • [C-2-1] DEBE implementar el sensor como se describe en la documentación de código abierto de Android sobre sensores compuestos .

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos y el sensor solo informa un valor, entonces las implementaciones de dispositivos:

  • [C-3-1] DEBE establecer la resolución en 1 para el sensor e informar el valor a través del método API Sensor.getResolution() .

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor está expuesto a desarrolladores externos, estos:

  • [C-4-1] NO DEBE incluir ningún parámetro de calibración fijo y determinado en fábrica en los datos proporcionados.

Si las implementaciones de dispositivos incluyen una combinación de acelerómetro de 3 ejes, un sensor giroscópico de 3 ejes o un sensor magnetómetro, son:

  • [C-SR-2] SE RECOMIENDA ENCARECIDAMENTE garantizar que el acelerómetro, el giroscopio y el magnetómetro tengan una posición relativa fija, de modo que si el dispositivo es transformable (por ejemplo, plegable), los ejes del sensor permanezcan alineados y consistentes con el sistema de coordenadas del sensor en todas las ocasiones posibles. Estados de transformación del dispositivo.

7.3.1. Acelerómetro

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos incluyen un acelerómetro,:

  • [C-1-1] DEBE poder informar eventos con una frecuencia de al menos 50 Hz.
  • [C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en las API de Android.
  • [C-1-4] DEBE ser capaz de medir desde caída libre hasta cuatro veces la gravedad (4g) o más en cualquier eje.
  • [C-1-5] DEBE tener una resolución de al menos 12 bits.
  • [C-1-6] DEBE tener una desviación estándar no mayor a 0,05 m/s^, donde la desviación estándar debe calcularse por eje en muestras recolectadas durante un período de al menos 3 segundos a la velocidad de muestreo más rápida.
  • DEBE informar eventos de hasta al menos 200 Hz.
  • DEBE tener una resolución de al menos 16 bits.
  • DEBE calibrarse mientras está en uso si las características cambian durante el ciclo de vida y compensarse, y preservar los parámetros de compensación entre reinicios del dispositivo.
  • DEBE tener compensación de temperatura.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes,:

  • [C-2-1] DEBE implementar y reportar el sensor TYPE_ACCELEROMETER .
  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION .
  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE implementar e informar el sensor TYPE_ACCELEROMETER_UNCALIBRATED . Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android cumplan con este requisito para que puedan actualizarse a la versión futura de la plataforma donde esto pueda ser REQUERIDO.
  • 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.

Si las implementaciones de dispositivos incluyen un acelerómetro con menos de 3 ejes,:

  • [C-3-1] DEBE implementar y reportar el sensor TYPE_ACCELEROMETER_LIMITED_AXES .
  • [C-SR-6] Está STRONGLY_RECOMMENDED implementar e informar el sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED .

Si las implementaciones del dispositivo incluyen un acelerómetro de 3 ejes y cualquiera de los sensores compuestos TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER :

  • [C-4-1] La suma de su consumo de energía DEBE ser siempre inferior a 4 mW.
  • DEBEN estar por debajo de 2 mW y 0,5 mW cuando el dispositivo está en condición dinámica o estática.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor giroscópico de 3 ejes,:

  • [C-5-1] DEBE implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION .
  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR .

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, un sensor giroscópico de 3 ejes y un sensor magnetómetro, estos:

  • [C-6-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR .

7.3.2. Magnetómetro

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un magnetómetro de 3 ejes (brújula).

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, estos:

  • [C-1-1] DEBE implementar el sensor TYPE_MAGNETIC_FIELD .
  • [C-1-2] DEBE poder informar eventos de hasta una frecuencia de al menos 10 Hz y DEBE informar eventos de hasta al menos 50 Hz.
  • [C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en las API de Android.
  • [C-1-4] DEBE ser capaz de medir entre -900 µT y +900 µT en cada eje antes de saturar.
  • [C-1-5] DEBE tener un valor de compensación de hierro duro inferior a 700 µT y DEBE tener un valor inferior a 200 µT, colocando el magnetómetro lejos de campos magnéticos dinámicos (inducidos por corriente) y estáticos (inducidos por imanes).
  • [C-1-6] DEBE tener una resolución igual o mayor a 0,6 µT.
  • [C-1-7] DEBE admitir la calibración y compensación en línea de la polarización del hierro duro y preservar los parámetros de compensación entre reinicios del dispositivo.
  • [C-1-8] DEBE tener aplicada la compensación de hierro dulce; la calibración se puede realizar mientras está en uso o durante la producción del dispositivo.
  • [C-1-9] DEBE tener una desviación estándar, calculada por eje en muestras recolectadas durante un período de al menos 3 segundos a la velocidad de muestreo más rápida, no mayor a 1,5 µT; DEBE tener una desviación estándar no mayor a 0,5 µT.
  • [C-1-10] DEBE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED .

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un sensor de acelerómetro y un sensor de giroscopio de 3 ejes, estos:

  • [C-2-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR .

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro, estos:

  • PUEDE implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR .

Si las implementaciones del dispositivo incluyen un magnetómetro de 3 ejes, un acelerómetro y un sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR , ellos:

  • [C-3-1] DEBE consumir menos de 10 mW.
  • DEBE consumir menos de 3 mW cuando el sensor está registrado para el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un receptor GPS/GNSS.

Si las implementaciones de dispositivos incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través del indicador de función android.hardware.location.gps , estas:

  • [C-1-1] DEBE admitir salidas de ubicación a una velocidad de al menos 1 Hz cuando se solicita a través de LocationManager#requestLocationUpdate .
  • [C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, trayectorias múltiples insignificantes, HDOP < 2) en 10 segundos (tiempo rápido para la primera fijación), cuando está conectado a una red de datos de 0,5 Mbps o más rápida. velocidad de conexión a internet. Este requisito generalmente se cumple mediante el uso de algún tipo de técnica GPS/GNSS asistida o prevista para minimizar el tiempo de bloqueo de GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y las efemérides/reloj del satélite).
    • [C-1-6] Después de realizar dicho cálculo de ubicación, las implementaciones del dispositivo DEBEN determinar su ubicación, a cielo abierto, dentro de los 5 segundos, cuando se reinician las solicitudes de ubicación, hasta una hora después del cálculo de ubicación inicial, incluso cuando la solicitud posterior se realiza sin conexión de datos y/o después de un ciclo de encendido.
  • En condiciones de cielo abierto después de determinar la ubicación, mientras está parado o en movimiento con menos de 1 metro por segundo al cuadrado de aceleración:

    • [C-1-3] 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.
    • [C-1-4] DEBE rastrear e informar simultáneamente a través de GnssStatus.Callback de al menos 8 satélites de una constelación.
    • DEBE poder rastrear simultáneamente al menos 24 satélites, de múltiples constelaciones (por ejemplo, GPS + al menos uno de Glonass, Beidou, Galileo).
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE continuar brindando resultados de ubicación GPS/GNSS normales a través de las API del proveedor de ubicación GNSS durante una llamada telefónica de emergencia.

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE informar las mediciones GNSS de todas las constelaciones rastreadas (como se informa en los mensajes GnssStatus), con la excepción de SBAS.

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE informar el AGC y la frecuencia de medición GNSS.

  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE informar todas las estimaciones de precisión (incluidos el rumbo, la velocidad y la vertical) como parte de cada ubicación GPS/GNSS.

  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE informar las mediciones GNSS tan pronto como se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.

  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE informar pseudodistancias y velocidades de pseudodistancia GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras está parado o en movimiento con menos de 0,2 metros por segundo al cuadrado de aceleración, sean suficientes para calcular la posición. dentro de los 20 metros y velocidad dentro de los 0,2 metros por segundo, al menos el 95% del tiempo.

7.3.4. Giroscopio

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un sensor de giroscopio.

Si las implementaciones de dispositivos incluyen un giroscopio,:

  • [C-1-1] DEBE poder informar eventos con una frecuencia de al menos 50 Hz.
  • [C-1-4] DEBE tener una resolución de 12 bits o más.
  • [C-1-5] DEBE tener compensación de temperatura.
  • [C-1-6] DEBE calibrarse y compensarse mientras está en uso y preservar los parámetros de compensación entre reinicios del dispositivo.
  • [C-1-7] DEBE tener una variación no mayor 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 frecuencia de muestreo, pero DEBE estar limitada por este valor. En otras palabras, si mide la varianza del giroscopio a una frecuencia de muestreo de 1 Hz, DEBE ser no mayor que 1e-7 rad^2/s^2.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que el error de calibración sea inferior a 0,01 rad/s cuando el dispositivo está estacionario a temperatura ambiente.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de 16 bits o más.
  • DEBE informar eventos de hasta al menos 200 Hz.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes,:

  • [C-2-1] DEBE implementar el sensor TYPE_GYROSCOPE .
  • [C-SR-4] Se recomienda encarecidamente implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED .

Si las implementaciones de dispositivos incluyen un giroscopio con menos de 3 ejes,:

  • [C-3-1] DEBE implementar e informar el sensor TYPE_GYROSCOPE_LIMITED_AXES .
  • [C-SR-5] Está STRONGLY_RECOMMENDED implementar e informar el sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED .

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, un sensor acelerómetro y un sensor magnetómetro, estos:

  • [C-4-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR .

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor giroscópico de 3 ejes,:

  • [C-5-1] DEBE implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION .
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR .

7.3.5. Barómetro

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un barómetro (sensor de presión del aire ambiente).

Si las implementaciones de dispositivos incluyen un barómetro,:

  • [C-1-1] DEBE implementar e informar el sensor TYPE_PRESSURE .
  • [C-1-2] DEBE poder entregar eventos a 5 Hz o más.
  • [C-1-3] DEBE tener compensación de temperatura.
  • [C-SR-2] MUY RECOMENDADO poder informar mediciones de presión en el rango de 300 hPa a 1100 hPa.
  • DEBE tener una precisión absoluta de 1hPa.
  • DEBE tener una precisión relativa de 0,12 hPa en un rango de 20 hPa (equivalente a una precisión de ~1 m con un cambio de ~200 m al nivel del mar).

7.3.6. Termómetro

Si las implementaciones de dispositivos incluyen un termómetro ambiental (sensor de temperatura), ellos:

  • [C-1-1] DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para el sensor de temperatura ambiente y el sensor DEBE medir la temperatura ambiente (habitación/cabina del vehículo) desde donde el usuario interactúa con el dispositivo en grados Celsius.

Si las implementaciones de dispositivos incluyen un sensor de termómetro que mide una temperatura distinta de la temperatura ambiente, como la temperatura de la CPU,:

Si las implementaciones de dispositivos incluyen un sensor para monitorear la temperatura de la piel, entonces:

7.3.7. Fotómetro

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

7.3.8. Sensor de proximidad

  • Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad.

Si las implementaciones de dispositivos incluyen un sensor de proximidad y solo informan una lectura binaria "cerca" o "lejana",:

  • [C-1-1] DEBE medir la proximidad de un objeto en la misma dirección que la pantalla. Es decir, el sensor de proximidad DEBE estar orientado para detectar objetos cerca de la pantalla, ya que la intención principal de este tipo de sensor es detectar un teléfono en uso por el usuario. Si las implementaciones del dispositivo incluyen un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API.
  • [C-1-2] DEBE tener 1 bit de precisión o más.
  • [C-1-3] DEBE utilizar 0 centímetros como lectura cercana y 5 centímetros como lectura lejana.
  • [C-1-4] DEBE informar un alcance y resolución máximos de 5.

7.3.9. Sensores de alta fidelidad

Si las implementaciones de dispositivos incluyen un conjunto de sensores de mayor calidad, como se define en esta sección, y los ponen a disposición de aplicaciones de terceros,:

  • [C-1-1] DEBE identificar la capacidad a través del indicador de función android.hardware.sensor.hifi_sensors .

Si las implementaciones de dispositivos declaran android.hardware.sensor.hifi_sensors ,:

  • [C-2-1] DEBE tener un sensor TYPE_ACCELEROMETER que:

    • DEBE tener un rango de medición entre al menos -8 g y +8 g, y SE RECOMIENDA ENCARECIDAMENTE tener un rango de medición entre al menos -16 g y +16 g.
    • DEBE tener una resolución de medición de al menos 2048 LSB/g.
    • DEBE tener una frecuencia de medición mínima de 12,5 Hz o menos.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior; DEBE admitir SensorDirectChannel RATE_VERY_FAST .
    • DEBE tener un ruido de medición no superior a 400 μg/√Hz.
    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 3000 eventos de sensor.
    • DEBE tener un consumo de energía por lotes no inferior a 3 mW.
    • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE tener un ancho de banda de medición de 3 dB de al menos el 80 % de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
    • DEBE tener una aceleración aleatoria inferior a 30 μg √Hz probada a temperatura ambiente.
    • DEBE tener un cambio de sesgo frente a la temperatura de ≤ +/- 1 mg/°C.
    • DEBE tener una no linealidad de línea de mejor ajuste de ≤ 0,5% y un cambio de sensibilidad frente a la temperatura de ≤ 0,03%/C°.
    • DEBE tener una sensibilidad transversal de < 2,5 % y una variación de la sensibilidad transversal < 0,2 % en el rango de temperatura de funcionamiento del dispositivo.
  • [C-2-2] DEBE tener un TYPE_ACCELEROMETER_UNCALIBRATED con los mismos requisitos de calidad que TYPE_ACCELEROMETER .

  • [C-2-3] DEBE tener un sensor TYPE_GYROSCOPE que:

    • DEBE tener un rango de medición entre al menos -1000 y +1000 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 menos.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior; DEBE admitir SensorDirectChannel RATE_VERY_FAST .
    • DEBE tener un ruido de medición no superior a 0,014°/s/√Hz.
    • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE tener un ancho de banda de medición de 3 dB de al menos el 80 % de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
    • DEBE tener una velocidad de caminata aleatoria inferior a 0,001 °/s √Hz probada a temperatura ambiente.
    • DEBE tener un cambio de polarización frente a la temperatura de ≤ +/- 0,05 °/ s / °C.
    • DEBE tener un cambio de sensibilidad frente a la temperatura de ≤ 0,02%/°C.
    • DEBE tener una no linealidad de línea de mejor ajuste de ≤ 0,2%.
    • DEBE tener una densidad de ruido de ≤ 0,007 °/s/√Hz.
    • DEBE tener un error de calibración inferior a 0,002 rad/s en un rango de temperatura de 10 ~ 40 ℃ cuando el dispositivo está estacionario.
    • DEBE tener una sensibilidad g inferior a 0,1°/s/g.
    • DEBE tener una sensibilidad entre ejes < 4,0 % y una variación de sensibilidad entre ejes < 0,3 % en el rango de temperatura de funcionamiento del dispositivo.
  • [C-2-4] DEBE tener un TYPE_GYROSCOPE_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GYROSCOPE .

  • [C-2-5] DEBE tener un sensor TYPE_GEOMAGNETIC_FIELD que:

    • DEBE tener un rango de medición entre al menos -900 y +900 μT.
    • 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 menos.
    • DEBE tener una frecuencia de medición máxima de 50 Hz o superior.
    • DEBE tener un ruido de medición no superior a 0,5 uT.
  • [C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GEOMAGNETIC_FIELD y además:

    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 600 eventos de sensor.
    • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE tener un espectro de ruido blanco de 1 Hz a al menos 10 Hz cuando la frecuencia de informe sea de 50 Hz o superior.
  • [C-2-7] DEBE tener un sensor TYPE_PRESSURE que:

    • DEBE tener un rango de medición entre al menos 300 y 1100 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 menos.
    • DEBE tener una frecuencia máxima de medición de 10 Hz o superior.
    • DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 300 eventos de sensor.
    • DEBE tener un consumo de energía por lotes no inferior a 2 mW.
  • [C-2-8] DEBE tener un sensor TYPE_GAME_ROTATION_VECTOR .

  • [C-2-9] DEBE tener un sensor TYPE_SIGNIFICANT_MOTION que:

    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
  • [C-2-10] DEBE tener un sensor TYPE_STEP_DETECTOR que:

    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 100 eventos de sensor.
    • DEBE tener un consumo de energía no 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 no inferior a 4 mW.
  • [C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER que:

    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
  • [C-2-12] DEBE tener un sensor TILT_DETECTOR que:

    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
  • [C-2-13] La marca de tiempo del mismo evento físico reportado por el acelerómetro, el giroscopio y el magnetómetro DEBE tener una diferencia de 2,5 milisegundos entre sí. La marca de tiempo del mismo evento físico reportado por el acelerómetro y el giroscopio DEBE estar con una diferencia de 0,25 milisegundos entre sí.

  • [C-2-14] DEBE tener marcas de tiempo de eventos del sensor de giroscopio en la misma base de tiempo que el subsistema de la cámara y dentro de 1 milisegundo de error.

  • [C-2-15] DEBE entregar muestras a las aplicaciones dentro de los 5 milisegundos desde el momento en que los datos están disponibles en cualquiera de los sensores físicos anteriores para la aplicación.

  • [C-2-16] NO DEBE tener un consumo de energía superior a 0,5 mW cuando el dispositivo está estático y 2,0 mW cuando el dispositivo está en movimiento cuando cualquier combinación de los siguientes sensores está habilitada:

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] PUEDE tener un sensor TYPE_PROXIMITY , pero si está presente DEBE tener una capacidad de búfer mínima de 100 eventos de sensor.

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

Si las implementaciones de dispositivos incluyen soporte directo de sensores, estos:

  • [C-3-1] DEBE declarar correctamente la compatibilidad con los tipos de canales directos y el nivel de tarifas de informes directos a través de la API isDirectChannelTypeSupported y getHighestDirectReportRateLevel .
  • [C-3-2] DEBE admitir al menos uno de los dos tipos de canal directo de sensor para todos los sensores que declaran soporte para canal directo de sensor.
  • DEBE admitir informes de eventos a través del canal directo del sensor para el sensor primario (variante sin activación) de los siguientes tipos:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensores biométricos

Para obtener información adicional sobre la medición de la seguridad de desbloqueo biométrico, consulte la documentación sobre Medición de la seguridad biométrica .

Si las implementaciones de dispositivos incluyen una pantalla de bloqueo segura,:

  • DEBE incluir un sensor biométrico

Los sensores biométricos se pueden clasificar como Clase 3 (anteriormente Fuerte ), Clase 2 (anteriormente Débil ) o Clase 1 (anteriormente Conveniencia ) en función de sus tasas de aceptación de falsificaciones e impostores, y de la seguridad de la tubería biométrica. Esta clasificación determina las capacidades que tiene el sensor biométrico para interactuar con la plataforma y con aplicaciones de terceros. Los sensores deben cumplir requisitos adicionales que se detallan a continuación si desean clasificarse como Clase 1 , Clase 2 o Clase 3 . Tanto la biometría de Clase 2 como la de Clase 3 obtienen capacidades adicionales como se detalla a continuación.

Si las implementaciones de dispositivos ponen un sensor biométrico a disposición de aplicaciones de terceros a través de android.hardware.biometrics.BiometricManager , android.hardware.biometrics.BiometricPrompt y android.provider.Settings.ACTION_BIOMETRIC_ENROLL , estos:

  • [C-4-1] DEBE cumplir con los requisitos para datos biométricos de Clase 3 o Clase 2 como se define en este documento.
  • [C-4-2] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase Autenticadores y cualquier combinación de los mismos. Por el contrario, NO DEBE respetar ni reconocer las constantes enteras pasadas a los métodos canAuthenticate(int) y setAllowedAuthenticators(int) distintas de aquellas documentadas como constantes públicas en Authenticators y cualquier combinación de las mismas.
  • [C-4-3] DEBE implementar la acción ACTION_BIOMETRIC_ENROLL en dispositivos que tienen datos biométricos de Clase 3 o Clase 2 . Esta acción DEBE presentar únicamente los puntos de entrada de inscripción para datos biométricos de Clase 3 o Clase 2 .

Si las implementaciones de dispositivos admiten biometría pasiva,:

  • [C-5-1] DEBE requerir de forma predeterminada un paso de confirmación adicional (por ejemplo, presionar un botón).
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE tener una configuración que permita a los usuarios anular las preferencias de la aplicación y siempre requiere un paso de confirmación adjunto.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que la acción de confirmación esté protegida de manera que un sistema operativo o un kernel comprometido no puedan falsificarla. Por ejemplo, esto significa que la acción de confirmación basada en un botón físico se enruta a través de un pin de entrada/salida de propósito general (GPIO) de solo entrada de un elemento seguro (SE) que no puede controlarse por ningún otro medio que no sea un botón físico. prensa.
  • [C-5-2] DEBE implementar adicionalmente un flujo de autenticación implícito (sin paso de confirmación) correspondiente a setConfirmationRequired(boolean) , que las aplicaciones pueden configurar para utilizar para flujos de inicio de sesión.

Si las implementaciones de dispositivos tienen múltiples sensores biométricos, estos:

Iniciar nuevos requisitos

  • [C-7-1] debe, cuando una biométrica está en bloqueo (es decir, la biométrica está deshabilitada hasta que el usuario desbloquea con autenticación primaria) o bloqueo de tiempo en el tiempo (es decir, la biométrica se deshabilita temporalmente hasta que el usuario espera un intervalo de tiempo) Debido a demasiados intentos fallidos, también bloquee todas las demás biometría de una clase biométrica inferior. En el caso del bloqueo de límite de tiempo, el tiempo de retroceso para la verificación biométrica debe ser el tiempo máximo de retroceso de todas las biométricas en el bloqueo de tiempo límite.

  • [C-SR-12] se recomiendan fuertemente, cuando un biométrico está en bloqueo (es decir, la biométrica está deshabilitada hasta que el usuario desbloquea con la autenticación primaria) o un bloqueo de tiempo en el tiempo (es decir, la biométrica se deshabilita temporalmente hasta que el usuario espera un tiempo intervalo) debido a demasiados intentos fallidos, para bloquear también todas las demás biometría de la misma clase biométrica. En el caso del bloqueo de límite de tiempo, se recomienda encarecidamente el tiempo de retroceso para la verificación biométrica para ser el tiempo máximo de retroceso de todas las biometría en el bloqueo de tiempo.

  • [C-7-2] debe desafiar al usuario para la autenticación primaria recomendada (por ejemplo: PIN, patrón, contraseña) para restablecer el contador de bloqueo para que se bloquee un biométrico. Se puede permitir que la biometría de clase 3 restablezca el contador de bloqueo para una biométrica bloqueada de la misma clase o baja. No se debe permitir que la biometría de Clase 2 o Clase 1 complete una operación de bloqueo de reinicio para cualquier biometría.

Finalizar los nuevos requisitos

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE exigir que solo se confirme un dato biométrico por autenticación (por ejemplo, si el dispositivo tiene disponibles sensores de huellas dactilares y faciales, se debe enviar onAuthenticationSucceeded después de confirmar cualquiera de ellos).

Para que las implementaciones de dispositivos permitan el acceso a las claves del almacén de claves a aplicaciones de terceros, deben:

  • [C-6-1] DEBE cumplir con los requisitos para la Clase 3 como se define en esta sección a continuación.
  • [C-6-2] DEBE presentar solo datos biométricos de Clase 3 cuando la autenticación requiere BIOMETRIC_STRONG o la autenticación se invoca con un CryptoObject .

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 1 (anteriormente Conveniencia ), deben:

  • [C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0,002%.
  • [C-1-2] DEBE revelar que este modo puede ser menos seguro que un PIN, patrón o contraseña seguros y enumerar claramente los riesgos de habilitarlo, si las tasas de aceptación de falsificaciones e impostores son superiores al 7 % según lo medido por el Protocolos de prueba biométrica de Android .
  • [C-1-9] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) después de no más de veinte pruebas falsas y un tiempo de espera de no menos de noventa segundos para la verificación biométrica, cuando una prueba falsa es una. con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un biométrico registrado.
  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE reducir el número total de pruebas falsas para la verificación biométrica especificada en [C-1-9] si las tasas de aceptación de falsificaciones e impostores son superiores al 7 % según lo medido por los Protocolos de prueba biométrica de Android. .
  • [C-1-3] DEBE calificar los intentos de límite de verificación biométrica, donde una prueba falsa es aquella con una calidad de captura adecuada ( BIOMETRIC_ACQUIRED_GOOD ) que no coincide con una prueba biométrica registrada.
  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE calificar los intentos de límite durante al menos 30 segundos después de cinco pruebas falsas para la verificación biométrica para el número máximo de pruebas falsas según [C-1-9], donde una prueba falsa es aquella con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un dato biométrico registrado.
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE tener toda la lógica de limitación de velocidad en TEE.
  • [C-1-10] DEBE desactivar la biometría una vez que se haya activado por primera vez la interrupción de la autenticación primaria, como se describe en [C-0-2] de la sección 9.11.

  • [C-1-11] DEBE tener una tasa de aceptación de parodias e impostores no superior al 30%, con (1) una tasa de aceptación de parodias e impostores para especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 30%, y (2 ) una tasa de aceptación de parodias e impostores de especies PAI de Nivel B no superior al 40%, según lo medido por los Protocolos de prueba biométrica de Android.

  • [C-1-4] DEBE evitar agregar nuevos datos biométricos sin establecer primero una cadena de confianza haciendo que el usuario confirme la credencial del dispositivo existente o agregue una nueva (PIN/patrón/contraseña) que esté protegida por TEE; La implementación del Proyecto de código abierto de Android proporciona el mecanismo en el marco para hacerlo.

  • [C-1-5] DEBE eliminar por completo todos los datos biométricos identificables de un usuario cuando se elimina la cuenta del usuario (incluso mediante un restablecimiento de fábrica).

  • [C-1-6] DEBE respetar el indicador individual para ese elemento biométrico (es decir, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).

  • [C-1-7] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) una vez cada 24 horas o menos. Nota: La actualización de dispositivos iniciados con la versión 9 de Android o anterior DEBE exigir al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) una vez cada 72 horas o menos.

  • [C-1-8] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) o datos biométricos de Clase 3 (FUERTE) después de uno de los siguientes:

    • un período de inactividad de 4 horas, O
    • 3 intentos fallidos de autenticación biométrica.
    • El período de tiempo de inactividad y el recuento de autenticación fallida se restablecen después de cualquier confirmación exitosa de las credenciales del dispositivo. Nota: La actualización de dispositivos iniciados con la versión 9 de Android o anterior PUEDE estar exenta de C-1-8.
  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE utilizar la lógica del marco proporcionado por el Proyecto de código abierto de Android para hacer cumplir las restricciones especificadas en [C-1-7] y [C-1-8] para dispositivos nuevos.

  • [C-SR-8] Se RECOMIENDA ENCARECIDAMENTE tener una tasa de rechazo falso inferior al 10%, medida en el dispositivo.

  • [C-SR-9] Se RECOMIENDA ENCARECIDAMENTE tener una latencia inferior a 1 segundo, medida desde que se detecta el dato biométrico hasta que se desbloquea la pantalla, para cada dato biométrico registrado.

Iniciar nuevos requisitos

  • [C-1-12] debe tener una tasa de aceptación de la falsificación e impostores no superiores al 40% por especie de instrumento de ataque de presentación (PAI) , según lo medido por los protocolos de prueba de biometría de Android .

  • [C-SR-13] se recomienda encarecidamente tener una tasa de aceptación de la parodia e impostores no superiores al 30% por especie de instrumento de ataque de presentación (PAI) , medido por los protocolos de prueba de biometría Android .

  • [C-SR-14] se recomienda encarecidamente revelar la clase biométrica del sensor biométrico y los riesgos correspondientes de habilitarlo.

  • [C-SR-17] se recomiendan encarecidamente implementar las nuevas interfaces de Aidl (como, IFace.aidl e IFingerprint.aidl ).

Finalizar los nuevos requisitos

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 2 (anteriormente Débil ), deben:

  • [C-2-1] DEBE cumplir con todos los requisitos para la Clase 1 anterior.

  • [C-2-2] DEBE tener una tasa de aceptación de parodias e impostores no superior al 20%, con (1) una tasa de aceptación de parodias e impostores para especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 20%, y (2 ) una tasa de aceptación de parodias e impostores de especies PAI de Nivel B no superior al 30%, según lo medido por los Protocolos de prueba biométrica de Android .

Iniciar nuevos requisitos

  • [C-SR-15] se recomienda encarecidamente tener una tasa de aceptación de la parodia e impostores no superiores al 20% por especie de instrumento de ataque de presentación (PAI) , medido por los protocolos de prueba de biometría Android .

Finalizar los nuevos requisitos

  • [C-2-3] debe realizar la coincidencia biométrica en un entorno de ejecución aislado fuera del usuario de Android o el espacio del núcleo, como el entorno de ejecución de confianza (TEE), o en un chip con un canal seguro al entorno de ejecución aislado o en protegido Máquina virtual que cumple con los requisitos en la Sección 9.17 .
  • [C-2-4] DEBE tener todos los datos identificables cifrados y autenticados criptográficamente de manera que no puedan adquirirse, leerse o modificarse fuera del entorno de ejecución aislado o un chip con un canal seguro hacia el entorno de ejecución aislado como se documenta en las pautas de implementación. en el sitio del proyecto de código abierto de Android o una máquina virtual protegida controlada por Hypervisor que cumple con los requisitos en la Sección 9.17 .
  • [C-2-5] Para datos biométricos basados ​​en cámaras, mientras se realiza la autenticación o inscripción biométrica:
    • Debe operar la cámara en un modo que evite que los marcos de la cámara se lean o se alteren fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado o una máquina virtual protegida controlada por Hypervisor que cumple con los requisitos en la Sección 9.17 .
    • Para las soluciones RGB de una sola cámara, los marcos de la cámara PUEDEN ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para el registro, pero aún así NO DEBEN ser modificables.
  • [C-2-6] NO DEBE permitir que aplicaciones de terceros distingan entre inscripciones biométricas individuales.
  • [C-2-7] no debe permitir el acceso no encriptado a datos biométricos identificables o cualquier datos derivados de él (como incrustaciones) al procesador de aplicaciones fuera del contexto del TEE o la máquina virtual protegida controlada por Hypervisor que cumple con los requisitos en la sección 9.17 . La actualización de dispositivos lanzados con la versión 9 de Android o anterior no está exenta de C-2-7.
  • [C-2-8] DEBE tener una canalización de procesamiento segura de modo que un sistema operativo o un kernel comprometido no puedan permitir que se inyecten datos directamente para autenticarse falsamente como usuario. Nota: Si las implementaciones de dispositivos ya se lanzaron en la versión 9 de Android o anterior y no pueden cumplir con el requisito C-2-8 a través de una actualización del software del sistema, PUEDEN estar exentos del requisito.

  • [C-SR-10] Se RECOMIENDA ENCARECIDAMENTE incluir detección de vida para todas las modalidades biométricas y detección de atención para la biometría facial.

  • [C-2-9] DEBE poner el sensor biométrico a disposición de aplicaciones de terceros.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 3 (anteriormente Fuerte ), deben:

  • [C-3-1] DEBE cumplir con todos los requisitos de la Clase 2 anterior, excepto [C-1-7] y [C-1-8].
  • [C-3-2] DEBE tener una implementación de almacén de claves respaldada por hardware.
  • [C-3-3] DEBE tener una tasa de aceptación de parodias e impostores no superior al 7%, con (1) una tasa de aceptación de parodias e impostores para especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 7%, y (2 ) una tasa de aceptación de parodias e impostores de especies PAI de Nivel B no superior al 20%, según lo medido por los Protocolos de prueba biométrica de Android .
  • [C-3-4] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) una vez cada 72 horas o menos.
  • [C-3-5] DEBE volver a generar la ID del autenticador para todos los datos biométricos de Clase 3 admitidos en el dispositivo si alguno de ellos se vuelve a inscribir.
  • [C-3-6] Debe habilitar claves de almacén de claves con respaldo biométrico para aplicaciones de terceros.

Iniciar nuevos requisitos

  • [C-SR-16] se recomienda encarecidamente tener una tasa de aceptación de la parodia e impostura no superior al 7% por especie de instrumento de ataque de presentación (PAI) , medido por los protocolos de prueba de biometría de Android .

Finalizar los nuevos requisitos

Si las implementaciones de dispositivos contienen un sensor de huellas dactilares debajo de la pantalla (UDFPS), estas:

  • [C-SR-11] Se RECOMIENDAN ENCARECIDAMENTE para evitar que el área táctil del UDFPS interfiera con la navegación de 3 botones (que algunos usuarios pueden necesitar por motivos de accesibilidad).

7.3.11. Sensor de postura

Implementaciones de dispositivos:

  • PUEDE admitir sensor de postura con 6 grados de libertad.

Si las implementaciones de dispositivos admiten sensores de postura con 6 grados de libertad,:

  • [C-1-1] DEBE implementar e informar el sensor TYPE_POSE_6DOF .
  • [C-1-2] DEBE ser más preciso que el vector de rotación solo.

7.3.12. Sensor de ángulo de bisagra

Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra,:

7.3.13. IEEE 802.1.15.4 (UWB)

Si las implementaciones del dispositivo incluyen soporte para 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, ellos:

Iniciar nuevos requisitos

  • [C-1-2] debe informar el indicador de la función de hardware android.hardware.uwb .
  • [C-1-3] debe admitir todos los siguientes conjuntos de configuración (combinaciones predefinidas de parámetros FIRA UCI ) definidas en la implementación de AOSP.
    • CONFIG_ID_1 : STATIC STS DS-TWR definido por FIRA Rango, modo diferido, intervalo de alcance 240 ms.
    • CONFIG_ID_2 : STATIC STS DS-TWR , modo diferido, intervalo de rango de 200 ms. Caso de uso típico: el teléfono inteligente interactúa con muchos dispositivos inteligentes.
    • CONFIG_ID_3 : igual que CONFIG_ID_1 , excepto que no se informan los datos de ángulo de llegada (AOA).
    • CONFIG_ID_4 : igual que CONFIG_ID_1 , excepto que el modo de seguridad P-STS está habilitado.
    • CONFIG_ID_5 : igual que CONFIG_ID_2 , excepto que el modo de seguridad P-STS está habilitado.
    • CONFIG_ID_6 : igual que CONFIG_ID_3 , excepto que el modo de seguridad P-STS está habilitado.
    • CONFIG_ID_7 : igual que CONFIG_ID_2 , excepto que el modo de tecla de controle individual P-STS está habilitado.
  • [C-1-4] DEBE proporcionar una opción al usuario que le permita alternar el estado de encendido/apagado de la radio UWB.
  • [C-1-5] Debe aplicar que las aplicaciones que usan la radio UWB tengan el permiso UWB_RANGING (bajo el grupo de permiso NEARBY_DEVICES ).

Pasar las pruebas de conformidad y certificación relevantes definidas por organizaciones estándar, incluidas FIRA , CCC y CSA , ayuda a garantizar las funciones 802.1.15.4 correctamente.

Finalizar los nuevos requisitos

7.4. Conectividad de datos

7.4.1. Telefonía

"Telefonía", según lo utilizado por las API de Android, y este documento se refiere específicamente al hardware relacionado con la colocación de llamadas de voz y el envío de mensajes SMS , o establecer datos móviles a través de una red móvil (p. Ej. GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo que admite "telefonía" puede optar por ofrecer algunas o todos los servicios de llamadas, mensajes y datos como se adapta al producto.

a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes, son para el propósito de Android considerado independiente de cualquier conectividad de datos que pueda implementarse utilizando la misma red. En otras palabras, la funcionalidad y las API de Android se refieren específicamente a llamadas de voz y SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar/recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si utilizan una red celular para la conectividad de datos.

  • Android PUEDE usarse en dispositivos que no incluyen hardware de telefonía. Es decir, Android es compatible con dispositivos que no son teléfonos.

Si las implementaciones de dispositivos incluyen telefonía GSM o CDMA, estos:

  • [C-1-1] DEBE declarar el indicador de función android.hardware.telephony y otros indicadores de subfunciones según la tecnología.
  • [C-1-2] DEBE implementar soporte completo para la API para esa tecnología.
  • DEBE permitir todos los tipos de servicios celulares disponibles (2G, 3G, 4G, 5G, etc.) durante las llamadas de emergencia (independientemente de los tipos de red establecidos por SetAllowedNetworkTypeBitmap() ).

Si las implementaciones de dispositivos no incluyen hardware de telefonía, estas:

  • [C-2-1] DEBE implementar las API completas como no operativas.

Si las implementaciones de dispositivos admiten eUICC o eSIM/SIM integradas e incluyen un mecanismo propietario para que la funcionalidad eSIM esté disponible para desarrolladores externos, ellos:

Si las implementaciones de dispositivos no configuran la propiedad del sistema ro.telephony.iwlan\_operation\_mode en 'legacy', entonces:

Si las implementaciones de dispositivos admiten un único registro de subsistema multimedia IP (IMS) para las funciones del servicio de telefonía multimedia (MMTEL) y del servicio de comunicación enriquecido (RCS) y se espera que cumplan con los requisitos de los operadores de telefonía celular con respecto al uso de un único registro IMS para todo el tráfico de señalización IMS, ellos:

Si las implementaciones de dispositivos informan la función android.hardware.telephony , entonces:

Si las implementaciones del dispositivo informan la función android.hardware.telephony y proporcionan una barra de estado del sistema, entonces:

  • [C-7-1] DEBE seleccionar una suscripción activa representativa para un UUID de grupo determinado para mostrarla al usuario en cualquier prestación que proporcione información sobre el estado de la SIM. Ejemplos de tales posibilidades incluyen el ícono de señal celular de la barra de estado o el mosaico de configuración rápida.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que la suscripción de representante se elija como la suscripción de datos activa , a menos que el dispositivo esté en una llamada de voz, durante la cual se RECOMIENDA ENCARECIDAMENTE que la suscripción de representante sea la suscripción de voz activa.

Si las implementaciones de dispositivos informan la función android.hardware.telephony , entonces:

  • [C-6-7] DEBE ser capaz de abrir y utilizar simultáneamente el número máximo de canales lógicos (20 en total) para cada UICC según ETSI TS 102 221.
  • [C-6-8] NO DEBE aplicar ninguno de los siguientes comportamientos a las aplicaciones de operadores activas (según lo designado por TelephonyManager#getCarrierServicePackageName ) automáticamente o sin la confirmación explícita del usuario:
    • Revocar o limitar el acceso a la red
    • Revocar permisos
    • Restringir la ejecución de aplicaciones en segundo plano o en primer plano más allá de las funciones de administración de energía existentes incluidas en AOSP
    • Deshabilitar o desinstalar la aplicación

Si las implementaciones del dispositivo informan la función android.hardware.telephony y todas las suscripciones activas no oportunistas que comparten un UUID de grupo están deshabilitadas, eliminadas físicamente del dispositivo o marcadas como oportunistas, entonces el dispositivo:

  • [C-8-1] DEBE desactivar automáticamente todas las suscripciones oportunistas activas restantes en el mismo grupo.

Si las implementaciones de dispositivos incluyen telefonía GSM pero no telefonía CDMA, estos:

Si las implementaciones del dispositivo admiten eUICC con múltiples puertos y perfiles,:

7.4.1.1. Compatibilidad con bloqueo de números

Si las implementaciones de dispositivos informan sobre la función android.hardware.telephony.calling ,:

  • [C-1-1] DEBE incluir soporte para bloqueo de números
  • [C-1-2] DEBE implementar completamente BlockedNumberContract y la API correspondiente como se describe en la documentación del SDK.
  • [C-1-3] DEBE bloquear todas las llamadas y mensajes de un número de teléfono en 'BlockedNumberProvider' sin ninguna interacción con las aplicaciones. La única excepción es cuando el bloqueo de números se levanta temporalmente como se describe en la documentación del SDK.

  • [C-1-4] DEBE escribir en el proveedor de registro de llamadas de la plataforma para una llamada bloqueada y DEBE filtrar las llamadas con BLOCKED_TYPE fuera de la vista de registro de llamadas predeterminada en la aplicación de marcador preinstalada.

  • [C-1-5] NO DEBE escribir al proveedor de Telefonía para solicitar un mensaje bloqueado.

  • [C-1-6] DEBE implementar una interfaz de usuario de administración de números bloqueados, que se abre con la intención devuelta por el método TelecomManager.createManageBlockedNumbersIntent() .

  • [C-1-7] NO DEBE permitir que los usuarios secundarios vean o editen los números bloqueados en el dispositivo, ya que la plataforma Android supone que el usuario principal tiene control total de los servicios de telefonía, una sola instancia, en el dispositivo. Toda la interfaz de usuario relacionada con el bloqueo DEBE estar oculta para los usuarios secundarios y aún así DEBE respetarse la lista de bloqueados.

  • DEBE migrar los números bloqueados al proveedor cuando un dispositivo se actualiza a Android 7.0.

  • DEBE proporcionar al usuario la posibilidad de mostrar las llamadas bloqueadas en la aplicación de marcador preinstalada.

7.4.1.2. API de telecomunicaciones

Si las implementaciones de dispositivos informan android.hardware.telephony.calling ,:

  • [C-1-1] DEBE admitir las API ConnectionService descritas en el SDK .
  • [C-1-2] DEBE mostrar una nueva llamada entrante y brindar al usuario la posibilidad de aceptar o rechazar la llamada entrante cuando el usuario está en una llamada en curso realizada por una aplicación de terceros que no admite la función de retención especificada a través de CAPABILITY_SUPPORT_HOLD .
  • [C-1-3] DEBE tener una aplicación que implemente InCallService .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE notificar al usuario que al responder una llamada entrante se cancelará una llamada en curso.

    La implementación de AOSP cumple estos requisitos mediante una notificación de aviso que indica al usuario que responder a una llamada entrante provocará que se corte la otra llamada.

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE precargar la aplicación de marcador predeterminada que muestra una entrada del registro de llamadas y el nombre de una aplicación de terceros en su registro de llamadas cuando la aplicación de terceros configura la tecla extra EXTRA_LOG_SELF_MANAGED_CALLS en su PhoneAccount en true .

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE manejar los eventos KEYCODE_MEDIA_PLAY_PAUSE y KEYCODE_HEADSETHOOK de los auriculares de audio para las API android.telecom como se muestra a continuación:

    • Llame Connection.onDisconnect() cuando se detecte una pulsación breve del evento de tecla durante una llamada en curso.
    • Llame a Connection.onAnswer() cuando se detecte una pulsación breve del evento de tecla durante una llamada entrante.
    • Llame Connection.onReject() cuando se detecte una pulsación prolongada del evento de tecla durante una llamada entrante.
    • Alternar el estado de silencio de CallAudioState .
7.4.1.3. Descarga Keepalive de NAT-T celular

Implementaciones de dispositivos:

  • DEBE incluir soporte para la descarga de Keepalive celular.

Si las implementaciones de dispositivos incluyen soporte para la descarga de Cellular keepalive y exponen la funcionalidad a aplicaciones de terceros,:

  • [C-1-1] DEBE admitir la API SocketKeepAlive.
  • [C-1-2] DEBE admitir al menos una ranura keepalive simultánea a través del celular.
  • [C-1-3] DEBE admitir tantas ranuras de mantenimiento de actividad celular simultáneas como las que admite Cellular Radio HAL.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir al menos tres ranuras de mantenimiento de actividad celular por instancia de radio.

Si las implementaciones de dispositivos no incluyen soporte para la descarga de mantenimiento de actividad celular, estas:

  • [C-2-1] DEBE devolver ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones de dispositivos:

  • DEBE incluir soporte para una o más formas de 802.11.

Si las implementaciones de dispositivos incluyen soporte para 802.11 y exponen la funcionalidad a una aplicación de terceros, ellos:

  • [C-1-1] DEBE implementar la API de Android correspondiente.
  • [C-1-2] DEBE informar el indicador de función de hardware android.hardware.wifi .
  • [C-1-3] DEBE implementar la API de multidifusión como se describe en la documentación del SDK.
  • [C-1-4] debe admitir DNS de multidifusión (MDNS) y no debe filtrar paquetes MDNS (224.0.0.251 o FF02 :: FB ) en cualquier momento de la operación, incluido cuando la pantalla no está en un estado activo, a menos que se caiga o se caiga o El filtrado de estos paquetes es necesario para mantenerse dentro de los rangos de consumo de energía requeridos por los requisitos reglamentarios aplicables al mercado objetivo. Para implementaciones de dispositivos Android Television, incluso en estados de energía en espera.
  • [C-1-5] NO DEBE tratar la llamada al método API WifiManager.enableNetwork() como una indicación suficiente para cambiar la Network actualmente activa que se utiliza de forma predeterminada para el tráfico de aplicaciones y que devuelven los métodos API ConnectivityManager como getActiveNetwork y registerDefaultNetworkCallback . En otras palabras, solo PUEDEN desactivar el acceso a Internet proporcionado por cualquier otro proveedor de red (por ejemplo, datos móviles) si validan con éxito que la red Wi-Fi proporciona acceso a Internet.
  • [C-1-6] Se RECOMIENDA ENCARECIDAMENTE que, cuando se llame al método API ConnectivityManager.reportNetworkConnectivity() , vuelva a evaluar el acceso a Internet en la Network y, una vez que la evaluación determine que la Network actual ya no proporciona acceso a Internet, cambie a cualquier otra red disponible (por ejemplo, datos móviles) que proporcione acceso a Internet.
  • [C-1-7] DEBE aleatorizar la dirección MAC de origen y el número de secuencia de las tramas de solicitud de sonda, una vez al comienzo de cada escaneo, mientras STA está desconectada.
  • [C-1-8] DEBE utilizar una dirección MAC coherente (NO DEBE aleatorizar la dirección MAC a mitad de un análisis).
  • [C-1-9] DEBE iterar el número de secuencia de solicitud de sondeo de forma normal (secuencialmente) entre las solicitudes de sondeo en un escaneo.
  • [C-1-10] DEBE aleatorizar el número de secuencia de solicitud de sonda entre la última solicitud de sonda de un escaneo y la primera solicitud de sonda del siguiente escaneo.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE aleatorizar la dirección MAC de origen utilizada para todas las comunicaciones de STA a un punto de acceso (AP) mientras se asocia y asocia.
    • El dispositivo DEBE utilizar una dirección MAC aleatoria diferente para cada SSID (FQDN para Passpoint) con el que se comunica.
    • El dispositivo DEBE proporcionar al usuario una opción para controlar la aleatorización por SSID (FQDN para Passpoint) con opciones aleatorias y no aleatorias, y DEBE configurar el modo predeterminado para que las nuevas configuraciones de Wi-Fi sean aleatorias.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE utilizar un BSSID aleatorio para cualquier AP que creen.
    • La dirección MAC DEBE ser aleatoria y persistente según el SSID utilizado por el AP.
    • El DISPOSITIVO PUEDE proporcionar al usuario una opción para desactivar esta función. Si se proporciona dicha opción, la aleatorización DEBE estar habilitada de forma predeterminada.

Si las implementaciones de dispositivos incluyen soporte para el modo de ahorro de energía Wi-Fi como se define en el estándar IEEE 802.11,:

  • DEBE desactivar el modo de ahorro de energía de Wi-Fi siempre que una aplicación adquiera el bloqueo WIFI_MODE_FULL_HIGH_PERF o el bloqueo WIFI_MODE_FULL_LOW_LATENCY a través de las API WifiManager.createWifiLock() y WifiManager.WifiLock.acquire() y el bloqueo esté activo.
  • [C-3-2] La latencia promedio de ida y vuelta entre el dispositivo y un punto de acceso mientras el dispositivo está en modo de bloqueo de baja latencia de Wi-Fi ( WIFI_MODE_FULL_LOW_LATENCY ) DEBE ser menor que la latencia durante un bloqueo de alto rendimiento de Wi-Fi ( modo WIFI_MODE_FULL_HIGH_PERF ).
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere y entra en vigor un bloqueo de baja latencia ( WIFI_MODE_FULL_LOW_LATENCY ).

Si las implementaciones de dispositivos admiten Wi-Fi y usan Wi-Fi para escanear la ubicación,:

7.4.2.1. Wi-Fi directo

Implementaciones de dispositivos:

  • DEBE incluir soporte para Wi-Fi Direct (Wi-Fi peer-to-peer).

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Direct,:

  • [C-1-1] DEBE implementar la API de Android correspondiente como se describe en la documentación del SDK.
  • [C-1-2] DEBE informar la función de hardware android.hardware.wifi.direct .
  • [C-1-3] DEBE admitir el funcionamiento normal de Wi-Fi.
  • [C-1-4] DEBE admitir operaciones Wi-Fi y Wi-Fi Direct simultáneamente.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE aleatorizar la dirección MAC de origen para todas las conexiones Wi-Fi Direct recién formadas.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para TDLS y TDLS está habilitado por la API WiFiManager, ellos:

  • [C-1-1] DEBE declarar soporte para TDLS a través de WifiManager.isTdlsSupported .
  • DEBE usar TDLS solo cuando sea posible Y beneficioso.
  • DEBE tener algo de heurística y NO usar TDLS cuando su rendimiento podría ser peor que a través del punto de acceso Wi-Fi.
7.4.2.3. Compatible con Wi-Fi

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Aware y exponen la funcionalidad a aplicaciones de terceros, entonces:

  • [C-1-1] DEBE implementar las API WifiAwareManager como se describe en la documentación del SDK .
  • [C-1-2] DEBE declarar el indicador de función android.hardware.wifi.aware .
  • [C-1-3] DEBE admitir operaciones Wi-Fi y Wi-Fi Aware simultáneamente.
  • [C-1-4] DEBE aleatorizar la dirección de la interfaz de administración de Wi-Fi Aware en intervalos no superiores a 30 minutos y siempre que Wi-Fi Aware esté habilitado, a menos que esté en curso una operación de rango de Aware o que una ruta de datos de Aware esté activa (la aleatorización es no se espera mientras la ruta de datos esté activa).

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Aware y Wi-Fi Location como se describe en la Sección 7.4.2.5 y exponen estas funcionalidades a aplicaciones de terceros, entonces:

7.4.2.4. Punto de acceso Wi-Fi

Si las implementaciones de dispositivos incluyen soporte para 802.11 (Wi-Fi), ellos:

  • [C-1-1] DEBE incluir soporte para Wi-Fi Passpoint .
  • [C-1-2] DEBE implementar las API WifiManager relacionadas con Passpoint como se describe en la documentación del SDK .
  • [C-1-3] DEBE admitir el estándar IEEE 802.11u, específicamente relacionado con el descubrimiento y selección de redes, como el servicio de publicidad genérica (GAS) y el protocolo de consulta de red de acceso (ANQP).
  • [C-1-4] DEBE declarar el indicador de función android.hardware.wifi.passpoint .
  • [C-1-5] DEBE seguir la implementación de AOSP para descubrir, hacer coincidir y asociarse a redes Passpoint.
  • [C-1-6] DEBE admitir al menos el siguiente subconjunto de protocolos de aprovisionamiento de dispositivos según se define en Wi-Fi Alliance Passpoint R2: autenticación EAP-TTLS y SOAP-XML.
  • [C-1-7] DEBE procesar el certificado del servidor AAA como se describe en la especificación Hotspot 2.0 R3.
  • [C-1-8] DEBE admitir el control del usuario sobre el aprovisionamiento a través del selector de Wi-Fi.
  • [C-1-9] DEBE mantener las configuraciones de Passpoint persistentes durante los reinicios.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE respaldar la función de aceptación de términos y condiciones.
  • [C-SR-2] Se RECOMIENDAN ENCARECIDAMENTE para respaldar la función de información del lugar.

Si se proporciona un interruptor de control de usuario de desactivación de punto de acceso global, las implementaciones:

  • [C-3-1] DEBE habilitar Passpoint de forma predeterminada.
7.4.2.5. Ubicación de Wi-Fi (tiempo de ida y vuelta de Wi-Fi - RTT)

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para ubicación Wi-Fi y exponen la funcionalidad a aplicaciones de terceros, entonces:

  • [C-1-1] DEBE implementar las API WifiRttManager como se describe en la documentación del SDK .
  • [C-1-2] DEBE declarar el indicador de función android.hardware.wifi.rtt .
  • [C-1-3] DEBE aleatorizar la dirección MAC de origen para cada ráfaga de RTT que se ejecuta mientras la interfaz Wi-Fi en la que se ejecuta el RTT no está asociada a un punto de acceso.
  • [C-1-4] DEBE tener una precisión de 2 metros con un ancho de banda de 80 MHz en el percentil 68 (calculado con la función de distribución acumulativa).
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE informarlo con precisión dentro de 1,5 metros con un ancho de banda de 80 MHz en el percentil 68 (calculado con la función de distribución acumulativa).
7.4.2.6. Descarga de Wi-Fi Keepalive

Implementaciones de dispositivos:

  • DEBE incluir soporte para la descarga de Wi-Fi keepalive.

Si las implementaciones de dispositivos incluyen soporte para la descarga de Wi-Fi keepalive y exponen la funcionalidad a aplicaciones de terceros,:

  • [C-1-1] DEBE admitir la API SocketKeepAlive .
  • [C-1-2] debe admitir al menos tres ranuras de Keepalive concurrentes sobre Wi-Fi

Si las implementaciones de dispositivos no incluyen soporte para la descarga de Wi-Fi keepalive,:

7.4.2.7. Wi-Fi Easy Connect (Protocolo de aprovisionamiento de dispositivos)

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Easy Connect y exponen la funcionalidad a aplicaciones de terceros, estos:

7.4.2.8. Validación del certificado del servidor Wi-Fi empresarial

Si el certificado del servidor Wi-Fi no está validado o el nombre de dominio del servidor Wi-Fi no está configurado, las implementaciones del dispositivo:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE no brindar al usuario la opción de agregar manualmente la red Wi-Fi empresarial en la aplicación Configuración.
7.4.2.9. Confianza en el primer uso (TOFU)

Si las implementaciones de dispositivos admiten Confianza en el primer uso (TOFU) y permiten al usuario definir configuraciones WPA/WPA2/WPA3-Enterprise, entonces:

  • [C-4-1] DEBE proporcionar al usuario una opción para seleccionar el uso de TOFU.

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth,:

  • Debe admitir códecs de audio avanzados y códecs de audio Bluetooth (por ejemplo, LDAC)

Si las implementaciones de dispositivos admiten HFP, A2DP y AVRCP,:

  • DEBE admitir al menos 5 dispositivos conectados en total.

Si las implementaciones de dispositivos declaran la característica android.hardware.vr.high_performance , estas:

  • [C-1-1] DEBE admitir Bluetooth 4.2 y extensión de longitud de datos Bluetooth LE.

Android incluye soporte para Bluetooth y Bluetooth Low Energy .

Si las implementaciones de dispositivos incluyen soporte para Bluetooth y Bluetooth Low Energy,:

  • [C-2-1] DEBE declarar las características relevantes de la plataforma ( android.hardware.bluetooth y android.hardware.bluetooth_le respectivamente) e implementar las API de la plataforma.
  • DEBE implementar perfiles Bluetooth relevantes como A2DP, AVRCP, OBEX, HFP, etc., según corresponda para el dispositivo.

Si las implementaciones de dispositivos incluyen soporte para Bluetooth Low Energy (BLE), ellos:

  • [C-3-1] DEBE declarar la función de hardware android.hardware.bluetooth_le .
  • [C-3-2] DEBE habilitar las API de Bluetooth basadas en GATT (perfil de atributos genéricos) como se describe en la documentación del SDK y android.bluetooth .
  • [C-3-3] DEBE informar el valor correcto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar si se implementa la lógica de filtrado para las clases de API ScanFilter .
  • [C-3-4] DEBE informar el valor correcto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo de energía.
  • [C-3-5] DEBE implementar un tiempo de espera de dirección privada resoluble (RPA) de no más de 15 minutos y rotar la dirección en el tiempo de espera para proteger la privacidad del usuario cuando el dispositivo esté usando activamente BLE para escaneo o publicidad. Para evitar ataques de tiempo, los intervalos de tiempo de espera también DEBEN ser aleatorios entre 5 y 15 minutos.

  • DEBE admitir la descarga de la lógica de filtrado al chipset bluetooth al implementar la API ScanFilter .

  • DEBE admitir la descarga del escaneo por lotes al chipset bluetooth.

  • DEBE admitir publicidad múltiple con al menos 4 espacios.

Si las implementaciones de dispositivos admiten Bluetooth LE y utilizan Bluetooth LE para escanear la ubicación,:

  • [C-4-1] DEBE proporcionar al usuario la posibilidad de habilitar/deshabilitar el valor leído a través de la API del sistema BluetoothAdapter.isBleScanAlwaysAvailable() .

Si las implementaciones de dispositivos incluyen soporte para Bluetooth LE y perfil de audífonos, como se describe en Soporte de audio para audífonos mediante Bluetooth LE , ellos:

Si las implementaciones de dispositivos incluyen soporte para Bluetooth o Bluetooth Low Energy,:

  • [C-6-1] DEBE restringir el acceso a cualquier metadato de Bluetooth (como los resultados del escaneo) que podría usarse para derivar la ubicación del dispositivo, a menos que la aplicación solicitante pase con éxito una verificación de permiso android.permission.ACCESS_FINE_LOCATION basada en su actual estado de primer plano/fondo.

Si las implementaciones del dispositivo incluyen soporte para Bluetooth o Bluetooth Low Energy y el manifiesto de la aplicación no incluye una declaración del desarrollador que indique que no están derivando la ubicación de Bluetooth, entonces:

Si las implementaciones de dispositivos devuelven true para la API BluetoothAdapter.isLeAudioSupported() , entonces:

  • [C-7-1] DEBE admitir cliente de unidifusión.
  • [C-7-2] DEBE admitir 2M PHY.
  • [C-7-3] DEBE admitir publicidad extendida LE.
  • [C-7-4] DEBE admitir al menos 2 conexiones CIS en un CIG.
  • [C-7-5] DEBE habilitar el cliente de unidifusión BAP, el coordinador del conjunto CSIP, el servidor MCP, el controlador VCP y el servidor CCP simultáneamente.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE habilitar el cliente de unidifusión HAP.

Si las implementaciones de dispositivos devuelven true para la API BluetoothAdapter.isLeAudioBroadcastSourceSupported() , entonces:

  • [C-8-1] DEBE admitir al menos 2 enlaces BIS en un BIG.
  • [C-8-2] DEBE habilitar la fuente de transmisión BAP y el asistente de transmisión BAP simultáneamente.
  • [C-8-3] DEBE admitir publicidad periódica LE.

Si las implementaciones de dispositivos devuelven true para la API BluetoothAdapter.isLeAudioBroadcastAssistantSupported() , entonces:

  • [C-9-1] DEBE admitir PAST (Transferencia periódica de sincronización de publicidad).
  • [C-9-2] DEBE admitir publicidad periódica LE.

Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE , ellas:

  • [C-10-1] DEBE que las mediciones RSSI estén dentro de +/-9 dB para el 95 % de las mediciones a 1 m de distancia de un dispositivo de referencia que transmita a ADVERTISE_TX_POWER_HIGH en un entorno de línea de visión.
  • [C-10-2] DEBE incluir correcciones Rx/Tx para reducir las desviaciones por canal de modo que las mediciones en cada uno de los 3 canales, en cada una de las antenas (si se utilizan varias), estén dentro de +/-3 dB de uno otro para el 95% de las mediciones.

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE medir y compensar la compensación de Rx para garantizar que el RSSI BLE medio sea -60 dBm +/-10 dB a 1 m de distancia de un dispositivo de referencia que transmite en ADVERTISE_TX_POWER_HIGH , donde los dispositivos están orientados de manera que estén en 'planos paralelos' con pantallas orientadas en la misma dirección.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE medir y compensar la compensación de Tx para garantizar que el RSSI BLE medio sea -60 dBm +/-10 dB cuando se escanea desde un dispositivo de referencia colocado a 1 m de distancia y se transmite en ADVERTISE_TX_POWER_HIGH , donde los dispositivos están orientados. de modo que estén en "planos paralelos" con pantallas orientadas en la misma dirección.

Iniciar nuevos requisitos

  • [C-10-3] debe medir y compensar el desplazamiento de RX para garantizar que la mediana de RSSI BLSI sea -55dbm +/- 10 dB a 1 m de distancia desde un dispositivo de referencia que transmite en ADVERTISE_TX_POWER_HIGH .
  • [C-10-4] debe medir y compensar el desplazamiento de TX para garantizar que la mediana de RSSI BLSI sea -55dbm +/- 10 dB al escanear desde un dispositivo de referencia colocado a una distancia de 1 m y transmitir a ADVERTISE_TX_POWER_HIGH .

Finalizar los nuevos requisitos

Se recomienda encarecidamente seguir los pasos de configuración de medición especificados en los requisitos de calibración de presencia .

Si las implementaciones de dispositivos admiten la versión 5.0 de Bluetooth, entonces:

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE brindar soporte para:
    • LE 2M FÍSICO
    • Códec LE PHY
    • Extensión de publicidad LE
    • Publicidad periódica
    • Al menos 10 conjuntos de anuncios.
    • Al menos 8 conexiones LE simultáneas. Cada conexión puede tener cualquiera de los roles de topología de conexión.
    • Privacidad de la capa de enlace LE
    • Un tamaño de "lista de resolución" de al menos 8 entradas

7.4.4. Comunicaciones de campo cercano

Implementaciones de dispositivos:

  • DEBE incluir un transceptor y hardware relacionado para comunicaciones de campo cercano (NFC).
  • [C-0-1] DEBE implementar las API android.nfc.NdefMessage y android.nfc.NdefRecord incluso si no incluyen soporte para NFC o declaran la función android.hardware.nfc ya que las clases representan un formato de representación de datos independiente del protocolo .

Si las implementaciones de dispositivos incluyen hardware NFC y planean ponerlo a disposición de aplicaciones de terceros, ellos:

  • [C-1-1] 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:
  • [C-1-2] DEBE ser capaz de actuar como lector/escritor de NFC Forum (según lo definido por la especificación técnica de NFC Forum NFCForum-TS-DigitalProtocol-1.0) a través de los siguientes estándares NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NFCF (JIS X 6319-4)
    • ISODep (ISO 14443-4)
    • Tipos de etiquetas del Foro NFC 1, 2, 3, 4, 5 (definidas por el Foro NFC)
  • [C-SR-1] RECOMIENDA ENCARECIDAMENTE ser capaz de leer y escribir mensajes NDEF, así como datos sin procesar a través de los siguientes estándares NFC. Tenga en cuenta que, si bien los estándares NFC se indican como MUY RECOMENDADOS, se prevé que la Definición de compatibilidad para una versión futura los cambie a DEBE. Estos estándares son opcionales en esta versión pero serán necesarios en versiones futuras. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan esta versión de Android cumplan con estos requisitos ahora para que puedan actualizarse a futuras versiones de la plataforma.

  • [C-1-13] DEBE sondear todas las tecnologías compatibles mientras se encuentra en el modo de descubrimiento NFC.

  • DEBE estar en modo de descubrimiento NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.

  • DEBE ser capaz de leer el código de barras y la URL (si está codificada) de los productos Thinfilm NFC Barcode .

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

Android incluye soporte para el modo de emulación de tarjeta host NFC (HCE).

Si las implementaciones de dispositivos incluyen un chipset controlador NFC capaz de HCE (para NfcA y/o NfcB) y admiten enrutamiento de ID de aplicación (AID), estos:

  • [C-2-1] DEBE informar la constante de característica android.hardware.nfc.hce .
  • [C-2-2] DEBE admitir las API NFC HCE como se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen un chipset controlador NFC capaz de HCE para NfcF e implementan la función para aplicaciones de terceros, estos:

  • [C-3-1] DEBE informar la constante de característica android.hardware.nfc.hcef .
  • [C-3-2] DEBE implementar las API de emulación de tarjetas NfcF tal como se definen en el SDK de Android.

Si las implementaciones de dispositivos incluyen soporte NFC general como se describe en esta sección y admiten tecnologías MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF en MIFARE Classic) en la función de lector/escritor,:

  • [C-4-1] DEBE implementar las API de Android correspondientes según lo documentado en el SDK de Android.
  • [C-4-2] DEBE informar la función com.nxp.mifare del método android.content.pm.PackageManager.hasSystemFeature () . Tenga en cuenta que esta no es una característica estándar de Android y, como tal, no aparece como una constante en la clase android.content.pm.PackageManager .

7.4.5. Protocolos de red y API

7.4.5.1. Capacidad mínima de red

Implementaciones de dispositivos:

  • [C-0-1] DEBE incluir soporte para una o más formas de redes de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir soporte para al menos un estándar de datos capaz de 200 Kbit/seg o más. Ejemplos de tecnologías que satisfacen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet y Bluetooth PAN.
  • También DEBE incluir soporte para al menos un estándar de datos inalámbrico común, como 802.11 (Wi-Fi), cuando un estándar de red física (como Ethernet) es la conexión de datos principal.
  • PUEDE implementar más de una forma de conectividad de datos.
7.4.5.2. IPv6

Implementaciones de dispositivos:

  • [C-0-2] DEBE incluir una pila de redes IPv6 y admitir la comunicación IPv6 mediante las API administradas, como java.net.Socket y java.net.URLConnection , así como las API nativas, como los sockets AF_INET6 .
  • [C-0-3] DEBE habilitar IPv6 de forma predeterminada.
    • DEBE garantizar que la comunicación IPv6 sea tan confiable como IPv4, por ejemplo:
      • [C-0-4] DEBE mantener la conectividad IPv6 en modo dormido.
      • [C-0-5] La limitación de velocidad NO DEBE hacer que el dispositivo pierda la conectividad IPv6 en cualquier red compatible con IPv6 que utilice una vida útil de RA de al menos 180 segundos.
  • [C-0-6] DEBE proporcionar aplicaciones de terceros con conectividad IPv6 directa a la red cuando se conecta a una red IPv6, sin que se produzca ningún tipo de traducción de dirección o puerto localmente en el dispositivo. Tanto las API administradas como Socket#getLocalAddress o Socket#getLocalPort ) como las API de NDK como getsockname() o IPV6_PKTINFO DEBEN devolver la dirección IP y el puerto que realmente se utilizan para enviar y recibir paquetes en la red y que son visibles como la IP de origen y puerto a servidores de Internet (web).

El nivel requerido de compatibilidad con IPv6 depende del tipo de red, como se muestra en los siguientes requisitos.

Si las implementaciones de dispositivos admiten Wi-Fi,:

  • [C-1-1] DEBE admitir el funcionamiento de doble pila y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos admiten Ethernet,:

  • [C-2-1] DEBE admitir la operación de doble pila y solo IPv6 en Ethernet.

Si las implementaciones de dispositivos admiten datos móviles, estos:

  • [C-3-1] DEBE admitir la operación IPv6 (solo IPv6 y posiblemente de doble pila) en dispositivos móviles.

Si las implementaciones de dispositivos admiten más de un tipo de red (por ejemplo, Wi-Fi y datos móviles), estas:

  • [C-4-1] DEBE cumplir simultáneamente los requisitos anteriores en cada red cuando el dispositivo esté conectado simultáneamente a más de un tipo de red.
7.4.5.3. Portales cautivos

Un portal cautivo se refiere a una red que requiere iniciar sesión para obtener acceso a Internet.

Si las implementaciones de dispositivos proporcionan una implementación completa de la android.webkit.Webview API , estas:

  • [C-1-1] DEBE proporcionar una aplicación de portal cautivo para manejar la intención ACTION_CAPTIVE_PORTAL_SIGN_IN y mostrar la página de inicio de sesión del portal cautivo, enviando esa intención, al llamar a la API del sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle) .
  • [C-1-2] DEBE realizar la detección de portales cautivos y admitir el inicio de sesión a través de la aplicación del portal cautivo cuando el dispositivo está conectado a cualquier tipo de red, incluida la red celular/móvil, WiFi, Ethernet o Bluetooth.
  • [C-1-3] DEBE admitir el inicio de sesión en portales cautivos utilizando DNS de texto sin formato cuando el dispositivo está configurado para usar el modo estricto de DNS privado.
  • [C-1-4] DEBE utilizar DNS cifrado según la documentación del SDK para android.net.LinkProperties.getPrivateDnsServerName y android.net.LinkProperties.isPrivateDnsActive para todo el tráfico de red que no se comunica explícitamente con el portal cautivo.
  • [C-1-5] DEBE garantizar que, mientras el usuario inicia sesión en un portal cautivo, la red predeterminada utilizada por las aplicaciones (según lo devuelto por ConnectivityManager.getActiveNetwork , ConnectivityManager.registerDefaultNetworkCallback y utilizado de forma predeterminada por las API de red de Java, como java.net.Socket y API nativas como connect()) es cualquier otra red disponible que proporcione acceso a Internet, si está disponible.

7.4.6. Configuración de sincronización

Implementaciones de dispositivos:

  • [C-0-1] DEBE tener la configuración de sincronización automática maestra activada de forma predeterminada para que el método getMasterSyncAutomatically() devuelva "verdadero".

7.4.7. Ahorro de datos

Si las implementaciones de dispositivos incluyen una conexión medida, son:

  • [C-SR-1] RECOMENDAMOS ENCARECIDAMENTE proporcionar el modo de ahorro de datos.

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos,:

  • [C-1-1] DEBE admitir todas las API de la clase ConnectivityManager como se describe en la documentación del SDK

Si las implementaciones de dispositivos no proporcionan el modo de ahorro de datos,:

7.4.8. Elementos seguros

Si las implementaciones de dispositivos admiten elementos seguros compatibles con Open Mobile API y los ponen a disposición de aplicaciones de terceros,:

7.4.9. UWB

Si las implementaciones de dispositivos incluyen soporte para 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, entonces:

  • [C-1-1] DEBE implementar la API de Android correspondiente en android.uwb.
  • [C-1-2] DEBE informar el indicador de función de hardware android.hardware.uwb.
  • [C-1-3] DEBE admitir todos los perfiles UWB relevantes definidos en la implementación de Android.
  • [C-1-4] DEBE proporcionar una opción al usuario que le permita alternar el estado de encendido/apagado de la radio UWB.
  • [C-1-5] DEBE exigir que las aplicaciones que usan radio UWB tengan el permiso UWB_RANGING (en el grupo de permisos NEARBY_DEVICES).
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE pasar las pruebas de certificación y conformidad pertinentes definidas por organizaciones de normalización, incluidas FIRA , CCC y CSA .
  • [C-1-6] DEBE garantizar que las mediciones de distancia estén dentro de +/-15 cm para el 95 % de las mediciones en el entorno de la línea de visión a 1 m de distancia en una cámara no reflectante.
  • [C-1-7] debe garantizar que la mediana de las mediciones de distancia a 1 m desde el dispositivo de referencia esté dentro de [0.75m, 1.25m], donde la distancia de la verdad del suelo se mide desde el borde superior del DUT. mantenido boca arriba e inclinado 45 grados.
  • [C-SR-2] se recomienda encarecidamente seguir los pasos de configuración de medición especificados en los requisitos de calibración de presencia .

7.5. Cámaras

Si las implementaciones de dispositivos incluyen al menos una cámara, estas:

  • [C-1-1] DEBE declarar el indicador de característica android.hardware.camera.any .
  • [C-1-2] DEBE ser posible que una aplicación asigne simultáneamente 3 mapas de bits RGBA_8888 iguales al tamaño de las imágenes producidas por el sensor de cámara de mayor resolución del dispositivo, mientras la cámara está abierta para fines de vista previa básica y fotografía fija. captura.
  • [C-1-3] DEBE garantizar que la aplicación de cámara predeterminada preinstalada que maneja los intents MediaStore.ACTION_IMAGE_CAPTURE , MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE sea responsable de eliminar la ubicación del usuario en los metadatos de la imagen antes de enviarla a la aplicación receptora cuando La aplicación receptora no tiene ACCESS_FINE_LOCATION .

Si las implementaciones de dispositivos admiten la capacidad de salida HDR de 10 bits, entonces:

  • [C-2-1] DEBE admitir al menos el perfil HLG HDR para cada dispositivo de cámara que admita salida de 10 bits.
  • [C-2-2] DEBE admitir una salida de 10 bits para la cámara principal orientada hacia atrás o hacia la cámara frontal principal.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir salida de 10 bits para ambas cámaras principales.
  • [C-2-3] DEBE admitir los mismos perfiles HDR para todas las subcámaras físicas compatibles con BACKWARD_COMPATIBLE de una cámara lógica y para la propia cámara lógica.

Para los dispositivos de cámara lógica que admiten HDR de 10 bits e implementan la API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO , estos:

  • [C-3-1] DEBE admitir el cambio entre todas las cámaras físicas compatibles con versiones anteriores a través del control CONTROL_ZOOM_RATIO en la cámara lógica.

7.5.1. Cámara trasera

Una cámara trasera es una cámara ubicada en el lado del dispositivo opuesto a la pantalla; es decir, captura escenas en el lado opuesto del dispositivo, como una cámara tradicional.

Iniciar nuevos requisitos

Una cámara trasera es una cámara orientada al mundo que imagina escenas en el otro lado del dispositivo, como una cámara tradicional; En dispositivos portátiles, esa es una cámara ubicada en el lado del dispositivo opuesto a la pantalla.

Finalizar los nuevos requisitos

Implementaciones de dispositivos:

  • DEBE incluir una cámara trasera.

Si las implementaciones de dispositivos incluyen al menos una cámara trasera, estas:

  • [C-1-1] DEBE informar el indicador de función android.hardware.camera y android.hardware.camera.any .
  • [C-1-2] DEBE tener una resolución de al menos 2 megapíxeles.
  • DEBE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara (transparente al software de la aplicación).
  • PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
  • PUEDE incluir un flash.

Si la cámara incluye flash:

  • [C-2-1] la lámpara del flash NO DEBE estar encendida mientras se haya registrado 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 . Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara integrada del sistema del dispositivo, sino solo a aplicaciones de terceros que utilizan Camera.PreviewCallback .

7.5.2. Cámara frontal

Una cámara frontal es una cámara ubicada en el mismo lado del dispositivo que la pantalla; es decir, una cámara que normalmente se utiliza para tomar imágenes del usuario, como por ejemplo para videoconferencias y aplicaciones similares.

Iniciar nuevos requisitos

Una cámara frontal es una cámara orientada al usuario que generalmente se usa para obtener imágenes del usuario, como para videoconferencias y aplicaciones similares; En dispositivos portátiles, esa es una cámara ubicada en el mismo lado del dispositivo que la pantalla.

Finalizar los nuevos requisitos

Implementaciones de dispositivos:

  • PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, estas:

  • [C-1-1] DEBE informar el indicador de función android.hardware.camera.any y android.hardware.camera.front .
  • [C-1-2] DEBE tener una resolución de al menos VGA (640x480 píxeles).
  • [C-1-3] NO DEBE usar una cámara frontal como predeterminada para la API de cámara y NO DEBE configurar la API para tratar una cámara frontal como la cámara trasera predeterminada, incluso si es la única cámara en el dispositivo.
  • [C-1-4] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación especificada por la aplicación cuando la aplicación actual ha solicitado explícitamente que la pantalla de la cámara se gire mediante una llamada al método android.hardware.Camera.setDisplayOrientation() . Por el contrario, la vista previa DEBE reflejarse a lo largo del eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicita explícitamente que se gire la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation() .
  • [C-1-5] NO DEBE reflejar la imagen fija capturada final o las transmisiones de video devueltas a las devoluciones de llamada de la aplicación o comprometidas con el almacenamiento de medios.
  • [C-1-6] DEBE reflejar la imagen mostrada por la vista posterior de la misma manera que la secuencia de imágenes de vista previa de la cámara.
  • PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras orientadas hacia atrás como se describe en la sección 7.5.1 .

Si el usuario puede girar las implementaciones del dispositivo (por ejemplo, automáticamente mediante un acelerómetro o manualmente mediante la entrada del usuario):

  • [C-2-1] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.

7.5.3. Cámara externa

Iniciar nuevos requisitos

Una cámara externa es una cámara que se puede conectar o separarse físicamente de la implementación del dispositivo en cualquier momento y puede enfrentar cualquier dirección; como cámaras USB.

Finalizar los nuevos requisitos

Implementaciones de dispositivos:

  • PUEDE incluir soporte para una cámara externa que no necesariamente está siempre conectada.

Si las implementaciones de dispositivos incluyen soporte para una cámara externa,:

  • [C-1-1] DEBE declarar el indicador de función de la plataforma android.hardware.camera.external y android.hardware camera.any .
  • [C-1-2] DEBE admitir clase de video USB (UVC 1.0 o superior) si la cámara externa se conecta a través del puerto host USB.
  • [C-1-3] DEBE pasar las pruebas CTS de la cámara con un dispositivo de cámara externo físico conectado. Los detalles de las pruebas de la cámara CTS están disponibles en source.android.com .
  • DEBE admitir compresiones de vídeo como MJPEG para permitir la transferencia de flujos no codificados de alta calidad (es decir, flujos de imágenes sin formato o comprimidos de forma independiente).
  • PUEDE admitir múltiples cámaras.
  • PUEDE admitir codificación de video basada en cámara.

Si se admite la codificación de vídeo basada en cámara:

  • [C-2-1] Una secuencia simultánea sin codificar/MJPEG (QVGA o mayor resolución) DEBE ser accesible para la implementación del dispositivo.

7.5.4. Comportamiento de la API de la cámara

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

El paquete API anterior, android.hardware.Camera , está marcado como obsoleto en Android 5.0, pero aún debería estar disponible para que lo utilicen las aplicaciones. Las implementaciones de dispositivos Android DEBEN garantizar el soporte continuo de la API como se describe en esta sección y en el SDK de Android.

Todas las características que son comunes entre la clase obsoleta android.hardware.Camera y el paquete android.hardware.camera2 más nuevo DEBEN tener un rendimiento y una calidad equivalentes en ambas API. Por ejemplo, con configuraciones equivalentes, la velocidad y precisión del enfoque automático deben ser idénticas y la calidad de las imágenes capturadas debe ser la misma. No es necesario que las características que dependen de las diferentes semánticas de las dos API tengan una velocidad o calidad coincidentes, pero DEBEN coincidir lo más posible.

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

  • [C-0-1] DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para obtener una vista previa de los datos proporcionados a las devoluciones de llamada de la aplicación cuando una aplicación nunca ha llamado a android.hardware.Camera.Parameters.setPreviewFormat(int) .
  • [C-0-2] DEBE además estar en el formato de codificación NV21 cuando una aplicación registra una instancia android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() y el formato de vista previa es YCbCr_420_SP, los datos en el byte[ ] pasó onPreviewFrame() . Es decir, NV21 DEBE ser el predeterminado.
  • [C-0-3] DEBE admitir el formato YV12 (como lo indica la constante android.graphics.ImageFormat.YV12 ) para vistas previas de cámara tanto para cámaras frontales como traseras para android.hardware.Camera . (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxel nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
  • [C-0-4] DEBE admitir los formatos android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como salidas a través de la API android.media.ImageReader para dispositivos android.hardware.camera2 que anuncian la capacidad REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities .
  • [C-0-5] DEBE implementar la API de cámara completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático por hardware u otras capacidades. Por ejemplo, las cámaras que carecen de enfoque automático DEBEN llamar a cualquier instancia registrada android.hardware.Camera.AutoFocusCallback (aunque esto no tiene relevancia para una cámara sin enfoque automático). Tenga en cuenta que esto se aplica a las cámaras frontales; por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API deben ser "falsificadas" como se describe.
  • [C-0-6] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters y la clase android.hardware.camera2.CaptureRequest . 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 aquellas documentadas como constantes en android.hardware.Camera.Parameters . Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de cámara estándar si el hardware lo permite, y NO DEBEN admitir tipos de parámetros de cámara personalizados. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes utilizando técnicas de imágenes de alto rango dinámico (HDR) DEBEN admitir el parámetro de la cámara Camera.SCENE_MODE_HDR .
  • [C-0-7] DEBE informar el nivel adecuado de soporte con la propiedad android.info.supportedHardwareLevel como se describe en el SDK de Android e informar los indicadores de características del marco apropiados.
  • [C-0-8] También DEBE declarar las capacidades de la cámara individual de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar los indicadores de funciones apropiados; DEBE definir el indicador de función si alguno de sus dispositivos de cámara conectados admite la función.
  • [C-0-9] DEBE transmitir la intención Camera.ACTION_NEW_PICTURE cada vez que la cámara toma una nueva imagen y la entrada de la imagen se agrega al almacén de medios.
  • [C-0-10] DEBE transmitir la intención Camera.ACTION_NEW_VIDEO cada vez que la cámara graba un nuevo video y la entrada de la imagen se agrega al almacén multimedia.
  • [C-0-11] DEBE tener todas las cámaras accesibles a través de la API android.hardware.Camera obsoleta y también accesible a través de la API android.hardware.camera2 .
  • [C-0-12] DEBE garantizar que la apariencia facial NO se altere, lo que incluye, entre otros, la alteración de la geometría facial, el tono de la piel del rostro o el suavizado de la piel del rostro para cualquier API android.hardware.camera2 o android.hardware.Camera .
  • [C-SR-1] Para dispositivos con múltiples cámaras RGB en las proximidades y la cara en la misma dirección, se recomienda compatible con un dispositivo de cámara lógico que enumera la capacidad de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA , que consiste en todas las cámaras RGB en esa dirección como subdevicios físicos.

Si las implementaciones de dispositivos proporcionan una API de cámara patentada para aplicaciones de terceros, estas:

7.5.5. Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o trasera, dichas cámaras:

  • [C-1-1] DEBE estar orientado 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 sostiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo; es decir, se aplica tanto a dispositivos primarios horizontales como a dispositivos primarios verticales.

Los dispositivos que cumplan con todos los criterios siguientes están exentos del requisito anterior:

  • El dispositivo implementa pantallas de geometría variable, como pantallas plegables o con bisagras.
  • Cuando cambia el estado de plegado o bisagra del dispositivo, el dispositivo cambia entre la orientación vertical primaria y horizontal primaria (o viceversa).

Iniciar nuevos requisitos

  • Implementaciones de dispositivos que no son capaces de ser rotadas por el usuario, como los dispositivos automotrices.

Finalizar los nuevos requisitos

7.6. Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Implementaciones de dispositivos:

  • [C-0-1] DEBE incluir un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos y DEBEN ser capaces de descargar archivos individuales de al menos 100 MB de tamaño a la ubicación de "caché" predeterminada.

7.6.2. Almacenamiento compartido de aplicaciones

Implementaciones de dispositivos:

  • [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, también denominado a menudo "almacenamiento externo compartido", "almacenamiento compartido de aplicaciones" o por la ruta de Linux "/sdcard" en la que está montado.
  • [C-0-2] DEBE configurarse con almacenamiento compartido montado de forma predeterminada, en otras palabras, "listo para usar", independientemente de si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (por ejemplo, ranura para tarjeta Secure Digital). ).
  • [C-0-3] DEBE montar el almacenamiento compartido de la aplicación directamente en la sdcard SD de la ruta de Linux o incluir un enlace simbólico de Linux desde sdcard hasta el punto de montaje real.
  • [C-0-4] DEBE habilitar el almacenamiento con alcance de forma predeterminada para todas las aplicaciones orientadas al nivel API 29 o superior, excepto en la siguiente situación:
    • Cuando la aplicación ha solicitado android:requestLegacyExternalStorage="true" en su manifiesto.
  • [C-0-5] DEBE redactar metadatos de ubicación, como etiquetas GPS Exif, almacenados en archivos multimedia cuando se accede a esos archivos a través de MediaStore , excepto cuando la aplicación que llama tiene el permiso ACCESS_MEDIA_LOCATION .

Las implementaciones de dispositivos PUEDEN cumplir con los requisitos anteriores utilizando cualquiera de los siguientes:

  • Almacenamiento extraíble accesible para el usuario, como una ranura para tarjeta Secure Digital (SD).
  • Una parte del almacenamiento interno (no extraíble) implementado en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones de dispositivos utilizan almacenamiento extraíble para satisfacer los requisitos anteriores:

  • [C-1-1] DEBE implementar una interfaz de usuario emergente o de notificación que advierta al usuario cuando no hay ningún medio de almacenamiento insertado en la ranura.
  • [C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (por ejemplo, una tarjeta SD) o mostrar en la caja y en otro material disponible en el momento de la compra que el medio de almacenamiento debe adquirirse por separado.

Si las implementaciones de dispositivos utilizan una parte del almacenamiento no extraíble para satisfacer los requisitos anteriores,:

  • DEBE utilizar la implementación AOSP del almacenamiento compartido de la aplicación interna.
  • PUEDE compartir el espacio de almacenamiento con los datos privados de la aplicación.

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB,:

  • [C-3-1] DEBE proporcionar un mecanismo para acceder a los datos en el almacenamiento compartido de la aplicación desde una computadora host.
  • DEBE exponer el contenido de ambas rutas de almacenamiento de forma transparente a través del servicio de escáner de medios de Android y android.provider.MediaStore .
  • PUEDE usar almacenamiento masivo USB, pero DEBE usar el Protocolo de transferencia de medios para satisfacer este requisito.

Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y admiten el Protocolo de transferencia de medios,:

  • DEBE ser compatible con el host MTP de Android de referencia, Android File Transfer .
  • DEBE informar una clase de dispositivo USB de 0x00.
  • DEBE informar un nombre de interfaz USB de 'MTP'.

7.6.3. Almacenamiento adoptable

Si se espera que el dispositivo sea de naturaleza móvil a diferencia de la televisión, las implementaciones del dispositivo son:

  • [C-SR-1] RECOMIENDA ENCARECIDAMENTE implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlos accidentalmente puede causar pérdida/corrupción de datos.

Si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimiento de la batería u otra cubierta protectora, las implementaciones del dispositivo son:

7.7. USB

Si las implementaciones de dispositivos tienen un puerto USB,:

  • DEBE admitir el modo periférico USB y DEBE admitir el modo host USB.
  • DEBE admitir la desactivación de la señalización de datos a través de USB.

7.7.1. Modo periférico USB

Si las implementaciones del dispositivo incluyen un puerto USB que admite el modo periférico:

  • [C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
  • [C-1-2] DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo estándar USB a través de android.os.Build.SERIAL .
  • [C-1-3] DEBE detectar cargadores de 1,5 A y 3,0 A según el estándar de resistencia tipo C y DEBE detectar cambios en el anuncio si admiten USB tipo C.
  • [C-SR-1] El puerto DEBE utilizar un factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
  • [C-SR-2] El puerto DEBE estar ubicado 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 aplicaciones (incluida la pantalla de inicio), de modo que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
  • [C-SR-3] DEBE implementar soporte para consumir corriente de 1,5 A durante el chirrido HS y el tráfico como se especifica en la especificación de carga de batería USB, revisión 1.2 . Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
  • [C-SR-4] SE RECOMIENDA ENCARECIDAMENTE no admitir métodos de carga patentados que modifiquen el voltaje de Vbus más allá de los niveles predeterminados, o que alteren las funciones de fuente/sumidero, ya que tal puede resultar en problemas de interoperabilidad con los cargadores o dispositivos que admiten los métodos estándar de entrega de energía USB. Si bien esto se denomina "MUY RECOMENDADO", en futuras versiones de Android es posible que REQUIEREMOS que todos los dispositivos tipo C admitan una interoperabilidad total con los cargadores tipo C estándar.
  • [C-SR-5] SE RECOMIENDA ENCARECIDAMENTE admitir Power Delivery para el intercambio de roles de energía y datos cuando admiten USB tipo C y modo host USB.
  • DEBE admitir Power Delivery para carga de alto voltaje y soporte para modos alternativos como visualización.
  • DEBE implementar la API y la especificación del accesorio abierto de Android (AOA) como se documenta en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen un puerto USB e implementan la especificación AOA,:

  • [C-2-1] DEBE declarar compatibilidad con la función de hardware android.hardware.usb.accessory .
  • [C-2-2] La clase de almacenamiento masivo USB DEBE incluir la cadena "android" al final de la descripción de la interfaz Cadena iInterface del almacenamiento masivo USB
  • NO DEBE implementar el audio AOAv2 documentado en la documentación del Protocolo de accesorios abiertos de Android 2.0. El audio AOAv2 está obsoleto a partir de la versión 8.0 de Android (nivel de API 26).

7.7.2. Modo de host USB

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host:

  • [C-1-1] DEBE implementar la API del host USB de Android como se documenta en el SDK de Android y DEBE declarar compatibilidad con la función de hardware android.hardware.usb.host .
  • [C-1-2] DEBEN implementar soporte para conectar periféricos USB estándar, en otras palabras, DEBEN:
    • Tener un puerto tipo C en el dispositivo o enviarse con cables que adapten un puerto propietario del dispositivo a un puerto USB tipo C estándar (dispositivo USB tipo C).
    • Tenga un dispositivo tipo A o envíelo con cables que adapten un puerto propietario del dispositivo a un puerto USB tipo A estándar.
    • Tener un puerto micro-AB en el dispositivo, que DEBE enviarse con un cable que se adapte a un puerto tipo A estándar.
  • [C-1-3] NO DEBE enviarse con un adaptador que convierta de puertos USB tipo A o micro-AB a un puerto tipo C (receptáculo).
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
  • DEBE admitir la carga del dispositivo periférico USB conectado mientras está en modo host; anunciar una fuente de corriente de al menos 1,5 A como se especifica en la sección Parámetros de terminación de la Revisión 1.2 de la especificación de conector y cable USB tipo C para conectores USB tipo C o usar el rango de corriente de salida del puerto de carga descendente (CDP) como se especifica en el USB Especificaciones de carga de batería, revisión 1.2 para conectores Micro-AB.
  • DEBE implementar y admitir estándares USB tipo C.

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y la clase de audio USB,:

  • [C-2-1] DEBE admitir la clase USB HID .
  • [C-2-2] DEBE admitir la detección y mapeo de los siguientes campos de datos HID especificados en las Tablas de uso de HID de USB y la Solicitud de uso de comando de voz a las constantes KeyEvent como se muestra a continuación:
    • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
    • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
    • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y Storage Access Framework (SAF), estos:

  • [C-3-1] DEBE reconocer cualquier dispositivo MTP (Protocolo de transferencia de medios) conectado remotamente y hacer que su contenido sea accesible a través de los intents ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT . .

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y USB Type-C,:

  • [C-4-1] DEBE implementar la funcionalidad de puerto de función dual según lo define la especificación USB tipo C (sección 4.5.1.3.3). Para puertos de doble función, en dispositivos que incluyen un conector de audio de 3,5 mm, la detección de receptor USB (modo host) PUEDE estar desactivada de forma predeterminada, pero el usuario DEBE poder habilitarla.
  • [C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que admita DisplayPort, DEBE admitir velocidades de datos USB SuperSpeed ​​y se RECOMIENDA ENCARECIDAMENTE que admita la entrega de energía para el intercambio de roles de energía y datos.
  • [C-SR-3] SE RECOMIENDA ENCARECIDAMENTE NO admitir el modo de accesorio del adaptador de audio como se describe en el Apéndice A de la especificación del conector y cable USB tipo C, Revisión 1.2 .
  • DEBE implementar el modelo Try.* que sea más apropiado para el factor de forma del dispositivo. Por ejemplo, un dispositivo portátil DEBE implementar el modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

Si las implementaciones de dispositivos incluyen un micrófono,:

  • [C-1-1] DEBE informar la constante de la característica android.hardware.microphone .
  • [C-1-2] DEBE cumplir con los requisitos de grabación de audio de la sección 5.4 .
  • [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6 .
  • [C-SR-1] Se RECOMIENDAN ENCARECIDAMENTE para admitir la grabación de ultrasonido cercano como se describe en la sección 7.8.3 .

Si las implementaciones de dispositivos omiten un micrófono,:

  • [C-2-1] NO DEBE informar la constante de la característica android.hardware.microphone .
  • [C-2-2] DEBE implementar la API de grabación de audio al menos como no operativa, según la sección 7 .

7.8.2. Salida de audio

Si las implementaciones de dispositivos incluyen un altavoz o un puerto de salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 3,5 mm de 4 conductores o un puerto de modo host USB que utiliza clase de audio USB ,:

  • [C-1-1] DEBE informar la constante de la característica android.hardware.audio.output .
  • [C-1-2] DEBE cumplir con los requisitos de reproducción de audio de la sección 5.5 .
  • [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6 .
  • [C-SR-1] RECOMENDADO ENCARECIDAMENTE para admitir la reproducción de ultrasonido cercano como se describe en la sección 7.8.3 .

Si las implementaciones de dispositivos no incluyen un altavoz o un puerto de salida de audio,:

  • [C-2-1] NO DEBE informar la función android.hardware.audio.output .
  • [C-2-2] DEBE implementar las API relacionadas con la salida de audio al menos como no operativas.

A los efectos de esta sección, un "puerto de salida" es una interfaz física como un conector de audio de 3,5 mm, HDMI o un puerto de modo host USB con clase de audio USB. La compatibilidad con salida de audio a través de protocolos basados ​​en radio, como Bluetooth, WiFi o red celular, no califica como inclusión de un "puerto de salida".

7.8.2.1. Puertos de audio analógico

Para ser compatibles con los auriculares y otros accesorios de audio que utilizan el conector de audio de 3,5 mm en todo el ecosistema Android, si las implementaciones del dispositivo incluyen uno o más puertos de audio analógico, estos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir al menos uno de los puertos de audio para que sea un conector de audio de 3,5 mm de 4 conductores.

Si las implementaciones de dispositivos tienen un conector de audio de 3,5 mm de 4 conductores,:

  • [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono.
  • [C-1-2] DEBE admitir enchufes de audio TRRS con el orden de distribución de pines CTIA.
  • [C-1-3] DEBE admitir la detección y el mapeo de los códigos clave para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de tierra en el conector de audio:
    • 70 ohmios o menos : KEYCODE_HEADSETHOOK
    • 210-290 ohmios : KEYCODE_VOLUME_UP
    • 360-680 ohmios : KEYCODE_VOLUME_DOWN
  • [C-1-4] DEBE activar ACTION_HEADSET_PLUG al insertar un enchufe, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
  • [C-1-5] DEBE ser capaz de manejar al menos 150 mV ± 10 % del voltaje de salida con una impedancia de altavoz de 32 ohmios.
  • [C-1-6] DEBE tener un voltaje de polarización del micrófono entre 1,8 V ~ 2,9 V.
  • [C-1-7] DEBE detectar y asignar al código clave el siguiente rango de impedancia equivalente entre el micrófono y los conductores de tierra en el conector de audio:
    • 110-180 ohmios: KEYCODE_VOICE_ASSIST
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE admitir conectores de audio con el orden de distribución de pines OMTP.
  • [C-SR-3] Se RECOMIENDAN ENCARECIDAMENTE para admitir la grabación de audio desde auriculares estéreo con micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 3,5 mm de 4 conductores y admiten un micrófono, y transmiten android.intent.action.HEADSET_PLUG con el micrófono de valor adicional configurado como 1,:

  • [C-2-1] DEBE admitir la detección del micrófono en el accesorio de audio enchufado.
7.8.2.2. Puertos de audio digitales

Consulte la Sección 2.2.1 para conocer los requisitos específicos del dispositivo.

7.8.3. Ultrasonido cercano

El audio del ultrasonido cercano es la banda de 18,5 kHz a 20 kHz.

Implementaciones de dispositivos:

  • DEBE informar correctamente la compatibilidad con la capacidad de audio de ultrasonido cercano a través de la API AudioManager.getProperty de la siguiente manera:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es "true", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED DEBEN cumplir los siguientes requisitos:

  • [C-1-1] La respuesta de potencia media del micrófono en la banda de 18,5 kHz a 20 kHz DEBE estar no más de 15 dB por debajo de la respuesta a 2 kHz.
  • [C-1-2] La relación señal/ruido no ponderada del micrófono entre 18,5 kHz y 20 kHz para un tono de 19 kHz a -26 dBFS DEBE ser no inferior a 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es "verdadero":

  • [C-2-1] La respuesta media del altavoz en 18,5 kHz - 20 kHz DEBE ser no inferior a 40 dB por debajo de la respuesta a 2 kHz.

7.8.4. Integridad de la señal

Implementaciones de dispositivos:

  • DEBE proporcionar una ruta de señal de audio sin fallas para los flujos de entrada y salida en dispositivos portátiles, según lo definido por cero fallas medidas durante una prueba de un minuto por ruta. Pruebe usando OboeTester "Prueba de falla automatizada".

La prueba requiere un dongle de bucle invertido de audio , usado directamente en un conector de 3,5 mm y/o en combinación con un adaptador USB-C a 3,5 mm. Todos los puertos de salida de audio DEBEN probarse.

OboeTester actualmente admite rutas de AAudio, por lo que las siguientes combinaciones DEBEN probarse para detectar fallas usando AAudio:

Modo de rendimiento Intercambio Frecuencia de muestreo En Chans Fuera Chans
BAJA LATENCIA EXCLUSIVO NO ESPECIFICADO 1 2
BAJA LATENCIA EXCLUSIVO NO ESPECIFICADO 2 1
BAJA LATENCIA COMPARTIDO NO ESPECIFICADO 1 2
BAJA LATENCIA COMPARTIDO NO ESPECIFICADO 2 1
NINGUNO COMPARTIDO 48000 1 2
NINGUNO COMPARTIDO 48000 2 1
NINGUNO COMPARTIDO 44100 1 2
NINGUNO COMPARTIDO 44100 2 1
NINGUNO COMPARTIDO 16000 1 2
NINGUNO COMPARTIDO 16000 2 1

Una transmisión confiable DEBE cumplir con los siguientes criterios de relación señal-ruido (SNR) y distorsión armónica total (THD) para 2000 Hz sinusoidal.

transductor THD SNR
Altavoz incorporado principal, medido utilizando un micrófono de referencia externo. <3,0% >= 50dB
Micrófono incorporado principal, medido utilizando un altavoz de referencia externo. <3,0% >= 50dB
Conectores analógicos integrados de 3,5 mm, probados con un adaptador loopback < 1% >= 60dB
Adaptadores USB suministrados con el teléfono, probados con un adaptador loopback < 1,0% >= 60dB

7.9. Realidad virtual

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

7.9.1. Modo de realidad virtual

Android incluye soporte para el modo VR , una función que maneja la representación estereoscópica de notificaciones y desactiva los componentes de la interfaz de usuario del sistema monocular mientras una aplicación de realidad virtual se centra en el usuario.

7.9.2. Modo de realidad virtual: alto rendimiento

Si las implementaciones de dispositivos admiten el modo VR,:

  • [C-1-1] DEBE tener al menos 2 núcleos físicos.
  • [C-1-2] DEBE declarar la característica android.hardware.vr.high_performance .
  • [C-1-3] DEBE admitir el modo de rendimiento sostenido.
  • [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
  • [C-1-5] DEBE ser compatible con android.hardware.vulkan.level 0.
  • DEBE admitir android.hardware.vulkan.level 1 o superior.
  • [C-1-6] DEBE implementar EGL_KHR_mutable_render_buffer , EGL_ANDROID_front_buffer_auto_refresh , EGL_ANDROID_get_native_client_buffer , EGL_KHR_fence_sync , EGL_KHR_wait_sync , EGL_IMG_context_priority , EGL_EXT_protected_content , EGL_EXT_image_gl_colorspace colorspace y exponer las extensiones en la lista de extensiones EGL disponibles.
  • [C-1-8] DEBE implementar GL_EXT_multisampled_render_to_texture2 , GL_OVR_multiview , GL_OVR_multiview2 , GL_EXT_protected_textures y exponer las extensiones en la lista de extensiones GL disponibles.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar GL_EXT_external_buffer , GL_EXT_EGL_image_array , GL_OVR_multiview_multisampled_render_to_texture y exponer las extensiones en la lista de extensiones GL disponibles.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que sean compatibles con Vulkan 1.1.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE implementar VK_ANDROID_external_memory_android_hardware_buffer , VK_GOOGLE_display_timing , VK_KHR_shared_presentable_image y exponerlo en la lista de extensiones de Vulkan disponibles.
  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE exponer al menos una familia de colas de Vulkan donde flags contengan VK_QUEUE_GRAPHICS_BIT y VK_QUEUE_COMPUTE_BIT , y queueCount sea al menos 2.
  • [C-1-7] La ​​GPU y la pantalla DEBEN poder sincronizar el acceso al búfer frontal compartido de modo que la representación de ojos alternos del contenido de realidad virtual a 60 fps con dos contextos de representación se muestre sin artefactos de desgarro visibles.
  • [C-1-9] DEBE implementar soporte para los indicadores AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER , AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT como se describe en el NDK.
  • [C-1-10] DEBE implementar soporte para AHardwareBuffer s con cualquier combinación de los indicadores de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT , AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE , AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para al menos los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM , AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM , AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM , AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT .
  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE admitir la asignación de AHardwareBuffer con más de una capa y los indicadores y formatos especificados en C-1-10.
  • [C-1-11] DEBE admitir decodificación H.264 al menos 3840 x 2160 a 30 fps, comprimido a un promedio de 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).
  • [C-1-12] DEBE admitir HEVC y VP9, ​​DEBE ser capaz de decodificar al menos 1920 x 1080 a 30 fps comprimidos a un promedio de 10 Mbps y DEBE ser capaz de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-5 Mbps).
  • [C-1-13] DEBE admitir la API HardwarePropertiesManager.getDeviceTemperatures y devolver valores precisos para la temperatura de la piel.
  • [C-1-14] DEBE tener una pantalla integrada y su resolución DEBE ser de al menos 1920 x 1080.
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de pantalla de al menos 2560 x 1440.
  • [C-1-15] La pantalla DEBE actualizarse al menos 60 Hz mientras está en modo VR.
  • [C-1-17] La ​​pantalla DEBE admitir un modo de baja persistencia con ≤ 5 milisegundos de persistencia, definiéndose la persistencia como la cantidad de tiempo durante el cual un píxel emite luz.
  • [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la sección 7.4.3 de extensión de longitud de datos de Bluetooth LE.
  • [C-1-19] DEBE admitir e informar adecuadamente el tipo de canal directo para todos los siguientes tipos de sensores predeterminados:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE admitir el tipo de canal directo TYPE_HARDWARE_BUFFER para todos los tipos de canales directos enumerados anteriormente.
  • [C-1-21] DEBE cumplir con los requisitos relacionados con giroscopio, acelerómetro y magnetómetro para android.hardware.hifi_sensors , como se especifica en la sección 7.3.9 .
  • [C-SR-8] Se RECOMIENDA ENCARECIDAMENTE que admitan la función android.hardware.sensor.hifi_sensors .
  • [C-1-22] DEBE tener una latencia de movimiento a fotón de extremo a extremo que no supere los 28 milisegundos.
  • [C-SR-9] Se RECOMIENDA ENCARECIDAMENTE tener una latencia de movimiento de fotón de extremo a extremo no superior a 20 milisegundos.
  • [C-1-23] DEBE tener una relación de primer cuadro, que es la relación entre el brillo de los píxeles en el primer cuadro después de una transición de negro a blanco y el brillo de los píxeles blancos en estado estable, de al menos 85 %.
  • [C-SR-10] Se RECOMIENDA ENCARECIDAMENTE tener una relación de primer fotograma de al menos el 90 %.
  • PUEDE proporcionar un núcleo exclusivo para la aplicación en primer plano y PUEDE admitir la API Process.getExclusiveCores para devolver los números de los núcleos de la CPU que son exclusivos de la aplicación en primer plano superior.

Si se admite un núcleo exclusivo, entonces el núcleo:

  • [C-2-1] NO DEBE permitir que se ejecute ningún otro proceso del espacio de usuario (excepto los controladores de dispositivo utilizados por la aplicación), pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.

7.10. hápticos

Iniciar nuevos requisitos

Los dispositivos destinados a ser de mano o usados ​​pueden incluir un actuador háptico de propósito general, disponible para aplicaciones para fines que incluyen recibir atención a través de tonos de llamada, alarmas, notificaciones, así como comentarios de tacto general.

Si las implementaciones de dispositivos no incluyen un actuador háptico de este propósito general, ellos:

  • [7.10/c] debe devolver falso para Vibrator.hasVibrator() .

Si las implementaciones de dispositivos incluyen al menos un actuador háptico de propósito general, ellos:

Si las implementaciones del dispositivo siguen la asignación de constantes hápticas, ellos:

Finalizar los nuevos requisitos

Consulte la Sección 2.2.1 para conocer los requisitos específicos del dispositivo.

7.11. Clase de rendimiento de medios

La clase de rendimiento multimedia de la implementación del dispositivo se puede obtener de la API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS . Los requisitos para la clase de rendimiento multimedia se definen para cada versión de Android a partir de R (versión 30). El valor especial 0 indica que el dispositivo no pertenece a una clase de rendimiento multimedia.

Si las implementaciones de dispositivos devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS ,:

  • [C-1-1] DEBE devolver al menos un valor de android.os.Build.VERSION_CODES.R .

  • [C-1-2] DEBE ser una implementación de dispositivo portátil.

  • [C-1-3] DEBE cumplir con todos los requisitos de "Clase de rendimiento de medios" descritos en la sección 2.2.7 .

En otras palabras, la clase de rendimiento multimedia en Android T solo está definida para dispositivos portátiles en la versión T, S o R.

Consulte la sección 2.2.7 para conocer los requisitos específicos del dispositivo.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y potencia son fundamentales para la experiencia del usuario e impactan las suposiciones básicas que los desarrolladores tendrían al desarrollar una aplicación.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si existen ciertos requisitos mínimos para garantizar una velocidad de cuadros y tiempos de respuesta consistentes para aplicaciones y juegos. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener requisitos mensurables para la latencia de la interfaz de usuario y el cambio de tareas, como se describe en la sección 2 .

8.2. Rendimiento del acceso a E/S de archivos

Proporcionar una base común para un rendimiento consistente del acceso a archivos en el almacenamiento de datos privados de la aplicación (partición /data ) permite a los desarrolladores de aplicaciones establecer una expectativa adecuada que ayudaría a diseñar su software. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener ciertos requisitos descritos en la sección 2 para las siguientes operaciones de lectura y escritura:

  • Rendimiento de escritura secuencial . Medido escribiendo un archivo de 256 MB utilizando un búfer de escritura de 10 MB.
  • Rendimiento de escritura aleatoria . Medido escribiendo un archivo de 256 MB utilizando un búfer de escritura de 4 KB.
  • Rendimiento de lectura secuencial . Medido leyendo un archivo de 256 MB utilizando un búfer de escritura de 10 MB.
  • Rendimiento de lectura aleatoria . Medido leyendo un archivo de 256 MB utilizando un búfer de escritura de 4 KB.

8.3. Modos de ahorro de energía

Si las implementaciones de dispositivos incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP (por ejemplo, App Standby Bucket, Doze) o extienden las funciones para aplicar restricciones más estrictas que el RESTRINGIDO App Standby Bucket , estas:

  • [C-1-1] NO DEBE desviarse de la implementación de AOSP para los algoritmos de activación, mantenimiento y activación y el uso de la configuración global del sistema o DeviceConfig de los modos de ahorro de energía App Standby y Doze.
  • [C-1-2] NO DEBE desviarse de la implementación de AOSP para el uso de configuraciones globales o DeviceConfig para administrar la limitación de trabajos, alarmas y redes para aplicaciones en cada depósito para la aplicación en espera.
  • [C-1-3] NO DEBE desviarse de la implementación de AOSP para la cantidad de depósitos de aplicaciones en espera utilizados para la aplicación en espera.
  • [C-1-4] DEBE implementar App Standby Buckets y Doze como se describe en Administración de energía .
  • [C-1-5] DEBE devolver true para PowerManager.isPowerSaveMode() cuando el dispositivo está en modo de ahorro de energía.
  • [C-1-6] DEBE proporcionar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze o cualquier optimización de la batería y DEBE implementar la intención ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATION para pedirle al usuario que permita que una aplicación ignore las optimizaciones de la batería.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.

Si las implementaciones de dispositivos amplían las funciones de administración de energía que se incluyen en AOSP y esa extensión aplica restricciones más estrictas que el Rare App Standby Bucket , consulte la sección 3.5.1 .

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 inactivos según lo definido por la Interfaz de energía y configuración avanzada (ACPI).

Si las implementaciones de dispositivos implementan estados de energía S4 según lo define ACPI, ellos:

  • [C-1-1] DEBE ingresar a este estado solo después de que el usuario haya realizado una acción explícita para poner el dispositivo en un estado inactivo (por ejemplo, cerrando una tapa que es físicamente parte del dispositivo o apagando un vehículo o televisión) y antes de que el usuario reactive el dispositivo (por ejemplo, abriendo la tapa o volviendo a encender el vehículo o la televisión).

Si las implementaciones de dispositivos implementan estados de energía S3 según lo define ACPI, ellos:

  • [C-2-1] DEBE cumplir con C-1-1 anterior o DEBE ingresar al estado S3 solo cuando las aplicaciones de terceros no necesiten los recursos del sistema (por ejemplo, la pantalla, la CPU).

    Por el contrario, DEBE salir del estado S3 cuando las aplicaciones de terceros necesiten los recursos del sistema, como se describe en este SDK.

    Por ejemplo, mientras las aplicaciones de terceros solicitan mantener la pantalla encendida a través de FLAG_KEEP_SCREEN_ON o mantener la CPU funcionando a través de PARTIAL_WAKE_LOCK , el dispositivo NO DEBE ingresar al estado S3 a menos que, como se describe en C-1-1, el usuario haya tomado medidas explícitas para poner el dispositivo en un estado inactivo. Por el contrario, en un momento en que se activa una tarea que las aplicaciones de terceros implementan a través de JobScheduler o se entrega Firebase Cloud Messaging a aplicaciones de terceros, el dispositivo DEBE salir del estado S3 a menos que el usuario haya puesto el dispositivo en un estado inactivo. Estos no son ejemplos completos y AOSP implementa extensas señales de activación que desencadenan una activación de este estado.

8.4. Contabilidad del consumo de energía

Una contabilidad y un informe más precisos del consumo de energía proporcionan al desarrollador de la aplicación tanto los incentivos como las herramientas para optimizar el patrón de uso de energía de la aplicación.

Implementaciones de dispositivos:

  • [C-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [C-SR-2] RECOMIENDA ENCARECIDAMENTE informar todos los valores de consumo de energía en miliamperios hora (mAh).
  • [C-SR-3] SE RECOMIENDA ENCARECIDAMENTE informar el consumo de energía de la CPU por el UID de cada proceso. El proyecto de código abierto de Android cumple con el requisito mediante la implementación del módulo del kernel uid_cputime .
  • [C-SR-4] SE RECOMIENDA ENCARECIDAMENTE hacer que este uso de energía esté disponible a través del comando shell adb shell dumpsys batterystats para el desarrollador de la aplicación.
  • DEBE atribuirse al propio componente de hardware si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

8.5. Rendimiento consistente

El rendimiento puede fluctuar dramáticamente para aplicaciones de alto rendimiento y larga ejecución, ya sea debido a que otras aplicaciones se ejecutan en segundo plano o a que la CPU se acelera debido a límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea capaz, la aplicación de primer plano pueda solicitar que el sistema optimice la asignación de recursos para abordar tales fluctuaciones.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos informan que admiten el modo de rendimiento sostenido,:

  • [C-1-1] DEBE proporcionar a la aplicación de primer plano superior un nivel constante de rendimiento durante al menos 30 minutos, cuando la aplicación lo solicite.
  • [C-1-2] DEBE respetar la API Window.setSustainedPerformanceMode() y otras API relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU,:

  • DEBE proporcionar al menos un núcleo exclusivo que la aplicación de primer plano pueda reservar.

Si las implementaciones de dispositivos admiten la reserva de un núcleo exclusivo para la aplicación de primer plano, estas:

  • [C-2-1] DEBE informar a través del método API Process.getExclusiveCores() los números de identificación de los núcleos exclusivos que la aplicación de primer plano superior puede reservar.
  • [C-2-2] NO DEBE permitir que ningún proceso del espacio de usuario, excepto los controladores de dispositivo utilizados por la aplicación, se ejecute en los núcleos exclusivos, pero PUEDE permitir que algunos procesos del kernel se ejecuten según sea necesario.

Si las implementaciones de dispositivos no admiten un núcleo exclusivo,:

9. Compatibilidad del modelo de seguridad

Implementaciones de dispositivos:

  • [C-0-1] DEBE implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma Android como se define en el documento de referencia de seguridad y permisos en las API en la documentación para desarrolladores de Android.

  • [C-0-2] DEBE admitir la instalación de aplicaciones autofirmadas sin requerir permisos/certificados adicionales de terceros/autoridades.

Si las implementaciones de dispositivos declaran la función android.hardware.security.model.compatible ,:

  • [C-1-1] DEBE soportar los requisitos enumerados en las siguientes subsecciones.

9.1. Permisos

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir el modelo de permisos de Android y el modelo de roles de Android como se define en la documentación para desarrolladores de Android. Específicamente, DEBEN hacer cumplir cada permiso y función definidos como se describe en la documentación del SDK; no se pueden omitir, modificar ni ignorar permisos ni funciones.

  • PUEDE agregar permisos adicionales, siempre que las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.\* .

  • [C-0-2] Los permisos con un protectionLevel de PROTECTION_FLAG_PRIVILEGED solo DEBEN otorgarse a aplicaciones preinstaladas en las rutas privilegiadas de la imagen del sistema (así como archivos APEX ) y estar dentro del subconjunto de permisos explícitamente permitidos para cada una. aplicación. La implementación de AOSP cumple con este requisito leyendo y respetando los permisos permitidos para cada aplicación de los archivos en la ruta etc/permissions/ y utilizando la ruta system/priv-app como ruta privilegiada.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 las solicitan en tiempo de ejecución.

Implementaciones de dispositivos:

  • [C-0-3] 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 administre los permisos de tiempo de ejecución.

  • [C-0-4] DEBE tener una y sólo una implementación de ambas interfaces de usuario.

  • [C-0-5] NO DEBE otorgar ningún permiso de ejecución a las aplicaciones a menos que:

    • Se instalan en el momento del envío del dispositivo, Y
    • El consentimiento del usuario se puede obtener antes de que la aplicación utilice el permiso,

      O

    • Los permisos de tiempo de ejecución se otorgan mediante la política de concesión de permisos predeterminada o por tener una función de plataforma.

  • [C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo a las aplicaciones del sistema que registren un Agente de Recuperación debidamente protegido. Un agente de recuperación adecuadamente protegido se define como un agente de software en el dispositivo que se sincroniza con un almacenamiento remoto fuera del dispositivo, que está equipado con hardware seguro con una protección equivalente o más fuerte que la que se describe en el servicio Google Cloud Key Vault para evitar la fuerza bruta. ataques al factor de conocimiento de la pantalla de bloqueo.

Implementaciones de dispositivos:

  • [C-0-7] DEBE cumplir con las propiedades de permiso de ubicación de Android cuando una aplicación solicita datos de ubicación o actividad física a través de la API estándar de Android o un mecanismo propietario. Dichos datos incluyen, entre otros:

    • Ubicación del dispositivo (por ejemplo, latitud y longitud) como se describe en la sección 9.8.8 .
    • Información que se puede utilizar para determinar o estimar la ubicación del dispositivo (por ejemplo, SSID, BSSID, ID de celular o ubicación de la red a la que está conectado el dispositivo).
    • Actividad física del usuario o clasificación de la actividad física.

Más específicamente, implementaciones de dispositivos:

    *   [C-0-8] MUST obtain user consent to allow an app to access the
        location or physical activity data.
    *   [C-0-9] MUST grant a runtime permission ONLY to the app that holds
        sufficient permission as described on SDK.
        For example,

TelephonyManager#getServiceState requiere android.permission.ACCESS_FINE_LOCATION ).

Las únicas excepciones a las propiedades de permiso de ubicación de Android anteriores son para las aplicaciones que no acceden a la Ubicación para derivar o identificar la ubicación del usuario; específicamente:

  • Cuando las aplicaciones tienen el permiso RADIO_SCAN_WITHOUT_LOCATION .
  • Para fines de configuración y configuración de dispositivos, donde las aplicaciones del sistema tienen el permiso NETWORK_SETTINGS o NETWORK_SETUP_WIZARD .

Los permisos se pueden marcar como restringidos alterando su comportamiento.

  • [C-0-10] Los permisos marcados con la bandera hardRestricted NO DEBEN otorgarse a una aplicación a menos que:

    • Hay un archivo APK de la aplicación en la partición del sistema.
    • El usuario asigna una función asociada con los permisos hardRestricted a una aplicación.
    • El instalador otorga hardRestricted a una aplicación.
    • A una aplicación se le otorga la hardRestricted en una versión anterior de Android.
  • [C-0-11] Las aplicaciones que tienen un permiso softRestricted DEBEN obtener solo acceso limitado y NO DEBEN obtener acceso completo hasta que estén incluidas en la lista permitida como se describe en el SDK, donde se define el acceso completo y limitado para cada permiso softRestricted (por ejemplo, READ_EXTERNAL_STORAGE ).

  • [C-0-12] NO DEBE proporcionar ninguna función o API personalizada para eludir las restricciones de permiso definidas en las API setPermissionPolicy y setPermissionGrantState .

  • [C-0-13] DEBE utilizar las API de AppOpsManager para registrar y rastrear todos y cada uno de los accesos programáticos a datos protegidos por permisos peligrosos de actividades y servicios de Android.

  • [C-0-14] DEBE asignar roles únicamente a aplicaciones con funcionalidades que cumplan con los requisitos del rol.

  • [C-0-15] No DEBE definir roles que sean duplicados o funcionalidades de superconjunto de roles definidos por la plataforma.

Si los dispositivos informan android.software.managed_users ,:

  • [C-1-1] NO DEBE tener los siguientes permisos otorgados silenciosamente por el administrador:
    • Ubicación (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
    • Cámara (CÁMARA)
    • Micrófono (RECORD_AUDIO)
    • Sensor corporal (BODY_SENSORS)
    • Actividad física (ACTIVITY_RECOGNITION)

Si las implementaciones de dispositivos brindan al usuario la posibilidad de elegir qué aplicaciones pueden superponerse a otras aplicaciones con una actividad que maneja la intención ACTION_MANAGE_OVERLAY_PERMISSION , estas:

  • [C-2-1] DEBE garantizar que todas las actividades con filtros de intención para la intención ACTION_MANAGE_OVERLAY_PERMISSION tengan la misma pantalla de interfaz de usuario, independientemente de la aplicación que la inicia o de cualquier información que proporcione.

Si las implementaciones de dispositivos informan android.software.device_admin,:

  • [C-3-1] DEBE mostrar un descargo de responsabilidad durante la configuración totalmente administrada del dispositivo (configuración del propietario del dispositivo) que indique que el administrador de TI tendrá la capacidad de permitir que las aplicaciones controlen la configuración del teléfono, incluidos el micrófono, la cámara y la ubicación, con opciones para el usuario. para continuar con la configuración o salir de ella A MENOS que el administrador haya optado por perder el control de los permisos en el dispositivo.

Si las implementaciones de dispositivos preinstalan cualquier paquete que contenga cualquiera de las funciones System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence o System Visual Intelligence , los paquetes:

  • [C-4-1] debe cumplir con todos los requisitos descritos para las implementaciones de dispositivos en las secciones "9.8.6 Captura de contenido" "9.8.6 Datos de nivel de sistema operativo y ambiental y 9.8.15 implementaciones de API de sandboxed".

  • [C-4-2] NO DEBE tener el permiso android.permission.INTERNET. Esto es más estricto que lo MUY RECOMENDADO que figura en la sección 9.8.6.
  • [C-4-3] no debe vincularse a otras aplicaciones, excepto las siguientes aplicaciones del sistema: Bluetooth, Contactos, Medios, Telefonía, SystemUI y Componentes que proporcionan API de Internet. Esto es más estricto que lo MUY RECOMENDADO que figura en la sección 9.8.6.

Iniciar nuevos requisitos

Si las implementaciones del dispositivo incluyen una aplicación predeterminada para admitir VoiceInteractionService ellos:

  • [C-5-1] no debe otorgar ACCESS_FINE_LOCATION como el valor predeterminado para esa aplicación.

Finalizar los nuevos requisitos

9.2. UID y aislamiento de procesos

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir el modelo de zona de pruebas de aplicaciones de Android, en el que cada aplicación se ejecuta como un UID estilo Unix único y en un proceso separado.
  • [C-0-2] DEBE admitir la ejecución de múltiples aplicaciones con el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de Seguridad y Permisos .

9.3. Permisos del sistema de archivos

Implementaciones de dispositivos:

9.4. Entornos de ejecución alternativos

Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de permisos y seguridad de Android, incluso si incluyen entornos de ejecución que ejecutan aplicaciones utilizando algún otro software o tecnología que no sea el formato ejecutable Dalvik o el código nativo. En otras palabras:

  • [C-0-1] Los tiempos de ejecución alternativos DEBEN ser aplicaciones de Android y cumplir con el modelo de seguridad estándar de Android, como se describe en otra parte de la sección 9 .

  • [C-0-2] NO SE DEBE otorgar acceso a tiempos de ejecución alternativos a recursos protegidos por permisos no solicitados en el archivo AndroidManifest.xml del tiempo de ejecución a través del mecanismo uses-permission .

  • [C-0-3] Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones utilicen funciones protegidas por permisos de Android restringidos a aplicaciones del sistema.

  • [C-0-4] Los tiempos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android y las aplicaciones instaladas que utilizan 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. .

  • [C-0-5] Los tiempos de ejecución alternativos NO DEBEN iniciarse, otorgar ni recibir acceso a los entornos sandbox correspondientes a otras aplicaciones de Android.

  • [C-0-6] Los tiempos de ejecución alternativos NO DEBEN iniciarse, otorgarse ni otorgarse a otras aplicaciones ningún privilegio de superusuario (root) o de cualquier otra identificación de usuario.

  • [C-0-7] Cuando los archivos .apk de tiempos de ejecución alternativos se incluyen en la imagen del sistema de las implementaciones del dispositivo, DEBEN firmarse con una clave distinta de la clave utilizada para firmar otras aplicaciones incluidas con las implementaciones del dispositivo.

  • [C-0-8] Al instalar aplicaciones, los tiempos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android utilizados por la aplicación.

  • [C-0-9] Cuando una aplicación necesita hacer uso de un recurso del dispositivo para el cual existe 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á para acceder a ese recurso.

  • [C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, el entorno de ejecución DEBE enumerar todos los permisos que posee el propio tiempo de ejecución al instalar cualquier aplicación que utilice ese tiempo de ejecución.

  • Los tiempos de ejecución alternativos DEBEN instalar aplicaciones a través de PackageManager en entornos aislados de Android separados (ID de usuario de Linux, etc.).

  • Los tiempos de ejecución alternativos PUEDEN proporcionar una única zona de pruebas de Android compartida por todas las aplicaciones que utilizan el tiempo de ejecución alternativo.

9.5. Soporte multiusuario

Android incluye soporte para múltiples usuarios y brinda soporte para el aislamiento completo de usuarios y la clonación de perfiles de usuario con aislamiento parcial (es decir, un único perfil de usuario adicional de tipo android.os.usertype.profile.CLONE ).

  • Las implementaciones de dispositivos PUEDEN, pero NO DEBEN, habilitar la función multiusuario si utilizan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones de dispositivos incluyen soporte para múltiples usuarios, estos:

  • [C-1-2] DEBE, para cada usuario, implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma Android como se define en el documento de referencia de Seguridad y Permisos en las API.
  • [C-1-3] DEBE tener directorios de almacenamiento de aplicaciones compartidos (también conocidos como /sdcard ) separados y aislados para cada instancia de usuario.
  • [C-1-4] DEBE garantizar que las aplicaciones que pertenecen a un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer o escribir en los archivos propiedad de cualquier otro usuario, incluso si los datos de ambos usuarios están almacenados en el mismo volumen o sistema de archivos.
  • [C-1-5] DEBE cifrar el contenido de la tarjeta SD cuando el modo multiusuario está habilitado usando una clave almacenada solo en medios no extraíbles a los que solo puede acceder el sistema si las implementaciones del dispositivo utilizan medios extraíbles para las API de almacenamiento externo. Como esto hará que los medios sean ilegibles para una PC host, se requerirá que las implementaciones del dispositivo cambien a MTP o un sistema similar para proporcionar a las PC host acceso a los datos del usuario actual.

Si las implementaciones de dispositivos incluyen soporte para múltiples usuarios, entonces para todos los usuarios, excepto los usuarios creados específicamente para ejecutar instancias duales de la misma aplicación, ellos:

  • [C-2-1] DEBE tener directorios de almacenamiento de aplicaciones compartidos (también conocidos como /sdcard) separados y aislados para cada instancia de usuario.
  • [C-2-2] DEBE garantizar que las aplicaciones que pertenecen a un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer o escribir en los archivos propiedad de cualquier otro usuario, incluso si los datos de ambos usuarios están almacenados en el mismo volumen. o sistema de archivos.

Las implementaciones de dispositivos PUEDEN crear un único perfil de usuario adicional de tipo android.os.usertype.profile.CLONE contra el usuario principal (y solo contra el usuario principal) con el fin de ejecutar instancias duales de la misma aplicación. Estas instancias duales comparten almacenamiento parcialmente aislado, se presentan al usuario final en el iniciador al mismo tiempo y aparecen en la misma vista reciente. Por ejemplo, esto podría usarse para permitir que el usuario instale dos instancias separadas de una sola aplicación en un dispositivo con doble SIM.

Si las implementaciones de dispositivos crean el perfil de usuario adicional mencionado anteriormente, entonces:

  • [C-3-1] DEBE proporcionar acceso únicamente al almacenamiento o a los datos que ya sean accesibles para el perfil de usuario principal o que sean propiedad directa de este perfil de usuario adicional.
  • [C-3-2] NO DEBE tener esto como perfil de trabajo.
  • [C-3-3] DEBE tener directorios de datos de aplicaciones privadas aislados de la cuenta de usuario principal.
  • [C-3-4] NO DEBE permitir que se cree el perfil de usuario adicional si hay un Propietario del dispositivo aprovisionado (consulte la sección 3.9.1) ni permitir que se aprovisione un Propietario del dispositivo sin eliminar primero el perfil de usuario adicional.

Iniciar nuevos requisitos

Si las implementaciones de dispositivos crean el perfil de usuario adicional mencionado anteriormente, entonces:

  • [C-4-5] debe distinguir visualmente los iconos de la aplicación de instancia dual cuando los iconos se presentan a los usuarios.
  • [C-4-6] debe proporcionar una afordancia de usuario para eliminar los datos completos de perfil de clones.
  • [C-4-7] debe desinstalar todas las aplicaciones de clones, eliminar los directorios de datos de aplicaciones privadas y su contenido, y eliminar datos de perfil de clones, cuando el usuario elija eliminar los datos completos del perfil de clones.
  • Debe solicitar al usuario que elimine los datos completos de perfil de clon cuando se elimine la última aplicación Clone.
  • [C-4-8] debe informar al usuario que los datos de la aplicación se eliminarán cuando la aplicación clon no esté instalada, o proporcione una opción a los usuarios para mantener los datos de la aplicación cuando la aplicación no esté instalada desde el dispositivo.
  • [C-4-9] debe eliminar los directorios de datos de la aplicación privada y su contenido, cuando el usuario elige eliminar los datos durante la desinstalación.

  • [C-4-14] debe tener un permiso separado y una gestión de almacenamiento para las aplicaciones que se ejecutan en este perfil adicional

  • [C-4-5] solo debe permitir aplicaciones en el perfil adicional que tienen una actividad de lanzador para acceder a contactos a los que ya están accesibles para el perfil de usuario principal.

Finalizar los nuevos requisitos

9.6. Advertencia de SMS Premium

Android incluye soporte para advertir a los usuarios sobre cualquier mensaje SMS premium saliente. Los mensajes SMS premium son mensajes de texto enviados a un servicio registrado con un operador que puede generar un cargo para el usuario.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony ,:

  • [C-1-1] DEBE advertir a los usuarios antes de enviar un mensaje SMS a números identificados por expresiones regulares definidas en el archivo /data/misc/sms/codes.xml del dispositivo. El proyecto de código abierto de Android proporciona una implementación que satisface este requisito.

9.7. Características de seguridad

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad tanto en el kernel como en la plataforma, como se describe a continuación.

Android Sandbox incluye funciones que utilizan el sistema de control de acceso obligatorio (MAC) de Security-Enhanced Linux (SELinux), seccomp sandboxing y otras funciones de seguridad en el kernel de Linux. Implementaciones de dispositivos:

  • [C-0-1] DEBE mantener la compatibilidad con las aplicaciones existentes, incluso cuando SELinux o cualquier otra característica de seguridad se implemente bajo el marco de Android.
  • [C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta y bloquea exitosamente una violación de seguridad mediante la característica de seguridad implementada bajo el marco de Android, pero PUEDE tener una interfaz de usuario visible cuando ocurre una violación de seguridad desbloqueada que resulta en una solución exitosa. explotar.
  • [C-0-3] NO DEBE hacer que SELinux o cualquier otra característica de seguridad implementada bajo el marco de Android sea configurable para el usuario o desarrollador de la aplicación.
  • [C-0-4] NO DEBE permitir que una aplicación que pueda afectar a otra aplicación a través de una API (como una API de administración de dispositivos) configure una política que rompa la compatibilidad.
  • [C-0-5] DEBE dividir el marco de medios en múltiples procesos para que sea posible otorgar acceso de manera más restringida a cada proceso, como se describe en el sitio del Proyecto de código abierto de Android.
  • [C-0-6] DEBE implementar un mecanismo de espacio aislado de la aplicación del kernel que permita el filtrado de llamadas al sistema utilizando una política configurable de programas multiproceso. El proyecto de código abierto de Android cumple con este requisito habilitando seccomp-BPF con sincronización de grupo de subprocesos (TSYNC) como se describe en la sección Configuración del kernel de source.android.com .

La integridad del kernel y las funciones de autoprotección son parte integral de la seguridad de Android. Implementaciones de dispositivos:

  • [C-0-7] DEBE implementar mecanismos de protección de desbordamiento del búfer de la pila del kernel. Ejemplos de tales mecanismos son CC_STACKPROTECTOR_REGULAR y CONFIG_CC_STACKPROTECTOR_STRONG .
  • [C-0-8] DEBE implementar protecciones estrictas de la memoria del kernel donde el código ejecutable es de solo lectura, los datos de solo lectura no son ejecutables ni escribibles, y los datos escribibles no son ejecutables (por ejemplo, CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX ).
  • [C-0-9] DEBE implementar la verificación de límites de tamaño de objetos estáticos y dinámicos de las copias entre el espacio de usuario y el espacio del kernel (por ejemplo, CONFIG_HARDENED_USERCOPY ) en dispositivos que originalmente se entregaban con el nivel de API 28 o superior.
  • [C-0-10] NO DEBE ejecutar la memoria del espacio de usuario cuando se ejecuta en el modo kernel (por ejemplo, hardware PXN o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN ) en dispositivos que originalmente se enviaron con el nivel API 28 o superior.
  • [C-0-11] NO DEBE leer ni escribir memoria de espacio de usuario en el kernel fuera de las API de acceso de copia de usuario normal (por ejemplo, PAN de hardware o emulada a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN ) en dispositivos que originalmente se entregaban con el nivel de API 28 o superior.
  • [C-0-12] DEBE implementar el aislamiento de la tabla de páginas del kernel si el hardware es vulnerable a CVE-2017-5754 en todos los dispositivos que se envían originalmente con nivel API 28 o superior (por ejemplo, CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0 ).
  • [C-0-13] DEBE implementar un refuerzo de predicción de sucursales si el hardware es vulnerable a CVE-2017-5715 en todos los dispositivos que originalmente se enviaron con API nivel 28 o superior (por ejemplo, CONFIG_HARDEN_BRANCH_PREDICTOR ).

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE habilitar la inicialización de la pila en el kernel para evitar el uso de variables locales no inicializadas ( CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO ). Además, las implementaciones de dispositivos NO DEBEN asumir el valor utilizado por el compilador para inicializar los locales.

  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE mantener los datos del kernel que se escriben solo durante la inicialización marcados como de solo lectura después de la inicialización (por ejemplo, __ro_after_init ).

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE aleatorizar el diseño del código del kernel y la memoria, y evitar exposiciones que puedan comprometer la aleatorización (por ejemplo, CONFIG_RANDOMIZE_BASE con entropía del gestor de arranque a través del /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL ). .

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE habilitar la integridad del flujo de control (CFI) en el kernel para proporcionar protección adicional contra ataques de reutilización de código (por ejemplo, CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK ).

  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE no deshabilitar Control-Flow Integrity (CFI), Shadow Call Stack (SCS) o Integer Overflow Sanitization (IntSan) en los componentes que lo tienen habilitado.

  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE habilitar CFI, SCS e IntSan para cualquier componente adicional del espacio de usuario sensible a la seguridad, como se explica en CFI e IntSan .

  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE habilitar la inicialización de la pila en el kernel para evitar el uso de variables locales no inicializadas ( CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO ). Además, las implementaciones de dispositivos NO DEBEN asumir el valor utilizado por el compilador para inicializar los locales.

  • [C-SR-8] Se RECOMIENDA ENCARECIDAMENTE habilitar la inicialización del montón en el kernel para evitar el uso de asignaciones de montón no inicializadas ( CONFIG_INIT_ON_ALLOC_DEFAULT_ON ) y NO DEBEN asumir el valor utilizado por el kernel para inicializar esas asignaciones.

Si las implementaciones de dispositivos utilizan un kernel de Linux que sea capaz de admitir SELinux,:

  • [C-1-1] DEBE implementar SELinux.
  • [C-1-2] DEBE configurar SELinux en modo de aplicación global.
  • [C-1-3] DEBE configurar todos los dominios en modo obligatorio. No se permiten dominios en modo permisivo, incluidos dominios específicos de un dispositivo/proveedor.
  • [C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas de nunca permitir presentes dentro de la carpeta system/sepolicy proporcionada en el Proyecto de código abierto de Android (AOSP) y la política DEBE compilarse con todas las reglas de nunca permitir presentes, para ambos AOSP. Dominios SELinux, así como dominios específicos de dispositivos/proveedores.
  • [C-1-5] DEBE ejecutar aplicaciones de terceros orientadas al nivel API 28 o superior en entornos sandbox de SELinux por aplicación con restricciones de SELinux por aplicación en el directorio de datos privados de cada aplicación.
  • DEBE conservar la política SELinux predeterminada proporcionada en la carpeta system/sepolicy del proyecto de código abierto de Android y solo agregarla a esta política para su propia configuración específica del dispositivo.

Si las implementaciones de dispositivos utilizan un kernel distinto de Linux o Linux sin SELinux,:

  • [C-2-1] DEBE utilizar un sistema de control de acceso obligatorio que sea equivalente a SELinux.

Si las implementaciones de dispositivos utilizan dispositivos de E/S capaces de DMA, estos:

  • [C-SR-9] Se RECOMIENDA ENCARECIDAMENTE aislar cada dispositivo de E/S capaz de DMA, utilizando una IOMMU (por ejemplo, la SMMU ARM).

Android contiene múltiples funciones de defensa en profundidad que son parte integral de la seguridad del dispositivo. Además, Android se centra en reducir clases clave de errores comunes que contribuyen a la mala calidad y seguridad.

Para reducir errores de memoria, implementaciones de dispositivos:

  • [C-SR-10] Se RECOMIENDA ENCARECIDAMENTE probarlos utilizando herramientas de detección de errores de memoria del espacio de usuario como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ o ASan para otros tipos de dispositivos.
  • [C-SR-11] Se RECOMIENDA ENCARECIDAMENTE probarlos utilizando herramientas de detección de errores de memoria del kernel como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 o CONFIG_KASAN_GENERIC para otros tipos de dispositivos).
  • [C-SR-12] Se RECOMIENDA ENCARECIDAMENTE utilizar herramientas de detección de errores de memoria en producción como MTE, GWP-ASan y KFENCE.

Si las implementaciones de dispositivos utilizan un TEE basado en Arm TrustZone,:

  • [C-SR-13] Se RECOMIENDA ENCARECIDAMENTE utilizar un protocolo estándar para compartir memoria, entre Android y TEE, como Arm Firmware Framework para Armv8-A (FF-A).
  • [C-SR-14] Se RECOMIENDA ENCARECIDAMENTE restringir las aplicaciones confiables para que accedan únicamente a la memoria que se ha compartido explícitamente con ellas a través del protocolo anterior. Si el dispositivo admite el nivel de excepción Arm S-EL2, el administrador de partición segura debe aplicarlo. De lo contrario, TEE OS debería aplicar esto.

Iniciar nuevos requisitos

Una tecnología de seguridad de la memoria es una tecnología que mitiga al menos las siguientes clases de errores con una probabilidad alta (> 90%) en aplicaciones que usan la opción Manifiester android:memtagMode :

  • desbordamiento del búfer de montón
  • Usar después de gratis
  • Doble libre
  • Wild Free (libre de un puntero no malloc)

Implementaciones de dispositivos:

  • [C-SR-15] se recomienda encarecidamente establecer ro.arm64.memtag.bootctl_supported .

Si las implementaciones del dispositivo establecen la propiedad del sistema ro.arm64.memtag.bootctl_supported a verdadero, ellos:

  • [C-3-1] debe permitir que la propiedad del sistema arm64.memtag.bootctl acepte una lista separada por comas de los siguientes valores, con el efecto deseado aplicado en el siguiente reinicio posterior:

    • memtag : una tecnología de seguridad de memoria como se definió anteriormente está habilitado
    • memtag-once : una tecnología de seguridad de memoria como se define anteriormente está habilitada transitoriamente, y se deshabilita automáticamente, el siguiente reinicio
    • memtag-off : una tecnología de seguridad de memoria como se definió anteriormente está deshabilitado
  • [C-3-2] debe permitir que el usuario de Shell establezca arm64.memtag.bootctl .

  • [C-3-3] debe permitir que cualquier proceso lea arm64.memtag.bootctl .

  • [C-3-4] debe establecer arm64.memtag.bootctl al estado solicitado actualmente al arranque, también debe actualizar la propiedad, si la implementación del dispositivo permite modificar el estado sin cambiar la propiedad del sistema.

  • [C-SR-16] se recomienda encarecidamente para mostrar una configuración de desarrollador que establece MEMTAG-ONCE y reinicia el dispositivo. Con un gestor de arranque compatible, el proyecto de código abierto de Android cumple con los requisitos anteriores a través del protocolo de cargador de arranque MTE .

  • [C-SR-17] se recomienda encarecidamente que muestre una configuración en el menú Configuración de seguridad que permite al usuario habilitar memtag .

Finalizar los nuevos requisitos

9.8. Privacidad

9.8.1. Historial de uso

Android almacena el historial de elecciones del usuario y gestiona dicho historial mediante UsageStatsManager .

Implementaciones de dispositivos:

  • [C-0-1] DEBE mantener un período de retención razonable de dicho historial de usuario.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE mantener el período de retención de 14 días configurado de forma predeterminada en la implementación de AOSP.

Android almacena los eventos del sistema utilizando los identificadores StatsLog y administra dicho historial a través de StatsManager y la API del sistema IncidentManager .

Implementaciones de dispositivos:

  • [C-0-2] DEBE incluir solo los campos marcados con DEST_AUTOMATIC en el informe de incidentes creado por la clase IncidentManager de la API del sistema.
  • [C-0-3] No DEBE utilizar los identificadores de eventos del sistema para registrar ningún otro evento que no sea el descrito en los documentos del SDK StatsLog . Si se registran eventos adicionales del sistema, PUEDEN usar un identificador de átomo diferente en el rango entre 100.000 y 200.000.

9.8.2. Grabación

Implementaciones de dispositivos:

  • [C-0-1] NO DEBE precargar ni distribuir componentes de software listos para usar que envíen información privada del usuario (por ejemplo, pulsaciones de teclas, texto mostrado en la pantalla, informe de errores) fuera del dispositivo sin el consentimiento del usuario o notificaciones claras en curso.
  • [C-0-2] debe mostrar una advertencia del usuario y obtener un consentimiento explícito del usuario que permita que cualquier información confidencial que se muestre en la pantalla del usuario se captura habilitado que incluya exactamente el mismo mensaje que AOSP cada vez que cada vez que una sesión capture la sesión para capturar la La fundición de pantalla o la grabación de pantalla se habilitan a través de MediaProjection.createVirtualDisplay() , VirtualDeviceManager.createVirtualDisplay() o API propiadas. NO DEBE proporcionar a los usuarios la posibilidad de desactivar la visualización futura del consentimiento del usuario.
  • [C-0-3] DEBE tener una notificación continua para el usuario mientras la transmisión o grabación de pantalla está habilitada. AOSP cumple con este requisito al mostrar un ícono de notificación continua en la barra de estado.

Iniciar nuevos requisitos

  • [C-SR-1] se recomienda encarecidamente mostrar una advertencia del usuario que es exactamente el mismo mensaje implementado en AOSP, pero puede modificarse siempre que el mensaje advierte claramente al usuario que se captura cualquier información confidencial en la pantalla del usuario.

  • [C-0-4] no debe proporcionar a los usuarios la posibilidad de deshabilitar las indicaciones futuras del consentimiento del usuario para capturar la pantalla, a menos que la sesión sea iniciada por una aplicación del sistema que el usuario ha permitido associate() con android.app.role.COMPANION_DEVICE_APP_STREAMING o el perfil del dispositivo android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING Device.

    Finalizar los nuevos requisitos

Si las implementaciones del dispositivo incluyen la funcionalidad en el sistema que captura el contenido que se muestra en la pantalla y/o registra la transmisión de audio reproducida en el dispositivo que no sea a través del sistema API ContentCaptureService , u otros medios patentados descritos en la Sección 9.8.6 OS y datos ambientales , ellos:

  • [C-1-1] DEBE tener una notificación continua para el usuario siempre que esta funcionalidad esté habilitada y esté capturando/grabando activamente.

Si las implementaciones de dispositivos incluyen un componente habilitado de fábrica, capaz de grabar audio ambiental y/o grabar el audio reproducido en el dispositivo para inferir información útil sobre el contexto del usuario, ellos:

  • [C-2-1] NO DEBE almacenar en un almacenamiento persistente en el dispositivo ni transmitir fuera del dispositivo el audio sin procesar grabado ni ningún formato que pueda volver a convertirse al audio original o casi a un facsímil, excepto con el consentimiento explícito del usuario.

Un "indicador de micrófono" se refiere a una vista en la pantalla, que es constantemente visible para el usuario y no puede oscurecerse, que los usuarios entienden como si un micrófono estuviera en uso (a través de texto, color, ícono o alguna combinación únicos).

Un "indicador de cámara" se refiere a una vista en la pantalla, que es constantemente visible para el usuario y no puede ser ocultada, que los usuarios entienden cuando una cámara está en uso (a través de texto, color, ícono o alguna combinación únicos).

Después del primer segundo mostrado, un indicador puede cambiar visualmente, como hacerse más pequeño, y no es necesario que se muestre como se presentó y entendió originalmente.

El indicador del micrófono se puede fusionar con un indicador de la cámara que se muestra activamente, siempre que el texto, los íconos o los colores indiquen al usuario que el uso del micrófono ha comenzado.

El indicador de la cámara se puede fusionar con un indicador de micrófono que se muestra activamente, siempre que el texto, los íconos o los colores indiquen al usuario que el uso de la cámara ha comenzado.

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede HotwordDetectionService , SOURCE_HOTWORD , ContentCaptureService o aplicaciones que desempeñan las funciones mencionadas. en la Sección 9.1 Permisos con identificador CDD [C-3-X]. .
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE mostrar la lista de aplicaciones recientes y activas que usan el micrófono tal como se devuelve desde PermissionManager.getIndicatorAppOpUsageData() , junto con los mensajes de atribución asociados con ellas.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE no ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

Si las implementaciones de dispositivos declaran android.hardware.camera.any ,:

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando solo acceden a la cámara las aplicaciones que desempeñan las funciones mencionadas en la Sección 9.1 Permisos con identificador CDD [ C-3-X].
  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE mostrar aplicaciones recientes y activas usando la cámara tal como se devuelven desde PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE no ocultar el indicador de la cámara para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

9.8.3. Conectividad

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB,:

  • [C-1-1] 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.8.4. Tráfico de red

Implementaciones de dispositivos:

  • [C-0-1] DEBE preinstalar los mismos certificados raíz para el almacén de la Autoridad de certificación (CA) de confianza del sistema que se proporcionan en el Proyecto de código abierto de Android ascendente.
  • [C-0-2] DEBE enviarse con un almacén de CA raíz de usuario vacío.
  • [C-0-3] DEBE mostrar una advertencia al usuario indicando que el tráfico de la red puede ser monitoreado cuando se agrega una CA raíz de usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones del dispositivo:

  • [C-1-1] DEBE mostrar una advertencia al usuario que indique:
    • Ese tráfico de red puede ser monitoreado.
    • Ese tráfico de red se enruta a través de la aplicación VPN específica que proporciona la VPN.

Si las implementaciones de dispositivos tienen un mecanismo, habilitado de forma predeterminada, que enruta el tráfico de datos de la red a través de un servidor proxy o una puerta de enlace VPN (por ejemplo, precargando un servicio VPN con android.permission.CONTROL_VPN otorgado), ellos:

  • [C-2-1] DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el Controlador de políticas de dispositivo habilite esa VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage() , en cuyo caso el usuario no necesita proporcionar un consentimiento por separado. pero sólo DEBE ser notificado.

Si las implementaciones de dispositivos implementan la posibilidad de que el usuario active la función "VPN siempre activa" de una aplicación VPN de terceros, ellos:

  • [C-3-1] DEBE deshabilitar esta prestación de usuario para aplicaciones que no admiten el servicio VPN siempre activo en el archivo AndroidManifest.xml configurando el atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON en false .

9.8.5. Identificadores de dispositivos

Implementaciones de dispositivos:

  • [C-0-1] DEBE impedir el acceso al número de serie del dispositivo y, cuando corresponda, IMEI/MEID, número de serie de SIM e identidad de suscriptor móvil internacional (IMSI) desde una aplicación, a menos que cumpla con uno de los siguientes requisitos:
    • es una aplicación de operador firmada y verificada por los fabricantes de dispositivos.
    • se le ha concedido el permiso READ_PRIVILEGED_PHONE_STATE .
    • tiene privilegios de operador como se define en Privilegios de operador de la UICC .
    • es el propietario de un dispositivo o propietario de un perfil al que se le ha concedido el permiso READ_PHONE_STATE .
    • (Solo para número de serie SIM/ICCID) tiene el requisito de las regulaciones locales de que la aplicación detecte cambios en la identidad del suscriptor.

9.8.6. Captura de contenido y búsqueda de aplicaciones Nivel OS y datos ambientales

Android, a través de la API del sistema , ContentCaptureService , AugmentedAutofillService , AppSearchGlobalManager.query , o por otros medios patentados , admite un mecanismo para las implementaciones de dispositivos para capturar las siguientes interacciones de datos entre las aplicaciones y los datos confidenciales del usuario:

  • Texto y gráficos representados en pantalla, incluidos, entre otros, notificaciones y datos de asistencia a través de AssistStructure API.
  • Datos multimedia, como audio o vídeo, grabados o reproducidos por el dispositivo.
  • Eventos de entrada (por ejemplo, tecla, mouse, gesto, voz, video y accesibilidad).

Iniciar nuevos requisitos

  • Cualquier pantalla u otros datos enviados a través del AugmentedAutofillService al sistema.
  • Cualquier pantalla u otros datos accesibles a través de la API Content Capture .
  • Cualquier pantalla u otros datos accesibles a través de FieldClassificationService API
  • Cualquier datos de aplicación pasados ​​al sistema a través de la API AppSearchManager y accesible a través de AppSearchGlobalManager.query .

Finalizar los nuevos requisitos

  • Cualquier otro evento que una aplicación proporcione al sistema a través de la API Content Capture o la API AppSearchManager , una API patentada y de Android con capacidad similar.

  • Cualquier texto u otros datos enviados a través de la TextClassifier API al System TextClassifier, es decir, al servicio del sistema para comprender el significado del texto, además de generar las próximas acciones previstas en función del texto.
  • Datos indexados por la implementación de la plataforma AppSearch, incluidos, entre otros, texto, gráficos, datos multimedia u otros datos similares.

Iniciar nuevos requisitos

  • Los datos de audio obtenidos como resultado del uso de SpeechRecognizer#onDeviceSpeechRecognizer() por la implementación del reconocimiento de voz.
  • Datos de audio obtenidos en segundo plano (continuamente) a través AudioRecord , SoundTrigger u otras API de audio, y no dio como resultado un indicador visible del usuario
  • Datos de la cámara obtenidos en el fondo (continuamente) a través del camarógrafo u otras API de la cámara, y no dan como resultado un indicador visible del usuario

Finalizar los nuevos requisitos

Si las implementaciones de dispositivos capturan alguno de los datos anteriores, ellos:

  • [C-1-1] debe cifrar todos esos datos cuando se almacenan en el dispositivo. Este cifrado PUEDE realizarse utilizando el cifrado basado en archivos de Android o cualquiera de los cifrados enumerados como API versión 26+ descritos en Cipher SDK .
  • [C-1-2] no debe hacer una copia de seguridad de datos sin procesar o cifrados utilizando métodos de copia de seguridad de Android o cualquier otro método de copia de seguridad.
  • [C-1-3] solo debe enviar todos estos datos y la sesión de la sesión del dispositivo utilizando un mecanismo de preservación de la privacidad , excepto con el consentimiento explícito del usuario cada vez que se comparten los datos . El mecanismo de preservación de la privacidad se define como "aquellos que permiten sólo el análisis en conjunto e impiden la comparación de eventos registrados o resultados derivados con usuarios individuales", para evitar que los datos por usuario sean introspectables (por ejemplo, implementados utilizando una tecnología de privacidad diferencial como RAPPOR ).
  • [C-1-4] no debe asociar dichos datos con ninguna identidad del usuario (como Account ) en el dispositivo, excepto con el consentimiento explícito del usuario cada vez que se asocian los datos.
  • [C-1-5] no debe compartir dichos datos con otros componentes del sistema operativo que no sigan los requisitos descritos en la sección actual (9.8.6 Contenido Capture los datos del nivel del sistema operativo y ambiental ), excepto con el consentimiento explícito del usuario cada vez que es compartido. A menos que dicha funcionalidad se construya como una API SDK de Android ( AmbientContext , HotwordDetectionService ).
  • [C-1-6] debe proporcionar el servicio del usuario para borrar dichos datos que la implementación ContentCaptureService o el medio de propiedad se recopile si cuando los datos se almacenan en cualquier forma en el dispositivo. Si el usuario elige borrar los datos, debe eliminar todos los datos históricos recopilados.
  • [C-1-7] debe proporcionar una posibilidad del usuario para optar por la salida de los datos, recopilados a través de AppSearch o medios propietarios de que se muestren en Android Platform EG Launcher.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE NO solicitar permiso de INTERNET.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE acceder a Internet únicamente a través de API estructuradas respaldadas por implementaciones de código abierto disponibles públicamente.

Iniciar nuevos requisitos

  • [C-SR-3] se recomienda que se implementen con API SDK de Android o un repositorio de código abierto de propiedad OEM similar; y / o realizarse en una implementación de sandboxed (ver 9.8.15 implementaciones de API de sandboxed).

Finalizar los nuevos requisitos

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema ContentCaptureService , AppSearchManager.index o cualquier servicio propietario que capture los datos como se describe anteriormente, ellos:

  • [C-1-1] NO DEBE permitir que los usuarios reemplacen los servicios con una aplicación o servicio instalable por el usuario y DEBE permitir solo que los servicios preinstalados capturen dichos datos.
  • [C-1-2] NO DEBE permitir que ninguna aplicación que no sea el mecanismo de servicios preinstalados pueda capturar dichos datos.
  • [C-1-3] DEBE proporcionar al usuario la posibilidad de desactivar los servicios.
  • [C-1-4] NO DEBE omitir la posibilidad de que el usuario administre los permisos de Android que poseen los servicios y siga el modelo de permisos de Android como se describe en la Sección 9.1. Permiso .
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE mantener los servicios separados de otros componentes del sistema (por ejemplo, no vincular el servicio ni compartir ID de proceso), excepto lo siguiente:

    • Telefonía, contactos, interfaz de usuario del sistema y medios

Android, a través de SpeechRecognizer#onDeviceSpeechRecognizer() brinda la capacidad de realizar reconocimiento de voz en el dispositivo, sin involucrar a la red. Cualquier implementación de SpeechRecognizer en el dispositivo DEBE seguir las políticas descritas en esta sección.

9.8.7. Acceso al portapapeles

Implementaciones de dispositivos:

  • [C-0-1] NO DEBE devolver datos recortados del portapapeles (por ejemplo, a través de la API ClipboardManager ) a menos que la aplicación de terceros sea el IME predeterminado o sea la aplicación que actualmente tiene el foco.

  • [C-0-2] DEBE borrar los datos del portapapeles como máximo 60 minutos después de que se colocaron en un portapapeles por última vez o se leyeron desde un portapapeles.

9.8.8. Ubicación

La ubicación incluye información en la clase Ubicación de Android (como Latitud, Longitud, Altitud), así como identificadores que se pueden convertir en Ubicación. La ubicación puede ser tan precisa como DGPS (Sistema de posicionamiento global diferencial) o tan aproximada como las ubicaciones a nivel de país (como la ubicación del código de país - MCC - Código de país móvil).

La siguiente es una lista de tipos de ubicación que derivan directamente la ubicación de un usuario o se pueden convertir a la ubicación de un usuario. Esta no es una lista completa, pero debe usarse como ejemplo de de qué ubicación se puede derivar directa o indirectamente:

  • GPS/GNSS/DGPS/PPP
    • Solución de posicionamiento global o sistema de navegación global por satélite o solución de posicionamiento global diferencial
    • Esto también incluye mediciones GNSS sin procesar y estado GNSS.
      • La ubicación precisa se puede derivar de las mediciones GNSS sin procesar
  • Tecnologías inalámbricas con identificadores únicos como:
    • Puntos de acceso WiFi (MAC, BSSID, Nombre o SSID)
    • Bluetooth/BLE (MAC, BSSID, Nombre o SSID)
    • UWB (MAC, BSSID, Nombre o SSID)
    • ID de torre celular (3G, 4G, 5G… I, incluidas todas las tecnologías futuras de módem celular que tengan identificadores únicos)

Como punto de referencia principal, consulte las API de Android que requieren permisos ACCESS_FINE_Location o ACCESS_COARSE_Location.

Implementaciones de dispositivos:

  • [C-0-1] NO DEBE activar/desactivar la configuración de ubicación del dispositivo y la configuración de escaneo de Wi-Fi/Bluetooth sin el consentimiento o la iniciación explícitos del usuario.
  • [C-0-2] DEBE proporcionar al usuario la posibilidad de acceder a información relacionada con la ubicación, incluidas solicitudes de ubicación recientes, permisos a nivel de aplicación y uso de escaneo de Wi-Fi/Bluetooth para determinar la ubicación.
  • [C-0-3] DEBE garantizar que la aplicación que utiliza la API de derivación de ubicación de emergencia [LocationRequest.setLocationSettingsIgnored()] sea una sesión de emergencia iniciada por el usuario (por ejemplo, marque el 911 o envíe un mensaje de texto al 911). Sin embargo, para el sector automotriz, un vehículo PUEDE iniciar una sesión de emergencia sin interacción activa del usuario en caso de que se detecte un accidente (por ejemplo, para satisfacer los requisitos de eCall).
  • [C-0-4] DEBE preservar la capacidad de la API de omisión de ubicación de emergencia para omitir la configuración de ubicación del dispositivo sin cambiar la configuración.
  • [C-0-5] DEBE programar una notificación que recuerde al usuario después de que una aplicación en segundo plano haya accedido a su ubicación utilizando el permiso [ ACCESS_BACKGROUND_LOCATION ].

9.8.9. Aplicaciones instaladas

Las aplicaciones de Android orientadas al nivel API 30 o superior no pueden ver detalles sobre otras aplicaciones instaladas de forma predeterminada (consulte Visibilidad del paquete en la documentación del SDK de Android).

Implementaciones de dispositivos:

  • [C-0-1] NO DEBE exponer a ninguna aplicación orientada al nivel API 30 o superior detalles sobre cualquier otra aplicación instalada, a menos que la aplicación ya pueda ver detalles sobre la otra aplicación instalada a través de las API administradas. Esto incluye, entre otros, detalles expuestos por cualquier API personalizada agregada por el implementador del dispositivo o accesible a través del sistema de archivos.
  • [C-0-2] NO DEBE otorgar a ninguna aplicación acceso de lectura o escritura a archivos en el directorio dedicado y específico de cualquier otra aplicación dentro del almacenamiento externo. Las únicas excepciones son las siguientes:
    • La autoridad del proveedor de almacenamiento externo (por ejemplo, aplicaciones como DocumentsUI).
    • Proveedor de descargas que utiliza la autoridad del proveedor de "descargas" para descargar archivos al almacenamiento de aplicaciones.
    • Aplicaciones de protocolo de transferencia de medios (MTP) firmadas por plataforma que utilizan el permiso privilegiado ACCESS_MTP para permitir la transferencia de archivos a otro dispositivo.
    • Las aplicaciones que instalan otras aplicaciones y tienen el permiso INSTALL_PACKAGES solo pueden acceder a directorios "obb" con el fin de administrar archivos de expansión APK .

9.8.10. Informe de error de conectividad

Si las implementaciones de dispositivos declaran el indicador de función android.hardware.telephony ,:

  • [C-1-1] DEBE admitir la generación de informes de errores de conectividad a través de BUGREPORT_MODE_TELEPHONY con BugreportManager.
  • [C-1-2] DEBE obtener el consentimiento del usuario cada vez que se utiliza BUGREPORT_MODE_TELEPHONY para generar un informe y NO DEBE solicitar al usuario que dé su consentimiento a todas las solicitudes futuras de la aplicación.
  • [C-1-3] NO DEBE devolver el informe generado a la aplicación solicitante sin el consentimiento explícito del usuario.
  • [C-1-4] Los informes generados utilizando BUGREPORT_MODE_TELEPHONY DEBEN contener al menos la siguiente información:
    • Volcado TelephonyDebugService
    • Volcado TelephonyRegistry
    • WifiService
    • Volcado ConnectivityService
    • Un volcado de la instancia CarrierService del paquete que realiza la llamada (si está vinculada)
    • Búfer de registro de radio
    • SubscriptionManagerService vertedero
  • [C-1-5] NO DEBE incluir lo siguiente en los informes generados:
    • Cualquier tipo de información que no esté directamente relacionada con la depuración de conectividad.
    • Cualquier tipo de registros de tráfico de aplicaciones instaladas por el usuario o perfiles detallados de aplicaciones/paquetes instalados por el usuario (los UID están bien, los nombres de los paquetes no).
  • PUEDE incluir información adicional que no esté asociada con ninguna identidad de usuario. (por ejemplo, registros de proveedores).

Si las implementaciones de dispositivos incluyen información adicional (por ejemplo, registros de proveedores) en los informes de errores y esa información tiene un impacto en la privacidad/seguridad/batería/almacenamiento/memoria,:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE tener una configuración de desarrollador deshabilitada de forma predeterminada. La implementación de referencia de AOSP cumple con esto al proporcionar la opción Enable verbose vendor logging en la configuración del desarrollador para incluir registros de proveedores adicionales específicos del dispositivo en los informes de errores.

9.8.11. Intercambio de blobs de datos

Android, a través de BlobStoreManager , permite que las aplicaciones aporten blobs de datos al sistema para compartirlos con un conjunto seleccionado de aplicaciones.

Si las implementaciones de dispositivos admiten blobs de datos compartidos como se describe en la documentación del SDK ,:

9.8.12. Reconocimiento de música

Android, a través de la API del sistema MusicRecognitionManager, admite un mecanismo para que las implementaciones de dispositivos soliciten reconocimiento de música, dada una grabación de audio, y delegue el reconocimiento de música a una aplicación privilegiada que implemente la API MusicRecognitionService.

Si las implementaciones de dispositivos incluyen un servicio que implementa System API MusicRecognitionManager o cualquier servicio propietario que transmita datos de audio como se describe anteriormente, ellos:

  • [C-1-1] DEBE exigir que la persona que llama a MusicRecognitionManager tenga el permiso MANAGE_MUSIC_RECOGNITION
  • [C-1-2] DEBE exigir que una única aplicación de reconocimiento de música preinstalada implemente MusicRecognitionService.
  • [C-1-3] NO DEBE permitir que los usuarios reemplacen MusicRecognitionManagerService o MusicRecognitionService con una aplicación o servicio instalable por el usuario.
  • [C-1-4] DEBE garantizar que cuando MusicRecognitionManagerService acceda al registro de audio y lo reenvíe a la aplicación que implementa MusicRecognitionService, el acceso al audio se rastree mediante invocaciones de AppOpsManager.noteOp / startOp .

Si las implementaciones de dispositivos de MusicRecognitionManagerService o MusicRecognitionService almacenan datos de audio capturados,:

  • [C-2-1] NO DEBE almacenar ningún audio sin procesar ni huellas digitales de audio en el disco, ni en la memoria durante más de 14 días.
  • [C-2-2] NO DEBE compartir dichos datos más allá de MusicRecognitionService, excepto con el consentimiento explícito del usuario cada vez que se comparta.

9.8.13. Administrador de privacidad del sensor

Si las implementaciones de dispositivos brindan al usuario la posibilidad de software para apagar la cámara y/o la entrada del micrófono para la implementación del dispositivo, ellos:

  • [C-1-1] DEBE devolver con precisión "verdadero" para el método API de soportesSensorToggle() relevante.
  • [C-1-2] DEBE, cuando una aplicación intenta acceder a un micrófono o cámara bloqueados, presentar al usuario una opción de usuario no descartable que indique claramente que el sensor está bloqueado y requiere la opción de continuar bloqueando o desbloqueando según la implementación de AOSP que cumpla con este requisito.
  • [C-1-3] DEBE pasar únicamente datos de audio y cámara en blanco (o falsos) a las aplicaciones y no informar un código de error debido a que el usuario no enciende la cámara ni el micrófono a través de las posibilidades de usuario presentadas según [C-1-2 ] arriba.

Iniciar nuevos requisitos

9.8.14. Administrador de Credenciales

Remoto.

9.8.15. Implementaciones de API de sandboxed

Android, a través de un conjunto de API delegadas, proporciona un mecanismo para procesar datos seguros de nivel de sistema operativo y ambiental. Dicho procesamiento puede delegarse a un APK preinstalado con acceso privilegiado y capacidades de comunicación reducidas, conocidas como implementación de API de sandboxed.

Cualquier implementación de API de sandboxed:

  • [C-0-1] no debe solicitar el permiso de Internet.
  • [C-0-2] solo debe acceder a Internet a través de API estructuradas respaldadas por implementaciones de código abierto disponibles públicamente utilizando mecanismos de preservación de la privacidad, o indirectamente a través de API SDK de Android. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o los resultados derivados a los usuarios individuales", para evitar que los datos por usuario sean introspectables (por ejemplo, implementados utilizando una tecnología de privacidad diferencial como RAPOR ).
  • [C-0-3] debe mantener los servicios separados de otros componentes del sistema (por ejemplo, no vincular el servicio o compartir ID de proceso), excepto los siguientes:
    • Telefonía, contactos, interfaz de usuario del sistema y medios
  • [C-0-4] no debe permitir a los usuarios reemplazar los servicios con una aplicación o servicio instalable por el usuario
  • [C-0-5] solo debe permitir que los servicios preinstalados capturen dichos datos. A menos que la capacidad de reemplazo esté integrada en AOSP (por ejemplo, para aplicaciones de asistente digital).
  • [C-0-6] no debe permitir que ninguna aplicación que no sea el mecanismo de servicios preinstalado pueda capturar dichos datos. A menos que dicha capacidad de captura se implementa con una API SDK de Android.
  • [C-0-7] debe proporcionar el objetivo del usuario para deshabilitar los servicios.
  • [C-0-8] no debe omitir el acceso del usuario para administrar los permisos de Android que mantienen los servicios y seguir el modelo de permisos de Android como se describe en la Sección 9.1. Permiso .

9.8.16. Datos continuos de audio y cámara

Además de los requisitos que se describen en 9.8.2 grabación, 9.8.6 datos de nivel de sistema operativo y ambiental, y 9.8.15 implementaciones de API de sandboxed, implementaciones que utilizan datos de audio obtenidos en segundo plano (continuamente) a través de Audiorecord, SoundRigger u otras API de audio O datos de la cámara obtenidos en el fondo (continuamente) a través del camarógrafo u otras API de la cámara:

  • [C-0-1] debe hacer cumplir un indicador correspondiente (cámara y/o micrófono según la Sección 9.8.2 Grabación), a menos:
  • [C-SR-1] se recomienda encarecidamente que requiera el consentimiento del usuario para cada funcionalidad que utilice dichos datos y se deshabilite de forma predeterminada.
  • [C-SR-2] se recomienda aplicar el mismo tratamiento (es decir, siga las restricciones descritas en 9.8.2 grabación, 9.8.6 datos de nivel de sistema operativo y ambiental, 9.8.15 implementaciones de API de arena y 9.8.16 audio continuo y continuo Datos de la cámara) a los datos de la cámara que provienen de un dispositivo portátil remoto.

Si los datos de la cámara se suministran desde un dispositivo portátil remoto y se accede en una forma no cifrada fuera del sistema operativo Android, implementación de sandboxed o una funcionalidad de sandboxed creada por WearableSensingManager , entonces ellos:

  • [C-1-1] debe indicar al dispositivo portátil remoto para mostrar un indicador adicional allí.

Si los dispositivos proporcionan capacidad para interactuar con una aplicación de asistente digital sin la palabra clave asignada (ya sea manejando consultas genéricas de usuario o analizar la presencia del usuario a través de la cámara):

  • [C-2-1] debe garantizar que dicha implementación sea proporcionada por un paquete que contenga el rol android.app.role.ASSISTANT .
  • [C-2-2] debe garantizar que dicha implementación utilice HotwordDetectionService y/o VisualQueryDetectionService API de Android.

9.8.17. Telemetria

Android almacena el sistema y los registros de aplicaciones utilizando API STATSLOG. Estos registros se administran a través de las API StatsManager que pueden ser utilizadas por aplicaciones de sistemas privilegiadas.

StatsManager también proporciona una forma de recopilar datos clasificados como sensibles a la privacidad de los dispositivos con un mecanismo de preservación de privacidad. En particular, StatsManager::query API proporciona la capacidad de consultar categorías de métricas restringidas definidas en STATSLOG .

Cualquier consulta de implementación y recopilación de métricas restringidas de Statsmanager:

  • [C-0-1] debe ser la única aplicación/implementación en el dispositivo y mantener el permiso READ_RESTRICTED_STATS .
  • [C-0-2] solo debe enviar datos de telemetría y el registro del dispositivo utilizando un mecanismo de preservación de la privacidad. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o los resultados derivados a los usuarios individuales", para evitar que los datos por usuario sean introspectables (por ejemplo, implementados utilizando una tecnología de privacidad diferencial como RAPOR ).
  • [C-0-3] no debe asociar dichos datos con ninguna identidad del usuario (como la cuenta ) en el dispositivo.
  • [C-0-4] no debe compartir dichos datos con otros componentes del sistema operativo que no sigan los requisitos descritos en la sección actual (9.8.17 Telemetría de preservación de la privacidad).
  • [C-0-5] debe proporcionar una posibilidad del usuario para habilitar/deshabilitar la recopilación, uso y intercambio de telemetría de preservación de la privacidad.
  • [C-0-6] debe proporcionar el servicio del usuario para borrar dichos datos que la implementación recopila si los datos se almacenan en cualquier formulario en el dispositivo. Si el usuario eligió borrar los datos, debe eliminar todos los datos actualmente almacenados en el dispositivo.
  • [C-0-7] debe revelar la implementación subyacente de protocolo de preservación de la privacidad en un repositorio de código abierto.
  • [C-0-8] debe hacer cumplir las políticas de salida de datos en esta sección a la recopilación de datos de compuerta en categorías de métricas restringidas definidas en STATSLOG .

Finalizar los nuevos requisitos

9.9. Cifrado de almacenamiento de datos

Todos los dispositivos DEBEN cumplir con los requisitos de la sección 9.9.1. Los dispositivos que se iniciaron en un nivel API anterior al de este documento están exentos de los requisitos de las secciones 9.9.2 y 9.9.3; en su lugar, DEBEN cumplir con los requisitos de la sección 9.9 del documento de Definición de compatibilidad de Android correspondiente al nivel de API en el que se lanzó el dispositivo.

9.9.1. Arranque directo

Implementaciones de dispositivos:

  • [C-0-1] DEBE implementar las API del modo de inicio directo incluso si no admiten el cifrado de almacenamiento.

  • [C-0-2] Los intentos ACTION_LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED DEBEN transmitirse aún para indicar a las aplicaciones con arranque directo que las ubicaciones de almacenamiento cifradas por dispositivo (DE) y cifradas con credenciales (CE) están disponibles para el usuario.

9.9.2. Requisitos de cifrado

Implementaciones de dispositivos:

  • [C-0-1] DEBE cifrar los datos privados de la aplicación (partición /data ), así como la partición de almacenamiento compartido de la aplicación (partición /sdcard ) si es una parte permanente y no extraíble del dispositivo.
  • [C-0-2] DEBE habilitar el cifrado de almacenamiento de datos de forma predeterminada en el momento en que el usuario haya completado la experiencia de configuración inmediata.
  • [C-0-3] DEBE cumplir con el requisito de cifrado de almacenamiento de datos anterior implementando uno de los dos métodos de cifrado siguientes:

9.9.3. Métodos de cifrado

Si las implementaciones de dispositivos están cifradas:

  • [C-1-1] DEBE iniciarse sin solicitar credenciales al usuario y permitir que las aplicaciones compatibles con el inicio directo accedan al almacenamiento cifrado del dispositivo (DE) después de que se transmita el mensaje ACTION_LOCKED_BOOT_COMPLETED .
  • [C-1-2] DEBE permitir el acceso al almacenamiento con credenciales cifradas (CE) solo después de que el usuario haya desbloqueado el dispositivo proporcionando sus credenciales (por ejemplo, código de acceso, PIN, patrón o huella digital) y se transmita el men