A partir de 2026, para alinearnos con nuestro modelo de desarrollo estable de la rama principal y garantizar la estabilidad de la plataforma para el ecosistema, publicaremos el código fuente en AOSP en el segundo y cuarto trimestre. Para compilar AOSP y contribuir a él, te recomendamos que utilices android-latest-release en lugar de aosp-main. La rama del manifiesto android-latest-release siempre hará referencia a la versión más reciente que se envió al AOSP. Para obtener más información, consulta Cambios en AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Definición de compatibilidad con Android 17 [VERSIÓN PRELIMINAR]

1. Introducción

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

El uso de "DEBE", "NO DEBE", "SE REQUIERE", "SE DEBERÁ", "NO SE DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" se ajusta al estándar IETF definido en el RFC2119.

Según se usa en este documento, un "implementador de dispositivos" o "implementador" es una persona u organización que desarrolla una solución de hardware o software que ejecuta Android 17. Una "implementación del dispositivo" o "implementación" es la solución de hardware o software que se desarrolla.

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

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

Por este motivo, el Proyecto de código abierto de Android es la implementación de referencia y preferida de Android. Se RECOMIENDA ENCARECIDAMENTE a los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente "upstream" disponible en el Proyecto de código abierto de Android. Si bien algunos componentes se pueden reemplazar hipotéticamente por implementaciones alternativas, se RECOMIENDA ENCARECIDAMENTE no seguir esta práctica, ya que aprobar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento total con la implementación estándar de Android, lo que incluye el Conjunto de pruebas de compatibilidad y otros aspectos. Por último, ten 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 de la documentación de ese SDK. En todos los casos en los que esta Definición de Compatibilidad o el Conjunto de Pruebas de Compatibilidad no coincidan con la documentación del SDK, se considerará que la documentación del SDK es la fuente autorizada. Todos los detalles técnicos que se proporcionan en los recursos vinculados a lo largo de este documento se consideran parte de esta Definición de Compatibilidad por inclusión.

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 de forma universal a cualquier implementación de dispositivos Android, se enumeran en las secciones posteriores a la Sección 2. En este documento, se hace referencia a estos requisitos como "Requisitos principales".

1.1.2. ID del requisito

El ID de requisito se asigna a los requisitos de tipo MUST.

El ID se asigna solo para los requisitos OBLIGATORIOS.
Los requisitos ALTAMENTE RECOMENDADOS se marcan como [SR], pero no se les asigna un ID.
El ID consta de los siguientes elementos : ID de tipo de dispositivo - ID de condición - ID de requisito (p.ej., C-0-1).

Cada ID se define de la siguiente manera:

ID de tipo de dispositivo (obtén más información en 2. Tipos de dispositivos)
- C: Core (requisitos que se aplican a todas las implementaciones de dispositivos Android)
- H: Dispositivo Android de mano
- T: Dispositivo Android Television
- R.: Implementación de Android Automotive
- W: Implementación de Android Watch
- Pestaña: Implementación en tablets 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 1ª condición y el número aumenta en 1 dentro de la misma sección y el mismo tipo de dispositivo.
ID del requisito
- Este ID comienza en 1 y se incrementa 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 IDs de requisitos de la sección 2 tienen dos partes. El primer valor corresponde a un ID de sección, como se describió anteriormente. La segunda parte identifica el factor de forma y el requisito específico del factor de forma.

ID de sección seguido del ID de requisito que se describió anteriormente.

El ID de la sección 2 consta de lo siguiente: ID de sección / ID de tipo de dispositivo - ID de condición - ID de requisito (p.ej., 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 usar para una variedad de tipos de dispositivos y factores de forma. Para admitir la seguridad en los dispositivos, se espera que la pila de software, incluido cualquier SO de reemplazo o una implementación alternativa del kernel, se ejecute en un entorno seguro, como se describe en la sección 9 y en otras partes de este CDD. Existen algunos tipos de dispositivos que tienen un ecosistema de distribución de aplicaciones relativamente mejor establecido.

En esta sección, se describen esos tipos de dispositivos, así como los requisitos y las recomendaciones adicionales aplicables a cada uno.

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

2.1 Configuraciones del dispositivo

Para conocer las principales diferencias en la configuración de hardware según el tipo de dispositivo, consulta los requisitos específicos del dispositivo que se indican a continuación en esta sección.

2.2. Requisitos para dispositivos portátiles

Un dispositivo de mano Android hace referencia a una implementación de dispositivo Android que se suele usar sosteniéndolo en la mano, como un reproductor de MP3, un teléfono o una tablet.

Las implementaciones de dispositivos Android se clasifican como dispositivos portátiles si cumplen con todos los criterios que se indican a continuación:

Tener una fuente de alimentación que proporcione movilidad, como una batería
Tener un tamaño de pantalla diagonal física en el rango de 4 a 8 pulgadas
Tener una interfaz de entrada táctil

Los requisitos adicionales que se indican en el resto de esta sección son específicos para las implementaciones de dispositivos de mano Android.

2.2.1. Hardware

Implementaciones de dispositivos de mano:

[7.1.1.1/H-0-1] DEBE tener al menos una pantalla compatible con Android que mida al menos 5.58 cm (2.2 pulgadas) en el borde corto y 8.63 cm (3.4 pulgadas) en el borde largo.
[7.1.1.3/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar a los usuarios una opción para cambiar el tamaño de la pantalla (densidad de pantalla).
[7.1.1.1/H-0-2] DEBE admitir la composición de GPU de búferes gráficos que sean al menos tan grandes como la resolución más alta de cualquier pantalla integrada.
[7.1.1.1/H-0-3]^* DEBE asignar cada pantalla UI_MODE_NORMAL disponible para aplicaciones de terceros a un área de pantalla física sin obstrucciones que tenga al menos 5.58 cm (2.2 in) en el borde más corto y 8.64 cm (3.4 in) en el borde más largo.
[7.1.1.3/H-0-1]^* DEBE establecer DENSITY_DEVICE_STABLE en un 92% o más de la densidad física real de la pantalla correspondiente.

Si las implementaciones de dispositivos de mano incluyen compatibilidad con Vulkan, deben cumplir con los siguientes requisitos:

[7.1.4.2/H-1-1] DEBE satisfacer los requisitos especificados por el perfil de Baseline de Android 2021.

Si las implementaciones de dispositivos de mano declaran compatibilidad con cualquier ABI de 64 bits (con o sin ninguna ABI de 32 bits) y devuelven false para ActivityManager.isLowRamDevice(), :

[7.1.4.2/H-2-1] DEBE admitir Vulkan 1.1 o versiones posteriores.

Si las implementaciones de dispositivos de mano afirman que admiten pantallas de alto rango dinámico a través de Configuration.isScreenHdr(), deben cumplir con lo siguiente:

[7.1.4.5/H-1-1] DEBE anunciar la compatibilidad con 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 de mano:

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

Si las implementaciones de dispositivos de mano declaran compatibilidad a través de una propiedad del sistema graphics.gpu.profiler.support, deben cumplir con lo siguiente:

[7.1.4.6/H-1-1] DEBE informar como resultado un registro de protobuf que cumpla con el esquema para los contadores de GPU y las etapas de procesamiento de GPU definidos en la documentación de Perfetto.
[7.1.4.6/H-1-2] DEBE informar valores conformes para los contadores de GPU del dispositivo según el proto del paquete gpu counter trace.
[7.1.4.6/H-1-3] DEBE informar valores conformes para los RenderStages de la GPU del dispositivo según el proto de paquetes de registro de etapas de renderización.
[7.1.4.6/H-1-4] DEBE informar un punto de seguimiento de frecuencia de GPU como se especifica en el formato: power/gpu_frequency.

Implementaciones de dispositivos de mano:

[7.1.5/H-0-1] DEBE incluir compatibilidad con el modo de compatibilidad de aplicaciones heredadas tal como se implementa en el código fuente abierto de Android upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los activadores ni los 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 compatibilidad con aplicaciones de Editor de método de entrada (IME) de terceros.
[7.2.3/H-0-2] DEBE enviar el evento de presión normal y prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano. El sistema NO DEBE consumir estos eventos, y se PUEDEN activar desde fuera del dispositivo Android (p.ej., un teclado de hardware externo conectado al dispositivo Android).
[7.2.3/H-0-3] DEBE proporcionar la función de inicio en todas las pantallas compatibles con Android que proporcionen la pantalla principal.
[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 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 app que implementa VoiceInteractionService o una actividad que controla ACTION_ASSIST con la pulsación prolongada de KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no controla esos eventos de pulsación prolongada.
[7.3.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos de mano incluyen un acelerómetro de 3 ejes, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos de mano incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, deben cumplir con lo siguiente:

[7.3.3/H-2-1] DEBE informar las mediciones de GNSS tan pronto como se encuentren, incluso si aún no se informó una ubicación calculada a partir de GPS/GNSS.
[7.3.3/H-2-2] DEBE informar las seudoranges y las tasas de seudoranges del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras el dispositivo está estacionario o se mueve con una aceleración inferior a 0.2 metros por segundo al cuadrado, son suficientes para calcular la posición con una precisión de 20 metros y la velocidad con una precisión de 0.2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos de mano incluyen un giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[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 1,000 grados por segundo.

Implementaciones de dispositivos de mano que pueden realizar una llamada de voz y que indican cualquier valor que no sea PHONE_TYPE_NONE en getPhoneType:

[7.3.8/H] DEBE incluir un sensor de proximidad.

Implementaciones de dispositivos de mano:

[7.3.11/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE que admitan el sensor de posición con 6 grados de libertad.

Si las implementaciones de dispositivos de mano admiten conectividad de datos celulares, deben cumplir con lo siguiente:

[7.4.1/H-1-1] DEBE declarar la marca de función android.hardware.telephony.data.

Implementaciones de dispositivos de mano que incluyen compatibilidad con Bluetooth de bajo consumo:

[7.4.3/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE que admitan la extensión de longitud de paquetes de datos de Bluetooth de bajo consumo.

Nota: Este requisito [7.4.3/H-SR-1] se convertirá en OBLIGATORIO en una versión futura de Android.

Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 (Wi-Fi), deben cumplir con lo siguiente:

[7.4.2.4/H-1-1] DEBE incluir compatibilidad con Wi-Fi Passpoint.

Si los dispositivos admiten el protocolo de redes con reconocimiento de vecinos (NAN) de Wi-Fi declarando PackageManager.FEATURE_WIFI_AWARE y la ubicación Wi-Fi (tiempo de ida y vuelta de Wi-Fi, RTT) declarando PackageManager.FEATURE_WIFI_RTT, cumplen con lo siguiente:

[7.4.2.5/H-1-1] DEBE informar el rango con precisión dentro de +/-1 metro con un ancho de banda de 160 MHz en el percentil 68 (según se calcula con la función de distribución acumulativa), +/-2 metros con 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, según se observa a través de la API de Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE informar el rango con precisión dentro de +/-1 metro con un ancho de banda de 160 MHz en el percentil 90 (según se calcula con la función de distribución acumulativa), +/-2 metros con un 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, según se observa a través de la API de Android WifiRttManager#startRanging.

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

Si los dispositivos portátiles admiten el protocolo de detección de proximidad (PD) de Wi-Fi declarando PackageManager.FEATURE_WIFI_PD y la ubicación Wi-Fi (tiempo de ida y vuelta de Wi-Fi, RTT) declarando PackageManager.FEATURE_WIFI_RTT, entonces:

[7.4.2.10/H-1-1] DEBE usar un ancho de banda de al menos 160 MHz.
[7.4.2.10/H-1-2] DEBE informar el rango con precisión dentro de +/-0.25 metros con un ancho de banda de 160 MHz en el percentil 68 (según se calcula con la función de distribución acumulativa), como se observa a través de la API de Android WifiRttManager#startRanging.

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

Si las implementaciones de dispositivos de mano declaran FEATURE_BLUETOOTH_LE, deben cumplir con lo siguiente:

[7.4.3/H-1-3] DEBE medir y compensar la desviación de Rx para garantizar que la mediana del RSSI de BLE sea de -50 dBm +/- 15 dB a 1 m de distancia de un dispositivo de referencia que transmita a ADVERTISE_TX_POWER_HIGH.
[7.4.3/H-1-4] DEBE medir y compensar el desplazamiento de transmisión para garantizar que la mediana del RSSI de BLE sea de -50 dBm +/- 15 dB cuando se realice la búsqueda desde un dispositivo de referencia ubicado a 1 m de distancia y que transmita a ADVERTISE_TX_POWER_HIGH.

Si las implementaciones de dispositivos de mano incluyen al menos una cámara orientada hacia atrás, deben cumplir con lo siguiente:

[7.5.1/H-1-1] DEBE tener una resolución de al menos 2 megapíxeles.

Si las implementaciones de dispositivos portátiles incluyen un dispositivo de cámara lógica que enumera las capacidades con CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, deben cumplir con lo siguiente:

[7.5.4/H-1-1] DEBE tener un campo visual (FOV) normal de forma predeterminada y DEBE estar entre 50 y 60 grados.

Implementaciones de dispositivos de mano:

[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 "true" para ActivityManager.isLowRamDevice() cuando hay menos de 1 GB de memoria disponible para el kernel y el espacio del usuario.

Si las implementaciones de dispositivos de mano declaran compatibilidad solo con una ABI de 32 bits, se aplican las siguientes condiciones:

[7.6.1/H-1-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 416 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta qHD (p.ej., FWVGA).
[7.6.1/H-2-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 592 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta HD+ (p.ej., HD, WSVGA).
[7.6.1/H-3-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 896 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta FHD (p.ej., WSXGA+).
[7.6.1/H-4-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,344 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta QHD (p.ej., QWXGA).

Si las implementaciones de dispositivos de mano declaran compatibilidad con cualquier ABI de 64 bits (con o sin ninguna ABI de 32 bits), se deben cumplir los siguientes requisitos:

[7.6.1/H-5-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 816 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta qHD (p.ej., FWVGA).
[7.6.1/H-6-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 944 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta HD+ (p.ej., HD, WSVGA).
[7.6.1/H-7-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1,280 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta FHD (p.ej., WSXGA+).
[7.6.1/H-8-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,824 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta QHD (p.ej., QWXGA).

Ten en cuenta que la "memoria disponible para el kernel y el espacio del usuario" que se menciona más arriba se refiere al espacio de memoria que se proporciona además de la memoria que ya está dedicada a los componentes de hardware, como la radio, el video, etcétera, que no están bajo el control del kernel en las implementaciones del dispositivo.

Si las implementaciones de dispositivos de mano incluyen menos de 1 GB de memoria disponible para el kernel y el espacio de usuario, o bien 1 GB, deben cumplir con lo siguiente:

[7.6.1/H-9-1] DEBE declarar la marca 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 de mano incluyen más de 1 GB de memoria disponible para el kernel y el espacio del usuario, deben cumplir con lo siguiente:

[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 la marca de función android.hardware.ram.normal.

Si las implementaciones de dispositivos de mano incluyen una memoria disponible para el kernel y el espacio del usuario mayor o igual a 2 GB y menor a 4 GB, deben cumplir con lo siguiente:

[7.6.1/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE que solo se admita el espacio de usuario de 32 bits (tanto las apps como el código del sistema).

Si las implementaciones de dispositivos de mano incluyen menos de 2 GB de memoria disponible para el kernel y el espacio de usuario, deben cumplir con lo siguiente:

[7.6.1/H-1-1] DEBE admitir solo una ABI (solo de 64 bits o solo de 32 bits).

Implementaciones de dispositivos de mano:

[7.6.2/H-0-1] NO DEBE proporcionar un almacenamiento compartido de la aplicación inferior a 1 GiB.
[7.7.1/H] DEBE incluir un puerto USB que admita el modo periférico.

Si las implementaciones de dispositivos de mano incluyen un puerto USB con un controlador que funciona en modo periférico, deben cumplir con lo siguiente:

[7.7.1/H-1-1] DEBE implementar la API de Android Open Accessory (AOA).

Si las implementaciones de dispositivos de mano incluyen un puerto USB que admite el modo de host, deben cumplir con lo siguiente:

[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 de mano:

[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 de mano son capaces de cumplir con todos los requisitos de rendimiento para admitir el modo RV y lo incluyen, deben cumplir con lo siguiente:

[7.9.1/H-1-1] DEBE declarar la marca 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 y que las aplicaciones de RV puedan habilitar a través de android.app.Activity#setVrModeEnabled.

Si las implementaciones de dispositivos de mano incluyen uno o más puertos USB-C en modo host y se implementan (clase de audio USB), además de los requisitos de la sección 7.7.2, deben cumplir con lo siguiente:

[7.8.2.2/H-1-1] DEBE proporcionar la siguiente asignación de software de códigos HID:

Función	Asignaciones	Contexto	Comportamiento
A	Página de uso de HID: 0x0C Uso de HID: 0x0CD Tecla del kernel: `KEY_PLAYPAUSE` Tecla de Android: `KEYCODE_MEDIA_PLAY_PAUSE`	Reproducción de contenido multimedia	Entrada: Presión breve Salida: Reproducir o pausar
		Reproducción de contenido multimedia	Entrada: Mantén presionado Salida: Inicia el comando por voz Envía: `android.speech.action.VOICE_SEARCH_HANDS_FREE` si el dispositivo está bloqueado o la pantalla está apagada. De lo contrario, envía `android.speech.RecognizerIntent.ACTION_WEB_SEARCH`
		Llamada entrante	Entrada: Presión breve Salida: Aceptar llamada
		Llamada entrante	Entrada: Mantener presionado Salida: Rechazar llamada
		Llamada en curso	Entrada: Presión breve Salida: Finalizar llamada
		Llamada en curso	Entrada: Mantén presionado Salida: Silenciar o activar el micrófono
B	Página de uso de HID: 0x0C Uso de HID: 0x0E9 Tecla del kernel: `KEY_VOLUMEUP` Tecla de Android: `VOLUME_UP`	Reproducción de contenido multimedia, Llamada en curso	Entrada: Presión breve o prolongada Salida: Aumenta el volumen del sistema o de los auriculares
C	Página de uso de HID: 0x0C Uso de HID: 0x0EA Tecla del kernel: `KEY_VOLUMEDOWN` Tecla de Android: `VOLUME_DOWN`	Reproducción de contenido multimedia, Llamada en curso	Entrada: Presión breve o prolongada Salida: Disminuye el volumen del sistema o de los auriculares
D	Página de uso de HID: 0x0C Uso de HID: 0x0CF Tecla del kernel: `KEY_VOICECOMMAND` Tecla de Android: `KEYCODE_VOICE_ASSIST`	Todos. Se puede activar en cualquier instancia.	Entrada: Presión breve o prolongada Salida: Inicia el comando por voz

[7.8.2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG cuando se inserte un conector, pero solo después de que se hayan enumerado correctamente las interfaces y los extremos de audio USB para identificar el tipo de terminal conectado.

Cuando se detectan los tipos de terminal de audio USB 0x0302, sucede lo siguiente:

[7.8.2.2/H-2-1] DEBE transmitir el intent ACTION_HEADSET_PLUG con el parámetro adicional "micrófono" establecido en 0.

Cuando se detectan los tipos de terminal de audio USB 0x0402, sucede lo siguiente:

[7.8.2.2/H-3-1] DEBE transmitir el intent ACTION_HEADSET_PLUG con el parámetro adicional "microphone" establecido en 1.

Cuando se llama a la API de AudioManager.getDevices() mientras el periférico USB está conectado, sucede lo siguiente:

[7.8.2.2/H-4-1] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y rol isSink() si el campo de tipo de terminal de audio USB es 0x0302.
[7.8.2.2/H-4-2] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y rol 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 rol isSource() si el campo de tipo de terminal de audio USB es 0x0402.
[7.8.2.2/H-4-4] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y rol isSink() si el campo de tipo de terminal de audio USB es 0x603.
[7.8.2.2/H-4-5] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y rol isSource() si el campo de tipo de terminal de audio USB es 0x604.
[7.8.2.2/H-4-6] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y rol isSink() si el campo de tipo de terminal de audio USB es 0x400.
[7.8.2.2/H-4-7] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y rol isSource() si el campo de tipo de terminal de audio USB es 0x400.
[7.8.2.2/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE que, cuando se conecte un periférico de audio USB-C, se realice la enumeración de los descriptores USB, se identifiquen los tipos de terminales y se transmita el Intent ACTION_HEADSET_PLUG en menos de 1,000 milisegundos.

Para las implementaciones de dispositivos de mano que declaran android.hardware.audio.output y android.hardware.microphone, consulta los requisitos de RTL y TTL en la sección 5.6.

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

Si las implementaciones de dispositivos de mano incluyen al menos un actuador resonante lineal de 7.10 de uso general, deben cumplir con lo siguiente:

[7.10/H] DEBE colocar el actuador cerca de la ubicación en la que se suele sostener o tocar el dispositivo con las manos.
[7.10/H] DEBE mover el actuador háptico en el eje X (de izquierda a derecha) de la orientación natural del dispositivo.

Si las implementaciones de dispositivos de mano tienen un actuador háptico de uso general que es un actuador resonante lineal (LRA) de eje X, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos de mano siguen la asignación de constantes hápticas, sucede lo siguiente:

[7.10/H]^* DEBE verificar el estado de implementación ejecutando las APIs de android.os.Vibrator.areAllEffectsSupported() y android.os.Vibrator.arePrimitivesSupported().
[7.10/H]^* DEBE realizar una evaluación de calidad para las constantes hápticas.
[7.10/H]^* DEBE verificar y actualizar, si es necesario, la configuración de resguardo para los elementos primitivos no admitidos, como se describe en la guía de implementación para las constantes.

2.2.2. Multimedia

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

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

[5.1/H-0-6] MPEG-D USAC con MPEG-D DRC (AAC de alta eficiencia extendido)

2.2.3. Software

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

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

Las implementaciones de dispositivos de mano DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de las 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
[5.3/H-0-6] AV1

2.2.3. Software

Implementaciones de dispositivos de mano:

[3.2.3.1/H-0-1] DEBE tener una aplicación que controle los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE y ACTION_CREATE_DOCUMENT como se describe en los documentos del SDK, y proporcionar la indicación visual al usuario para acceder a los datos del proveedor de documentos con la API de DocumentsProvider.

[3.2.3.1/H-0-2]^* DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los intents de aplicaciones que se enumeran aquí. Nota: La página "Intents comunes de la app" incluirá el nuevo intent obligatorio "android.settings.VPN_APP_EXCLUSION_SETTINGS".

[3.2.3.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar una aplicación de correo electrónico que pueda controlar intents de ACTION_SENDTO, ACTION_SEND o ACTION_SEND_MULTIPLE para enviar un correo electrónico.
[3.4.1/H-0-1] DEBE proporcionar una implementación completa de la API de android.webkit.Webview.
[3.4.2/H-0-1] DEBE incluir una aplicación de navegador independiente para la navegación web general del usuario.

[3.8.1/H-0-1] DEBE implementar un selector predeterminado que admita la fijación de widgets en la app.

[3.8.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un selector predeterminado que admita la fijación en la app de accesos directos, widgets y widgetFeatures.
[3.8.1/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE implementar un selector predeterminado que proporcione acceso rápido a los accesos directos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager.
[3.8.1/H-SR-3] Se RECOMIENDA ENCARECIDAMENTE incluir una app de selector predeterminada que muestre insignias para los íconos de apps.

[3.8.2/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE que admitan widgets de apps de terceros.

[3.8.2/H-0-1] DEBE admitir widgets de apps de terceros.

[3.8.3/H-0-1] DEBE permitir que las apps de terceros notifiquen a los usuarios sobre eventos importantes a través de las clases de API Notification y NotificationManager.
[3.8.3/H-0-2] DEBE admitir notificaciones enriquecidas.
[3.8.3/H-0-3] DEBE admitir notificaciones emergentes.
[3.8.3/H-0-4] DEBE incluir un panel de notificaciones que le permita al usuario controlar directamente (p.ej., responder, posponer, descartar, bloquear) las notificaciones a través de indicaciones visuales para el usuario, como botones de acción o el panel de control implementado en el AOSP.
[3.8.3/H-0-5] DEBE mostrar las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el panel de notificaciones.
[3.8.3/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE mostrar la primera opción proporcionada a través de RemoteInput.Builder setChoices() en el panel de notificaciones 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 panel de notificaciones cuando el usuario expanda todas las notificaciones en el panel de notificaciones.
[3.8.3.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar acciones para las que Notification.Action.Builder.setContextual se establece como true en línea con las respuestas que muestra Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.

Si las implementaciones de dispositivos de mano admiten notificaciones MediaStyle, deben cumplir con los siguientes requisitos:

[3.8.3.1/H-SR-2] SE RECOMIENDA ENCARECIDAMENTE proporcionar una indicación visual para el usuario (por ejemplo, un selector de salida) a la que se pueda acceder desde la IU del sistema y que permita a los usuarios cambiar entre las rutas de medios disponibles adecuadas (por ejemplo, dispositivos Bluetooth y rutas proporcionadas a MediaRouter2Manager) cuando una app publique una notificación de MediaStyle con un token de MediaSession.

Se puede promocionar la Notificación de actualización en vivo de una app cuando esta cumple con todas las características de promoción. En este documento, se describe esta notificación como Notificación de actualización en vivo promocionada. Las implementaciones de dispositivos de mano DEBEN mostrar de forma destacada la Notificación de actualización en vivo promocionada según los siguientes requisitos.

Si las implementaciones de dispositivos de mano declaran el nivel de API 36.1 o superior, deben hacer lo siguiente:

[3.8.3.1/H-0-1] DEBE mostrar una notificación de actualización en vivo promocionada en un lugar destacado de la pantalla de bloqueo.
[3.8.3.1/H-0-12] DEBE mostrarse en la parte superior de la pila de notificaciones Notificación emergente y por encima de las notificaciones coloreadas (en las que setColorized es true) cuando la Notificación de actualización en vivo promocionada se muestra entre otras notificaciones.
- PUEDE determinar la secuencia de orden de las Notificaciones de actualización en vivo promocionadas que se muestran en el panel de notificaciones y la pantalla de bloqueo cuando más de una app es apta para recibir Notificaciones de actualización en vivo promocionadas.
[3.8.3.1/H-0-2] DEBE mostrar una notificación de actualización en vivo promocionada en el estado expandido.
[3.8.3.1/H-0-3] NO DEBE proporcionar una opción para contraer la notificación expandida anterior.
[3.8.3.1/H-0-4] DEBE mostrar los estilos básicos (negrita, cursiva y subrayado) del contenido de texto en una notificación de actualización en vivo promocionada, según lo proporciona StyleSpan o UnderlineSpan.
[3.8.3.1/H-0-5] DEBE mostrar solo objetos de acción estándares (a través de Notification.Action) y DEBE ocultar los objetos de acción no estándares, como cuadros de entrada, botones de respuesta y acciones contextuales (a través de addRemoteInput() y setContextual()) en una notificación de actualización en vivo promocionada, incluso cuando la notificación los contenga.
[3.8.3.1/H-0-6] DEBE mostrar una representación compacta, también denominada chip de estado en la documentación del SDK, para una notificación de actualización en vivo promocionada que DEBE incluir Notification.getSmallIcon().
- [3.8.3.1/H-0-7] Otros campos son opcionales para la representación compacta, pero, cuando se pueda expandir la representación compacta, DEBE mostrar Notification.getShortCriticalText() si está presente o Notification.when si Notification.getShortCriticalText no está presente.
- [3.8.3.1/H-0-8] Cuando hay más de una notificación de actualización en vivo promocionada, SE DEBE mostrar al menos una de ellas en la barra de estado como una representación compacta.
- [3.8.3.1/H-0-9] DEBE mostrar la notificación asociada (opción preferida) o abrir la app asociada (a través de Notification.contentIntent) cuando el usuario presione la representación compacta.
- [3.8.3.1/H-0-13] DEBE mostrar el mismo contenido en la notificación asociada que el que está disponible en el panel de notificaciones.
[3.8.3.1/H-0-10] DEBE proporcionar una indicación visual para el usuario que permita desactivar y habilitar la visualización promocionada de las notificaciones de apps individuales.
[3.8.3.1/H-0-11] DEBE renderizar correctamente todas las notificaciones de actualización en vivo, incluidas, sin limitaciones, las notificaciones de actualización en vivo no promocionadas que no cumplen o solo cumplen parcialmente con las características de promoción. Estas notificaciones NO promocionadas DEBEN mostrarse en un estado no promocionado.

Si las implementaciones de dispositivos que incluyen la tecla de navegación de la función de Recientes, como se detalla en la sección 7.2.3, alteran la interfaz, deben cumplir con lo siguiente:

[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 activar o desactivar la función.

Si las implementaciones de dispositivos de mano admiten la acción de Asistente, deben cumplir con lo siguiente:

[3.8.4/H-SR-2] SE RECOMIENDA ENCARECIDAMENTE usar la presión prolongada en la tecla HOME como 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, es decir, la aplicación que implementa VoiceInteractionService o una actividad que controla el intent ACTION_ASSIST.

Si las implementaciones de dispositivos de mano admiten conversation notifications y las agrupan en una sección separada de las notificaciones de alerta y silenciosas que no son de conversación, cumplen con los siguientes requisitos:

[3.8.4/H-1-1]^* DEBE mostrar las notificaciones de conversación antes que las que no son de conversación, con la excepción de las notificaciones de servicios en primer plano en curso y las notificaciones con importance:high.

Si las implementaciones de dispositivos de mano Android admiten una pantalla de bloqueo, deben cumplir con los siguientes requisitos:

[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 de mano admiten una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:

[3.9/H-1-1] DEBE implementar el rango completo de políticas de administración de dispositivos definidas en la documentación del SDK de Android.

Si las implementaciones de dispositivos de mano incluyen compatibilidad con las APIs de ControlsProviderService y Control, y permiten que las aplicaciones de terceros publiquen controles de dispositivos, deben cumplir con lo siguiente:

[3.8.16/H-1-1] DEBE declarar el parámetro de configuración de la función android.software.controls y establecerlo en true.
[3.8.16/H-1-2] DEBE proporcionar una indicación visual para el usuario con la capacidad de agregar, editar, seleccionar y operar los controles de dispositivos favoritos del usuario desde los controles registrados por las aplicaciones de terceros a través de las APIs de ControlsProviderService y Control.
[3.8.16/H-1-3] DEBE proporcionar acceso a esta indicación visual para el usuario en un máximo de tres interacciones desde un Launcher predeterminado.
[3.8.16/H-1-4] DEBE renderizar con precisión en esta interfaz para el usuario el nombre y el ícono de cada app de terceros que proporcione controles a través de la API de ControlsProviderService, así como cualquier campo especificado que proporcionen las APIs de Control.
[3.8.16/H-1-5] DEBE proporcionar una indicación visual para que el usuario inhabilite los controles de dispositivos triviales para la autenticación designados por la app desde los controles registrados por las aplicaciones de terceros a través de las APIs de ControlsProviderService y Control Control.isAuthRequired.
[3.8.16/H-1-6] Las implementaciones de dispositivos DEBEN renderizar con precisión la indicación visual para el usuario de la siguiente manera:
- Si el dispositivo tiene establecido config_supportsMultiWindow=true y la app declara los metadatos META_DATA_PANEL_ACTIVITY en la declaración de ControlsProviderService, incluido el ComponentName de una actividad válida (según lo define la API), la app DEBE incorporar dicha actividad en esta indicación visual para el usuario.
- Si la app no declara metadatos META_DATA_PANEL_ACTIVITY, DEBE renderizar los campos especificados tal como los proporciona la API de ControlsProviderService, así como los campos especificados que proporcionan las APIs de Control.
[3.8.16/H-1-7] Si la app declara los metadatos META_DATA_PANEL_ACTIVITY, DEBE pasar el parámetro de configuración definido en [3.8.16/H-1-5] con EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS cuando inicie la actividad incorporada.

Por el contrario, si las implementaciones de dispositivos de mano no implementan esos controles, sucederá lo siguiente:

[3.8.16/H-2-1] DEBE informar null para las APIs de ControlsProviderService y Control.
[3.8.16/H-2-2] DEBE declarar el parámetro de configuración de la función android.software.controls y establecerlo en false.

Si las implementaciones de dispositivos de mano no se ejecutan en el modo de tareas bloqueadas, cuando se copia contenido en el portapapeles, sucede lo siguiente:

[3.8.17/H-1-1] DEBE presentar una confirmación al usuario de que los datos se copiaron en el portapapeles (p. ej., una miniatura o una alerta de "Se copió el contenido"). Además, incluye aquí una indicación de si los datos del portapapeles se sincronizarán en todos los dispositivos.

Implementaciones de dispositivos de mano:

[3.10/H-0-1] DEBE admitir servicios de accesibilidad de terceros.
[3.10/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar los servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de Accesibilidad con interruptores y TalkBack (para los idiomas admitidos por el motor de texto a voz preinstalado) o que la superen, tal como se proporcionan en el proyecto de código abierto de TalkBack.
[3.11/H-0-1] DEBE admitir la instalación de motores de TTS de terceros.
[3.11/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor de TTS que admita los idiomas disponibles en el dispositivo.
[3.13/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE incluir un componente de IU de Configuración rápida.

Si las implementaciones de dispositivos de mano Android declaran compatibilidad con FEATURE_BLUETOOTH o FEATURE_WIFI, deben cumplir con lo siguiente:

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

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

Implementaciones de dispositivos de mano:

[3.20.1/H-0-1] DEBE implementar todos los requisitos de Assistant Audio Stream.

[7.2.3/H] La zona de reconocimiento de gestos para la función de inicio NO DEBE tener una altura superior a 32 dp desde la parte inferior de la pantalla.

Si las implementaciones de dispositivos de mano proporcionan una función de navegación como un gesto desde cualquier lugar de los bordes izquierdo y derecho de la pantalla, haz lo siguiente:

[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 gestos DEBE tener un ancho de 24 dp de forma predeterminada.

Si las implementaciones de dispositivos de mano admiten una pantalla de bloqueo segura y tienen una memoria disponible para el kernel y el espacio del usuario mayor o igual a 2 GB, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos de mano Android declaran la compatibilidad con la cámara a través de android.hardware.camera.any, deben hacer lo siguiente:

[7.5.4/H-1-1] DEBE respetar la intención de android.media.action.STILL_IMAGE_CAMERA y android.media.action.STILL_IMAGE_CAMERA_SECURE, y lanzar la cámara en el modo de imagen fija como se describe en el SDK.
[7.5.4/H-1-2] DEBE respetar la intención de android.media.action.VIDEO_CAMERA de iniciar la cámara en modo de video, como se describe en el SDK.

Si la aplicación de configuración de la implementación del dispositivo implementa una funcionalidad dividida con la incorporación de actividades, debe hacer lo siguiente:

[3.2.3.1/ H-1-1] DEBE tener una actividad que controle el intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY cuando la funcionalidad de división está activada. La actividad DEBE estar protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK y DEBE iniciar la actividad del Intent analizado desde Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

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

[7.4.1.2/H-0-1] DEBE declarar la marca de función android.software.telecom.

[7.4.1.2/H-0-2] DEBE implementar el framework de telecomunicaciones.

2.2.4. Rendimiento y potencia

[8.1/H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas inconsistente o la demora en renderizar fotogramas NO DEBEN ocurrir más de 5 veces por segundo, y DEBEN ser inferiores a 1 vez por segundo.
[8.1/H-0-2] Latencia de la interfaz de usuario. Las implementaciones de dispositivos DEBEN garantizar una experiencia del usuario de baja latencia desplazándose por una lista de 10,000 entradas de lista, según lo define el Conjunto de pruebas de compatibilidad (CTS) de Android, en menos de 36 s.
[8.1/H-0-3] Cambio de tareas. Cuando se hayan iniciado varias aplicaciones, el reinicio de una aplicación que ya se está ejecutando después de que se haya iniciado DEBE tardar menos de 1 segundo.

Implementaciones de dispositivos de mano:

[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 de mano incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en el AOSP o extienden las funciones que se incluyen en el AOSP, deben cumplir con lo siguiente:

[8.3/H-1-1] DEBE proporcionar al usuario la posibilidad de habilitar y, también, inhabilitar la función de Ahorro de batería.
[8.3/H-1-2] DEBE proporcionar al usuario la posibilidad de ver todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.

Implementaciones de dispositivos de mano:

[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 agotamiento aproximado de la batería que causan los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
[8.4/H-0-2] Se DEBEN 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 cada UID de proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo del kernel uid_cputime.
[8.4/H-0-4] DEBE poner este uso de energía a disposición del desarrollador de apps a través del comando de shell adb shell dumpsys batterystats.
[8.4/H] SE DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

Si las implementaciones de dispositivos de mano incluyen una pantalla o salida de video, deben cumplir con lo siguiente:

[8.4/H-1-1] DEBE respetar la intención de android.intent.action.POWER_USAGE_SUMMARY y mostrar un menú de configuración que muestre este consumo de energía.

Implementaciones de dispositivos de mano:

[8.5/H-0-1] DEBE proporcionar una indicación visual para que el usuario vea todas las apps con servicios activos en primer plano o trabajos iniciados por el usuario, incluida la duración de cada uno de estos servicios desde que se iniciaron, como se describe en el documento del SDK.
[8.5/H-0-2]DEBE proporcionar una opción para que el usuario detenga una app que ejecuta un servicio en primer plano o un trabajo iniciado por el usuario.

2.2.5. Modelo de seguridad

Implementaciones de dispositivos de mano:

[9/H-0-1] DEBE declarar la función android.hardware.security.model.compatible.
[9.1/H-0-1] DEBE permitir que las apps 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 que permita otorgar o revocar el acceso a dichas apps en respuesta a la intención android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Si las implementaciones de dispositivos de mano incluyen una aplicación predeterminada para admitir el VoiceInteractionService, deben cumplir con lo siguiente:

[9.1/H-0-2] NO DEBE otorgar ACCESS_FINE_LOCATION como valor predeterminado para esa aplicación.

Las implementaciones de dispositivos DEBEN declarar la compatibilidad con android.software.credentials y lo siguiente:

[9/H-0-2] DEBE respetar la intención de android.settings.CREDENTIAL_PROVIDER para permitir la selección de un proveedor preferido para el Administrador de credenciales. Este proveedor se habilitará para Autocompletar y también será la ubicación predeterminada para guardar las credenciales nuevas que se ingresen a través de Credential Manager.
[9/H-0-3] DEBE admitir al menos 2 proveedores de credenciales simultáneos y proporcionar una indicación visual para el usuario en la app de Configuración para habilitar o inhabilitar proveedores.
[9.5/H-1-1] Se quitó el requisito en Android 16.

Implementaciones de dispositivos de mano:

[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 los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash de las familias MD5, SHA-1 y SHA-2 para admitir correctamente los algoritmos compatibles con el sistema Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito utilizando la implementación de 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 aislado y solo cuando se realice correctamente, permitir que se usen 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 upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
[9.11/H-0-5] DEBE admitir la certificación de claves en la que la clave de firma de certificación esté protegida por hardware seguro y la firma se realice en hardware seguro. Se DEBE evitar que las claves de firma de la certificación se usen como identificadores permanentes del dispositivo.

Nota: Para cumplir con este requisito, debes compartir la misma clave de certificación para un SKU determinado, a menos que se produzcan al menos 100,000 unidades de ese SKU. Si se producen más de 100,000 unidades de ese SKU, se PUEDE usar una clave diferente para cada grupo de 100,000 unidades después de eso. Como alternativa, se puede usar la solución de Remote Key Provisioning para aprovisionar claves de certificación de corta duración en el dispositivo.

Ten 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 certificación de claves, a menos que declare la función android.hardware.fingerprint, que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Cuando las implementaciones de dispositivos de mano admiten una pantalla de bloqueo segura, hacen lo siguiente:

[9.11/H-1-1] DEBE permitir que el usuario elija el tiempo de espera de suspensión más corto, es decir, un tiempo de transición del estado desbloqueado al bloqueado, de 15 segundos o menos.
[9.11/H-1-2] DEBE proporcionar al usuario la posibilidad de ocultar notificaciones y desactivar todas las formas de autenticación, excepto la autenticación principal que se describe en 9.11.1 Pantalla de bloqueo segura. El AOSP cumple con el requisito como modo hermético.

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y uno o más agentes de confianza que implementan la API de TrustAgentService System, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos de mano tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza que llaman a la API de TrustAgentService.grantTrust() del sistema con la marca FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, cumplen con los siguientes requisitos:

[9.11.1/H-1-1] MUST call TrustManagerService.revokeTrust() after either:
- Un máximo de 24 horas desde que se otorgó la confianza
- Un período de inactividad de 8 horas

Si las implementaciones de dispositivos de mano incluyen varios usuarios y no declaran la marca de función android.hardware.telephony, deben hacer lo siguiente:

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

Si las implementaciones de dispositivos de mano incluyen varios usuarios y declaran la marca de función android.hardware.telephony, deben hacer lo siguiente:

[9.5/H-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de AOSP de los controles para permitir o inhabilitar el acceso de otros usuarios a las llamadas de voz y los SMS.
[9.5/H-4-1] Se quitó el requisito en Android 16.
[9.5/H-4-2] Se quitó el requisito en Android 16.

Configuración restringida

La opción Configuración restringida proporciona al usuario advertencias visibles y solicita su confirmación para otorgar permisos a cada aplicación que cumpla con uno de los siguientes criterios:

Se instala después de descargarse a través de una aplicación (por ejemplo, una aplicación de mensajería o un navegador) que no sea una aplicación de "tienda de aplicaciones" identificada por PackageManager como PACKAGE_DOWNLOADED_FILE.
Se identifica como PACKAGE_SOURCE_LOCAL_FILE cuando se instala desde un archivo local (por ejemplo, la aplicación se transfirió de forma lateral) identificado por PackageManager.

Para cualquiera de los permisos aplicados y sus identificadores asociados que se enumeran en [9.8/H-0-5] a continuación.

Dichas aplicaciones se etiquetan como "Aplicaciones Cubiertas" para los requisitos que se indican en esta sección.

Implementaciones de dispositivos:

[9.8/H-0-1] DEBE implementar la configuración restringida como se describió anteriormente para lo siguiente:
- Permisos especiales
  - Accesibilidad (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - Agente de escucha de notificaciones (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - Apps de administrador del dispositivo (Manifest.permission.BIND_DEVICE_ADMIN)
  - Mostrar sobre otras apps (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - Acceso a los datos de uso (AppOpsManager.OPSTR_GET_USAGE_STATS)
- Roles (apps predeterminadas)
  - Marcador (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- Permisos de tiempo de ejecución
  - Tiempo de ejecución de SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] DEBE habilitar la Configuración restringida como predeterminada y se RECOMIENDA ENCARECIDAMENTE que no haya ninguna indicación visual que permita al usuario desactivar la Configuración restringida para todas las aplicaciones.
[9.8/H-0-3] DEBE garantizar que se obtenga la confirmación del usuario para cada Aplicación Cubierta antes de que se puedan otorgar cualquiera de los Permisos Aplicados.
[9.8/H-0-4] SOLO DEBE permitir que se obtenga la confirmación del usuario para habilitar la configuración restringida desde la página AppInfo de la Aplicación Cubierta, con la API de EnhancedConfirmationManager.
[9.8/H-0-5] Se RECOMIENDA ENCARECIDAMENTE integrar y llamar a EnhancedConfirmationManager para todos los permisos especiales, para determinar de forma dinámica si son un parámetro de configuración restringido.
- Alarmas y recordatorios: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Acceso a todos los archivos: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Mostrar sobre otras apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Instalar apps desconocidas: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Administrar contenido multimedia: AppOpsManager.OPSTR_MANAGE_MEDIA
- Modificar la configuración del sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
- Pantalla en pantalla: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Activar la pantalla: AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notificaciones de pantalla completa: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Control de Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Accesibilidad: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Agente de escucha de notificaciones: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Acceso a los datos de uso: AppOpsManager.OPSTR_GET_USAGE_STATS
- Administrador del dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
- No interrumpir: Manifest.permission.MANAGE_NOTIFICATIONS

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 la cámara.

Si las implementaciones de dispositivos de mano admiten la API de System HotwordDetectionService o algún otro mecanismo para la detección de palabras clave sin indicación de acceso al micrófono, deben cumplir con lo siguiente:

[9.8/H-1-1] DEBE asegurarse de que el servicio de detección de palabras clave solo pueda transmitir datos al sistema, a ContentCaptureService o al servicio de reconocimiento de voz integrado en el dispositivo creado por SpeechRecognizer#createOnDeviceSpeechRecognizer().
[9.8/H-1-2] DEBE asegurarse de que el servicio de detección de palabras clave solo pueda transmitir datos de audio del micrófono o datos derivados de ellos al servidor del sistema a través de la API de HotwordDetectionService, o bien a ContentCaptureService a través de la API de ContentCaptureManager.
[9.8/H-1-3] NO DEBE proporcionar audio del micrófono que dure más de 30 segundos para una solicitud individual activada por hardware al servicio de detección de palabras clave.
[9.8/H-1-4] NO DEBE proporcionar audio del micrófono almacenado en búfer con una antigüedad superior a 8 segundos para una solicitud individual al servicio de detección de palabras clave.
[9.8/H-1-5] NO DEBE proporcionar audio del micrófono almacenado en búfer con una antigüedad superior a 30 segundos al servicio de interacción por voz o a una entidad similar.
[9.8/H-1-6] NO DEBE permitir que se transmitan más de 100 bytes de datos (sin incluir transmisiones de audio) desde el servicio de detección de palabras clave en cada resultado exitoso de palabras clave.
[9.8/H-1-7] NO DEBE permitir que se transmitan más de 5 bits de datos desde el servicio de detección de palabras clave en cada resultado negativo de palabras clave.
[9.8/H-1-8] SOLO DEBE permitir la transmisión de datos fuera del servicio de detección de palabras clave en una solicitud de validación de palabras clave 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 clave.
[9.8/H-1-10] NO DEBE mostrar en la IU datos cuantitativos sobre el uso del micrófono por parte del servicio de detección de palabras clave.
[9.8/H-1-11] DEBE registrar la cantidad de bytes incluidos en cada transmisión del servicio de detección de palabras clave para permitir la inspección 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 del servicio de detección de palabras clave para permitir la inspección por parte de los investigadores de seguridad.
[9.8/H-1-14] DEBE mostrar el indicador de micrófono, como se describe en la sección 9.8.2, cuando se transmite un resultado exitoso de palabra clave activa al servicio de interacción por voz o a una entidad similar.
[9.8/H-1-15] DEBE garantizar que los flujos de audio proporcionados en los resultados exitosos de palabras clave se transmitan de forma unidireccional desde el servicio de detección de palabras clave al servicio de interacción por voz.
[9.8/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE notificar a los usuarios antes de establecer una aplicación como proveedor del servicio de detección de palabras clave.
[9.8/H-SR-2] SE RECOMIENDA ENCARECIDAMENTE que se inhabilite la transmisión de datos no estructurados fuera del servicio de detección de palabras clave.
[9.8/H-SR-3] Se RECOMIENDA ENCARECIDAMENTE reiniciar el proceso que aloja el servicio de detección de palabras clave al menos una vez por hora o cada 30 eventos de activación por hardware, lo que ocurra primero.

Si las implementaciones de dispositivos incluyen una aplicación que usa la API del sistema HotwordDetectionService o un mecanismo similar para la detección de palabras clave sin indicación de uso del micrófono, la aplicación debe cumplir con lo siguiente:

[9.8/H-2-1] DEBE proporcionar un aviso explícito al usuario para cada frase de palabra clave 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 clave.
[9.8/H-2-3] NO DEBE transmitir desde el servicio de detección de palabras clave, datos de audio, datos que se puedan usar para reconstruir (total o parcialmente) el audio, o contenido de audio no relacionado con la palabra clave en sí, excepto al servicio de reconocimiento de voz ContentCaptureService o integrado en el dispositivo.

Si las implementaciones de dispositivos de mano admiten la API de System VisualQueryDetectionService o algún otro mecanismo para la detección de búsquedas sin indicación de acceso al micrófono o la cámara, deben cumplir con lo siguiente:

[9.8/H-3-1] DEBE asegurarse de que el servicio de detección de consultas solo pueda transmitir datos al sistema, a ContentCaptureService o al servicio de reconocimiento de voz integrado en el dispositivo (creado por SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/H-3-2] NO DEBE permitir que se transmita información de audio o video fuera de VisualQueryDetectionService, excepto a ContentCaptureService o al servicio de reconocimiento de voz integrado en el dispositivo.
[9.8/H-3-3] DEBE mostrar un aviso al usuario en la IU del sistema cuando el dispositivo detecte la intención del usuario de interactuar con la aplicación del asistente digital (p. ej., 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 la búsqueda del usuario detectada en la IU inmediatamente después de que se detecte la búsqueda del usuario.
[9.8/H-3-5] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección de búsquedas visuales.

Si las implementaciones de dispositivos de mano declaran android.hardware.microphone, deben cumplir con lo siguiente:

[9.8.2/H-4-1] DEBE mostrar el indicador de micrófono cuando una app accede a los datos de audio del micrófono, pero no cuando solo acceden al micrófono HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o las apps que tienen los roles mencionados en el artículo 9.1 con el identificador de CDD [C-4-X].
[9.8.2/H-4-2] DEBE mostrar la lista de apps recientes y activas que usan el micrófono, según lo que devuelve PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados.
[9.8.2/H-4-3] NO debe ocultar el indicador del micrófono para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.
[9.8.2/H-4-4] DEBE mostrar la lista de apps recientes y activas que usan el micrófono, según lo que devuelve PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados.

Si las implementaciones de dispositivos de mano declaran android.hardware.camera.any, deben cumplir con lo siguiente:

[9.8.2/H-5-1] DEBE mostrar el indicador de acceso a la cámara cuando una app accede a datos de la cámara en vivo, pero no cuando solo se accede a la cámara desde las apps que tienen los roles mencionados en el artículo 9.1 con el identificador de CDD [C-4-X].
[9.8.2/H-5-2] DEBE mostrar las apps recientes y activas que usan la cámara, según lo que devuelve PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados a ellas.
[9.8.2/H-5-3] NO debe ocultar el indicador de acceso a la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.

Cuando una app en primer plano que no es del sistema accede a la ubicación precisa de un dispositivo, este hace lo siguiente:

[9.8.8/H-6-1] DEBE mostrar un indicador visible para el usuario.

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si las implementaciones de dispositivos admiten la función, deben cumplir con los siguientes requisitos:

[9.10/H-1-1] DEBE verificar todas las particiones de solo lectura que se hayan activado durante la secuencia de inicio de Android, y el resumen de VBMeta debe incluir todas estas particiones verificadas en su cálculo.

2.2.6. Compatibilidad de las opciones y herramientas para desarrolladores

Implementaciones de dispositivos de mano (* no aplicable a tablets):

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

Implementaciones de dispositivos de mano:

Perfetto
- [6.1/H-0-2] DEBE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [6.1/H-0-3] El objeto binario de 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 archivo binario de Perfetto DEBE escribir como resultado un registro 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 objeto binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
- [6.1/H-0-6] El daemon de registro de perfetto DEBE estar habilitado de forma predeterminada (propiedad del sistema persist.traced.enable).

Realizamos cambios significativos en la estructura de requisitos de la clase Media Performance. A partir de la API 37, agregamos los nuevos niveles 1, 10, 20 y 37. También redujimos la complejidad de los requisitos haciendo referencia a una página de mediciones de la clase de rendimiento del contenido multimedia, en la que se detalla cada requisito medido por nivel de MPC.

2.2.7. Clase de rendimiento del contenido multimedia manual

Consulta la sección 7.11 para obtener la definición de la clase de rendimiento del contenido multimedia y la Definición de la clase de rendimiento del contenido multimedia para todas las medidas.

2.2.7.1. Medios

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

DEBE cumplir con todos los requisitos de medios que se indican en la sección 2.2.7.1 del CDD de Android 17 correspondientes al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-1] DEBE anunciar la cantidad máxima de sesiones de decodificador de video por hardware que se pueden ejecutar de forma simultánea en cualquier combinación de códecs a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-2] DEBE admitir sesiones de decodificador de video por hardware (AVC, HEVC, VP9, AV1 o versiones posteriores), instancias simultáneas y pérdida de fotogramas correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-3] DEBE anunciar la cantidad máxima de sesiones de codificador de video por hardware que se pueden ejecutar de forma simultánea en cualquier combinación de códecs a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-4] DEBE admitir sesiones de codificador de video por hardware (AVC, HEVC, VP9, AV1 o versiones posteriores), instancias simultáneas y pérdidas de fotogramas correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-5] DEBE anunciar la cantidad máxima de sesiones simultáneas de codificador y decodificador de video por hardware en cualquier combinación de códecs a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-6] DEBE admitir sesiones de decodificador y codificador de video por hardware (AVC, HEVC, VP9, AV1 o versiones posteriores), instancias simultáneas y pérdidas de fotogramas correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-7] DEBE tener una latencia de inicialización del códec para una sesión de codificación de video de 1080p o inferior para todos los codificadores de video de hardware cuando estén bajo carga correspondiente al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-8] DEBE tener una latencia de inicialización del códec para una sesión de codificación de audio con una tasa de bits de 128 kbps o inferior para todos los codificadores de audio cuando estén bajo carga, lo que corresponde al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-9] DEBE admitir 2 instancias de sesiones seguras de decodificador de video por hardware (AVC, HEVC, VP9, AV1 o versiones posteriores) y pérdidas de fotogramas correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-10] DEBE admitir 3 instancias de sesiones de decodificador de video por hardware no seguro junto con 1 instancia de sesión de decodificador de video por hardware seguro (4 instancias en total) (AVC, HEVC, VP9, AV1 o posterior), resoluciones y pérdidas de fotogramas correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-11] DEBE admitir un decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 o AV1 que corresponda al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-12] DEBE tener una latencia de inicialización del códec para una sesión de decodificación de video de 1080p o menor para todos los decodificadores de video por hardware cuando estén bajo carga correspondiente al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-13] DEBE tener una latencia de inicialización del códec para una sesión de decodificación de audio de 128 kbps o una tasa de bits inferior para todos los decodificadores de audio cuando estén bajo carga, lo que corresponde al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-14] DEBE admitir el perfil, la función y el método de visualización del decodificador de hardware AV1 correspondientes al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-15] DEBE tener al menos 1 decodificador de video por hardware que admita 4K60, lo que corresponde al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-16] DEBE tener al menos 1 codificador de video por hardware que admita 4K60 y que corresponda al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes por hardware que admita el Perfil de Baseline de AVIF correspondiente al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.1/H-1-18] DEBE admitir el codificador AV1 que cumpla con los requisitos de resolución, bits por segundo y velocidad de fotogramas correspondientes al nivel de clase de rendimiento de contenido multimedia declarado del dispositivo.
[5.1/H-1-19] DEBE admitir 3 instancias de sesiones de codificador y decodificador de video por hardware de 10 bits (HDR) (AVC, HEVC, VP9, AV1 o versiones posteriores), resolución y pérdida de fotogramas correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-20] DEBE admitir la función Feature_HdrEditing para todos los codificadores de hardware AV1 y HEVC presentes en el dispositivo que correspondan al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-21] DEBE admitir FEATURE_DynamicColorAspect para todos los decodificadores de video por hardware (AVC, HEVC, VP9, AV1 o versiones posteriores) correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[5.1/H-1-22] DEBE admitir la codificación, la decodificación, la edición con GPU y la visualización de contenido de video en la relación de aspecto vertical correspondiente al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.2/H-2-1] Si la implementación del dispositivo admite codificadores AVC o HEVC de hardware, DEBE cumplir con el objetivo de calidad mínimo definido por las curvas de distorsión de la velocidad del codificador de video para esos códecs, que corresponden al nivel de clase de rendimiento multimedia declarado del dispositivo.

[5.2/H-2-2] DEBE admitir MMAP en la ruta del altavoz correspondiente al nivel de clase de rendimiento multimedia declarado del dispositivo.

[5.3/H-1-1] DEBE cumplir con los requisitos de rendimiento de la sesión de video y de pérdida de fotogramas correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.3/H-1-2] DEBE cumplir con los requisitos de rendimiento de cambio de resolución de video correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-1-1] DEBE cumplir con los requisitos de latencia de toque a tono correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-1-2] DEBE cumplir con los requisitos de latencia de audio de ida y vuelta correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-1-3] DEBE cumplir con los requisitos de audio de 24 bits correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-1-4] DEBE admitir dispositivos de audio USB de 4 o más canales que correspondan al nivel de clase de rendimiento de contenido multimedia declarado del dispositivo.
[5.6/H-1-5] DEBE admitir dispositivos MIDI compatibles con la clase y declarar la marca de función MIDI correspondiente al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-1-9] DEBE admitir al menos 12 combinaciones de canales que correspondan al nivel de clase de rendimiento de medios declarado del dispositivo.

[5.6/H-3-1] DEBE poder controlar el cambio entre la reproducción de ondas sinusoidales sin subejecución de los búferes de audio correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-3-2] DEBE cumplir con los requisitos de canales de salida de dispositivos de audio USB correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.6/H-3-3] DEBE cumplir con los requisitos de canales de entrada de dispositivos de audio USB correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.

[5.6/H-SR-1] SE RECOMIENDA ENCARECIDAMENTE que admitan la mezcla de canales de audio correspondiente al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.7/H-1-2] DEBE admitir MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con las capacidades de desencriptación correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[5.12/H-1-2] DEBE cumplir con los requisitos de formato de color para los codificadores de hardware AV1 y HEVC correspondientes al nivel de clase de rendimiento de medios declarado del dispositivo.
[5.12/H-1-3] DEBE anunciar la compatibilidad con la extensión EXT_YUV_target correspondiente al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.1.4/H-1-1] DEBE cumplir con los requisitos de la unidad de procesamiento de pantalla (DPU) correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.

2.2.7.2. Cámara

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

DEBE cumplir con los requisitos de la cámara que se indican en la sección 2.2.7.2 del CDD de Android 17 correspondientes al nivel de clase de rendimiento de medios declarado del dispositivo.

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

[7.5/H-1-1] DEBE cumplir con los requisitos de resolución de la cámara principal orientada hacia atrás y de captura de video correspondientes al nivel de clase de rendimiento de contenido multimedia declarado del dispositivo.
[7.5/H-1-2] DEBE cumplir con los requisitos de resolución de la cámara frontal principal y de captura de video correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-3] DEBE admitir los requisitos de la propiedad android.info.supportedHardwareLevel correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-4] DEBE admitir CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para las cámaras principales correspondientes al nivel de clase de rendimiento de medios declarado del dispositivo.
[7.5/H-1-5] DEBE cumplir con los requisitos de latencia de captura JPEG de camera2 correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-6] DEBE cumplir con los requisitos de latencia de inicio de camera2 correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-8] DEBE cumplir con los requisitos de captura de cámara RAW correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-9] DEBE cumplir con los requisitos de captura de video de alta velocidad de la cámara principal orientada hacia atrás correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-10] DEBE cumplir con los requisitos mínimos de relación de zoom correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-11] DEBE implementar la transmisión simultánea de la cámara frontal y posterior en las cámaras principales que correspondan al nivel de clase de rendimiento de medios declarado del dispositivo.
[7.5/H-1-12] DEBE admitir la estabilización de video para la cámara posterior principal correspondiente al nivel de clase de rendimiento de medios declarado del dispositivo.
[7.5/H-1-13] DEBE admitir la capacidad de LOGICAL_MULTI_CAMERA para la cámara trasera principal que corresponde al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-14] DEBE admitir la capacidad de STREAM_USE_CASE para la cámara frontal principal y la cámara posterior principal correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-15] DEBE admitir extensiones del modo nocturno a través de las extensiones de CameraX y Camera2 para las cámaras principales que corresponden al nivel de clase de rendimiento multimedia declarado del dispositivo.
[7.5/H-1-16] DEBE admitir la capacidad de DYNAMIC_RANGE_TEN_BIT para las cámaras principales correspondientes al nivel de clase de rendimiento de medios declarado del dispositivo.
[7.5/H-1-17] DEBE admitir funciones de detección de rostros para las cámaras principales correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.5/H-1-18] DEBE admitir JPEG_R para las cámaras principal trasera y principal frontal correspondientes al nivel de clase de rendimiento multimedia declarado del dispositivo.
[7.5/H-1-19] DEBE admitir CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para la cámara posterior principal que corresponda al nivel de clase de rendimiento de medios declarado del dispositivo.
[7.5/H-1-20] DEBE generar JPEG_R de forma predeterminada para las cámaras principal trasera y principal frontal en la app de cámara nativa correspondiente al nivel de clase de rendimiento multimedia declarado del dispositivo.

[7.5/H-1-21] DEBE tener al menos una cámara frontal o una cámara trasera que corresponda al nivel de clase de rendimiento de contenido multimedia declarado del dispositivo.

2.2.7.3. Hardware

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

DEBE cumplir con los requisitos de hardware que se indican en la sección 2.2.7.3 del CDD de Android 17 correspondientes al nivel de clase de rendimiento de contenido multimedia declarado del dispositivo.

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

[7.1.1.1/H-1-1] Este elemento se omite de forma intencional.
[7.1.1.1/H-2-1] DEBE tener una resolución de pantalla que corresponda al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.1.1.3/H-1-1] Este elemento se omite de forma intencional.
[7.1.1.3/H-2-1] DEBE tener una densidad de pantalla que corresponda al nivel de clase de rendimiento de medios declarado del dispositivo.
[7.1.1.3/H-3-1] DEBE admitir los requisitos de pantalla HDR correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.6.1/H-1-1] Este elemento se omite de forma intencional.
[7.6.1/H-2-1] DEBE cumplir con los requisitos de memoria correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.

2.2.7.4. Rendimiento

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

DEBE cumplir con los requisitos de rendimiento que se indican en la sección 2.2.7.4 del CDD de Android 17 correspondientes al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

[8.2/H-1-1] DEBE garantizar un rendimiento de escritura secuencial que corresponda al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[8.2/H-1-2] DEBE garantizar un rendimiento de escritura aleatoria que corresponda al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[8.2/H-1-3] DEBE garantizar un rendimiento de lectura secuencial que corresponda al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[8.2/H-1-4] DEBE garantizar un rendimiento de lectura aleatoria que corresponda al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[8.2/H-1-5] DEBE garantizar un rendimiento de lectura y escritura secuenciales paralelas que corresponda al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.

2.2.7.5. Gráficos

Si las implementaciones de dispositivos de mano devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

[7.1.4.1/H-1-2] DEBE admitir las extensiones de EGL requeridas que corresponden al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.
[7.1.4.1/H-1-3] DEBE admitir las funciones de Vulkan requeridas que corresponden al nivel de clase de rendimiento del contenido multimedia declarado del dispositivo.

2.3. Requisitos de la televisión

Un dispositivo Android Television hace referencia a una implementación de dispositivo Android que es una interfaz de entretenimiento para consumir medios digitales, películas, juegos, apps o TV en vivo para los usuarios que se encuentran a unos tres metros de distancia (una "interfaz de usuario de 10 pies" o "de sillón").

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

Proporcionamos un mecanismo para controlar de forma remota la interfaz de usuario renderizada en la pantalla que podría estar a tres metros 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 la pantalla

Los requisitos adicionales que se mencionan 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 el pad direccional.
[7.2.3/T-0-1] DEBE proporcionar las funciones de Inicio y Atrás.
[7.2.3/T-0-2] DEBE enviar el evento de presión normal y el de presión prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
[7.2.6.1/T-0-1] DEBE incluir compatibilidad con controles de juegos y declarar el parámetro de función android.hardware.gamepad.
[7.2.7/T] DEBE proporcionar un control remoto desde el que los usuarios puedan acceder a la navegación sin tacto 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, deben cumplir con lo siguiente:

[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 poder medir los cambios de orientación de hasta 1,000 grados por segundo.

Implementaciones de dispositivos de televisión:

[7.4.3/T-0-1] DEBE admitir Bluetooth y Bluetooth de bajo consumo.
[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 de host, deben cumplir con lo siguiente:

[7.5.3/T-1-1] DEBE incluir compatibilidad con una cámara externa que se conecte 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, haz lo siguiente:

[7.6.1/T-1-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 896 MB si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes

Si las implementaciones de dispositivos de TV son de 64 bits, haz lo siguiente:

[7.6.1/T-2-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,280 MB si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes

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 las aplicaciones de terceros:

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

[5.1/T-0-4] MPEG-D USAC con MPEG-D DRC (AAC de alta eficiencia extendido)

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

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

Implementaciones de dispositivos de televisión:

[5.2.2/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE que admitan la codificación H.264 de videos 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 las aplicaciones de terceros:

[5.3.3/T-0-1] MPEG-4 SP
[5.3.4/T-0-2] H.264 AVC
[5.3.5/T-0-3] H.265 HEVC
[5.3.6/T-0-4] VP8
[5.3.7/T-0-5] VP9
[5.3.1/T-0-6] MPEG-2
[5.3.2/T-0-7] AV1

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 fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

[5.3.1/T-1-1] HD 1080p a 29.97 fotogramas por segundo con perfil principal de nivel alto.
[5.3.1/T-1-2] HD 1080i a 59.94 fotogramas por segundo con Main Profile High Level. DEBEN desentrelazar el video MPEG-2 entrelazado y ponerlo a disposición de las 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 fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

[5.3.4/T-1-1] HD 1080p a 60 fotogramas por segundo con perfil de referencia
[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 fotogramas 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 fotogramas de video y resoluciones estándar hasta las siguientes (inclusive):

[5.3.5/T-1-1] HD 1080p a 60 fotogramas por segundo con Main Profile Level 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, deben cumplir con lo siguiente:

[5.3.5/T-2-1] DEBE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil Main10 de nivel 5 y nivel principal

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación de VP8, como se detalla en la sección 5.3.6, a velocidades de fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

[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 por hardware de VP9 DEBEN admitir la decodificación de VP9, como se detalla en la Sección 5.3.7, a velocidades de fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

[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 por hardware de VP9 admiten la decodificación de VP9 y el perfil de decodificación UHD, deben cumplir con lo siguiente:

[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 que admitan 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 compatibilidad con el volumen principal del sistema y la atenuación del volumen de salida de audio digital en las salidas compatibles, excepto en la salida de transferencia directa de audio comprimido (en la que no se realiza decodificación de audio en el dispositivo).

Si las implementaciones de dispositivos de televisión no tienen una pantalla integrada, sino que admiten una pantalla externa conectada a través de HDMI, deben cumplir con los siguientes requisitos:

[5.8/T-0-1] DEBE establecer el modo de salida HDMI en la resolución más alta para el formato de píxeles elegido que funcione con una frecuencia de actualización de 50 Hz o 60 Hz para la pantalla externa, según la frecuencia de actualización de video de la región en la que se vende el dispositivo.
[5.8/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE proporcionar un selector de frecuencia de actualización HDMI configurable por el usuario.
[5.8] DEBE establecer la frecuencia de actualización del modo de salida HDMI en 50 Hz o 60 Hz, según la frecuencia de actualización de video de la región en la que se vende el dispositivo.

[5.8/T-1-1] DEBE admitir 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, deben cumplir con lo siguiente:

[5.8/T-2-1] DEBE admitir 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 uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.
[3.4.1/T-0-1] DEBE proporcionar una implementación completa de la API de android.webkit.Webview.

Si las implementaciones de dispositivos Android Television admiten una pantalla de bloqueo, deben cumplir con los siguientes requisitos:

[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 que admitan el modo de multiventana de PIP.
[3.10/T-0-1] DEBE admitir servicios de accesibilidad de terceros.
[3.10/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar en el dispositivo servicios de accesibilidad comparables con la funcionalidad de Accesibilidad con interruptores y TalkBack (para los idiomas admitidos por el motor de texto a voz preinstalado) o que la superen, tal como se proporcionan en el proyecto de código abierto de TalkBack.

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

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

El marco de trabajo de entrada de Android TV (TIF) simplifica la entrega de contenido en vivo a los dispositivos Android TV. El TIF proporciona una API estándar para crear módulos de entrada que controlan dispositivos Android TV.

Implementaciones de dispositivos de televisión:

[3/T-0-2] SE DEBE declarar la función de la plataforma android.software.live_tv.
[3/T-0-3] DEBE admitir todas las APIs de TIF para que se pueda instalar y usar en el dispositivo una aplicación que use estas APIs y el servicio de entradas basadas en TIF de terceros.

El Android Television Tuner Framework (TF) unifica el manejo de contenido en vivo de Tuner con el contenido de transmisión de IP en dispositivos Android Television. El framework de Tuner proporciona una API estándar para crear servicios de entrada que usan el sintonizador de televisión de Android.

Si las implementaciones de dispositivos admiten el sintonizador, deben cumplir con los siguientes requisitos:

[3/T-1-1] DEBE admitir todas las APIs de Tuner Framework para que una aplicación que use estas APIs se pueda instalar y usar en el dispositivo.

2.3.4. Rendimiento y potencia

[8.1/T-0-1] Latencia de fotogramas coherente. La latencia de fotogramas incoherente o la demora en renderizar fotogramas NO DEBEN ocurrir más de 5 veces por segundo y DEBEN ser inferiores a 1 vez 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 el AOSP o extienden las funciones que se incluyen en el AOSP, deben cumplir con lo siguiente:

[8.3/T-1-1] DEBE proporcionar al usuario la posibilidad de habilitar e inhabilitar la función de Ahorro de batería.

Si las implementaciones de dispositivos de televisión no tienen batería, deben cumplir con lo siguiente:

[8.3/T-1-2] DEBE registrar el dispositivo como un dispositivo sin batería, como se describe en Cómo admitir dispositivos sin batería.

Si las implementaciones de dispositivos de televisión tienen una batería, deben cumplir con lo siguiente:

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

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 agotamiento aproximado de la batería que causan los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
[8.4/T-0-2] DEBE registrar todos los valores de consumo de energía en miliamperios por hora (mAh).
[8.4/T-0-3] DEBE informar el consumo de energía de la CPU por cada UID de proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo del kernel uid_cputime.
[8.4/T] SE DEBE atribuir al componente de hardware en sí 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 de shell adb shell dumpsys batterystats para el desarrollador de apps.

2.3.5. Modelo de seguridad

Implementaciones de dispositivos de televisión:

[9/T-0-1] DEBE declarar la función android.hardware.security.model.compatible.

Si las implementaciones de dispositivos de televisión incluyen una aplicación predeterminada para admitir el VoiceInteractionService, deben hacer lo siguiente:

[9.1/T-0-1] NO DEBE otorgar ACCESS_FINE_LOCATION como valor predeterminado para esa aplicación.

Implementaciones de dispositivos de televisión:

[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 los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash MD5, SHA-1 y de la familia SHA-2 para admitir correctamente los algoritmos compatibles con el sistema de almacén de claves de Android en un área aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito usando la implementación de 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 aislado y solo cuando se realice correctamente, permitir que se usen 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 upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
[9.11/T-0-4] DEBE admitir la certificación de claves en la que la clave de firma de certificación esté protegida por hardware seguro y la firma se realice en hardware seguro. Se DEBE evitar que las claves de firma de la certificación se usen como identificadores permanentes del dispositivo.

Nota: Para cumplir con este requisito, debes compartir la misma clave de certificación para un SKU determinado, a menos que se produzcan al menos 100,000 unidades de ese SKU. Si se producen más de 100,000 unidades de ese SKU, se PUEDE usar una clave diferente para cada grupo de 100,000 unidades después de eso. Como alternativa, se puede usar la solución de Remote Key Provisioning para aprovisionar claves de certificación de corta duración en el dispositivo.

Si las implementaciones de dispositivos de televisión admiten una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:

[9.11/T-1-1] DEBE permitir que el usuario elija el tiempo de espera de suspensión para la transición del estado desbloqueado al 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, deben hacer lo siguiente:

[9.5/T-2-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios del dispositivo administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la posibilidad de administrar restricciones más detalladas en las apps 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, deben hacer lo siguiente:

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

Si las implementaciones de dispositivos de televisión declaran android.hardware.microphone, deben cumplir con lo siguiente:

[9.8.2/T-4-1] DEBE mostrar el indicador de micrófono cuando una app accede a datos de audio del micrófono, pero no cuando solo se accede al micrófono a través de HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o apps que tienen los roles que se mencionan en la sección 9.1 Permisos con el identificador de CDD C-3-X.
[9.8.2/T-4-2] NO debe ocultar el indicador del micrófono para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.

Si las implementaciones de dispositivos de televisión declaran android.hardware.camera.any, deben cumplir con lo siguiente:

[9.8.2/T-5-1] DEBE mostrar el indicador de acceso a la cámara cuando una app accede a datos de la cámara en vivo, pero no cuando solo se accede a la cámara desde las apps que tienen los roles mencionados en la sección 9.1 Permisos con el identificador de CDD [C-3-X].
[9.8.2/T-5-2] NO debe ocultar el indicador de acceso a la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.

2.3.6. Compatibilidad de las opciones y herramientas para desarrolladores

Implementaciones de dispositivos de televisión:

Perfetto
- [6.1/T-0-1] DEBE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [6.1/T-0-2] El objeto binario de Perfetto DEBE aceptar como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [6.1/T-0-3] El objeto binario de Perfetto DEBE escribir como resultado un registro de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [6.1/T-0-4] MUST provide, through the perfetto binary, at least the data sources described in the perfetto documentation.
- [6.1/T-0-5] El daemon de Perfetto con seguimiento DEBE estar habilitado de forma predeterminada (propiedad del sistema persist.traced.enable).

2.4. Requisitos del reloj

Un dispositivo Android Watch hace referencia a una implementación de dispositivo Android que se puede usar en el cuerpo, tal vez en la muñeca.

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

Tener una pantalla con una longitud diagonal física de entre 1.1 y 2.5 pulgadas
Tener un mecanismo que permita llevarlo en el cuerpo

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

2.4.1. Hardware

Mira las implementaciones de dispositivos:

[7.1.1.1/W-0-1] DEBE tener una pantalla con un tamaño diagonal físico de entre 1.1 y 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 se encuentre 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 de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, deben cumplir con lo siguiente:

[7.3.3/W-1-1] DEBE informar las mediciones de GNSS tan pronto como se encuentren, incluso si aún no se informó una ubicación calculada a partir del GPS o GNSS.
[7.3.3/W-1-2] DEBE informar las seudoranges y las tasas de seudoranges del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras el dispositivo está estacionario o se mueve con una aceleración inferior a 0.2 metros por segundo al cuadrado, son suficientes para calcular la posición con una precisión de 20 metros y la velocidad con una precisión de 0.2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos Watch incluyen un giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[7.3.4/W-2-1] DEBE poder medir los cambios de orientación hasta 1,000 grados por segundo.

Si las implementaciones de dispositivos Watch admiten la conectividad de datos celulares, deben cumplir con lo siguiente:

[7.4.1/W-1-1] DEBE declarar la función android.hardware.telephony.data.

Mira las implementaciones de dispositivos:

[7.4.3/W-0-1] DEBE admitir 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 del usuario.
[7.8.1/W-0-1] DEBE incluir un micrófono.
[7.8.2/W] ES POSIBLE que tenga salida de audio.

2.4.2. Multimedia

No hay requisitos adicionales.

2.4.3. Software

Mira las implementaciones de dispositivos:

[3/W-0-1] DEBE declarar la función android.hardware.type.watch.
[3/W-0-2] DEBE admitir uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] Se DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los intents de aplicaciones que se indican aquí.

Mira las implementaciones de dispositivos:

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

Implementaciones de dispositivos Wear que declaran la marca 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 los servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de Accesibilidad con interruptores y TalkBack (para los idiomas admitidos por el motor de texto a voz preinstalado) o que la superen, tal como se proporciona en el proyecto de código abierto de TalkBack.

Si las implementaciones de dispositivos Watch informan la función android.hardware.audio.output, deben cumplir con lo siguiente:

[3.11/W-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor de TTS que admita los idiomas disponibles en el dispositivo.
[3.11/W-0-1] DEBE admitir la instalación de motores de 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 el AOSP o extienden las funciones que se incluyen en el AOSP, deben cumplir con lo siguiente:

[8.3/W-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar al usuario la posibilidad de mostrar todas las apps que están exentas de los modos de ahorro de energía App Standby y Descanso.
[8.3/W-SR-2] SE RECOMIENDA ENCARECIDAMENTE proporcionar al usuario la posibilidad de habilitar y, también, inhabilitar la función de Ahorro de batería.

Mira las implementaciones de dispositivos:

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

2.4.5. Modelo de seguridad

Mira las implementaciones de dispositivos:

[9/W-0-1] DEBE declarar la función android.hardware.security.model.compatible.

Si las implementaciones de dispositivos Watch incluyen una aplicación predeterminada para admitir el VoiceInteractionService, deben cumplir con lo siguiente:

[9.1/W-0-1] NO DEBE otorgar ACCESS_FINE_LOCATION como valor predeterminado para esa aplicación.

Si las implementaciones de dispositivos Watch incluyen varios usuarios y no declaran la marca de función android.hardware.telephony, sucede lo siguiente:

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

Si las implementaciones de dispositivos Watch incluyen varios usuarios y declaran la marca de función android.hardware.telephony, deben hacer lo siguiente:

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

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y uno o más agentes de confianza que implementan la API de TrustAgentService System, cumplen con los siguientes requisitos:

[9.11.1/W-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (como PIN, patrón o contraseña) con mayor frecuencia que una vez cada 72 horas al menos cada 336 horas (14 días) .

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y uno o más agentes de confianza que llaman a la API de TrustAgentService.grantTrust() del sistema con la marca FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, hacen lo siguiente:

[9.11.1/W-2-1] DEBE cumplir con las siguientes condiciones para llamar a grantTrust() con esa marca:
- El dispositivo está conectado a un dispositivo físico principal de mano cercano que tiene su propia pantalla de bloqueo.
- El usuario autenticó su identidad en esa pantalla de bloqueo o método biométrico de clase 3 en los últimos 30 segundos.
[9.11.1/W-2-2] DEBE establecer el estado del dispositivo en TrustState.TRUSTABLE cuando el dispositivo wearable se quita de la muñeca o del cuerpo, y TrustAgent no revocó la confianza.

2.5. Requisitos para la industria automotriz

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

Las implementaciones de dispositivos Android se clasifican como Automotriz si declaran la función android.hardware.type.automotive o cumplen con todos los siguientes criterios.

Estar incorporados como parte de un vehículo automotor o ser enchufables a él
Usar una pantalla en la fila del asiento del conductor como pantalla principal

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

2.5.1. Hardware

Implementaciones de dispositivos para automóviles:

[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.1.1.1/A-0-3] DEBE admitir la composición de GPU de búferes gráficos que sean al menos tan grandes como la resolución más alta de cualquier pantalla integrada.

Si las implementaciones de dispositivos Automotive admiten la función Multiusuario simultáneo (en la que varios usuarios de Android pueden interactuar con el dispositivo de forma simultánea, cada uno con su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), deben cumplir con lo siguiente:

[7.1.1.1/A-1-1] DEBE tener una pantalla independiente de al menos 6 pulgadas de tamaño diagonal físico para cada zona de ocupantes de la pantalla principal. Se debe etiquetar como CarOccupantZoneManager.DISPLAY_TYPE_MAIN para cada zona de ocupantes.
[7.1.1.1/A-1-2] DEBE tener un diseño de tamaño de pantalla de al menos 750 dp x 480 dp para cada pantalla principal.

Si las implementaciones de dispositivos para automóviles admiten OpenGL ES 3.1, deben cumplir con lo siguiente:

[7.1.4.1/A-0-1] DEBE declarar OpenGL ES 3.1 o una versión posterior.
[7.1.4.1/A-0-2] DEBE admitir Vulkan 1.1.
[7.1.4.1/A-0-3] DEBE incluir el cargador de Vulkan y exportar todos los símbolos.

Si las implementaciones de dispositivos para automóviles incluyen compatibilidad con Vulkan, deben cumplir con lo siguiente:

[7.1.4.2/A-1-1] DEBE satisfacer los requisitos especificados por el perfil de Baseline de Android 2021.

Si las implementaciones de dispositivos para automóviles indican que admiten pantallas de alto rango dinámico a través de Configuration.isScreenHdr(), deben cumplir con lo siguiente:

[7.1.4.5/A-1-1] DEBE anunciar la compatibilidad con 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 para automóviles:

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

Si las implementaciones de dispositivos para automóviles declaran compatibilidad a través de una propiedad del sistema graphics.gpu.profiler.support, deben hacer lo siguiente:

[7.1.4.6/A-1-1] DEBE informar como resultado un registro de protobuf que cumpla con el esquema para los contadores de GPU y los RenderStages de GPU definidos en la documentación de Perfetto.
[7.1.4.6/A-1-2] DEBE informar valores conformes para los contadores de la GPU del dispositivo según el proto del paquete gpu counter trace.
[7.1.4.6/A-1-3] DEBE informar valores conformes para los RenderStages de la GPU del dispositivo según el proto de paquetes de registro de etapas de renderización.
[7.1.4.6/A-1-4] DEBE informar un punto de seguimiento de frecuencia de GPU como se especifica en el formato: power/gpu_frequency.

Implementaciones de dispositivos para automóviles:

[7.1.5/A-0-1] DEBE incluir compatibilidad con el modo de compatibilidad de apps heredadas tal como se implementa en el código fuente abierto de Android upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los activadores o los umbrales en los que se activa el modo de compatibilidad, y NO DEBEN alterar el comportamiento del modo de compatibilidad en sí.

Implementaciones de dispositivos para automóviles:

[7.1.7/A-0-1] DEBE configurar las pantallas secundarias en la línea de visión del conductor como FLAG_PRIVATE.
[7.2.3/A-0-1] DEBE proporcionar la función de Inicio y PUEDE proporcionar las funciones de Atrás y Recientes.
[7.2.3/A-0-2] DEBE enviar el evento de presión normal y el de presión prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
[7.3/A-0-1] DEBE implementar y registrar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED y PARKING_BRAKE_ON.
[7.3/A-0-2] El valor de la marca NIGHT_MODE DEBE ser coherente con el modo claro/oscuro del panel y DEBE basarse en la entrada del sensor de luz ambiental. El sensor de luz ambiente subyacente PUEDE ser el mismo que el fotómetro.
[7.3/A-0-3] Se 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] MAY dead reckon Location by fusing GPS/GNSS with additional sensors. Si la Ubicación se calcula a ciegas, se RECOMIENDA ENCARECIDAMENTE implementar y registrar los tipos de sensores o los IDs de propiedades del vehículo correspondientes que se usen.
[7.3/A-0-4] La ubicación solicitada a través de LocationManager#requestLocationUpdates() NO DEBE correlacionarse 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 y un giroscopio de 3 ejes.
[7.3/A-SR-2] Se RECOMIENDA ENCARECIDAMENTE implementar y registrar el sensor de TYPE_HEADING.

[7.3/A-1-1] DEBE establecer el valor del parámetro NIGHT_MODE de forma coherente con el modo día/noche del panel en todas las pantallas, incluidas las de los asientos traseros.

Si las implementaciones de dispositivos para automóviles incluyen un acelerómetro, deben cumplir con lo siguiente:

[7.3.1/A-1-1] DEBE poder registrar eventos con una frecuencia de al menos 100 Hz.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, deben cumplir con los siguientes requisitos:

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

Si las implementaciones de dispositivos para automóviles incluyen un acelerómetro con menos de 3 ejes, deben cumplir con lo siguiente:

[7.3.1/A-1-3] DEBE implementar y registrar el sensor de TYPE_ACCELEROMETER_LIMITED_AXES.
[7.3.1/A-1-4] DEBE implementar y registrar el sensor de TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones de dispositivos para automóviles incluyen un giroscopio, deben cumplir con los siguientes requisitos:

[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 poder medir los cambios de orientación 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 para automóviles incluyen un giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[7.3.4/A-SR-2] SE RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto para el giroscopio de ejes limitados.

Si las implementaciones de dispositivos para automóviles incluyen un giroscopio con menos de 3 ejes, deben cumplir con lo siguiente:

[7.3.4/A-4-1] DEBE implementar y registrar el sensor de TYPE_GYROSCOPE_LIMITED_AXES.
[7.3.4/A-4-2] DEBE implementar y registrar el sensor de TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones de dispositivos para automóviles incluyen un receptor GPS/GNSS, pero no incluyen conectividad de datos basada en redes celulares, deben cumplir con lo siguiente:

[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 4 días o más en un plazo de 60 segundos.
[7.3.3/A-3-2] DEBE cumplir con los criterios de tiempo hasta la primera correcció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). Por lo general, el requisito 7.3.3/C-1-2 se cumple en los vehículos sin conectividad de datos basada en redes móviles, ya sea mediante las predicciones de órbita del GNSS calculadas en el receptor o la última ubicación conocida del vehículo junto con la capacidad de navegación a ciegas durante al menos 60 segundos con una precisión de posición que satisfaga 7.3.3/C-1-3, o bien una combinación de ambos.

Si las implementaciones de dispositivos para automóviles incluyen un sensor TYPE_HEADING, deben cumplir con lo siguiente:

[7.3.4/A-4-3] DEBE poder informar eventos con una frecuencia de al menos 1 Hz.
[7.3.4/A-SR-3] Se RECOMIENDA ENCARECIDAMENTE que informen eventos con una frecuencia de al menos 10 Hz.
DEBE hacer referencia al norte verdadero.
DEBE estar disponible incluso cuando el vehículo está detenido.
DEBE tener una resolución de al menos 1 grado.

Implementaciones de dispositivos para automóviles:

[7.4.3/A-0-1] DEBE admitir Bluetooth y DEBERÍA admitir Bluetooth de bajo consumo.
[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 de manos libres (HFP).
- Reproducción de contenido multimedia a través del perfil de distribución de audio (A2 DP).
- Control de reproducción de contenido multimedia a través del perfil de control remoto (AVRCP)
- Compartir contactos con el perfil de acceso a la agenda telefónica (PBAP)
[7.4.3/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE que se admita el perfil de acceso a mensajes (MAP) si el dispositivo tiene la zona del conductor.

[7.4.3/A-1-1] DEBE ser independiente y NO interferir en la experiencia de BT de otros usuarios.

Implementaciones de dispositivos para automóviles:

[7.4.5/A] DEBE incluir compatibilidad con la conectividad de datos basada en redes celulares.
[7.4.5/A] PUEDE usar la constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID de la API del sistema para las redes que deberían estar disponibles para las apps del sistema.

Si las implementaciones de dispositivos incluyen compatibilidad con la radio de transmisión AM/FM y exponen la funcionalidad a cualquier aplicación, deben cumplir con lo siguiente:

[7.4/A-1-1] DEBE declarar la compatibilidad con FEATURE_BROADCAST_RADIO.

Una cámara trasera es una cámara orientada al mundo que puede ubicarse en cualquier lugar del vehículo y que apunta hacia el exterior de la cabina del vehículo, es decir, capta imágenes de escenas en el lado opuesto 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 que apunta hacia el interior de la cabina del vehículo; es decir, capta imágenes del usuario, por ejemplo, para videoconferencias y aplicaciones similares.

Implementaciones de dispositivos para automóviles:

[7.5/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir una o más cámaras orientadas hacia el mundo.
PUEDE incluir una o más cámaras orientadas al usuario.
[7.5/A-SR-2] SE RECOMIENDA ENCARECIDAMENTE que admitan la transmisión simultánea de varias cámaras.

Si las implementaciones de dispositivos para automóviles incluyen al menos una cámara orientada hacia el exterior, para esa cámara, deben cumplir con lo siguiente:

[7.5/A-1-1] DEBE orientarse de modo que la dimensión larga de la cámara se alinee con el plano X-Y de los ejes del sensor de Android Automotive.
[7.5/A-SR-3] SE RECOMIENDA ENCARECIDAMENTE que tengan hardware de enfoque fijo o EDOF (profundidad de campo extendida).
[7.5/A-1-2] DEBE tener la cámara principal orientada hacia el mundo como la cámara orientada hacia el mundo con el ID de cámara más bajo.

Si las implementaciones de dispositivos para automóviles incluyen al menos una cámara orientada hacia el usuario, entonces, para esa cámara, se debe cumplir lo siguiente:

[7.5/A-2-1] La cámara principal orientada hacia el usuario DEBE ser la cámara orientada hacia el usuario con el ID de cámara más bajo.
SE PUEDE orientar de modo que la dimensión larga de la cámara se alinee con el plano X-Y de los ejes de los sensores automotrices de Android.

Si las implementaciones de dispositivos para automóviles incluyen una cámara a la que se puede acceder a través de la API de android.hardware.Camera o android.hardware.camera2, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos para automóviles incluyen una cámara a la que no se puede acceder a través de la API de android.hardware.Camera o android.hardware.camera2, deben cumplir con los siguientes requisitos:

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

Si las implementaciones de dispositivos para automóviles incluyen una o más cámaras a las que se puede acceder a través del servicio Extended View System, para cada una de esas cámaras, se debe cumplir con lo siguiente:

[7.5/A-5-1] NO DEBE rotar ni reflejar horizontalmente la vista previa de la cámara.
[7.5/A-SR-4] Se RECOMIENDA ENCARECIDAMENTE que tengan una resolución de al menos 1.3 megapíxeles.

Si las implementaciones de dispositivos para automóviles incluyen una o más cámaras a las que se puede acceder a través del servicio Extended View System y las APIs de android.hardware.Camera o android.hardware.Camera2, entonces, para cada una de esas cámaras, se debe cumplir con lo siguiente:

[7.5/A-6-1] DEBE informar el mismo ID de cámara.

Si las implementaciones de dispositivos para automóviles proporcionan una API de cámara propietaria, deben cumplir con los siguientes requisitos:

[7.5/A-7-1] DEBE implementar esa API de cámara con la API de android.hardware.camera2 o la API de Extended View System.

Implementaciones de dispositivos para automóviles:

[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 (partición /data).
[7.6.1/A] DEBE formatear la partición de datos para ofrecer un mejor rendimiento y una mayor durabilidad en el almacenamiento flash (por ejemplo, con el sistema de archivos f2fs).

Si las implementaciones de dispositivos para automóviles proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble, deben cumplir con lo siguiente:

[7.6.1/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE reducir la sobrecarga de E/S en las operaciones que se realizan en el almacenamiento externo, por ejemplo, usando SDCardFS.

[7.6.1/A-1-1] DEBE tener, en una sola instancia de AAOS, al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (partición /data) para cada usuario simultáneo de Android.

Si las implementaciones de dispositivos para automóviles son de 64 bits, haz lo siguiente:

[7.6.1/A-2-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 816 MB por pantalla principal si se usa alguna de las siguientes densidades:
- 280 dpi o menos en pantallas pequeñas o normales
- ldpi o inferior en pantallas muy grandes
- mdpi o inferior en pantallas grandes
[7.6.1/A-2-2] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 944 MB por pantalla principal si se usa alguna de las siguientes densidades:
- xhdpi o superior en pantallas pequeñas o normales
- hdpi o superior en pantallas grandes
- mdpi o superior en pantallas muy grandes
[7.6.1/A-2-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1,280 MB por pantalla principal si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes
[7.6.1/A-2-4] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,824 MB por pantalla principal si se usa alguna de las siguientes densidades:
- 560 DPI o más en pantallas pequeñas o normales
- 400 DPI o más en pantallas grandes
- xhdpi o superior en pantallas extra grandes

Implementaciones de dispositivos para automóviles:

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

Si las implementaciones de dispositivos para automóviles incluyen un puerto USB con un controlador que funciona en modo periférico, deben cumplir con lo siguiente:

[7.7.1/A-1-1] DEBE implementar la API de Android Open Accessory (AOA).

Si las implementaciones de dispositivos para automóviles incluyen un puerto USB que admite el modo de host, deben cumplir con lo siguiente:

[7.7.2/A-1-1] DEBE implementar la clase de audio USB como se describe en la documentación del SDK de Android.

Implementaciones de dispositivos para automóviles:

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

Implementaciones de dispositivos para automóviles:

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

[7.8.2/A-1-1] DEBE tener un dispositivo de salida de audio para cada pantalla principal en los sistemas multiusuario simultáneos.
[7.8.2/A-1-2] DEBE tener una zona de audio para el conductor que cubra la bocina global de la cabina. La zona del pasajero delantero puede compartir la zona de audio del conductor o tener su propia salida de audio.

Cuando se llama a la API de AudioManager.getDevices() mientras el periférico USB está conectado, sucede lo siguiente:

[7.8.2.2/A-1-1] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y rol isSink() si el campo de tipo de terminal de audio USB es 0x0302.
[7.8.2.2/A-1-2] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y rol isSink() si el campo de tipo de terminal de audio USB es 0x0402.
[7.8.2.2/A-1-3] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y rol isSink() si el campo de tipo de terminal de audio USB es 0x0603.
[7.8.2.2/A-1-4] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y rol isSink() si el campo de tipo de terminal de audio USB es 0x0400.

2.5.2. Multimedia

Las implementaciones de dispositivos para automóviles DEBEN admitir los siguientes formatos de codificación y decodificación de audio, y ponerlos a disposición de las aplicaciones de terceros:

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

[5.1/A-0-4] MPEG-D USAC con MPEG-D DRC (AAC de alta eficiencia extendido)

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

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

Las implementaciones de dispositivos para automóviles DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de las 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 para automóviles admitan la siguiente decodificación de video:

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

[5.5.3/A-1-1] DEBE definir curvas de volumen idénticas para todos los flujos de salida de audio que se asignen al mismo grupo de volumen que se define en el archivo de configuración de audio del automóvil.

2.5.3. Software

Implementaciones de dispositivos para automóviles:

[3/A-0-1] DEBE declarar la función android.hardware.type.automotive.
[3/A-0-2] DEBE admitir uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] DEBE admitir todas las APIs públicas en el espacio de nombres android.car.*.

Si las implementaciones de dispositivos para Automotive proporcionan una API propietaria con android.car.CarPropertyManager y android.car.VehiclePropertyIds, deben cumplir con lo siguiente:

[3/A-1-1] NO DEBE adjuntar privilegios especiales al uso de estas propiedades por parte de la aplicación del sistema ni impedir que las aplicaciones de terceros usen estas propiedades.
[3/A-1-2] NO DEBE replicar una propiedad del vehículo que ya exista en el SDK.

Implementaciones de dispositivos para automóviles:

[3.2.1/A-0-1] DEBE admitir y aplicar todas las constantes de permisos según se documenta en la página de referencia de permisos para automóviles.
[3.2.3.1/A-0-1] DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.
[3.2.3.1/A-0-2] DEBE tener una app que controle los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE y ACTION_CREATE_DOCUMENT como se describe en los documentos del SDK, y proporcionar la capacidad del usuario para acceder a los datos del proveedor de documentos con la API de DocumentsProvider.

Si la aplicación de configuración de la implementación del dispositivo para automóviles implementa una función de división con la incorporación de actividades, se cumplen las siguientes condiciones:

[3.2.3.1/A-1-1] DEBE tener una actividad que controle el intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY cuando la funcionalidad de división está activada. La actividad DEBE estar protegida por android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK y DEBE iniciar la actividad del Intent analizado desde Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
[3.4.1/A-0-1] DEBE proporcionar una implementación completa de la API de android.webkit.Webview.

[3.8/A-1-1] DEBE implementar la siguiente lista predefinida de UserRestrictions para los usuarios secundarios completos que no son el usuario en primer plano actual, pero que tienen acceso a la IU de la pantalla que se les asignó. La lista de UserRestrictions incluye DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE y DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] NO DEBE permitir que los usuarios secundarios completos que no sean el usuario en primer plano actual, pero que tengan acceso a la IU de la pantalla que se les asignó, cambien el modo día/noche, la configuración regional, la fecha, la hora, la zona horaria o las funciones de color de la pantalla (incluidos el brillo, Luz nocturna, la escala de grises de Bienestar digital y Reducir colores brillantes) para ningún otro usuario a través de la Configuración o de una API.

Implementaciones de dispositivos para automóviles:

[3.8.3/A-0-1] DEBE mostrar notificaciones que usen la API de Notification.CarExtender cuando lo soliciten aplicaciones de terceros.
[3.8.4/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.

Si las implementaciones de dispositivos para automóviles incluyen un botón de presionar para hablar, deben cumplir con los siguientes requisitos:

[3.8.4/A-1-1] DEBE usar una presión breve del botón de presionar para hablar como la interacción designada para iniciar la aplicación de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService.

Implementaciones de dispositivos para automóviles:

[3.8.3.1/A-0-1] DEBE renderizar correctamente los recursos como se describe en la documentación del SDK de Notifications on Automotive OS.
[3.8.3.1/A-0-2] DEBE mostrar PLAY y SILENCIAR para las acciones de notificación en lugar de las que se proporcionan a través de Notification.Builder.addAction().
[3.8.3.1/A] DEBE restringir el uso de tareas de administración enriquecidas, como los controles por canal de notificaciones. PUEDE usar la indicación visual de la interfaz de usuario por aplicación para reducir los controles.

Si las implementaciones de dispositivos para automóviles admiten propiedades del HAL de User, deben cumplir con lo siguiente:

[3.9.3/A-1-1] DEBE implementar todas las propiedades del ciclo de vida del usuario: INITIAL_USER_INFO, SWITCH_USER, CREATE_USER y REMOVE_USER.

Implementaciones de dispositivos para automóviles:

[3.14/A-0-1] DEBE incluir un framework de IU para admitir apps de terceros que usen las APIs de medios, como se describe en la sección 3.14.
[3.14/A-0-2] DEBE permitir que el usuario interactúe de forma segura con las Aplicaciones de medios mientras conduce.
[3.14/A-0-3] DEBE admitir la acción de Intent implícito CAR_INTENT_ACTION_MEDIA_TEMPLATE con el elemento adicional CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] DEBE proporcionar una ayuda visual para navegar a la actividad de preferencias de una aplicación de medios, pero SOLO DEBE habilitarla cuando no estén vigentes las restricciones de UX para automóviles.
[3.14/A-0-5] DEBE mostrar los mensajes de error establecidos por las aplicaciones de medios y DEBE admitir los elementos adicionales opcionales ERROR_RESOLUTION_ACTION_LABEL y ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] DEBE admitir una indicación visual de búsqueda integrada en la app para las apps que admiten búsquedas.
[3.14/A-0-7] DEBE respetar las definiciones de CONTENT_STYLE_BROWSABLE_HINT y CONTENT_STYLE_PLAYABLE_HINT cuando muestre la jerarquía de MediaBrowser.

Implementaciones de dispositivos para automóviles:

[3.14/A-0-8] DEBE declarar el parámetro de configuración android.software.car.templates_host.
[3.14/A-0-9] DEBE declarar la marca de función com.android.car.background_audio_while_driving.
[3.14/A-0-10] DEBE declarar la marca de función android.software.car.templates_host.media.

Si las implementaciones de dispositivos para automóviles incluyen una app de selector predeterminada, deben cumplir con los siguientes requisitos:

[3.14/A-1-1] DEBE incluir servicios multimedia y abrirlos con el intent CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementaciones de dispositivos para automóviles:

[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 visibles la barra de estado y la barra de navegación 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 IU del sistema, para garantizar que esos elementos sean claramente visibles en todo momento.

Implementaciones de dispositivos para automóviles:

[7.1.1/A-0-1] DEBE declarar la marca de función android.software.car.display_compatibility.

Mientras se ejecutan aplicaciones en primer plano con la función android.software.car.display_compatibility o aplicaciones sin la función android.hardware.type.automotive, dispositivos para automóviles:

[7.1.1/A-1-1] DEBE proporcionar la función Atrás.

Si las implementaciones de dispositivos para automóviles permiten a los usuarios realizar llamadas de cualquier tipo, deben cumplir con lo siguiente:

[7.4.1.2/A-1-1] DEBE declarar la marca de función android.software.telecom.

[7.4.1.2/A-1-2] DEBE implementar el marco de trabajo de telecomunicaciones.

2.5.4. Rendimiento y potencia

[8.1/A-0-1] Latencia de fotogramas coherente. La latencia de fotogramas inconsistente o la demora en renderizar fotogramas NO DEBEN ocurrir más de 5 veces por segundo, y DEBEN ser inferiores a 1 vez por segundo.
[8.1/A-0-2] Latencia de la interfaz de usuario. Las implementaciones de dispositivos DEBEN garantizar una experiencia del usuario de baja latencia desplazándose por una lista de 10,000 entradas de lista, según lo define el Conjunto de pruebas de compatibilidad (CTS) de Android, en menos de 36 segundos.
[8.1/A-0-3] Cambio de tareas. Cuando se hayan iniciado varias apps, el reinicio de una aplicación que ya se está ejecutando después de que se haya iniciado DEBE tardar menos de 1 segundo.

Implementaciones de dispositivos para automóviles:

[8.2/A-0-1] DEBE informar la cantidad de bytes leídos y escritos en el almacenamiento no volátil para el UID de cada proceso, de modo 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.2/A-0-2] DEBE garantizar un rendimiento de escritura secuencial de al menos 5 MB/s.
[8.2/A-0-3] DEBE garantizar un rendimiento de escritura aleatoria de al menos 0.5 MB/s.
[8.2/A-0-4] DEBE garantizar un rendimiento de lectura secuencial de al menos 15 MB/s.
[8.2/A-0-5] DEBE garantizar un rendimiento de lectura aleatoria de al menos 3.5 MB/s.

Si las implementaciones de dispositivos para automóviles devuelven android.os.Build.VERSION_CODES.U o un valor mayor para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben cumplir con lo siguiente:

[8.2/A-1-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 150 MB/s.
[8.2/A-1-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 10 MB/s.
[8.2/A-1-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 250 MB/s.
[8.2/A-1-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 100 MB/s.
[8.2/A-1-5] DEBE garantizar un rendimiento de lectura y escritura secuencial paralelo con un rendimiento de lectura 2 veces mayor y un rendimiento de escritura 1 vez mayor de al menos 50 MB/s.
[8.3/A-1-3] DEBE admitir el Modo de garaje.
[8.3/A] DEBE estar en el modo de cochera durante al menos 15 minutos después de cada viaje, a menos que se cumpla una de las siguientes condiciones:
- La batería está agotada.
- No se programan trabajos inactivos.
- El conductor sale del modo Garage.
[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 la descarga aproximada de la batería que causan los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
[8.4/A-0-2] SE DEBEN 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 cada UID de proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo del kernel uid_cputime.
[8.4/A] SE DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.
[8.4/A-0-4] DEBE poner este uso de energía a disposición del desarrollador de apps a través del comando de shell adb shell dumpsys batterystats.

2.5.5. Modelo de seguridad

Si las implementaciones de dispositivos para automóviles admiten varios usuarios, deben cumplir con los siguientes requisitos:

[9.5/A-1-1] NO DEBE permitir que los usuarios interactúen con el usuario del sistema sin encabezado ni cambien a él, excepto para la provisión de dispositivo.
[9.5/A-1-2] DEBE cambiar a un Usuario secundario antes de BOOT_COMPLETED.
[9.5/A-1-3] DEBE admitir la capacidad de crear un usuario invitado incluso cuando se haya alcanzado la cantidad máxima de usuarios en un dispositivo.

Si las implementaciones de dispositivos para automóviles admiten la API de System VisualQueryDetectionService o algún otro mecanismo para la detección de búsquedas sin indicación de acceso al micrófono o la cámara, deben hacer lo siguiente:

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

Si las implementaciones de dispositivos para automóviles declaran android.hardware.microphone, deben cumplir con lo siguiente:

[9.8.2/A-1-1] DEBE mostrar el indicador de micrófono cuando una app accede a los datos de audio del micrófono, pero no cuando HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o las apps que tienen los roles mencionados en la sección 9.1 con el identificador de CDD [C-4-X] solo acceden al micrófono.
[9.8.2/A-1-2] NO DEBE ocultar el indicador del micrófono para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.
[9.8.2/A-1-3] DEBE proporcionar una opción para activar o desactivar el micrófono en la app de Configuración.

Si las implementaciones de dispositivos para automóviles declaran android.hardware.camera.any, deben cumplir con lo siguiente:

[9.8.2/A-2-1] DEBE mostrar el indicador de acceso a la cámara cuando una app accede a datos de la cámara en vivo, pero no cuando solo se accede a la cámara desde las apps que tienen los roles definidos en la Sección 9.1 Permisos con el identificador de CDD [C-4-X].
[9.8.2/A-2-2] NO DEBE ocultar el indicador de acceso a la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.
[9.8.2/A-2-3] DEBE proporcionar una opción para que el usuario active o desactive la cámara en la app de Configuración.
[9.8.2/A-2-4] DEBE mostrar las apps recientes y activas que usan la cámara, según lo que devuelve PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados a ellas.

Implementaciones de dispositivos para automóviles:

[9/A-0-1] DEBE declarar la función 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 los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash MD5, SHA-1 y de la familia SHA-2 para admitir correctamente los algoritmos compatibles con el sistema Android Keystore en un área que esté aislada de forma segura del código que se ejecuta en el kernel y más allá. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito utilizando la implementación de 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 aislado y solo cuando se realice correctamente, permitir que se usen 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 upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
[9.11/A-0-4] DEBE admitir la certificación de claves en la que la clave de firma de certificación esté protegida por hardware seguro y la firma se realice en hardware seguro. Se DEBE evitar que las claves de firma de la certificación se usen como identificadores permanentes del dispositivo.

Nota: Para cumplir con este requisito, debes compartir la misma clave de certificación para un SKU determinado, a menos que se produzcan al menos 100,000 unidades de ese SKU. Si se producen más de 100,000 unidades de ese SKU, se PUEDE usar una clave diferente para cada grupo de 100,000 unidades después de eso. Como alternativa, se puede usar la solución de Remote Key Provisioning para aprovisionar claves de certificación de corta duración en el dispositivo.

Implementaciones de dispositivos para automóviles:

[9.14/A-0-1] DEBE controlar el acceso a los mensajes de los subsistemas del vehículo del framework de Android (p.ej., permitir tipos y fuentes de mensajes).
[9.14/A-0-2] DEBE supervisar los ataques de denegación de servicio del framework de Android o de apps de terceros. Esto protege contra el 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 las opciones y herramientas para desarrolladores

Implementaciones de dispositivos para automóviles:

Perfetto
- [6.1/A-0-1] DEBE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [6.1/A-0-2] El ejecutable de Perfetto DEBE aceptar como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [6.1/A-0-3] El objeto binario de Perfetto DEBE escribir como resultado un registro de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [6.1/A-0-4] DEBE proporcionar, a través del objeto binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
- [6.1/A-0-5] El daemon de Perfetto con seguimiento DEBE estar habilitado de forma predeterminada (propiedad del sistema persist.traced.enable).

2.6. Requisitos de la tablet

Un dispositivo tablet Android hace referencia a una implementación de dispositivo Android que suele cumplir con todos los siguientes criterios:

Se usa sujetándolo con ambas manos.
No tiene una configuración convertible ni de tipo clamshell.
Las implementaciones de teclado físico que se usan con el dispositivo se conectan a través de una conexión estándar (p.ej., USB o Bluetooth).
Tiene una fuente de alimentación que proporciona movilidad, como una batería.
Tiene un tamaño de visualización de más de 7" y menos de 18", medido en diagonal.

Las implementaciones de dispositivos tablet tienen requisitos similares a las implementaciones de dispositivos de mano. Las excepciones se indican con un asterisco (*) en esa sección y se mencionan como referencia en esta sección.

2.6.1. Hardware

Giroscopio

Si las implementaciones de dispositivos Tablet incluyen un giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[7.3.4/Tab-1-1] DEBE poder medir los cambios de orientación hasta 1,000 grados por segundo.

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

Las densidades de pantalla que se indican para pantallas pequeñas o normales en los requisitos de dispositivos portátiles no se aplican a las tablets.

Modo de realidad virtual (sección 7.9.1)

Alto rendimiento de realidad virtual (sección 7.9.2)

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

2.6.2. Modelo de seguridad

Claves y credenciales (sección 9.11)

Consulta la sección [9.11].

Si las implementaciones de dispositivos Tablet incluyen varios usuarios y no declaran la marca de función android.hardware.telephony, deben hacer lo siguiente:

[9.5/T-1-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la posibilidad de administrar restricciones más detalladas en las apps 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, deben hacer lo siguiente:

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

2.6.2. Software

[3.2.3.1/Tab-0-1] DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.

3. Software

3.1. Compatibilidad de la API administrada

El entorno de ejecución de código de bytes de Dalvik administrado 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 de Android expuestas a las 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 upstream.
[C-0-2] DEBE admitir o conservar todas las clases, los métodos y los elementos asociados marcados por la anotación TestApi (@TestApi).
[C-0-3] NO DEBE omitir ninguna API administrada, alterar las interfaces o firmas de las APIs, desviarse del comportamiento documentado ni incluir no-ops, excepto cuando se permita específicamente en esta Definición de Compatibilidad.
[C-0-4] DEBE mantener las APIs presentes y comportarse de manera razonable, incluso cuando se omitan algunas funciones de hardware para las que Android incluye APIs. Consulta la sección 7 para conocer los requisitos específicos de esta situación.
[C-0-5] NO DEBE permitir que las apps de terceros usen interfaces que no pertenecen al SDK, las cuales se definen como métodos y campos en los paquetes del lenguaje Java que se encuentran en la ruta de acceso de inicio en AOSP y que no forman parte del SDK público. Esto incluye las APIs decoradas con la anotación @hide, pero no con un @SystemAPI, como se describe en los documentos del SDK y los miembros de clase privados y privados del paquete.
[C-0-6] DEBE incluirse con todas y cada una de las interfaces que no pertenecen al SDK en las mismas listas restringidas que se proporcionan a través de las marcas provisional y de lista de bloqueo en la ruta de acceso prebuilts/runtime/appcompat/hiddenapi-flags.csv para la rama del nivel de API correspondiente en AOSP.
[C-0-7] DEBE admitir el mecanismo de actualización dinámica de configuración firmada para quitar interfaces que no pertenecen al SDK de una lista restringida incorporando la configuración firmada en cualquier APK, con las claves públicas existentes presentes en AOSP.

Sin embargo, ten en cuenta lo siguiente:
- PUEDE, si una API oculta está ausente o se implementa de manera diferente en la implementación del dispositivo, mover la API oculta a la lista de bloqueo o omitirla de todas las listas restringidas.
- SI, si ya existe una API oculta en el AOSP, agrega la API oculta a cualquiera de las listas restringidas.

[C-0-8] NO DEBE admitir la instalación de aplicaciones orientadas a un nivel de API inferior a 24 26.

3.1.1. Extensiones de Android

Android admite la extensión de la superficie de la API administrada de un nivel de API en particular actualizando la versión de la extensión para ese nivel de API. La API de 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 del AOSP de la biblioteca compartida ExtShared y los servicios ExtServices con versiones mayores o iguales que las versiones mínimas permitidas para cada nivel de API. Por ejemplo, las implementaciones de dispositivos con Android 7.0 que ejecutan el nivel de API 24 DEBEN incluir, al menos, la versión 1.
[C-0-2] SOLO DEBE devolver un número de versión de extensión válido que haya definido el AOSP.
[C-0-3] DEBE admitir todas las APIs definidas por las versiones de extensión que devuelve android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la misma manera que se admiten otras APIs administradas, según los requisitos de la sección 3.1.

3.1.2. Biblioteca de Android

Debido a la baja del cliente HTTP de Apache, las implementaciones de dispositivos deben cumplir con lo siguiente:

[C-0-1] NO DEBE colocar la biblioteca org.apache.http.legacy en la ruta de arranque.
[C-0-2] Se DEBE agregar la biblioteca org.apache.http.legacy a la ruta de clase de la aplicación solo cuando la app cumpla con una de las siguientes condiciones:
- Se segmenta para el nivel de API 28 o versiones anteriores.
- 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 flexible

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

3.2.1. Permisos

[C-0-1] Los implementadores de dispositivos DEBEN admitir y aplicar todas las constantes de permisos, como se documenta en la página de referencia de permisos. Ten en cuenta que en la sección 9, se enumeran requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de compilación

Las APIs de Android incluyen varias constantes en la clase android.os.Build que tienen como objetivo 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 las implementaciones de dispositivos DEBEN ajustarse.

Parámetro	Detalles
VERSION.RELEASE	Versión del sistema Android que se está ejecutando actualmente, en formato legible. Este campo DEBE tener uno de los valores de cadena definidos en Permitted Version Strings for Android 17.
VERSION.SDK	Versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. En el caso de Android 17, este campo DEBE tener el valor de número entero 17_INT.
VERSION.SDK_INT	Versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. En Android 17, este campo DEBE tener el valor de número entero 17&lowbar;INT.
VERSION.INCREMENTAL	Es 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 para el usuario. Este valor NO se debe reutilizar 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 código fuente se usó para generar la compilación. El valor de este campo DEBE poder codificarse como ASCII de 7 bits imprimible y coincidir con la expresión regular `^[^ :\/~]+$`.
JUEGOS DE MESA	Es un valor elegido por el implementador del dispositivo que identifica el hardware interno específico que usa el dispositivo, en formato legible para el usuario. 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_-]+$`.
SEGURIDAD	Es un valor que refleja el nombre de la marca asociada al dispositivo, tal como lo conocen los usuarios finales. DEBE estar en un formato legible para las personas y DEBE representar al fabricante del dispositivo o la marca de la empresa con la que 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&lowbar;ABIS	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con laAPI nativa
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con laAPI nativa
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
CPU&lowbar;ABI	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con laAPI nativa
CPU&lowbar;ABI2	Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
DISPOSITIVO	Es un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre interno que identifica la configuración de las funciones de 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 del dispositivo NO DEBE cambiar durante la vida útil del producto.
FINGERPRINT	Es una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible. DEBE seguir esta plantilla: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por ejemplo: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys La huella digital NO DEBE incluir caracteres de espacio en blanco. El valor de este campo DEBE poder codificarse como ASCII de 7 bits.
HARDWARE	Nombre del hardware (desde la línea de comandos 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_-]+$`.
HOST	Es una cadena que identifica de forma única el host en el que se compiló la compilación, en formato legible. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
ID	Es 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 lo suficientemente significativo para que los usuarios finales distingan entre las 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	Es el nombre comercial del fabricante del equipo original (OEM) del producto. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
SOC&lowbar;MANUFACTURER	Es el nombre comercial del fabricante del sistema en chip (SoC) principal que se usa en el producto. Los dispositivos con el mismo fabricante de SoC deben usar el mismo valor constante. Pídele al fabricante del SoC la constante correcta que debes usar. 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 "unknown". Este campo NO DEBE cambiar durante la vida útil del producto.
SOC&lowbar;MODEL	Es el nombre del modelo del sistema en chip (SoC) principal que se usa en el producto. Los dispositivos con el mismo modelo de SOC deben usar el mismo valor constante. Pídele al fabricante del SoC la constante correcta que debes usar. 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 NO DEBE ser igual a "unknown". Este campo NO DEBE cambiar durante la vida útil del producto.
MODEL	Es 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 ni una cadena vacía (""). Se RECOMIENDA ENCARECIDAMENTE que este campo NO cambie durante la vida útil del producto.
PRODUCTO	Es un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre interno del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente está destinado a que lo vean los 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 su vida útil.
ODM&lowbar;SKU	Es un valor opcional elegido por el implementador del dispositivo que contiene el SKU (Stock Keeping Unit) que se usa para hacer un seguimiento de las 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.,_-]+)$`.
SERIAL	DEBE devolver "UNKNOWN".
ETIQUETAS	Es una lista de etiquetas separadas por comas que elige el implementador del dispositivo y que distinguen aún más la compilación. Las etiquetas DEBEN poder codificarse como ASCII de 7 bits, coincidir con la expresión regular `^[a-zA-Z0-9._-]+` y tener uno de los valores correspondientes a las tres configuraciones típicas de firma de la plataforma de Android: release-keys, dev-keys y test-keys.
TIME	Es un valor que representa la marca de tiempo de cuándo se produjo la compilación.
TIPO	Es un valor que elige el implementador del dispositivo y 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 del tiempo de ejecución de Android: user, userdebug o eng.
USUARIO	Es el 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 ni la cadena vacía ("").
SECURITY&lowbar;PATCH	Es un valor que indica el nivel de parche de seguridad de una compilación. DEBE indicar que la compilación no es vulnerable de ninguna manera a ninguno de los problemas descritos hasta el Boletín público de seguridad de Android designado. DEBE tener el formato [AAAA-MM-DD] y coincidir con una cadena definida que se documenta en el Boletín público de seguridad de Android o en el Aviso de seguridad de Android, por ejemplo, "2015-11-01".
BASE&lowbar;OS	Es un valor que representa el parámetro FINGERPRINT de la compilación, que, de lo contrario, es idéntica 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 no existe tal compilación, informar una cadena vacía ("").
BOOTLOADER	Es un valor elegido por el implementador del dispositivo que identifica la versión específica del bootloader interno que se usa en el dispositivo, en un formato legible para las personas. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	DEBE (ser o devolver) un valor elegido por el implementador del dispositivo que identifique la versión específica de radio o módem interna que se usa en el dispositivo, en formato legible. Si un dispositivo no tiene radio o módem internos, 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._-,]+$`.
getSerial()	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]+$`.
STRONGBOX&lowbar;MANUFACTURER	Nombre comercial del fabricante del chip StrongBox que se usa en el producto. El proveedor de StrongBox proporciona la constante correcta. Los dispositivos con el mismo proveedor de StrongBox deben usar el mismo valor constante. El valor de este campo DEBE coincidir con la expresión regular `^([0-9A-Za-z ]+)` y NO DEBE ser igual a "unsupported". Este campo NO DEBE cambiar durante la vida útil del producto.
STRONGBOX&lowbar;MODEL	Nombre del modelo del chip StrongBox que se usa en el producto. El proveedor de StrongBox proporciona la constante correcta. Los dispositivos con el mismo proveedor de StrongBox DEBEN usar el mismo valor constante. El valor de este campo DEBE coincidir con la expresión regular `^([0-9A-Za-z ._/+-]+)$` y NO DEBE ser igual a "unsupported". Este campo NO DEBE cambiar durante la vida útil del producto.

3.2.3. Compatibilidad de intents

3.2.3.1. Intents de aplicaciones comunes

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

Implementaciones de dispositivos:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se indican aquí y proporcionar cumplimiento, es decir, satisfacer las expectativas del desarrollador para estos intents de aplicaciones comunes, como se describe en el SDK.

Consulta la Sección 2 para conocer los intents obligatorios de la aplicación para cada tipo de dispositivo.

3.2.3.2. Resolución de intents

[C-0-1] Como Android es una plataforma extensible, las implementaciones de dispositivos DEBEN permitir que las aplicaciones de terceros anulen cada patrón de intents al que se hace referencia en la sección 3.2.3.1, excepto Configuración. La implementación de código abierto de Android upstream permite esto de forma predeterminada.
[C-0-2] Los implementadores de dispositivos NO DEBEN adjuntar privilegios especiales al uso de estos patrones de intents por parte de las aplicaciones del sistema, ni impedir que las aplicaciones de terceros se vinculen a estos patrones y asuman su control. Esta prohibición incluye específicamente, sin limitaciones, la inhabilitación de la interfaz de usuario del "Selector", que permite al usuario elegir entre varias aplicaciones que controlan el mismo patrón de intent.
[C-0-3] Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario para que los usuarios modifiquen la actividad predeterminada de los intents.
Sin embargo, las implementaciones de dispositivos PUEDEN proporcionar actividades predeterminadas para patrones de URI específicos (p.ej., 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 intents que especifica el URI de datos "http://www.android.com" es más específico que el patrón de intents principal del navegador para "http://".

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

[C-0-4] DEBE intentar validar los filtros de intents realizando los pasos de validación definidos en la especificación de Vínculos de recursos digitales tal como la implementa el administrador de paquetes en el Proyecto de código abierto de Android upstream.
[C-0-5] DEBE intentar validar los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de URI validados correctamente como controladores de apps predeterminados para sus URIs.
PUEDE establecer filtros de intents de URI específicos como controladores de apps predeterminados para sus URI, si se verifican correctamente, pero fallan otros filtros de URI candidatos. Si la implementación de un dispositivo hace esto, DEBE proporcionar al usuario anulaciones de patrones por URI adecuadas en el menú de configuración.
DEBE proporcionar al usuario controles de vínculos de la app por app en la Configuración de la siguiente manera:
- [C-0-6] El usuario DEBE poder anular de forma integral el comportamiento predeterminado de los vínculos de la app para que una app se comporte de la siguiente manera: siempre abrir, siempre preguntar o nunca abrir, lo que se debe aplicar a todos los filtros de intents de URI candidatos por igual.
- [C-0-7] El usuario DEBE poder ver una lista de los filtros de intents de URI candidatos.
- La implementación del dispositivo PUEDE proporcionar al usuario la capacidad de anular filtros de intents de URI candidatos específicos que se verificaron correctamente, según cada filtro de intents.
- [C-0-8] La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intents de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros de intents de URI candidatos superen la verificación, mientras que otros pueden fallar.

3.2.3.3. Espacios de nombres de intents

[C-0-1] Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que cumpla con los nuevos patrones de intents o intents de transmisión con una ACTION, CATEGORY o cualquier otra cadena 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 patrones nuevos de intents o intents de transmisión con una cadena de ACTION, CATEGORY o cualquier otra clave en un espacio de paquetes que pertenezca a otra organización.
[C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni extender ninguno de los patrones de intents que se enumeran en la sección 3.2.3.1.
Las implementaciones de dispositivos PUEDEN incluir patrones de intents que usen espacios de nombres asociados de forma clara y evidente con su propia organización. Esta prohibición es análoga a la que se especifica para las clases de lenguaje Java en la sección 3.6.

3.2.3.4. Intents de transmisión

Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intents y notificarles los cambios en el entorno de hardware o software.

Implementaciones de dispositivos:

[C-0-1] DEBE transmitir las intents de transmisión pública que se indican aquí en respuesta a los eventos del sistema adecuados, como se describe en la documentación del SDK. Ten en cuenta que este requisito no entra en conflicto con el artículo 3.5, ya que las limitaciones para las aplicaciones en segundo plano también se describen en la documentación del SDK. Además, ciertas intents de transmisión dependen de la compatibilidad con el hardware. Si el dispositivo admite el hardware necesario, DEBE transmitir las intents y proporcionar el comportamiento en línea con la documentación del SDK.

3.2.3.5. Intents de la aplicación condicionales

Android incluye parámetros de configuración que brindan a los usuarios una forma sencilla de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla principal o los SMS.

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

Si las implementaciones de dispositivos informan android.software.home_screen, cumplen con los siguientes requisitos:

[C-1-1] DEBE satisfacer la intención de android.settings.HOME_SETTINGS para mostrar un menú de configuración predeterminado de la app para la pantalla principal.

Si las implementaciones de dispositivos informan android.hardware.telephony.calling, cumplen con los siguientes requisitos:

[C-2-1] DEBE proporcionar un menú de configuración que llame al intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar un diálogo que permita cambiar la aplicación de SMS predeterminada.
[C-2-2] DEBE satisfacer la intención de android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar un diálogo que permita al usuario cambiar la aplicación de Teléfono predeterminada.
- DEBE usar la IU de la app de Teléfono predeterminada seleccionada por el usuario para las llamadas entrantes y salientes, excepto para las llamadas de emergencia, que usarían la app de Teléfono preinstalada.
[C-2-3] DEBE satisfacer la intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para proporcionar al usuario la posibilidad de configurar el objeto ConnectionServices asociado con el objeto PhoneAccounts, así como un objeto PhoneAccount predeterminado que el proveedor de servicios de telecomunicaciones usará para realizar llamadas salientes. La implementación del AOSP cumple con este requisito, ya que incluye un menú "Opción de cuentas de llamadas" en el menú de configuración "Llamadas".
[C-2-4] DEBE permitir android.telecom.CallRedirectionService para una app que tenga el rol android.app.role.CALL_REDIRECTION.
[C-2-5] DEBE proporcionar la opción para que el usuario elija una app que tenga el rol de android.app.role.CALL_REDIRECTION.
[C-2-6] DEBE respetar los intents android.intent.action.SENDTO y android.intent.action.VIEW, y proporcionar una actividad para enviar o mostrar mensajes SMS.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que se cumplan los intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW y android.intent.action.DIAL con una aplicación de marcador precargada que pueda controlar estos intents y proporcionar el cumplimiento como se describe en el SDK.

Si las implementaciones de dispositivos informan android.hardware.nfc.hce, cumplen con los siguientes requisitos:

[C-3-1] DEBE satisfacer la intención android.settings.NFC_PAYMENT_SETTINGS para mostrar un menú de configuración predeterminado de la app para el pago sin contacto.
[C-3-2] DEBE satisfacer el intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT para mostrar una actividad que abra un diálogo y le solicite al usuario que cambie el servicio de emulación de tarjeta predeterminado para una categoría determinada, como se describe en el SDK.

Si las implementaciones de dispositivos informan android.hardware.nfc, cumplen con los siguientes requisitos:

[C-4-1] DEBE cumplir con estos intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED y android.nfc.action.TECH_DISCOVERED para mostrar una actividad que cumpla con las expectativas de los desarrolladores para estos intents, como se describe en el SDK.

Si las implementaciones de dispositivos informan android.hardware.bluetooth, cumplen con los siguientes requisitos:

[C-5-1] DEBE respetar el intent "android.bluetooth.adapter.action.REQUEST_ENABLE" y mostrar una actividad del sistema para permitir que el usuario active Bluetooth.
[C-5-2] DEBE respetar el intent 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' y mostrar una actividad del sistema que solicite el modo visible.

Si las implementaciones de dispositivos admiten la función No molestar, deben cumplir con los siguientes requisitos:

[C-6-1] DEBE implementar una actividad que responda al intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, que, para las implementaciones con UI_MODE_TYPE_NORMAL, DEBE ser una actividad en la que el usuario pueda otorgar o rechazar el acceso de la app a la configuración de la política de DND.

Si las implementaciones de dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con los siguientes requisitos:

[C-7-1] DEBE proporcionar un mecanismo accesible para el usuario para agregar y configurar métodos de entrada de terceros en respuesta al intent android.settings.INPUT_METHOD_SETTINGS.

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con lo siguiente:

[C-8-1] DEBE respetar la intención de android.settings.ACCESSIBILITY_SETTINGS de proporcionar un mecanismo accesible para el usuario que permita habilitar e inhabilitar los servicios de accesibilidad de terceros junto con los servicios de accesibilidad precargados.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Easy Connect y exponen la funcionalidad a apps de terceros, deben cumplir con lo siguiente:

[C-9-1] DEBE implementar las APIs de Intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI como se describe en la documentación del SDK.

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos, deben cumplir con los siguientes requisitos:

[C-10-1] DEBE proporcionar una interfaz de usuario en la configuración que controle el intent de Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, lo que permite a los usuarios agregar aplicaciones a la lista de entidades permitidas o quitarlas de ella.

Si las implementaciones de dispositivos no proporcionan el modo Ahorro de datos, deben hacer lo siguiente:

[C-11-1] DEBE tener una actividad que controle el intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, pero PUEDE implementarlo como una operación sin efecto.

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

[C-12-3] DEBE controlar y SOLO DEBE permitir que las aplicaciones para Android preinstaladas controlen los siguientes intents: MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE y MediaStore.ACTION_VIDEO_CAPTURE, como se describe en el documento del SDK.

Si las implementaciones de dispositivos informan android.software.device_admin, cumplen con los siguientes requisitos:

[C-13-1] DEBE respetar el intent android.app.action.ADD_DEVICE_ADMIN para invocar una IU que guíe al usuario a través de la adición del administrador de dispositivos al sistema (o le permita rechazarlo).
[C-13-2] DEBE cumplir con las intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD y android.app.action.START_ENCRYPTION, y tener una actividad para proporcionar el cumplimiento de estas intents como se describe en el SDK aquí.

Si las implementaciones de dispositivos declaran la marca de función android.software.autofill, deben hacer lo siguiente:

[C-14-1] DEBE implementar por completo las APIs de AutofillService y AutofillManager, y cumplir con el intent android.settings.REQUEST_SET_AUTOFILL_SERVICE para mostrar un menú de configuración predeterminado de la app que permita habilitar y deshabilitar el autocompletado, y cambiar el servicio de autocompletado predeterminado para el usuario.

Si las implementaciones de dispositivos incluyen una app preinstalada o desean permitir que las apps de terceros accedan a las estadísticas de uso, deben hacer lo siguiente:

[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE proporcionar un mecanismo accesible para el usuario que permita otorgar o revocar el acceso a los datos de uso en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS para las apps que declaran el permiso android.permission.PACKAGE_USAGE_STATS.

Si las implementaciones de dispositivos tienen la intención de no permitir que ninguna app, incluidas las apps preinstaladas, acceda a las estadísticas de uso, deben hacer lo siguiente:

[C-15-1] DEBE tener una actividad que controle el patrón de intents android.settings.ACTION_USAGE_ACCESS_SETTINGS, pero DEBE implementarlo como una operación no operativa, es decir, tener un comportamiento equivalente al que se produce cuando se rechaza el acceso del usuario.

Si las implementaciones de dispositivos muestran vínculos a las actividades especificadas por AutofillService_passwordsActivity en Configuración o vínculos a contraseñas de usuarios a través de un mecanismo similar, deben cumplir con lo siguiente:

[C-16-1] DEBE mostrar esos vínculos para todos los servicios de autocompletado instalados.

Si las implementaciones de dispositivos admiten VoiceInteractionService y tienen más de una aplicación que usa esta API instalada a la vez, deben hacer lo siguiente:

[C-18-1] DEBE respetar la intención de android.settings.ACTION_VOICE_INPUT_SETTINGS para mostrar un menú de configuración predeterminado de la app para la entrada de voz y la asistencia.

Si las implementaciones de dispositivos informan la función android.hardware.audio.output, deben cumplir con lo siguiente:

[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE que se cumplan los intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA y android.speech.tts.engine.GET_SAMPLE_TEXT, y que se tenga una actividad para proporcionar el cumplimiento de estos intents como se describe en el SDK aquí.

Android incluye compatibilidad con protectores de pantalla interactivos, antes conocidos como Dreams. Los protectores de pantalla permiten a los usuarios interactuar con las aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o acoplado en una base de escritorio. Implementaciones de dispositivos:

DEBE incluir compatibilidad con 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 android.settings.DREAM_SETTINGS.

Si las implementaciones de dispositivos informan android.hardware.nfc.uicc o android.hardware.nfc.ese, cumplen con los siguientes requisitos:

[C-19-1] DEBE implementar la API de Intent NfcAdapter.ACTION_TRANSACTION_DETECTED (como "EVT_TRANSACTION" definido por la especificación técnica TS.26 de GSM Association - Requisitos de teléfonos celulares NFC).

3.2.4. Actividades en pantallas secundarias o múltiples

Si las implementaciones de dispositivos permiten iniciar actividades de Android normales en más de una pantalla, deben cumplir con lo siguiente:

[C-1-1] DEBE establecer la marca de función android.software.activities_on_secondary_displays.
[C-1-2] DEBE garantizar la compatibilidad de la API de forma similar a una actividad que se ejecuta en la pantalla principal.
[C-1-3] DEBE iniciar la actividad nueva en la misma pantalla que la actividad que la inició cuando la actividad nueva se inicia sin especificar una pantalla de destino a través de la API de ActivityOptions.setLaunchDisplayId().
[C-1-4] DEBE destruir todas las actividades cuando se quita una pantalla con la marca 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 app habilite la opción para mostrarse sobre la pantalla de bloqueo con la API de Activity#setShowWhenLocked().
DEBE tener android.content.res.Configuration, que corresponde a esa pantalla para que se muestre, funcione correctamente y mantenga la compatibilidad si se inicia una actividad en la pantalla secundaria.

Si las implementaciones del dispositivo permiten iniciar actividades de Android normales en pantallas secundarias y una pantalla secundaria tiene la marca android.view.Display.FLAG_PRIVATE, se aplican las siguientes condiciones:

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

3.3. Compatibilidad con la API nativa

La compatibilidad con el código nativo es un desafío. Por este motivo, los implementadores de dispositivos deben hacer lo siguiente:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE usar las implementaciones de las bibliotecas que se indican a continuación del proyecto de código abierto de Android upstream.

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 .so ELF compilado para la arquitectura de hardware del dispositivo apropiada. Dado que el código nativo depende en gran medida de la tecnología del procesador subyacente, Android define varias interfaces binarias de aplicaciones (ABIs) en el NDK de Android.

Implementaciones de dispositivos:

[C-0-1] DEBE ser compatible con una o más ABIs del NDK de Android definidas.
[C-0-2] DEBE incluir compatibilidad con 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 compatible con el formato binario (para la ABI) con cada biblioteca requerida en la siguiente lista.
[C-0-5] DEBE informar con precisión la interfaz binaria de la aplicación (ABI) nativa que admite el dispositivo a través de los parámetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS y android.os.Build.SUPPORTED_64_BIT_ABIS, cada uno de los cuales es una lista de ABI separadas por comas y ordenadas de la más a la menos preferida.
[C-0-6] DEBE informar, a través de los parámetros anteriores, un subconjunto de la siguiente lista de ABIs y NO DEBE informar ningún ABI que no esté en la lista.
- armeabi (ya no es compatible como destino en el NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[C-0-7] DEBE poner a disposición de las apps que incluyen código nativo todas las siguientes bibliotecas, que proporcionan APIs nativas:
- libaaudio.so (compatibilidad con audio nativo de AAudio)
- libamidi.so (compatibilidad nativa con MIDI, si se declara la función android.software.midi como se describe en la sección 5.9)
- libandroid.so (compatibilidad con actividades nativas de Android)
- libc (biblioteca C)
- libcamera2ndk.so
- libdl (vinculador dinámico)
- libEGL.so (administración de superficies OpenGL nativas)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (registro de Android)
- libmediandk.so (compatibilidad con APIs de medios nativas)
- libm (biblioteca matemática)
- libneuralnetworks.so (API de Neural Networks)
- libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
- libOpenSLES.so (compatibilidad de audio con OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (compatibilidad mínima con C++)
- libvulkan.so (Vulkan)
- libz (compresión Zlib)
- Interfaz de JNI
[C-0-8] NO DEBE agregar ni quitar las funciones públicas de las bibliotecas nativas mencionadas anteriormente.
[C-0-9] DEBE enumerar las bibliotecas adicionales que no son de AOSP y que se exponen directamente a las apps 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 las apps de terceros que se segmentan para el nivel de API 24 o superior, ya que están reservadas.
[C-0-11] DEBE exportar todos los símbolos de funciones de OpenGL ES 3.1 y del Android Extension Pack, según se definen en el NDK, a través de la biblioteca libGLESv3.so. Ten en cuenta que todos los símbolos DEBEN estar presentes, pero 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] MUST export function symbols for the core Vulkan 1.1 function symbols, as well as the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, and VK_KHR_get_physical_device_properties2 extensions through the libvulkan.so library. Ten 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 los casos en los que se espera la implementación completa de cada una de las funciones correspondientes.
DEBE compilarse con el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android upstream.

Ten en cuenta que las versiones futuras de Android pueden introducir compatibilidad con ABIs adicionales.

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

Si las implementaciones de dispositivos informan la compatibilidad con la ABI armeabi, deben cumplir con lo siguiente:

[C-3-1] TAMBIÉN DEBE admitir armeabi-v7a y registrar su compatibilidad, ya que armeabi solo se usa para la retrocompatibilidad con apps más antiguas.

Si las implementaciones de dispositivos informan la compatibilidad con la ABI armeabi-v7a, para las apps que usan esta ABI, se cumplen las siguientes condiciones:

[C-2-1] DEBE incluir las siguientes líneas en /proc/cpuinfo y NO DEBE alterar los valores en el mismo dispositivo, incluso cuando los lean otras ABI.
- Features:, seguido de una lista de las funciones opcionales de CPU ARMv7 que admite el dispositivo.
- CPU architecture:, seguido de un número entero que describe la arquitectura ARM más alta compatible con el dispositivo (p.ej., "8" para dispositivos ARMv8).
[C-2-2] SIEMPRE debe mantener disponibles las siguientes operaciones, incluso en el caso de que la ABI se implemente en una arquitectura ARMv8, ya sea a través de la compatibilidad nativa de la CPU o a través de la emulación de software:
- Instrucciones SWP y SWPB
- Operaciones de barrera CP15ISB, CP15DSB y CP15DMB
[C-2-3] DEBE incluir compatibilidad con 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 de android.webkit.Webview, cumplen con los siguientes requisitos:

[C-1-1] SE DEBE informar android.software.webview.
[C-1-2] DEBE usar la compilación del proyecto Chromium del proyecto de código abierto de Android upstream en la rama Android 17 para la implementación de la API de android.webkit.WebView.
[C-1-3] La cadena de agente de usuario que informa WebView para las apps que segmentan el nivel de SDK 35 y versiones anteriores DEBE tener el siguiente formato:

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/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 lo está, DEBE tener el mismo valor que android.os.Build.MODEL.
- Se PUEDE omitir "Build/$(BUILD)", pero, si está presente, la cadena $(BUILD) DEBE ser la misma 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 upstream.
- Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del usuario-agente.
El componente WebView DEBE incluir compatibilidad con la mayor cantidad posible de funciones de HTML5 y, si admite la función, DEBE cumplir con la especificación de HTML5.
[C-1-4] DEBE renderizar el contenido proporcionado o el contenido de la URL remota en un proceso distinto de la aplicación que crea una instancia de la WebView. Específicamente, el proceso de renderizador independiente DEBE tener privilegios más bajos, ejecutarse como un ID de usuario independiente, no tener acceso al directorio de datos de la app, no tener acceso directo a la red y solo tener acceso a los servicios del sistema mínimos requeridos a través de Binder. La implementación de WebView en AOSP cumple con este requisito.

[C-1-5] La cadena del agente de usuario predeterminada del sistema que informa WebView para las apps que segmentan el nivel del SDK 36 y versiones posteriores DEBE tener el siguiente formato:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- $(VERSION) DEBE ser el valor estático 10.
- $(MODEL) DEBE ser la letra estática K.
- $(CHROMIUM_MAJOR_VER) DEBE ser la versión principal de Chromium en el proyecto de código abierto de Android upstream.
- Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del usuario-agente.

Ten en cuenta que, si las implementaciones de dispositivos son de 32 bits o declaran la marca 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, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir cada una de estas APIs asociadas con HTML5:
[C-1-2] DEBE admitir la API de webstorage de HTML5/W3C y DEBERÍA admitir la API de IndexedDB de HTML5/W3C. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer a IndexedDB por sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.
PUEDE enviar una cadena de usuario-agente personalizada en la aplicación del navegador independiente.
DEBE implementar la compatibilidad con la mayor cantidad posible de HTML5 en la aplicación del navegador independiente (ya sea que se base en la aplicación del navegador WebKit upstream o en un reemplazo de terceros).

Sin embargo, si las implementaciones de dispositivos no incluyen una aplicación de navegador independiente, deben cumplir con lo siguiente:

[C-2-1] DEBE seguir admitiendo los patrones de intención públicos, como se describe en la sección 3.2.3.1.

3.5. Compatibilidad de comportamiento de la API

Implementaciones de dispositivos:

[C-0-9] DEBE garantizar que se aplique la compatibilidad de comportamiento de la API para todas las apps 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 de entidades permitidas que garantice la compatibilidad del comportamiento de la API solo para las apps que seleccionen los implementadores de dispositivos.

El comportamiento de cada uno de los tipos de API (administrada, flexible, nativa y web) debe ser coherente con la implementación preferida del Proyecto de código abierto de Android upstream. Estas son algunas áreas específicas de compatibilidad:

[C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de una intención estándar.
[C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etcétera).
[C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
Los dispositivos NO DEBEN alterar las limitaciones que se aplican a las aplicaciones en segundo plano. Más específicamente, para las apps en segundo plano:
- [C-0-4] DEBEN dejar de ejecutar las devoluciones de llamada que registra la app para recibir resultados de GnssMeasurement y GnssNavigationMessage.
- [C-0-5] DEBEN limitar la frecuencia de las actualizaciones que se proporcionan a la app a través de la clase de la API LocationManager o el método WifiManager.startScan().
- [C-0-6] Si la app se orienta al nivel de API 25 o superior, NO DEBE permitir el registro de receptores de emisión para las emisiones implícitas de intents estándar de Android en el manifiesto de la app, a menos que el intent de emisión requiera un permiso de "signature" o "signatureOrSystem" protectionLevel o esté en la lista de exenciones.
- [C-0-7] Si la app se segmenta para el nivel de API 25 o superior, DEBE detener los servicios en segundo plano de la app, como si la app hubiera llamado al método stopSelf() de los servicios, a menos que la app se coloque en una lista de entidades permitidas temporal para controlar una tarea visible para el usuario.
- [C-0-8] Si la app se orienta al nivel de API 25 o superior, DEBE liberar los bloqueos de activación que mantiene.
[C-0-11] Los dispositivos DEBEN devolver los siguientes proveedores de seguridad como los primeros siete valores del array del método Security.getProviders(), en el orden indicado y con los nombres proporcionados (como los devuelve Provider.getName()) y las clases, a menos que la app haya modificado la lista a través de 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. BC: com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. Restricción de aplicación

Si las implementaciones de dispositivos implementan un mecanismo propietario para restringir apps (p.ej., cambiar o restringir los comportamientos de la API que se describen en el SDK) y ese mecanismo es más restrictivo que el segmento de App Standby restringido, deben hacer lo siguiente:

[C-1-1] DEBE permitir que el usuario vea la lista de apps restringidas.
[C-1-2] DEBE proporcionar al usuario la posibilidad de activar o desactivar todas estas restricciones propietarias en cada app.
[C-1-3] NO DEBE aplicar automáticamente estas restricciones propietarias sin evidencia de un comportamiento deficiente del sistema, pero PUEDE aplicar las restricciones en las apps cuando se detecte un comportamiento deficiente del sistema, como bloqueos de activación atascados, servicios de ejecución prolongada y otros criterios. Los implementadores de dispositivos PUEDEN determinar los criterios, pero estos DEBEN estar relacionados con el impacto de la app en el estado del sistema. NO se deben usar como criterios otros que no estén relacionados exclusivamente con el estado del sistema, como la falta de popularidad de la app en el mercado.
[C-1-4] NO DEBE aplicar automáticamente estas restricciones propietarias para las apps cuando un usuario haya desactivado las restricciones de la app de forma manual, y PUEDE sugerirle al usuario que aplique estas restricciones propietarias.
[C-1-5] DEBE informar a los usuarios si estas restricciones de propiedad se aplican a una app automáticamente. Esta información SE DEBE proporcionar en el período de las 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 a la API desde una app.
[C-1-7] NO DEBE restringir la app en primer plano superior que el usuario utiliza de forma explícita.
[C-1-8] DEBE suspender estas restricciones de propiedad en una app siempre que un usuario comience a usarla de forma explícita, lo que la convierte en la aplicación en primer plano superior.
[C-1-10] DEBE proporcionar un documento o sitio web público y claro que describa cómo se aplican las restricciones de propiedad. Se DEBE poder acceder a este documento o sitio web desde los documentos del SDK de Android y DEBE incluir lo siguiente:
- Condiciones de activación de las restricciones de propiedad.
- Qué y cómo se puede restringir una app
- Cómo se puede eximir una app de esas restricciones
- Cómo una app puede solicitar una exención de las restricciones de propiedad, si admite dicha exención para las apps que el usuario puede instalar

Si una app está preinstalada en el dispositivo y un usuario nunca la usó explícitamente durante más de 30 días, se aplican las excepciones [C-1-3] y [C-1-5].

Si las implementaciones de dispositivos extienden las restricciones de apps implementadas en AOSP, deben cumplir con lo siguiente:

[C-2-1]DEBE seguir la implementación que se describe en este documento.

3.5.2. Hibernación de aplicaciones

Si las implementaciones de dispositivos incluyen la hibernación de apps que se incluye en el AOSP o extiende la función que se incluye en el 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 se DEBE aplicar la restricción en la app para un usuario cuando haya evidencia de que el usuario no usó la app durante un período. Se RECOMIENDA ENCARECIDAMENTE que esta duración sea de un mes o más. El uso DEBE definirse por la interacción del usuario explícita a través de la API de UsageStats#getLastTimeVisible() o cualquier otra acción que haga que una app salga del estado de detención forzada, incluidas las vinculaciones de servicios, las vinculaciones de proveedores de contenido, las transmisiones explícitas, etcétera, que se rastrearán con una nueva API UsageStats#getLastTimeAnyComponentUsed().
[C-1-3] SOLO se DEBEN aplicar restricciones que afecten a todos los usuarios del dispositivo cuando haya evidencia de que NINGÚN usuario usó el paquete durante un período. Se RECOMIENDA ENCARECIDAMENTE que esta duración sea de un mes o más.
[C-1-4] NO DEBE hacer que la app no pueda responder a intents de actividad, vinculaciones de servicio, solicitudes de proveedores de contenido ni emisiones explícitas.

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

3.6. Espacios de nombres de la API

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

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

Es decir, cumplen con los siguientes requisitos:

[C-0-1] NO DEBE modificar las APIs expuestas públicamente en la plataforma de Android cambiando las firmas de métodos o clases, ni quitando clases o campos de clases.
[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) ni APIs de prueba o del sistema a las APIs 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 upstream.

Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero dichas modificaciones deben cumplir con los siguientes requisitos:

[C-0-3] NO DEBE afectar el comportamiento declarado ni la firma en lenguaje Java de ninguna API expuesta públicamente.
[C-0-4] NO SE DEBE publicitar ni exponer de ninguna otra manera a los desarrolladores.

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

[C-0-5] NO DEBE estar en un espacio de nombres que pertenezca a otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* o a uno similar: solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a los espacios de nombres de otras empresas.
[C-0-6] DEBE empaquetarse en una biblioteca compartida de Android para que solo las apps que las usen de forma explícita (a través del mecanismo <uses-library>) se vean afectadas por el mayor uso de memoria de esas APIs.

Los implementadores de dispositivos PUEDEN agregar APIs personalizadas en lenguajes nativos, fuera de las APIs del NDK, pero las APIs personalizadas deben cumplir con los siguientes requisitos:

[C-1-1] NO DEBE estar en una biblioteca del NDK ni en una biblioteca que pertenezca a otra organización, como se describe aquí.

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

Ten en cuenta que las restricciones anteriores corresponden a las convenciones estándar para nombrar APIs en el lenguaje de programación Java. Esta sección solo tiene como objetivo reforzar esas convenciones y hacerlas vinculantes a través de su inclusión en esta Definición de Compatibilidad.

3.7. Compatibilidad con el entorno de ejecución

Implementaciones de dispositivos:

[C-0-1] DEBE admitir el formato completo Dalvik Executable (DEX) y la especificación y semántica del código de bytes de Dalvik.
[C-0-2] DEBE configurar los entornos de ejecución de Dalvik para asignar memoria de acuerdo con la plataforma de Android upstream y según se especifica en la siguiente tabla. (Consulta la sección 7.1.1 para obtener las definiciones de tamaño y densidad de pantalla).
DEBE usar Android Runtime (ART), la implementación upstream de referencia del formato ejecutable de Dalvik y el sistema de administración de paquetes de la implementación de referencia.
DEBE ejecutar pruebas de fuzzing en varios modos de ejecución y arquitecturas de destino para garantizar la estabilidad del tiempo de ejecución. Consulta JFuzz y DexFuzz en el sitio web del Proyecto de código abierto de Android.

Ten 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 la aplicación
Reloj Android	120 dpi (ldpi)	32 MB
	140 DPI (140DPI)
	160 dpi (mdpi)
	180 DPI (180dpi)
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220dpi)	36 MB
	240 dpi (hdpi)
	280 DPI (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi	48 MB
	400 DPI (400 dpi)	56 MB
	420 DPI (420DPI)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi	112 MB
	640 dpi (xxxhdpi)	154 MB
Pequeño/normal	120 dpi (ldpi)	32 MB
	140 DPI (140DPI)
	160 dpi (mdpi)
	180 DPI (180dpi)	48 MB
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220dpi)
	240 dpi (hdpi)
	280 DPI (280dpi)
	320 dpi (xhdpi)	80 MB
	360 dpi	80 MB
	400 DPI (400 dpi)	96 MB
	420 DPI (420DPI)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi	192 MB
	640 dpi (xxxhdpi)	256 MB
grande	120 dpi (ldpi)	32 MB
	140 DPI (140DPI)	48 MB
	160 dpi (mdpi)	48 MB
	180 DPI (180dpi)	80 MB
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220dpi)
	240 dpi (hdpi)
	280 DPI (280dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi	160 MB
	400 DPI (400 dpi)	192 MB
	420 DPI (420DPI)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi	384 MB
	640 dpi (xxxhdpi)	512 MB
Extragrande	120 dpi (ldpi)	48 MB
	140 DPI (140DPI)	80 MB
	160 dpi (mdpi)	80 MB
	180 DPI (180dpi)	96 MB
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220dpi)
	240 dpi (hdpi)
	280 DPI (280dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi	240 MB
	400 DPI (400 dpi)	288 MB
	420 DPI (420DPI)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Selector (pantalla principal)

Android incluye una aplicación de Launcher (pantalla principal) y admite aplicaciones de terceros para reemplazar el Launcher del dispositivo (pantalla principal).

Si las implementaciones del dispositivo permiten que las aplicaciones de terceros reemplacen la pantalla principal del dispositivo, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos incluyen un selector predeterminado que admite la fijación de accesos directos en la app, deben cumplir con lo siguiente:

[C-2-1] SE DEBE informar true para ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] DEBE tener una opción para el usuario que le pregunte antes de agregar un acceso directo solicitado por las apps a través del método de la API de ShortcutManager.requestPinShortcut().
[C-2-3] DEBE admitir accesos directos fijados, dinámicos y estáticos, como se documenta en la página de accesos directos a aplicaciones.

Por el contrario, si las implementaciones de dispositivos no admiten la fijación de accesos directos en la app, deben hacer lo siguiente:

[C-3-1] Se DEBE informar false para ShortcutManager.isRequestPinShortcutSupported().

Si las implementaciones de dispositivos implementan un selector predeterminado que proporciona acceso rápido a los accesos directos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos incluyen una app de selector predeterminada que muestra insignias para los íconos de apps, deben cumplir con los siguientes requisitos:

[C-5-1] DEBE respetar el método de la API NotificationChannel.setShowBadge(). En otras palabras, muestra una indicación visual asociada con el ícono de la app si el valor se establece como true y no muestra ningún esquema de distintivos de íconos de la app cuando todos los canales de notificaciones de la app establecieron el valor como false.
PUEDE anular los distintivos de íconos de la app con su esquema de distintivos propietario cuando las aplicaciones de terceros indiquen que admiten el esquema de distintivos propietario a través del uso de APIs propietarias, pero DEBE usar los recursos y los valores proporcionados a través de las APIs de distintivos de notificaciones que se describen en el SDK, como las APIs de Notification.Builder.setNumber() y Notification.Builder.setBadgeIconType().

Si las implementaciones de dispositivos admiten íconos monocromáticos, estos íconos deben cumplir con los siguientes requisitos:

[C-6-1] SOLO se deben usar cuando el usuario las habilita de forma explícita (p.ej., a través de la configuración o el menú del selector de fondos de pantalla).

3.8.2. Widgets

Android admite widgets de apps de terceros definiendo un tipo de componente y una API y un ciclo de vida correspondientes que permiten que las aplicaciones expongan un "AppWidget" al usuario final.

Si las implementaciones de dispositivos admiten widgets de apps de terceros, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar la compatibilidad con la función de la plataforma android.software.app_widgets.
[C-1-2] DEBE incluir compatibilidad integrada con AppWidgets y exponer recursos de interfaz de usuario para agregar, configurar, obtener una vista previa, quitar, ver y cambiar el tamaño de los AppWidgets,a menos que la seguridad del usuario (como la distracción del conductor) sea un problema.

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

[C-1-4] DEBE admitir vistas previas de widgets generadas de forma dinámica.
[C-1-5] DEBE tener una indicación visual para el usuario con la vista previa que le pregunte antes de agregar un widget solicitado por las apps a través de AppWidgetManager.requestPinAppWidget().
[C-1-6] DEBE admitir la fijación de widgets en la app.
[C-1-7] DEBE informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().

PUEDE admitir widgets de aplicaciones en la pantalla de bloqueo.

Si las implementaciones de dispositivos admiten widgets de apps de terceros y la fijación de accesos directos en la app, deben cumplir con lo siguiente:

[C-2-1] SE DEBE informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] DEBE tener una indicación visual para el usuario que le pregunte antes de agregar un acceso directo solicitado por las apps a través del método de la API de AppWidgetManager.requestPinAppWidget().

3.8.3. Notificaciones

Android incluye las APIs de Notification y NotificationManager que permiten a los desarrolladores de apps de terceros notificar a los usuarios sobre eventos importantes y atraer su atención con los componentes de hardware (p.ej., sonido, vibración y luz) y las funciones de software (p.ej., panel de notificaciones, barra del sistema) del dispositivo.

3.8.3.1. Presentación de notificaciones

Si las implementaciones del dispositivo permiten que las apps de terceros notifiquen a los usuarios sobre eventos importantes, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir notificaciones que usen funciones de hardware, como se describe en la documentación del SDK y en la medida de lo posible con el hardware de implementación del dispositivo. Por ejemplo, si una implementación de dispositivo incluye un vibrador, DEBE implementar correctamente las APIs de vibración. Si una implementación de dispositivo carece de hardware, las APIs correspondientes DEBEN implementarse como no-ops. Este comportamiento se detalla más en la sección 7.
[C-1-2] DEBE renderizar correctamente todos los recursos (íconos, archivos de animación, etcétera) proporcionados en las APIs o en la guía de estilo de íconos de la barra de estado o del sistema, aunque PUEDE proporcionar una experiencia del usuario alternativa para las notificaciones que no sea la que proporciona la implementación de referencia de Android Open Source.
[C-1-3] DEBE cumplir y aplicar correctamente los comportamientos descritos para las APIs para actualizar, quitar y agrupar notificaciones.
[C-1-4] DEBE proporcionar el comportamiento completo de la API de NotificationChannel que se documenta en el SDK.
[C-1-5] DEBE proporcionar una opción para que el usuario bloquee y modifique la notificación de una app de terceros específica en cada canal y nivel de paquete de la app.
[C-1-6] TAMBIÉN DEBE proporcionar una indicación visual para que el usuario muestre los canales de notificación borrados.
[C-1-7] DEBE renderizar correctamente todos los recursos (imágenes, calcomanías, íconos, etcétera) proporcionados a través de Notification.MessagingStyle junto con el texto de la 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 que se establece a través de setGroupConversation.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar una indicación visual para que el usuario controle las notificaciones que se exponen a las apps a las que se les otorgó el permiso de Notification Listener. La granularidad DEBE ser tal que el usuario pueda controlar para cada objeto de escucha de notificaciones qué tipos de notificaciones se transfieren a este objeto de escucha. Los tipos DEBEN incluir notificaciones de "conversaciones", "alertas", "silenciosas" y "constantes importantes".
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE proporcionar una indicación visual para que los usuarios especifiquen las apps que se excluirán de la notificación de cualquier objeto de escucha de notificaciones específico.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE que se muestre automáticamente una opción para que el usuario bloquee las notificaciones de una app de terceros específica en cada canal y a nivel del paquete de la app después de que el usuario descarte esa notificación varias veces.
DEBE admitir notificaciones enriquecidas.
SHOULD presentar algunas notificaciones de mayor prioridad como notificaciones de atención.
DEBE tener una opción para posponer las notificaciones.
La MAY solo puede administrar la visibilidad y el momento en que las apps de terceros pueden notificar a los usuarios sobre eventos importantes para mitigar problemas de seguridad, como la distracción del conductor.

Android 11 introduce la compatibilidad con las notificaciones de conversaciones, que son notificaciones que usan MessagingStyle y proporcionan un ID de acceso directo de Personas publicado.

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 servicios en primer plano en curso y las notificaciones de importance:high.

Si las implementaciones del dispositivo admiten conversation notifications y la app proporciona los datos necesarios para bubbles, se cumplen las siguientes condiciones:

[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE mostrar esta conversación como una burbuja. La implementación del AOSP cumple con estos requisitos con la IU del sistema, la Configuración y el Selector predeterminados.

Si las implementaciones de dispositivos admiten notificaciones enriquecidas, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE usar los recursos exactos que se proporcionan a través de la clase de API Notification.Style y sus subclases para los elementos de recursos presentados.
DEBE presentar todos y cada uno de los elementos de recursos (p.ej., ícono, título y texto de resumen) definidos en la clase de la API de Notification.Style y sus subclases.

Las notificaciones de atención son notificaciones que se presentan al usuario a medida que llegan, independientemente de la plataforma en la que se encuentre. Si las implementaciones del dispositivo admiten notificaciones de atención, deben cumplir con lo siguiente:

[C-3-1] DEBE usar la vista y los recursos de la notificación de atención, como se describe en la clase de la API de Notification.Builder cuando se presenten notificaciones de atención.
[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 detección de notificaciones

Android incluye las APIs de NotificationListenerService que permiten que las apps (una vez que el usuario las habilita de forma explícita) reciban una copia de todas las notificaciones a medida que se publican o actualizan.

Implementaciones de dispositivos:

[C-0-1] DEBE actualizar de forma correcta y oportuna las notificaciones en su totalidad a todos los servicios de escucha instalados y habilitados por el usuario, incluidos todos los metadatos adjuntos al objeto de notificación.
[C-0-2] DEBE respetar la llamada a la API de snoozeNotification(), descartar la notificación y realizar una devolución de llamada después del período de aplazamiento establecido en la llamada a la API.

Si las implementaciones de dispositivos tienen una opción para posponer notificaciones, deben cumplir con lo siguiente:

[C-1-1] DEBE reflejar el estado de la notificación pospuesta correctamente a través de las APIs estándares, como NotificationListenerService.getSnoozedNotifications().
[C-1-2] DEBE poner a disposición del usuario esta opción para posponer las notificaciones de cada app de terceros instalada, a menos que provengan de servicios persistentes o en primer plano.

3.8.3.3. DND (No interrumpir) o modo de prioridad

Si las implementaciones de dispositivos admiten la función No molestar (también llamada Modo de prioridad), deben cumplir con lo siguiente:

[C-1-1] DEBE mostrar las Reglas de No molestar automáticas creadas por las aplicaciones junto con las reglas predefinidas y creadas por el usuario cuando la implementación del dispositivo haya proporcionado un medio para que el usuario otorgue o rechace el acceso de las apps de terceros a la configuración de la política de DND.
[C-1-3] DEBE respetar los valores de suppressedVisualEffects que se pasan a través de NotificationManager.Policy y, si una app estableció alguna de las marcas SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEBE indicarle al usuario que los efectos visuales se suprimen en el menú de configuración de NPD.

3.8.3.4. Protección de notificaciones sensibles

La información sensible de las notificaciones incluye contenido como contraseñas únicas, códigos de confirmación únicos y códigos similares de autenticación o restablecimiento que pueden aparecer en las notificaciones a los usuarios.

Si las implementaciones del dispositivo permiten que las apps de terceros notifiquen a los usuarios sobre eventos importantes, deben cumplir con lo siguiente:

[C-1-1] Se DEBE ocultar la información sensible de las notificaciones para que no se pase a los objetos de escucha de notificaciones, a menos que el servicio de objeto de escucha sea uno de los siguientes:
- Apps firmadas por el sistema con un uid < 10,000
- IU del sistema
- Almeja
- App de dispositivo complementario designada (definida por CompanionDeviceManager)
- La función SYSTEM_AUTOMOTIVE_PROJECTION
- La función SYSTEM_NOTIFICATION_INTELLIGENCE
- Rol de HOME

La implementación de NotificationAssistantServices en el AOSP ejemplifica y cumple con estos requisitos. Consulta android.ext.services.notification para ver un ejemplo.

3.8.4. APIs de Assist

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

Si las implementaciones del dispositivo admiten la acción de Asistencia, deben cumplir con lo siguiente:

[C-2-1] DEBE indicar claramente al usuario final cuándo se comparte el contexto de una de las siguientes maneras:
- Cada vez que la aplicación de asistencia accede al contexto, se muestra una luz blanca alrededor de los bordes de la pantalla que cumple o supera la duración y el brillo de la implementación del Proyecto de código abierto de Android.
- En el caso de la aplicación de asistencia preinstalada, se debe proporcionar una indicación visual para el usuario que esté a menos de dos navegaciones de distancia del menú de configuración predeterminado de la app de asistencia y entrada de voz, y solo se debe compartir el contexto cuando el usuario invoca explícitamente la aplicación de asistencia a través de una palabra clave o una tecla de navegación de asistencia.

[C-2-1] DEBE compartir el contexto con la aplicación de asistencia solo cuando el usuario la invoque de forma explícita a través de la entrada de la tecla de navegación de asistencia, una palabra clave o cualquier otro punto de entrada designado.

[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, es decir, la aplicación que implementa VoiceInteractionService o una actividad que controla el intent ACTION_ASSIST.

3.8.5. Alertas y mensajes emergentes

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

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el usuario bloquee la visualización de ventanas de alerta de una app que usen TYPE_APPLICATION_OVERLAY. La implementación del AOSP cumple con este requisito, ya que tiene controles en el panel de notificaciones.
[C-1-2] DEBE cumplir con la API de Toast y mostrar los avisos de las aplicaciones a los usuarios finales de alguna manera muy visible.

3.8.6. Temas

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

Android incluye una familia de temas "Holo" y "Material" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen si desean que coincidan con el aspecto y la sensación del tema Holo según lo define el SDK de Android.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[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 recursos expuestos a las aplicaciones.
[C-1-3] DEBE establecer la familia de fuentes "sans-serif" en Roboto versión 2.x para los idiomas que admite Roboto, o bien proporcionar una indicación visual para que el usuario cambie 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 color dinámico según se especifica en la documentación del AOSP de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulta android.theme.customization.system_palette y android.theme.customization.theme_style).
[C-1-5] DEBE generar paletas tonales de colores dinámicos con los estilos de tema de color enumerados en la documentación de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulta android.theme.customization.theme_styles), es decir, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD y MONOCHROMATIC.

"Color de origen" que se usa para generar paletas tonales de color dinámico 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 varios colores de origen válidos para elegir uno.
- DEBE usar 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 desarrolladores de aplicaciones los usen si desean que coincidan con la apariencia del tema del dispositivo según lo define el implementador del dispositivo.

Las implementaciones de dispositivos PUEDEN modificar los atributos del tema predeterminado del dispositivo expuestos a las aplicaciones.

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

Si las implementaciones de dispositivos incluyen una barra de estado del sistema, deben cumplir con lo siguiente:

[C-2-1] DEBE usar el color blanco para los íconos de estado del sistema (como la intensidad de la señal y el nivel de batería) y las notificaciones emitidas por el sistema, a menos que el ícono indique un estado problemático o una app solicite una barra de estado clara con la marca WindowInsetsController#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, consulta R.style) cuando una app solicite una barra de estado clara.

3.8.7. Fondos de pantalla animados

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

Se considera que el hardware es capaz de ejecutar fondos de pantalla en vivo de forma confiable si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones en la 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 o las aplicaciones fallen, funcionen mal, consuman una cantidad excesiva de CPU o batería, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware no es capaz de ejecutar fondos animados. Por ejemplo, algunos fondos de pantalla animados pueden usar un contexto de OpenGL 2.0 o 3.x para renderizar su contenido. Los fondos animados no se ejecutarán de forma confiable en hardware que no admita varios contextos de OpenGL, ya que el uso de un contexto de OpenGL por parte del fondo animado puede entrar en conflicto con otras aplicaciones que también usan un contexto de OpenGL.

Las implementaciones de dispositivos capaces de ejecutar fondos animados de forma confiable, como se describió anteriormente, DEBEN implementar fondos animados.

Si las implementaciones de dispositivos incluyen fondos animados, deben cumplir con los siguientes requisitos:

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

3.8.8. Cambio de actividad

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

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

Si las implementaciones de dispositivos que incluyen la tecla de navegación de la función de Recientes, como se detalla en la sección 7.2.3, alteran la interfaz, deben cumplir con lo siguiente:

[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 Recientes.
DEBE mostrar un elemento de cierre ("x"), pero PUEDE retrasar esto hasta que el usuario interactúe con las pantallas.
DEBE implementar un acceso directo para cambiar fácilmente a la actividad anterior.
DEBE activar la acción de cambio rápido entre las dos apps usadas más recientemente cuando se presiona dos veces la tecla de función de Recientes.
DEBE activar el modo multiventana de pantalla dividida, si se admite, cuando se mantenga presionada la tecla de funciones de Recientes.
PUEDE mostrar los elementos recientes afiliados como un grupo que se mueve junto.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE usar la interfaz de usuario de Android ascendente (o una interfaz similar basada en miniaturas) para la pantalla de resumen.

3.8.9. Administración de entradas

Android incluye compatibilidad con Input Management y con editores de métodos de entrada de terceros.

Si las implementaciones de dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar la función de plataforma android.software.input_methods y admitir las APIs del IME según se definen en la documentación del SDK de Android.

3.8.10. Control de contenido multimedia en la pantalla de bloqueo

La API de Remote Control Client dejó de estar disponible a partir de Android 5.0 en favor de la plantilla de notificación de medios, que permite que las aplicaciones de medios se integren con los controles de reproducción que se muestran en la pantalla de bloqueo.

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

Consulta la sección 3.2.3.5 para conocer la intención de configuración de los protectores de pantalla.

3.8.12. Ubicación

Si las implementaciones de dispositivos incluyen un sensor de hardware (p.ej., GPS) que puede proporcionar las coordenadas de ubicación, deben cumplir con lo siguiente:

[C-1-2] DEBE mostrar el estado actual de la ubicación en el menú Ubicación de Configuración.
[C-1-3] NO DEBE mostrar modos de ubicación en el menú Ubicación de Configuración.

3.8.13. Unicode y fuente

Android incluye compatibilidad con los caracteres de emoji definidos en Unicode 10.0.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[C-1-1] DEBE poder renderizar estos caracteres de emoji en forma de glifo de color.
[C-1-2] DEBE incluir compatibilidad con lo siguiente:
- 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 el dispositivo.
- Cobertura completa de Unicode 7.0 para los alfabetos latino, griego y cirílico, incluidos los rangos de latín extendido A, B, C y D, y todos los glifos del bloque de símbolos de moneda de Unicode 7.0.
[C-1-3] NO DEBE quitar ni modificar NotoColorEmoji.tff en la imagen del sistema. (Se acepta agregar una nueva fuente de emojis para anular los emojis en NotoColorEmoji.tff).
DEBE admitir el tono de piel y los emojis de familias diversas, como se especifica en el Informe Técnico núm. 51 de Unicode.

Si las implementaciones de dispositivos incluyen un IME, deben cumplir con lo siguiente:

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

Android incluye compatibilidad para renderizar fuentes de Myanmar. Birmania tiene varias fuentes que no cumplen con Unicode, conocidas comúnmente como "Zawgyi", para renderizar idiomas birmanos.

Si las implementaciones de dispositivos incluyen compatibilidad con birmano, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE renderizar texto con una fuente compatible con Unicode de forma predeterminada; NO DEBE establecerse una fuente no compatible con Unicode 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 cumpla con Unicode si el dispositivo admite una fuente que no cumpla con Unicode. La fuente que no cumple con Unicode NO DEBE quitar ni sobrescribir la fuente Unicode.
[C-2-3] DEBE renderizar texto con una fuente que no cumpla con Unicode SOLO SI se especifica un código de idioma con código de escritura Qaag (p.ej., my-Qaag). No se pueden usar otros códigos de idioma o región ISO (ya sean asignados, no asignados o reservados) para hacer referencia a la fuente que no cumple con Unicode para Myanmar. Los desarrolladores de aplicaciones y los autores de páginas web pueden especificar my-Qaag como el código de idioma designado, como lo harían con cualquier otro idioma.

3.8.14. Multiventanas

Si las implementaciones de dispositivos tienen la capacidad de mostrar varias actividades al mismo tiempo, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar esos modos multiventana de acuerdo con los comportamientos y las APIs de la aplicación que se describen en la documentación de compatibilidad con el modo multiventana del SDK de Android y cumplir con los siguientes requisitos:
[C-1-2] Se quitó el requisito en Android 16.
[C-1-3] NO DEBE ofrecer el modo de pantalla dividida ni el de formato 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] Una actividad NO DEBE cambiar de tamaño a uno inferior a 220 dp en modos multiventana que no sean de pantalla en pantalla.

[C-1-5] DEBE mostrar las tareas con la propiedad selfMovable en opacidad completa, con una decoración persistente distinguible (p.ej., barra de título) y un método para cerrar esas tareas desde sus decoraciones persistentes.

Las implementaciones de dispositivos con un tamaño de pantalla xlarge DEBEN admitir el modo de formato libre.

Si las implementaciones de dispositivos admiten el modo multiventana y el modo de pantalla dividida, deben cumplir con lo siguiente:

[C-2-2] DEBE recortar la actividad anclada de una multiventana de pantalla dividida, pero DEBE mostrar parte de su contenido si la app del Selector es la ventana enfocada.
[C-2-3] DEBE respetar los valores declarados de AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight de la aplicación de selector de terceros y no anular estos valores durante la visualización de contenido de la actividad anclada.

Si las implementaciones de dispositivos admiten el modo multiventana y el modo multiventana de pantalla en pantalla, deben cumplir con lo siguiente:

[C-3-1] DEBE iniciar actividades en el modo multiventana de pantalla en pantalla cuando la app se encuentre en las siguientes situaciones:
- Se segmenta para el nivel de API 26 o uno superior, y declara android:supportsPictureInPicture
- Se segmenta para el nivel de API 25 o uno inferior, y declara android:resizeableActivity y android:supportsPictureInPicture.
[C-3-2] DEBE exponer las acciones en su SystemUI como lo especifica la actividad de PIP actual a través de la API de 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 especifica la actividad PIP a través de la API de setAspectRatio().
[C-3-4] DEBE usar KeyEvent.KEYCODE_WINDOW para controlar la ventana de PIP. Si no se implementa el modo de PIP, la clave DEBE estar disponible para la actividad en primer plano.
[C-3-5] DEBE proporcionar una indicación visual para que el usuario bloquee la visualización de una app en modo PIP. La implementación de AOSP cumple con este requisito, ya que incluye controles en el panel de notificaciones.
[C-3-6] DEBE asignar el siguiente ancho y alto mínimos para la ventana de PIP cuando una aplicación no declara ningún valor para AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight:
- Los dispositivos con el valor Configuration.uiMode establecido en un valor distinto de UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho y una altura mínimos de 108 dp.
- Los dispositivos con el Configuration.uiMode establecido en UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.

Si las implementaciones de dispositivos incluyen más de un área de pantalla compatible con Android y ponen esas áreas a disposición de las apps, deben cumplir con lo siguiente:

[C-4-1] DEBE admitir el modo multiventana.

Si las implementaciones de dispositivos admiten el modo multiventana, deben cumplir con lo siguiente:

[C-5-1] DEBE implementar la versión correcta del nivel de API de las extensiones de Window Manager, como se describe en Extensiones de WindowManager.

3.8.15. Corte de pantalla

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

Si las implementaciones de dispositivos incluyen cortes de pantalla, deben cumplir con lo siguiente:

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

3.8.16. Controles de dispositivos

Android incluye APIs de ControlsProviderService y Control para permitir que las aplicaciones de terceros publiquen controles de dispositivos para que los usuarios puedan ver rápidamente el estado y realizar acciones.

Consulta 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 ninguna conexión de red sin una acción explícita del usuario (p.ej., presionar un botón en la superposición) o indicación de que se está enviando contenido, excepto en el caso de los servicios mencionados en 9.8.6 Captura de contenido y Búsqueda en la app.

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

[C-1-1] SE DEBE ocultar la vista previa visible para el usuario

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

3.8.18. Botón de ubicación

El botón de ubicación es un elemento de la IU de Android que los desarrolladores de apps pueden incorporar en sus apps para obtener un permiso de ubicación precisa para la sesión de esa app.

Implementaciones de dispositivos:

[C-0-1] NO DEBE agregar, modificar ni quitar las opciones de personalización proporcionadas a los desarrolladores de apps para el botón de ubicación.

3.9. Administración del dispositivo

Android incluye funciones que permiten que las aplicaciones de controlador de políticas de dispositivos realicen funciones de administración de dispositivos a nivel del sistema, como aplicar políticas de contraseñas o realizar una limpieza de manera remota, a través de las APIs de Device Policy Manager.

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, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir el registro de un controlador de política de dispositivo (DPC) como una app de propietario del dispositivo, como se describe a continuación:
- Cuando la implementación del dispositivo no tiene configurados usuarios ni datos del usuario, sucede lo siguiente:
  - [C-1-5] DEBE inscribir la aplicación del DPC como la app de propietario del dispositivo o habilitar la app del DPC para elegir si se convertirá en propietario del dispositivo o propietario del perfil, si el dispositivo declara compatibilidad con la comunicación de campo cercano (NFC) a través de la marca de función android.hardware.nfc y recibe un mensaje NFC que contiene un registro con el tipo de MIME MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] DEBE enviar el intent ACTION_GET_PROVISIONING_MODE después de que se active el aprovisionamiento del propietario del dispositivo para que la app del DPC pueda elegir si se convierte en propietario del dispositivo o propietario del perfil, según los valores de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a menos que se pueda determinar a partir del contexto que solo hay una opción válida.
  - [C-1-9] DEBE enviar el intent ACTION_ADMIN_POLICY_COMPLIANCE a la app de propietario del dispositivo si se establece un propietario del dispositivo durante el aprovisionamiento, independientemente del método de aprovisionamiento que se use. El usuario no debe poder continuar en el asistente de configuración hasta que finalice la app de propietario del dispositivo.
- Cuando la implementación del dispositivo tiene usuarios o datos del usuario, sucede lo siguiente:
  - [C-1-7] NO DEBE inscribir ninguna aplicación de DPC como app de propietario del dispositivo.
[C-1-2] Se quitó el requisito en Android 15.
[C-2-1] Se quitó el requisito en Android 15.
[C-2-2] Se quitó el requisito en Android 15.
[C-2-3] Se quitó el requisito en Android 15.

3.9.1.2. Aprovisionamiento de perfiles administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar android.software.device_admin y, además, implementar las APIs que permiten que una aplicación de controlador de política de dispositivo (DPC) se convierta en el propietario de un nuevo perfil administrado.
[C-1-2] Se quitó el requisito en Android 16.
[C-1-3] DEBE proporcionar las siguientes opciones para el usuario en la Configuración para indicarle cuándo el Controlador de políticas del dispositivo (DPC) inhabilitó una función del sistema en particular:
- Un ícono coherente o alguna otra indicación visual para el usuario (por ejemplo, el ícono de información de AOSP directo) para representar cuando un administrador del dispositivo restringe un parámetro de configuración en particular.
- Es un mensaje de explicación breve que proporciona el administrador del dispositivo a través de setShortSupportMessage.
- Es el ícono de la aplicación del DPC.
[C-1-4] DEBE iniciar el controlador para el intent ACTION_PROVISIONING_SUCCESSFUL en el perfil de trabajo si se establece un propietario del perfil cuando el intent android.app.action.PROVISION_MANAGED_PROFILE inicia el aprovisionamiento y el DPC implementó el controlador.
[C-1-5] DEBE enviar la transmisión de ACTION_PROFILE_PROVISIONING_COMPLETE al DPC del perfil de trabajo cuando el intent android.app.action.PROVISION_MANAGED_PROFILE inicie el aprovisionamiento.
[C-1-6] DEBE enviar el intent ACTION_GET_PROVISIONING_MODE después de que se active el aprovisionamiento del propietario del perfil para que la app del DPC pueda elegir si se convierte en propietario del dispositivo o propietario del perfil, excepto cuando el aprovisionamiento se active con el intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] DEBE enviar el intent 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 use, excepto cuando el aprovisionamiento se activa con el intent android.app.action.PROVISION_MANAGED_PROFILE. El usuario no debe poder continuar en el asistente de configuración hasta que finalice la app de propietario del perfil.
[C-1-8] DEBE enviar la transmisión de ACTION_MANAGED_PROFILE_PROVISIONED al DPC del perfil personal cuando se establezca un propietario del perfil, independientemente del método de aprovisionamiento que se utilice.

3.9.2. Compatibilidad con perfiles administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir perfiles administrados a través de las APIs de 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 ícono (similar a la insignia de trabajo upstream de AOSP) para representar las aplicaciones y los widgets administrados, y otros elementos de la IU 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 cuándo el usuario se encuentra dentro de una aplicación de perfil administrado.
[C-1-5] DEBE mostrar un mensaje emergente que indique que el usuario está en el perfil administrado 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 indicación visual en el "Selector" de intents para permitir que el usuario reenvíe el intent del perfil administrado al usuario principal o viceversa, si el Controlador de políticas del dispositivo lo habilita.
[C-1-7] Cuando existe un perfil administrado, DEBE exponer las siguientes opciones para el usuario principal y el perfil administrado:
- Contabilidad separada del uso de la batería, la ubicación, los datos móviles y el uso del almacenamiento para el usuario principal y el perfil administrado.
- Administración independiente de las aplicaciones de VPN instaladas en el perfil de usuario principal o administrado.
- Administración independiente de las aplicaciones instaladas en el perfil de usuario principal o administrado.
- Administración independiente de las cuentas dentro del perfil de usuario principal o 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ítica de dispositivo lo permite.
[C-1-9] DEBE garantizar que cumpla con todos los requisitos de seguridad aplicables para un dispositivo con varios usuarios habilitados (consulta la sección 9.5), aunque el perfil administrado no se considere otro usuario además del usuario principal.
[C-1-10] DEBE garantizar que los datos de la captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se capture una captura de pantalla con una ventana topActivity que tenga enfoque (aquella con la que el usuario interactuó por última vez entre todas las actividades) y pertenezca a una app del perfil de trabajo.
[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 o ventanas de la aplicación del perfil de trabajo cuando se guarda una captura de pantalla en el perfil de trabajo (para garantizar que los datos del perfil personal no se guarden en el perfil de trabajo).

Si las implementaciones de dispositivos declaran android.software.managed_users y android.software.secure_lock_screen, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir la capacidad de especificar una pantalla de bloqueo independiente que cumpla con los siguientes requisitos para otorgar acceso solo a las apps que se ejecutan en un perfil administrado.
- Las implementaciones de dispositivos DEBEN respetar el intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD y mostrar una interfaz para configurar una credencial de pantalla de bloqueo independiente para el perfil administrado.
- Las credenciales de la pantalla de bloqueo del perfil administrado DEBEN usar los mismos mecanismos de almacenamiento de credenciales y administración que el perfil principal, como se documenta en el sitio del Proyecto de código abierto de Android.
- Las políticas de contraseñas del DPC DEBEN aplicarse solo a las credenciales de la pantalla de bloqueo del perfil administrado, a menos que se llame a la instancia de DevicePolicyManager que devuelve getParentProfileInstance.
Cuando se muestran los contactos del perfil administrado en el registro de llamadas preinstalado, la IU durante la llamada, las notificaciones de llamadas en curso y perdidas, y las apps de contactos y mensajería, DEBEN mostrar el mismo distintivo que se usa para indicar las aplicaciones del perfil administrado.

3.9.3. Asistencia para usuarios administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el usuario salga de la sesión del usuario actual y vuelva al usuario principal en una sesión multiusuario cuando isLogoutEnabled devuelva true. Se DEBE poder acceder a la indicación visual del usuario desde la pantalla de bloqueo sin desbloquear el dispositivo.

Si las implementaciones de dispositivos declaran android.software.device_admin y proporcionan una indicación visual integrada en el dispositivo para agregar usuarios secundarios adicionales, deben cumplir con lo siguiente:

[C-SR-1] Los dispositivos que se RECOMIENDAN ENCARECIDAMENTE deben mostrar las mismas divulgaciones de consentimiento del propietario del dispositivo de 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, de modo que los usuarios comprendan que el dispositivo está administrado.

3.9.4. Requisitos del rol de administración de políticas del dispositivo

Si las implementaciones de dispositivos declaran android.software.device_admin, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir el rol de administración de políticas del dispositivo, como se define en la Sección 9.1. La aplicación que tiene el rol de administración de políticas del dispositivo SE PUEDE definir configurando config_devicePolicyManagement en el nombre del paquete. El nombre del paquete DEBE ir seguido de dos puntos (:) y el certificado de firma, a menos que la aplicación esté cargada previamente.

Si no se define un nombre de paquete para config_devicePolicyManagement como se describió anteriormente, sucede lo siguiente:

[C-2-1] Las implementaciones de dispositivos DEBEN admitir el aprovisionamiento sin una aplicación de titular del rol de administración de políticas del dispositivo (AOSP proporciona una implementación de referencia).

Si se define un nombre de paquete para config_devicePolicyManagement como se describió anteriormente, sucede lo siguiente:

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

Si se define un nombre de paquete para config_devicePolicyManagementUpdater como se describió anteriormente, sucede lo siguiente:

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

3.9.5. Framework de resolución de políticas de dispositivos

Si las implementaciones de dispositivos declaran android.software.device_admin, deben cumplir con lo siguiente:

[C-1-1] DEBE resolver los conflictos de políticas de dispositivos según se documenta en el Framework de resolución de políticas de dispositivos.

3.10. Accesibilidad

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

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una implementación del framework de accesibilidad de Android como se describe en la documentación del SDK de las APIs de accesibilidad.
[C-1-2] DEBE generar eventos de accesibilidad y entregar el AccessibilityEvent adecuado a todas las implementaciones de AccessibilityService registradas, como se documenta en el SDK.
[C-1-4] DEBE proporcionar una indicación visual para que el usuario controle los servicios de accesibilidad que declaran AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Ten en cuenta que, en el caso de las implementaciones de dispositivos con una barra de navegación del sistema, SE DEBE permitir que el usuario tenga la opción de incluir 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, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE implementar estos servicios de accesibilidad preinstalados como apps compatibles con el inicio directo cuando el almacenamiento de datos esté encriptado con la encriptación basada en archivos (FBE).
DEBE proporcionar un mecanismo en el flujo de configuración inicial para que los usuarios habiliten los servicios de accesibilidad pertinentes, así como opciones para ajustar el tamaño de fuente, el tamaño de visualización y los gestos de ampliación.

3.11. Text-to-Speech

Android incluye APIs que permiten que las aplicaciones usen servicios de texto a voz (TTS) y que los proveedores de servicios proporcionen implementaciones de servicios de TTS.

Si las implementaciones de dispositivos informan la función android.hardware.audio.output, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir las APIs del framework de TTS de Android.

Si las implementaciones de dispositivos admiten la instalación de motores de TTS de terceros, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE proporcionar una indicación visual para que el usuario seleccione un motor de TTS para usarlo a nivel del sistema.

3.12. N/A

3.13. Configuración rápida

Android proporciona un componente de IU de Configuración rápida que permite acceder rápidamente a acciones que se usan con frecuencia o que se necesitan con urgencia.

Si las implementaciones de dispositivos incluyen un componente de IU de Configuración rápida y admiten la Configuración rápida de terceros, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE permitir que el usuario agregue o quite las tarjetas proporcionadas a través de las APIs de quicksettings desde una app de terceros.
[C-1-2] NO DEBE agregar automáticamente una tarjeta de una app de terceros directamente a la Configuración rápida.
[C-1-3] DEBE mostrar todos los mosaicos agregados por el usuario desde apps de terceros junto con los mosaicos de configuración rápida proporcionados por el sistema.

3.14. IU de medios

Si las implementaciones de dispositivos incluyen aplicaciones no activadas por voz (las Apps) que interactúan con aplicaciones de terceros a través de MediaBrowser o MediaSession, las Apps deben cumplir con los siguientes requisitos:

[C-1-2] DEBE mostrar claramente los íconos obtenidos a través de getIconBitmap() o getIconUri() y los títulos obtenidos a través de getTitle(), como se describe en MediaDescription. Es posible que se acorten los títulos para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor).
[C-1-3] DEBE mostrar el ícono de la aplicación de terceros cada vez que muestre contenido proporcionado por esta aplicación de terceros.
[C-1-4] DEBE permitir que el usuario interactúe con toda la jerarquía de MediaBrowser. PUEDE restringir el acceso a parte de la jerarquía para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor), pero NO DEBE dar un trato preferencial según 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. Apps instantáneas

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

[C-1-1] Las Instant Apps SOLO deben tener permisos que tengan android:protectionLevel establecido en "instant".
[C-1-2] Las Instant Apps NO DEBEN interactuar con las apps instaladas a través de intentos implícitos, a menos que se cumpla una de las siguientes condiciones:
- El filtro de patrones de intents del componente está expuesto y tiene CATEGORY_BROWSABLE.
- La acción es una de ACTION_SEND, ACTION_SENDTO o ACTION_SEND_MULTIPLE.
- El destino se expone de forma explícita con android:visibleToInstantApps
[C-1-3] Las apps instantáneas NO DEBEN interactuar de forma explícita con las apps instaladas, a menos que el componente se exponga a través de android:visibleToInstantApps.
[C-1-4] Las Apps Instaladas NO DEBEN ver detalles sobre las Apps Instantáneas en el dispositivo, a menos que la App Instantánea se conecte explícitamente a la aplicación instalada.
Las implementaciones de dispositivos DEBEN proporcionar las siguientes opciones para que los usuarios interactúen con las apps instantáneas. El AOSP cumple con los requisitos con la IU del sistema, la configuración y el Selector predeterminados. Implementaciones de dispositivos:
- [C-1-5] DEBE proporcionar una opción para que el usuario vea y borre las Apps instantáneas almacenadas en caché de forma local para cada paquete de app individual.
- [C-1-6] DEBE proporcionar una notificación persistente para el usuario que se pueda contraer mientras se ejecuta una app instantánea en primer plano. Esta notificación al usuario DEBE incluir que las apps instantáneas no requieren instalación y proporcionar una indicación visual que dirija al usuario a la pantalla de información de la aplicación en Configuración. En el caso de las Apps instantáneas que se inician a través de intents web, según se define con un intent con la acción establecida en Intent.ACTION_VIEW y con un esquema de "http" o "https", una indicación visual adicional para el usuario DEBE permitir que el usuario no inicie la App instantánea y que inicie el vínculo asociado con el navegador web configurado, si hay un navegador disponible en el dispositivo.
- [C-1-7] DEBE permitir que se acceda a las Instant Apps desde la función Recientes si esta está disponible en el dispositivo.
[C-1-8] DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para los intents que se indican aquí en el SDK y hacer que los intents sean visibles para las Instant Apps.

3.16. Sincronización de dispositivos complementarios

Android incluye compatibilidad con el vinculación de dispositivos complementarios para administrar de manera más eficaz la asociación con dispositivos complementarios y proporciona la API de CompanionDeviceManager para que las apps accedan a esta función.

Si las implementaciones de dispositivos admiten la función de vinculación de dispositivos complementarios, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar la marca de función FEATURE_COMPANION_DEVICE_SETUP.
[C-1-2] DEBE garantizar que las APIs del paquete android.companion estén completamente implementadas.
[C-1-3] DEBE proporcionar recursos para que el usuario seleccione o confirme que hay un dispositivo complementario presente y en funcionamiento, que DEBE usar el mismo mensaje que se implementó en el AOSP sin agregados ni modificaciones.

3.17. Apps pesadas

Si las implementaciones de dispositivos declaran la función FEATURE_CANT_SAVE_STATE, deben cumplir con lo siguiente:

[C-1-1] DEBE tener solo una app instalada que especifique cantSaveState en ejecución en el sistema a la vez. Si el usuario sale de una app de este tipo sin salir de ella de forma explícita (por ejemplo, presionando el botón de inicio mientras sale de una actividad activa, el sistema, en lugar de presionar el botón de atrás sin que queden actividades activas en el sistema), las implementaciones del dispositivo DEBEN priorizar esa app en la RAM como lo hacen con otros elementos que se espera que sigan ejecutándose, como los servicios en primer plano. Mientras una app de este tipo se ejecuta en segundo plano, el sistema puede seguir aplicándole 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 que permita elegir la app que no participará en el mecanismo normal de guardar y restablecer el estado una vez que el usuario inicie una segunda app declarada con el atributo cantSaveState.
[C-1-3] NO DEBE aplicar otros cambios en la política a las apps que especifican cantSaveState, como cambiar el rendimiento de la CPU o la prioridad de programación.

Si las implementaciones de dispositivos no declaran la función FEATURE_CANT_SAVE_STATE, sucederá lo siguiente:

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

3.18. Contactos

Android incluye APIs de 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 suelen sincronizarse con un servicio web, pero los datos TAMBIÉN PUEDEN residir solo de forma local en el dispositivo. Los contactos que solo se almacenan en el dispositivo se denominan contactos locales.

Los RawContacts se "asocian con" o se "almacenan en" una Account 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: Es una cuenta para los 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: Es una cuenta para los 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 no nulos 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 del dispositivo usan una cuenta local personalizada, haz lo siguiente:

[C-1-1] ACCOUNT_NAME de la cuenta local personalizada DEBE devolver ContactsContract.RawContacts.getLocalAccountName
[C-1-2] ACCOUNT_TYPE, de la cuenta local personalizada DEBE devolver ContactsContract.RawContacts.getLocalAccountType
[C-1-3] Los contactos sin procesar insertados por aplicaciones de terceros sin especificar una cuenta DEBEN insertarse en la cuenta de contactos predeterminada del dispositivo. Si la cuenta de contactos predeterminada es DEFAULT_ACCOUNT_STATE_LOCAL o DEFAULT_ACCOUNT_STATE_NOT_SET, estos contactos sin procesar DEBEN almacenarse en la cuenta local personalizada.
[C-1-4] Los contactos sin procesar insertados en la cuenta local personalizada NO se deben quitar cuando se agregan o quitan cuentas.
[C-1-5] Las operaciones de eliminación realizadas en la cuenta local personalizada DEBEN generar la purga inmediata de los contactos sin procesar (como si el parámetro CALLER_IS_SYNCADAPTER se hubiera establecido en verdadero), incluso si el parámetro CALLER_IS_SYNCADAPTER se hubiera establecido en falso o no se hubiera especificado.

Cuentas de SIM: Son las cuentas de los contactos sin procesar que se duplican desde una o más tarjetas SIM físicas insertadas en el dispositivo y que no están asociadas a una cuenta en AccountManager.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos usan cuentas de SIM:

[C-1-6] ContactsContract.SimContacts.getSimAccounts DEBE devolver las cuentas de SIM.

3.18.2. Selector de contactos del sistema

Android incluye compatibilidad con un selector de contactos del sistema que permite que las apps accedan a información de contacto limitada sin necesidad de permisos de acceso amplios.

Si las implementaciones de dispositivos admiten contactos de Android, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar el Selector de contactos del sistema (com.android.contactspicker) para las apps que se segmentan para el nivel de API 37 o versiones posteriores.
[C-1-2] DEBE implementar el intent Intent.ACTION_PICK_CONTACTS.

3.19. Configuración de idioma

Implementaciones de dispositivos:

[C-0-1] NO DEBE proporcionar ninguna indicación visual para que el usuario seleccione el tratamiento del lenguaje específico del género para los idiomas que no admiten traducciones específicas del género. Consulta los recursos gramaticales para obtener más información.

3.20. Experiencias basadas en el Asistente

El framework de desarrollo del asistente de Android permite el control de voz de las apps para Android. Con Asistente, los usuarios pueden usar su voz para iniciar apps, realizar tareas, acceder a contenido y mucho más.

En esta sección, consulta las siguientes clasificaciones para las implementaciones de dispositivos especializados:

Volumen fijo: Un dispositivo de volumen fijo es aquel que tiene controles de volumen, pero impide que las apps cambien el nivel de la transmisión de audio con los métodos AudioManager estándar (por ejemplo, los automóviles con SO Android Automotive).
Volumen completo: Un dispositivo de volumen completo es aquel cuyo volumen está bloqueado en un nivel completo y sin atenuar, y en el que se impide el control del software (por ejemplo, una TV con bocinas externas).
Volumen único: Un dispositivo de volumen único es aquel que asigna todos los flujos de audio a un solo flujo de volumen, lo que hace que los ajustes de volumen afecten a todos los flujos de audio de manera uniforme (por ejemplo, una TV).

3.20.1. Requisitos de la transmisión de audio del Asistente

Una aplicación que tiene el permiso MANAGE_ASSISTANT_AUDIO:

[C-0-1] SE DEBE permitir cambiar el volumen de STREAM_ASSISTANT de forma programática.

Si las implementaciones de dispositivos no declaran android.hardware.type.watch y no son de volumen fijo, de volumen único o de volumen completo, sucede lo siguiente:

[C-1-1] DEBE implementar STREAM_ASSISTANT como una transmisión de audio desacoplada y NO DEBE tener un alias para ninguna otra transmisión.
[C-1-2] DEBE garantizar que el volumen de reproducción de audio que usa AudioAttributes con USAGE_ASSISTANT esté controlado por STREAM_ASSISTANT.
[C-1-3] DEBE garantizar que, para un auricular Bluetooth determinado, el índice de volumen STREAM_ASSISTANT siga siendo el mismo cuando el auricular cambie entre los perfiles de audio A2DP y HFP.
[C-1-4] DEBE impedir que cualquier transmisión que no sea STREAM_ASSISTANT pueda cambiar el volumen de STREAM_ASSISTANT o la atenuación aplicada a la reproducción de STREAM_ASSISTANT mientras MODE_ASSISTANT_CONVERSATION esté activo.USAGE_ASSISTANT
[C-1-5] DEBE cambiar el volumen de la transmisión de STREAM_ASSISTANT y ningún otro volumen de transmisión cuando se ajusta el volumen a través de las teclas de volumen del dispositivo o periférico (como auriculares Bluetooth) y cuando se cumplen las siguientes condiciones:
- MODE_ASSISTANT_CONVERSATION está activo.
- No hay personalización específica de la app ni reproducción remota activa.
[C-1-6] DEBE reflejar cualquier cambio en el volumen del Asistente en la interfaz de usuario.

3.21. Compatibilidad con las funciones de sincronización de dispositivos complementarios

Android incluye compatibilidad con funciones de sincronización de datos en dispositivos complementarios.

Si las implementaciones de dispositivos admiten la función de sincronización de No interrumpir, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar la API de ContextualModeManager#isModeSyncSupported.
[C-1-2] DEBE sincronizar el parámetro de configuración que indica que la función No interrumpir está habilitada a través del canal seguro CompanionDeviceManager con un formato de datos compatible con la implementación predeterminada de CompanionDeviceManagerService.
[C-1-3] DEBE habilitar esta sincronización si ContextualModeManager#isModeSyncEnabled devuelve true.

Si las implementaciones de dispositivos admiten la función de sincronización del modo avión, deben cumplir con los siguientes requisitos:

[C-1-4] DEBE sincronizar el parámetro de configuración que indica que el modo de avión está habilitado a través del canal seguro CompanionDeviceManager con un formato de datos compatible con la implementación predeterminada de CompanionDeviceManagerService.
[C-1-5] DEBE habilitar esta sincronización si Settings.Global.AIRPLANE_MODE_SYNC está habilitado.

3.22. API de ComputerControls

La API de ComputerControls permite que los agentes compatibles realicen acciones autónomas y no programadas en nombre del usuario para completar tareas en un dispositivo Android.

[C-1-1] Si las implementaciones de dispositivos precargan la biblioteca de extensiones com.android.extensions.computercontrol para admitir ComputerControl, deben hacer lo siguiente:

DEBE habilitar android.software.activities_on_secondary_display.
DEBE mostrar la función del sistema com.android.extensions.computercontrol como disponible.
DEBE habilitar VirtualDeviceManager.
DEBE incluir com.android.extensions.computercontrol en la lista que devuelve PackageManager#getSharedLibraries().
DEBE precargarse la aplicación de la plataforma com.android.virtualdevicemanager (objetivo de compilación VirtualDeviceManager).

4. Compatibilidad con el empaquetado de aplicaciones

Implementaciones de dispositivos:

[C-0-1] DEBE poder instalar y ejecutar archivos ".apk" de Android tal como los genera la herramienta "aapt" incluida en el SDK de Android oficial.
- Dado que el requisito anterior puede ser difícil de cumplir, se RECOMIENDA que las implementaciones de dispositivos usen el sistema de administración de paquetes de la implementación de referencia del AOSP.

[C-0-2] DEBE admitir la verificación de archivos ".apk" con el esquema de firma de APK v3.2, el esquema de firma de APK v3.1, el esquema de firma de APK v3, el esquema de firma de APK v2 y la firma de JAR.

[C-0-3] NO DEBE extender los formatos de .apk, manifiesto de Android, código de bytes de Dalvik o código de bytes de RenderScript de manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.
[C-0-4] NO DEBE permitir que las apps que no sean el "instalador de registro" actual del paquete desinstalen la app de forma silenciosa sin ninguna confirmación del usuario, como se documenta en el SDK para el permiso DELETE_PACKAGE. Las únicas excepciones son la app del verificador de paquetes del sistema que controla el intent PACKAGE_NEEDS_VERIFICATION y la app del administrador de almacenamiento que controla el intent ACTION_MANAGE_STORAGE.
[C-0-5] DEBE tener una actividad que controle el intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NO DEBE instalar paquetes de aplicaciones de fuentes desconocidas, a menos que la app que solicita la instalación cumpla con todos los siguientes requisitos:
- DEBE declarar el permiso REQUEST_INSTALL_PACKAGES o tener el valor de android:targetSdkVersion establecido en 24 o menos.
- El usuario DEBE haber otorgado permiso para instalar apps desde fuentes desconocidas.
DEBE proporcionar una indicación visual para el usuario para otorgar o revocar el permiso para instalar apps de Fuentes desconocidas por aplicación, pero PUEDE optar por implementar esto como una no-op y devolver RESULT_CANCELED para startActivityForResult() si la implementación del dispositivo no quiere permitir que los usuarios tengan esta opción. Sin embargo, incluso en esos casos, DEBEN indicarle al usuario por qué no se presenta esa opción.
[C-0-7] DEBE mostrar un 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 la misma API del sistema PackageManager.setHarmfulAppWarning marcó como potencialmente dañina.
DEBE proporcionar una indicación visual para que el usuario elija desinstalar o iniciar una aplicación en el diálogo de advertencia.
[C-0-8] DEBE implementar la compatibilidad con el sistema de archivos incremental, como se documenta aquí.
[C-0-9] DEBE admitir la verificación de archivos .apk con el esquema de firma de APK v4 y el esquema de firma de 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 contenedores definidos en la sección 5.1 para cada códec declarado por MediaCodecList.
[C-0-2] DEBE declarar y registrar la compatibilidad de los codificadores y decodificadores disponibles para las aplicaciones de terceros a través de MediaCodecList.
[C-0-3] DEBE poder decodificar correctamente y poner a disposición de las apps de terceros todos los formatos que puede codificar. Esto incluye todos los flujos de bits que generan sus codificadores y los perfiles que se informan en su CamcorderProfile.

Implementaciones de dispositivos:

DEBE intentar lograr la latencia mínima del códec, en otras palabras,
- NO DEBE consumir ni almacenar búferes de entrada, y solo debe devolver los búferes de entrada una vez que se hayan procesado.
- NO DEBE conservar los búferes decodificados durante más tiempo del especificado por el estándar (p.ej., SPS).
- NO DEBE conservar los búferes codificados durante más tiempo del que requiere la estructura de GOP.

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

Ten en cuenta que ni Google ni Open Handset Alliance garantizan que estos códecs estén libres de patentes de terceros. Se recomienda a quienes deseen usar 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 pertinentes.

5.1. Códecs de medios

5.1.1. Codificación de audio

Consulta más detalles en el artículo 5.1.3. Detalles de los 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 las apps de terceros:

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

[C-1-4] MPEG-D USAC con MPEG-D DRC (AAC de alta eficiencia extendido)

Todos los codificadores de audio DEBEN admitir lo siguiente:

[C-3-1] Frames de audio con orden de bytes nativo de PCM de 16 bits a través de la API de android.media.MediaCodec.

Cuando codifiques MPEG-D USAC con audio MPEG-D DRC (AAC de alta eficiencia extendido), haz lo siguiente:

[C-3-2] Todos los flujos de bits DEBEN contener los conjuntos de metadatos que se ajusten al perfil de control de sonoridad MPEG-D o al perfil de control de rango dinámico MPEG-D, nivel 1 o superior, de conformidad con ISO/IEC 23003-4.

5.1.2. Decodificación de audio

Consulta más detalles en el artículo 5.1.3. Detalles de los códecs de audio.

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

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

Si las implementaciones de dispositivos admiten la decodificación de búferes 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 de android.media.MediaCodec, se DEBE admitir lo siguiente:

[C-2-1] La decodificación DEBE realizarse sin mezcla reducida (p.ej., una transmisión AAC 5.0 debe decodificarse en cinco canales de PCM, y una transmisión AAC 5.1 debe decodificarse en seis canales de PCM).
[C-2-2] Los metadatos de rango dinámico DEBEN definirse como se indica en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3, y las claves de DRC android.media.MediaFormat para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves de DRC de AAC se introdujeron en la API 21 y son las siguientes: 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 con los requisitos C-2-1 y C-2-2 anteriores.

Cuando se decodifica audio USAC, MPEG-D (ISO/IEC 23003-4):

[C-3-1] Los metadatos de sonoridad y DRC SE DEBEN interpretar y aplicar según el perfil de control de rango dinámico de DRC de MPEG-D, nivel 1.
[C-3-2] El decodificador DEBE comportarse según la configuración establecida con las siguientes claves de 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:

MAY admite el control de la sonoridad y el rango dinámico con 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 y de ISO/IEC 14496-3 están presentes en un flujo de bits decodificado, entonces:

Los metadatos de ISO/IEC 23003-4 DEBEN tener prioridad.

Todos los decodificadores de audio DEBEN admitir la salida de lo siguiente:

[C-6-1] Frames de audio con orden de bytes nativo de PCM de 16 bits a través de la API de android.media.MediaCodec.

[C-7-1] La aplicación DEBE poder configurarse para usar la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT y controlar si el contenido se mezcla en estéreo (cuando se usa un valor de 2) o se genera con la cantidad nativa de canales (cuando se usa un valor igual o superior a esa cantidad). Por ejemplo, un valor de 6 o más configuraría un decodificador para que genere 6 canales cuando se le proporcione contenido 5.1.
[C-7-2] Durante la decodificación, el decodificador DEBE anunciar la máscara de canal que se usa en el formato de salida con la clave KEY_CHANNEL_MASK, utilizando las constantes android.media.AudioFormat (ejemplo: CHANNEL_OUT_5POINT1).

Todos los dispositivos portátiles o tablets que incluyen un efecto de espacializador, y todos los dispositivos automotrices y televisores:

[C-8-1] DEBE admitir la decodificación de IAMF v1.0 que contenga transmisiones de audio codificadas en AAC, FLAC, Opus o PCM, y DEBE presentar un decodificador de IAMF a través de la API de android.media.MediaCodec.
[C-8-2] DEBE garantizar que el decodificador de IAMF respete la máscara de canal que se usa para configurarlo a través de la clave KEY_CHANNEL_MASK, con constantes android.media.AudioFormat como CHANNEL_OUT_5POINT1.
[C-8-3] DEBE garantizar que el decodificador de IAMF anuncie la máscara de canal activa en el formato de salida a través de la clave KEY_CHANNEL_MASK, con constantes android.media.AudioFormat como CHANNEL_OUT_5POINT1.

Si las implementaciones de dispositivos admiten decodificadores de audio distintos del decodificador de audio AAC predeterminado y son capaces de generar audio multicanal (es decir, más de 2 canales) cuando se les proporciona contenido multicanal comprimido, se aplican las siguientes condiciones:

[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que la aplicación pueda configurar el decodificador con la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se reduce a estéreo (cuando se usa un valor de 2) o se genera con la cantidad nativa de canales (cuando se usa un valor igual o superior a esa cantidad). Por ejemplo, un valor de 6 o más configuraría un decodificador para que genere 6 canales cuando se le proporcione contenido 5.1.
[C-SR-3] Cuando se decodifica, se RECOMIENDA ENCARECIDAMENTE que el decodificador anuncie la máscara de canal que se usa en el formato de salida con la clave KEY_CHANNEL_MASK, usando las constantes android.media.AudioFormat (ejemplo: CHANNEL_OUT_5POINT1).

5.1.3. Detalles de los códecs de audio

Formato/códec	Detalles	Tipos de archivo o formatos de contenedor que se admitirán
G.711 μ-law y A-law	Compatibilidad con contenido mono/estéreo/5.1 muestreado a 8 kHz	WAVE (.wav)
Perfil AAC de MPEG-4 (AAC LC)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4 y .m4a) AAC sin procesar de ADTS (.aac, no se admite ADIF) MPEG-TS (.ts, no admite búsquedas, solo decodificación) Matroska (.mkv, solo decodificación)
Perfil MPEG-4 HE AAC (AAC+)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4 y .m4a)
Perfil MPEG-4 HE AACv2 (AAC+ mejorado)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4 y .m4a)
AAC ELD (AAC mejorado de bajo retraso)	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4 y .m4a)
USAC MPEG-D USAC con MPEG-D DRC (AAC de alta eficiencia extendido)	Decodificación: Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 7.35 a 48 kHz Codificación: Compatibilidad con contenido mono/estéreo con tasas de muestreo de 44.1 y 48 kHz.	MPEG-4 (.mp4 y .m4a)
AMR-NB	4.75 a 12.2 kbps con muestreo a 8 kHz	3GPP (.3gp)
AMR-WB	9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz, como se define en AMR-WB, códec de voz de banda ancha con compresión multitasa adaptativa	3GPP (.3gp)
FLAC	Tanto para el codificador como para el decodificador, SE DEBEN admitir al menos los modos mono y estéreo. Se DEBEN admitir tasas de muestreo de hasta 192 kHz y resoluciones de 16 y 24 bits. El procesamiento de datos de audio FLAC de 24 bits DEBE estar disponible con la configuración de audio de punto flotante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv, solo decodificación)
MP3	Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv, solo decodificación)
MIDI	MIDI tipo 0 y 1. Versión 1 y 2 de DLS. XMF y Mobile XMF. Compatibilidad con los formatos de tono RTTTL/RTX, OTA y iMelody	Tipo 0 y 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodificación: Admite contenido mono, estéreo, 5.0 y 5.1 con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. Codificación: Admite contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) Webm (.webm)
PCM/WAVE	El códec PCM DEBE admitir PCM lineal de 16 bits y punto flotante de 16 bits. El extractor de WAVE debe admitir PCM lineal de 16, 24 y 32 bits, y punto flotante de 32 bits (las tasas dependen del límite del hardware). Se DEBEN admitir tasas de muestreo de 8 kHz a 192 kHz.	WAVE (.wav)
Opus	Decodificación: Compatibilidad con contenido mono, estéreo, 5.0 y 5.1 con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. Codificación: Compatibilidad con contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) Webm (.webm)

5.1.4. Codificación de imágenes

Consulta más detalles en el apartado 5.1.6. Detalles de los códecs de imágenes.

Las implementaciones de dispositivos DEBEN admitir la codificación de imágenes que se indica a continuación:

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- Los dispositivos deben admitir BITRATE_MODE_CQ y el perfil de Baseline.

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, deben cumplir con lo siguiente:

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

5.1.5. Decodificación de imágenes

Consulta más detalles en el apartado 5.1.6. Detalles de los códecs de imágenes.

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 Baseline)

Si las implementaciones de dispositivos admiten la decodificación de video HEVC, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE 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 la aplicación lo solicita, por ejemplo, a través de la configuración de ARGB_8888 de android.graphics.Bitmap.

5.1.6. Detalles de los códecs de imágenes

Formato/códec	Detalles	Tipos de archivos y formatos de contenedor compatibles
JPEG	Básica + progresiva	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Sin procesar		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) y HEIC (.heic)
AVIF (perfil de Baseline)	Imagen, colección de imágenes, perfil de Baseline de secuencia de imágenes	Contenedor HEIF (.avif)

Codificadores y decodificadores de imágenes expuestos a través de la API de 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 Surface de entrada.
[C-1-3] DEBE admitir al menos uno de los siguientes formatos de color YUV420 8:8:8 planos o semipanos: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). SE RECOMIENDA ENCARECIDAMENTE que admitan ambos.

5.1.7. Códecs de video

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

Si las implementaciones de dispositivos incluyen un codificador o decodificador de video, deben cumplir con los siguientes requisitos:

[C-1-1] Los códecs de video DEBEN admitir tamaños de ByteBuffer de entrada y salida que se adapten al fotograma comprimido y sin comprimir más grande posible, según lo dicten el estándar y la configuración, pero sin asignar recursos en exceso.
[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 admitan 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 planos o semiplanos optimizados para hardware (YV12, NV12, NV21 o un formato equivalente optimizado por el proveedor).
[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 la aplicación lo solicita. Esto DEBE reflejarse en la compatibilidad con un formato de color YUV420 8:8:8 a través de android.media.MediaCodecInfo.

Si las implementaciones de dispositivos anuncian la compatibilidad con el perfil HDR a través de Display.HdrCapabilities, deben cumplir con lo siguiente:

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

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

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

A menos que la aplicación especifique lo contrario con la clave de formato KEY_COLOR_FORMAT, las implementaciones del decodificador de video deben cumplir con lo siguiente:

[C-4-1] DEBE establecerse de forma predeterminada en el formato de color optimizado para el hardware de pantalla si se configura con la salida de Surface.
[C-4-2] DEBE establecerse de forma predeterminada en un formato de color YUV420 8:8:8 optimizado para la lectura de CPU si se configura para no usar la salida de Surface.

En el caso de las implementaciones de dispositivos que incluyen un codificador o decodificador de video, se deben cumplir los siguientes requisitos:

[C-5-1] Los decodificadores de video que usan una tecnología de codificación del 2003 o posterior (como AV1, AVC, HEVC, VP8, VP9 o VVC) DEBEN cumplir con lo siguiente:
- Admitir un tamaño mínimo de 144 × 144 px
- Anuncia esta compatibilidad a través de la API de VideoCapabilities, por ejemplo, con los métodos getSupportedWidths() y getSupportedHeightsFor().
[C-5-2] Los codificadores de video que usan una tecnología de codificación del 2003 o posterior (como AV1, AVC, HEVC, VP8, VP9 o VVC) DEBEN cumplir con lo siguiente:
- Admite la entrada de la superficie de soporte con el siguiente tamaño mínimo para cada codificador:
  - AVC: 160 x 160 px
  - VP8, HEVC y VP9 (si se proporciona el codificador): 160 x 160 px
  - AV1 (si se proporciona el codificador): 256 x 256 px
- PUEDE producir un flujo de bits con un tamaño de fotograma mayor que el mínimo, siempre que codifique el tamaño adecuado con la información del rectángulo de recorte.

5.1.8. Lista de códecs de video

Formato/códec	Detalles	Tipos de archivo o formatos de contenedor que se admitirán
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, solo decodificación)
H.264 AVC	Consulta las secciones 5.2 y 5.3 para obtener más detalles.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, no admite búsquedas) Matroska (.mkv, solo decodificación)
H.265 HEVC	Consulta la sección 5.3 para obtener más detalles.	MPEG-4 (.mp4) Matroska (.mkv, solo decodificación)
MPEG-2	Perfil principal	MPEG2-TS (.ts, no admite búsquedas) MPEG-4 (.mp4, solo decodificación) Matroska (.mkv, solo decodificación)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, solo decodificación)
VP8	Consulta las secciones 5.2 y 5.3 para obtener más detalles.	WebM (.webm) Matroska (.mkv)
VP9	Consulta la sección 5.3 para obtener más detalles.	WebM (.webm) Matroska (.mkv)
AV1	Consulta la sección 5.2 y la sección 5.3 para obtener más detalles.	MPEG-4 (.mp4) Matroska (.mkv, solo decodificación)

5.1.9. Seguridad de códecs multimedia

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad de los códecs de medios, como se describe a continuación.

Android incluye compatibilidad con OMX, una API de aceleración multimedia multiplataforma, así como con Codec 2.0, una API de aceleración multimedia con una sobrecarga baja.

Si las implementaciones de dispositivos admiten contenido multimedia, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE proporcionar compatibilidad con los códecs de medios a través de las APIs de OMX o Codec 2.0 (o ambas) como en el Proyecto de código abierto de Android, y no inhabilitar ni eludir las protecciones de seguridad. Esto no significa específicamente que todos los códecs DEBEN usar la API de OMX o la de Codec 2.0, sino que DEBE estar disponible la compatibilidad con al menos una de estas APIs, y la compatibilidad con las APIs disponibles DEBE incluir las protecciones de seguridad presentes.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir compatibilidad con la API de Codec 2.0.

Si las implementaciones de dispositivos no admiten la API de Codec 2.0, deben hacer lo siguiente:

[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 medios (codificador o decodificador) que admita el dispositivo.
[C-2-2] Códecs cuyos nombres 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 de 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 de Codec 2.0, deben cumplir con los siguientes requisitos:

[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 medios (codificador o decodificador) que admita el dispositivo.
[C-3-2] DEBE alojar los códecs de software de Codec 2.0 en el proceso de códec de software que se proporciona en el Proyecto de código abierto de Android para permitir otorgar acceso a los códecs de software de forma más específica.
[C-3-3] Códecs cuyos nombres comienzan con "c2.android." DEBE basarse en el código fuente del Proyecto de código abierto de Android.

5.1.10. Caracterización de códecs de medios

Si las implementaciones de dispositivos admiten códecs de medios, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE devolver los valores correctos de la caracterización del códec de medios a través de la API de MediaCodecInfo.

En particular:

[C-1-2] Códecs con nombres que comienzan con "OMX". DEBE usar las APIs de OMX y tener nombres que cumplan con los lineamientos de nomenclatura de OMX IL.
[C-1-3] Códecs con nombres que comienzan con "c2." DEBE usar la API de Codec 2.0 y tener nombres que cumplan con los lineamientos de nomenclatura de 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 ni como acelerado por hardware.
[C-1-5] Los códecs que se ejecutan en un proceso de códec (del proveedor o del sistema) que tienen acceso a controladores de hardware que no sean asignadores y asignadores de memoria NO DEBEN caracterizarse como solo de software.
[C-1-6] Los códecs que no estén presentes en el Proyecto de código abierto de Android o que no se basen en el código fuente de ese proyecto DEBEN caracterizarse como de proveedor.
[C-1-7] Los códecs que utilizan la 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 de medios DEBEN admitir esos formatos.

Si las implementaciones de dispositivos admiten códecs de video, se deben cumplir los siguientes requisitos:

[C-2-1] Todos los códecs de video DEBEN publicar datos de la velocidad de fotogramas alcanzable para los siguientes tamaños si el códec los admite:

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificador MPEG4, H263, MPEG2) 320 × 180 px (VP8, VP8) 320 x 240 px (otro)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (otros, AV1)	1408 x 1152 px (H263) 1280 x 720 px (otro, AV1)	1920 × 1080 px (excepto MPEG4 y AV1)	3840 x 2160 px (HEVC, VP9, AV1)

[C-2-2] Los códecs de video que se caracterizan como acelerados por hardware DEBEN publicar información sobre los puntos de rendimiento. Cada uno DEBE enumerar todos los puntos de rendimiento estándar admitidos (que se indican en la API de PerformancePoint), a menos que estén cubiertos por otro punto de rendimiento estándar admitido.
Además, DEBEN publicar puntos de rendimiento extendidos si admiten un rendimiento de video sostenido que no sea uno de los estándares que se indican.

5.2. Codificación de video

Si las implementaciones de dispositivos admiten algún codificador de video y lo ponen a disposición de las apps de terceros, y configuran
MediaFormat.KEY_BITRATE_MODE en BITRATE_MODE_VBR para que el codificador funcione en el modo de tasa de bits variable, entonces, siempre que no afecte el nivel mínimo de calidad, la tasa de bits codificada debe cumplir con lo siguiente :

NO DEBE ser, en una ventana deslizante, más del 15% superior a la tasa de bits entre los intervalos de fotogramas clave (I-frame).
NO DEBE superar en más del 100% la tasa de bits en un período de 1 segundo.

Si las implementaciones de dispositivos admiten algún codificador de video y lo ponen a disposición de las apps de terceros, y establecen MediaFormat.KEY_BITRATE_MODE en BITRATE_MODE_CBR para que el codificador funcione en modo de tasa de bits constante, la tasa de bits codificada debe cumplir con los siguientes requisitos:

[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que NO supere en más del 15% la tasa de bits objetivo en una ventana deslizante de 1 segundo.

Si las implementaciones de dispositivos incluyen una pantalla integrada con una longitud diagonal de al menos 2.5 pulgadas o incluyen un puerto de salida de video, o bien declaran la compatibilidad con una cámara a través de la marca de función android.hardware.camera.any, deben cumplir con lo siguiente:

[C-1-1] DEBE incluir la compatibilidad con al menos uno de los codificadores de video VP8 o H.264, y ponerlo a disposición de las aplicaciones de terceros.
DEBE admitir los codificadores de video VP8 y H.264, y ponerlos a disposición de las aplicaciones de terceros.

Si las implementaciones de dispositivos admiten cualquiera de los codificadores de video H.264, VP8, VP9 o HEVC y los ponen a disposición de aplicaciones de terceros, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir velocidades de bits configurables de forma dinámica.
DEBE admitir velocidades de fotogramas variables, en las que el codificador de video DEBE determinar la duración instantánea del fotograma en función de las marcas de tiempo de los búferes de entrada y asignar su depósito de bits en función de esa duración del fotograma.

Si las implementaciones de dispositivos admiten el codificador de video MPEG-4 SP y lo ponen a disposición de las apps de terceros, deben hacer lo siguiente:

DEBE admitir velocidades de bits configurables de forma dinámica para el codificador admitido.

Si las implementaciones de dispositivos proporcionan codificadores de imágenes o video acelerados por hardware y admiten una o más cámaras de hardware conectadas o enchufables expuestas a través de las APIs de android.camera, se deben cumplir los siguientes requisitos:

[C-4-1] Todos los codificadores de imágenes y video acelerados por hardware DEBEN admitir la codificación de fotogramas 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 video o imagen.

Si las implementaciones de dispositivos proporcionan codificación HDR, deben cumplir con los siguientes requisitos:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar un complemento para la API de transcodificación sin interrupciones que permita convertir del formato HDR al formato SDR.

5.2.1. H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y los ponen a disposición de apps de terceros, deben hacer lo siguiente:

[C-1-1] DEBE admitir la resolución QCIF (176 x 144) con el nivel 45 del perfil de Baseline. La resolución SQCIF es opcional.

5.2.2. H.264

Si las implementaciones de dispositivos admiten el códec H.264, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el nivel 3 del perfil de Baseline. Sin embargo, la compatibilidad con ASO (ordenamiento de segmentos arbitrario), FMO (ordenamiento flexible de macrobloques) y RS (segmentos redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no usen ASO, FMO ni RS para el perfil de Baseline.
[C-1-2] DEBE admitir los perfiles de codificación de video en SD (definición estándar) que se indican en la siguiente tabla.
DEBE admitir el perfil principal de nivel 4.
DEBE admitir los perfiles de codificación de video en 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 APIs de medios, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir los perfiles de codificación que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	20 fps	30 fps	30 fps	30 fps
Tasa de bits del video	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

Si las implementaciones de dispositivos admiten el códec VP8, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir los perfiles de codificación de video SD.
DEBE admitir los siguientes perfiles de codificación de video en HD (alta definición).
[C-1-2] DEBE admitir la escritura de archivos Matroska WebM.
DEBE proporcionar un códec VP8 de hardware que cumpla con los requisitos de codificación de hardware de RTC del proyecto WebM para garantizar una calidad aceptable de los servicios de transmisión de video por Internet y de videoconferencias.

Si las implementaciones de dispositivos informan que admiten la codificación VP8 para videos con resolución de 720 p o 1080 p a través de las APIs de medios, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir los perfiles de codificación que se indican en la siguiente tabla.

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

5.2.4. VP9

Si las implementaciones de dispositivos admiten el códec VP9, deben cumplir con los siguientes requisitos:

[C-1-2] DEBE admitir el perfil 0, nivel 3.
[C-1-1] DEBE admitir la escritura de archivos WebM de Matroska.
[C-1-3] DEBE generar datos de CodecPrivate.
DEBE admitir los perfiles de decodificación de HD, como se indica en la siguiente tabla.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir los perfiles de decodificación en HD como se indica en la siguiente tabla si hay un codificador de hardware.

	SD	HD: 720p	HD: 1080p	UHD
Resolución de video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones de dispositivos afirman admitir el perfil 2 o el perfil 3 a través de las APIs de Media, deben cumplir con lo siguiente:

La compatibilidad con el formato de 12 bits es OPCIONAL.

5.2.5. H.265

Si las implementaciones de dispositivos admiten el códec H.265, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal de nivel 3 con una resolución de hasta 512 x 512.
[C-SR-1] se RECOMIENDA ENCARECIDAMENTE que admitan 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.

	SD	HD: 720p	HD: 1080p	UHD
Resolución de video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.2.6. AV1

Si las implementaciones de dispositivos admiten el códec AV1, deben cumplir con los siguientes requisitos:

[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 los datos de rendimiento a través de las APIs de getSupportedFrameRatesFor() o getSupportedPerformancePoints() para las resoluciones admitidas en la siguiente tabla.
[C-1-3] DEBE aceptar los metadatos de HDR y enviarlos al flujo de bits

Si el codificador AV1 está acelerado por hardware, sucede lo siguiente:

[C-2-1] DEBE admitir el perfil de codificación HD1080p incluido en la siguiente tabla:

	SD	HD: 720p	HD: 1080p	UHD
Resolución de video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	5 Mbps	8 Mbps	16 Mbps	50 Mbps

5.3. Decodificación de video

Si las implementaciones de dispositivos admiten los códecs VP8, VP9, H.264, H.265 o AV1, deben cumplir con los siguientes requisitos:

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

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal de alto nivel.

5.3.2. H.263

Si las implementaciones de dispositivos admiten decodificadores H.263, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el nivel 30 del perfil de Baseline (resoluciones CIF, QCIF y SQCIF a 30 FPS y 384 kbps) y el nivel 45 (resoluciones QCIF y SQCIF a 30 FPS y 128 kbps).

5.3.3. MPEG-4

Si las implementaciones de dispositivos incluyen decodificadores MPEG-4, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el nivel 3 del perfil simple.

5.3.4. H.264

Si las implementaciones de dispositivos admiten decodificadores H.264, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal nivel 3.1 y el perfil de Baseline. La compatibilidad con ASO (ordenamiento de segmentos arbitrario), FMO (ordenamiento flexible de macrobloques) y RS (segmentos redundantes) es OPCIONAL.
[C-1-2] DEBE poder decodificar videos con los perfiles de SD (definición estándar) que se indican en la siguiente tabla y que estén codificados con el perfil de Baseline y el perfil principal de nivel 3.1 (incluido 720p30).
DEBE ser capaz de decodificar videos con los perfiles de HD (alta definición) que se indican en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del video, las implementaciones del dispositivo deben hacer lo siguiente:

[C-2-1] DEBE admitir los perfiles de decodificación de video HD 720p que se indican en la siguiente tabla.
[C-2-2] DEBE admitir los perfiles de decodificación de video en HD 1080p que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	60 fps	30 fps (60 fps en ^televisores)
Tasa de bits del video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

Si las implementaciones de dispositivos admiten el códec H.265, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal nivel 3, el nivel principal y los perfiles de decodificación de video SD, como se indica en la siguiente tabla.
DEBE admitir los perfiles de decodificación de HD, como se indica en la siguiente tabla.
[C-1-2] DEBE admitir los perfiles de decodificación en HD que se indican en la siguiente tabla si hay un decodificador de hardware.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del video, sucede lo siguiente:

[C-2-1] Las implementaciones de dispositivos DEBEN admitir al menos uno de los perfiles de decodificación H.265 o VP9 de 720, 1080 y UHD.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 o 60 FPS (60 FPS^{Televisión con decodificación de hardware H.265})	60 fps
Tasa de bits del video	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones de dispositivos afirman que admiten un perfil HDR a través de las APIs de Media, se deben cumplir los siguientes requisitos:

[C-3-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos de HDR requeridos de la aplicación, así como admitir la extracción y la salida de los metadatos de HDR requeridos del flujo de bits o del 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 (p.ej., HDMI).

5.3.6. VP8

Si las implementaciones de dispositivos admiten el códec VP8, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir los perfiles de decodificación de SD que se indican en la siguiente tabla.
DEBE usar un códec VP8 de hardware que cumpla con los requisitos.
DEBE admitir los perfiles de decodificación de HD que se indican en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del video, sucede lo siguiente:

[C-2-1] Las implementaciones de dispositivos DEBEN admitir perfiles de 720 p 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)	HD: 720p	HD: 1080p
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps (60 fps en ^televisores)	30 (^televisión de 60 fps)
Tasa de bits del video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Si las implementaciones de dispositivos admiten el códec VP9, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir los perfiles de decodificación de video SD que se indican en la siguiente tabla.
DEBE admitir los perfiles de decodificación de HD, como se indica en la siguiente tabla.

Si las implementaciones de dispositivos admiten el códec VP9 y un decodificador de hardware, haz lo siguiente:

[C-2-1] DEBE admitir los perfiles de decodificación de HD 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 video, sucede lo siguiente:

[C-3-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones de VP9 o H.265 de los perfiles 720, 1080 y UHD.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 FPS (60 FPS^{Televisión con decodificación por hardware de VP9})	60 fps
Tasa de bits del video	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones de dispositivos afirman admitir VP9Profile2 o VP9Profile3 a través de las APIs de medios de "CodecProfileLevel", se deben cumplir los siguientes requisitos:

La compatibilidad con el 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 APIs de medios, deben cumplir con lo siguiente:

[C-4-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos de HDR requeridos (KEY_HDR_STATIC_INFO para todos los perfiles de HDR, así como "KEY_HDR10_PLUS_INFO" para los perfiles de HDR10Plus) de la aplicación. También DEBEN admitir la extracción y la salida de los metadatos HDR requeridos del flujo de bits o del 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 (p.ej., HDMI).

5.3.8. Dolby Vision

Si las implementaciones de dispositivos declaran compatibilidad con el decodificador Dolby Vision a través de HDR_TYPE_DOLBY_VISION, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar un extractor compatible con Dolby Vision.
[C-1-2] DEBE mostrar correctamente el contenido de Dolby Vision en la pantalla del dispositivo o en una pantalla externa conectada a través de un puerto de salida de video estándar (como HDMI).
[C-1-3] DEBE establecer el ID de pista de las capas básicas retrocompatibles (si las hay) de modo que sea igual al ID de pista de la capa combinada de Dolby Vision.

5.3.9. AV1

Si las implementaciones de dispositivos admiten el códec AV1 y lo ponen a disposición de las aplicaciones de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.

Si las implementaciones de dispositivos admiten el códec AV1 con un decodificador acelerado por hardware, deben cumplir con lo siguiente:

[C-2-1] DEBE poder decodificar al menos los perfiles de decodificación de video en HD 720p de la siguiente tabla cuando la altura que informa el método Display.getSupportedModes() es igual o superior a 720p.
[C-2-2] DEBE poder decodificar al menos los perfiles de decodificación de video en HD 1080p de la siguiente tabla cuando la altura que informa el método Display.getSupportedModes() sea igual o superior a 1080p.

	SD	HD: 720p	HD: 1080p	UHD
Resolución de video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	5 Mbps	8 Mbps	16 Mbps	50 Mbps

Si las implementaciones de dispositivos admiten el perfil HDR a través de las APIs de Media, entonces:

[C-3-1] DEBE admitir la extracción y la salida de metadatos de HDR del flujo de bits o del 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).

5.4. Grabación de audio

Si bien algunos de los requisitos que se describen en esta sección se indican como DEBERÍA desde Android 4.3, se prevé que la Definición de compatibilidad para versiones futuras cambie estos requisitos a DEBE. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos que se indican como SHOULD, ya que, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.

5.4.1. Captura de audio sin procesar y datos del micrófono

Si las implementaciones de dispositivos declaran android.hardware.microphone, deben cumplir con lo siguiente:

[C-1-1] DEBE permitir la captura de contenido de audio sin procesar para cualquier flujo de ENTRADA AudioRecord o AAudio que se abra correctamente. Como mínimo, se DEBEN admitir las siguientes características:
- Formato: PCM lineal, 16 bits
- Tasas de muestreo: 8,000, 11,025, 16,000, 44,100 y 48,000 Hz
- Canales: Mono
- Fuentes de audio: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE Esto también se aplica a los ajustes predeterminados de entrada equivalentes en AAudio, por ejemplo, AAUDIO_INPUT_PRESET_CAMCORDER.
DEBE permitir la captura de contenido de audio sin procesar con las siguientes características:
- Formato: PCM lineal, 16 y 24 bits
- Tasas de muestreo: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 y 48,000 Hz
- Canales: La cantidad de canales debe ser igual a la cantidad de micrófonos del dispositivo.
[C-1-2] DEBE capturar a tasas de muestreo superiores sin aumentar la resolución.
[C-1-3] DEBE incluir un filtro de suavizado adecuado cuando las frecuencias de muestreo mencionadas anteriormente se capturen con submuestreo.
DEBE permitir la captura de contenido de audio sin procesar con calidad de radio AM y DVD, lo que implica las siguientes características:
- Formato: PCM lineal, 16 bits
- Tasas de muestreo: 22,050 y 48,000 Hz
- Canales: Estéreo
[C-1-4] DEBE cumplir con la API de MicrophoneInfo y completar correctamente la información de los micrófonos disponibles en el dispositivo a los que pueden acceder las aplicaciones de terceros a través de la API de AudioManager.getMicrophones(), para AudioRecord activo que usa MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Si las implementaciones del dispositivo permiten la captura de contenido de audio sin procesar con calidad de radio AM y DVD, deben cumplir con lo siguiente:
[C-2-1] DEBE capturar sin aumentar la muestra a una proporción superior a 16000:22050 o 44100:48000.
[C-2-2] DEBE incluir un filtro de suavizado adecuado para cualquier aumento o reducción de la muestra.

5.4.2. Captura para el reconocimiento de voz

Si las implementaciones de dispositivos declaran android.hardware.microphone, deben cumplir con lo siguiente:

[C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION en una de las tasas de muestreo, 44,100 y 48,000.
[C-1-2] DEBE inhabilitar, de forma predeterminada, cualquier procesamiento de audio de reducción de ruido cuando se graba una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
[C-1-3] DEBE inhabilitar, de forma predeterminada, cualquier control de ganancia automático cuando se graba una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
DEBE exhibir características de amplitud en función de la frecuencia aproximadamente planas en el rango de frecuencias medias: específicamente ±3 dB de 100 Hz a 4,000 Hz para cada micrófono que se use para grabar la fuente de audio de reconocimiento de voz.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que los niveles de amplitud se encuentren en el rango de frecuencia baja, específicamente entre ±20 dB de 30 Hz a 100 Hz en comparación con el rango de frecuencia media para cada micrófono que se use para grabar la fuente de audio del reconocimiento de voz.
[C-SR-2] se RECOMIENDA ENCARECIDAMENTE que muestren niveles de amplitud en el rango de alta frecuencia, específicamente de ±30 dB desde 4,000 Hz hasta 22 kHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos que se usan para grabar la fuente de audio de reconocimiento de voz.
DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz reproducida a un nivel de presión acústica (SPL) de 90 dB (medido junto al micrófono) produzca una respuesta ideal de RMS 2500 dentro de un rango de 1770 y 3530 para muestras de 16 bits (o -22.35 dB ± 3 dB a escala completa para muestras de punto flotante o doble precisión) para cada micrófono que se use para grabar la fuente de audio de reconocimiento de voz.
DEBE grabar la transmisión de audio de reconocimiento de voz de modo que los niveles de amplitud de PCM realicen un seguimiento lineal de los cambios de SPL de entrada en un rango de al menos 30 dB, desde -18 dB hasta +12 dB re 90 dB SPL en el micrófono.
DEBE grabar la transmisión de audio de reconocimiento de voz con una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.

Si las implementaciones de dispositivos declaran tecnologías de android.hardware.microphone y supresión (reducción) de ruido optimizadas para el reconocimiento de voz, deben cumplir con lo siguiente:

[C-2-1] DEBE permitir que este efecto de audio se controle con la API de android.media.audiofx.NoiseSuppressor.
[C-2-2] DEBE identificar de forma única cada implementación de tecnología de reducción de ruido a través del campo AudioEffect.Descriptor.uuid.

5.4.3. Captura para el desvío de la reproducción

La clase android.media.MediaRecorder.AudioSource incluye la fuente de audio REMOTE_SUBMIX.

Si las implementaciones de dispositivos declaran android.hardware.audio.output y android.hardware.microphone, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX para que, cuando una aplicación use la API de android.media.AudioRecord para grabar desde esta fuente de audio, capture una combinación de todos los flujos de audio, excepto los 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, deben cumplir con lo siguiente:

DEBE implementar una tecnología de cancelación de eco acústico (AEC) optimizada para la comunicación de voz y aplicada a la ruta de captura cuando se captura con AudioSource.VOICE_COMMUNICATION.

Si las implementaciones de dispositivos proporcionan un cancelador de eco acústico que se inserta en la ruta de audio de captura cuando se selecciona AudioSource.VOICE_COMMUNICATION, deben cumplir con lo siguiente:

[C-SR-1] [C-1-1] se RECOMIENDA ENCARECIDAMENTE DEBE declarar esto a través del método de la API de AcousticEchoCanceler AcousticEchoCanceler.isAvailable() que devuelve true.

[C-1-2] DEBE reflejar la habilitación del AEC en la ruta de audio a través del método de la API de AcousticEchoCanceler AcousticEchoCanceler.getEnabled(), que debe devolver true cuando está activo y false cuando está inactivo.

[C-SR-2] [C-SR-1] se RECOMIENDAN_FUERTEMENTE para permitir que este efecto de audio se controle con la API de AcousticEchoCanceler.
[C-SR-3] [C-SR-2] se RECOMIENDA ENCARECIDAMENTE para identificar de forma única cada implementación de tecnología de CAE a través del campo AudioEffect.Descriptor.uuid.

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. Más precisamente, sucederá lo siguiente:

[C-1-1] DEBE permitir el acceso simultáneo al micrófono por parte de 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 por parte de una aplicación preinstalada que tenga un rol 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 esté capturando con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Sin embargo, cuando una app captura a través de AudioSource.VOICE_COMMUNICATION, otra app puede capturar la llamada de voz si es una app privilegiada (preinstalada) con el permiso CAPTURE_AUDIO_OUTPUT.
[C-1-4] Si dos o más aplicaciones capturan contenido de forma simultánea y ninguna tiene una IU en primer plano, la que inició la captura más recientemente recibe el audio.

5.5. Reproducción de audio

Android incluye la compatibilidad para permitir que las apps 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, deben cumplir con lo siguiente:

[C-1-1] DEBE permitir la reproducción de contenido de audio sin procesar 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
- Tasas de muestreo (en Hz):
  - 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 y 48,000 en las configuraciones de canales mencionadas anteriormente
  - 96,000 en mono y estéreo

5.5.2. Efectos de audio

Android proporciona una API para efectos de audio para las implementaciones de dispositivos.

Si las implementaciones de dispositivos declaran la función android.hardware.audio.output, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir las implementaciones de EFFECT_TYPE_EQUALIZER y EFFECT_TYPE_LOUDNESS_ENHANCER controlables a través de las subclases de AudioEffect Equalizer y LoudnessEnhancer.
[C-1-2] DEBE admitir la implementación de la API del visualizador, que se puede controlar a través de la clase Visualizer.
[C-1-3] DEBE admitir la implementación de EFFECT_TYPE_DYNAMICS_PROCESSING controlable a través de la subclase AudioEffect DynamicsProcessing.
[C-1-4] DEBE admitir efectos de audio con entrada y salida de punto flotante cuando los resultados del efecto se devuelven a la canalización de audio del framework. Esto se refiere a los efectos auxiliares o de inserción típicos, como el ecualizador. Se recomienda encarecidamente un comportamiento equivalente cuando la canalización de audio del framework no puede ver los resultados del efecto, como los efectos de posprocesamiento o descargados.
[C-1-5] DEBE asegurarse de que los efectos de audio admitan varios canales hasta el recuento de canales del mezclador, también conocido como FCC_LIMIT, cuando los resultados del efecto se devuelven a la canalización de audio del framework. Se refiere a los efectos auxiliares o de inserción típicos, pero excluye los efectos especiales, como los de reducción de mezcla, aumento de mezcla o espacialización, que cambian la cantidad de canales. Se recomienda un comportamiento equivalente cuando los efectos no son visibles para el canal de audio del framework, como los efectos de posprocesamiento o descargados.
DEBE admitir las implementaciones de EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER que se pueden controlar a través de las subclases 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 para automóviles:

DEBE permitir ajustar el volumen de audio por separado para cada transmisión de audio usando el tipo de contenido o el uso según lo definen AudioAttributes y el uso de audio del automóvil según se define públicamente en android.car.CarAudioManager.

5.5.4. Transferencia de audio

Si las implementaciones de dispositivos admiten la reproducción con descarga de audio, deben cumplir con lo siguiente:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE recortar el contenido de audio sin interrupciones que se reproduce entre dos clips con el mismo formato cuando lo especifiquen la API de AudioTrack sin interrupciones y el contenedor de medios para MediaPlayer.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE implementar la reproducción con descarga para los formatos AAC, MP3, OPUS y PCM.

Si las implementaciones de dispositivos declaran compatibilidad con la descarga de PCM de MMAP (declarada por un puerto de mezcla con marcas que contienen AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD y AUDIO_OUTPUT_FLAG_MMAP_NOIRQ), deben cumplir con lo siguiente:

[C-1-1] DEBE admitir al menos AUDIO_FORMAT_PCM_16_BIT, a 44.1 kHz y 48 kHz para estéreo y mono.
[C-1-2] DEBE tener un tamaño de búfer capaz de almacenar un mínimo de 5 segundos de audio a 48 kHz estéreo PCM de 16 bits por muestra.

5.5.5. Parámetros de reproducción

Si las implementaciones de dispositivos admiten la API de PlaybackParams, los parámetros de reproducción deben cumplir con lo siguiente:

[C-1-1] DEBE admitir velocidades entre 0.5 y 2.0 con un tono de 1.0.

5.6. Latencia de audio

La latencia de audio es la demora que se produce cuando una señal de audio pasa por un sistema. Muchas clases de aplicaciones dependen de latencias cortas para lograr efectos de sonido en tiempo real.

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

Latencia de salida. Es el intervalo entre el momento en que una aplicación escribe un fotograma de datos codificados en PCM y el momento en que el sonido correspondiente se presenta en el entorno en un transductor integrado en el dispositivo o la señal sale del dispositivo a través de un puerto y se puede observar de forma externa.
Latencia de salida en frío. Es el tiempo que transcurre entre el inicio de una transmisión de salida y la hora 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. Es la latencia de salida para los fotogramas posteriores, después de que el dispositivo reproduce audio.
Latencia de entrada. Es el intervalo entre el momento en que el entorno presenta un sonido al dispositivo en un transductor integrado en el dispositivo o en que una señal ingresa al dispositivo a través de un puerto y el momento en que una aplicación lee el fotograma correspondiente de datos codificados en PCM.
Entrada perdida. Es la parte inicial de un indicador de entrada que no se puede usar o no está disponible.
Latencia de entrada en frío. Es el tiempo que transcurre entre el inicio de la transmisión y el momento en que se recibe el primer fotograma válido, cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
Latencia de entrada continua. Es la latencia de entrada para los fotogramas posteriores mientras el dispositivo captura audio.
latencia de ida y vuelta continua. Es la suma de la latencia de entrada continua, la latencia de salida continua y un período de búfer. El período de búfer permite que la app procese la señal y que mitigue la diferencia de fase entre los flujos de entrada y salida.
API de cola de búfer PCM de OpenSL ES Conjunto de APIs de OpenSL ES relacionadas con PCM dentro del NDK de Android.
API de audio nativa de AAudio Es el conjunto de APIs de AAudio dentro del NDK de Android.
Timestamp. Es un par que consta de una posición de fotograma relativa dentro de una transmisión y la hora estimada en la que ese fotograma ingresa o sale de la canalización de procesamiento de audio en el extremo asociado. Consulta también AudioTimestamp.
glitch. Interrupción temporal o valor de muestra incorrecto en la señal de audio, que suele deberse a un desbordamiento inferior del búfer para la salida, un desbordamiento superior del búfer para la entrada o cualquier otra fuente de ruido digital o analógico.
Desviación absoluta media (MAD). Es el promedio del valor absoluto de las desviaciones de la media para un conjunto de valores.
La latencia de toque a tono (TTL), según la medición de CTS Verifier, es el tiempo que transcurre entre el momento en que se toca la pantalla y el momento en que se escucha en la bocina un tono generado como resultado de ese toque. Este valor se promedia en 5 mediciones con la API de audio nativa de AAudio para la salida.
La latencia de ida y vuelta (RTL), según la medición del verificador de CTS, es la latencia continua media en 5 mediciones, medidas en una ruta de bucle invertido que devuelve la salida a la entrada, con la API de audio nativa de AAudio.

Las rutas de bucle invertido son las siguientes:
- Bocina/micrófono: Bocina integrada a micrófono integrado
- Analógico: Conector analógico de 3.5 mm y un adaptador de bucle.
- USB: Adaptador de USB a 3.5 mm y un adaptador de bucle de retorno, o bien una interfaz de audio USB y cables de bucle de retorno
FEATURE_AUDIO_LOW_LATENCY. Se declara la función android.hardware.audio.low_latency.
FEATURE_AUDIO_PRO. Se declara la función android.hardware.audio.pro.
MPC. Clase de rendimiento del contenido multimedia
Latencia del seguimiento de la cabeza. Es el tiempo que transcurre desde que la unidad de medición inercial (IMU) capta el movimiento de la cabeza hasta que los transductores de los auriculares detectan el cambio en el sonido causado por este movimiento.

Implementaciones de dispositivos:

[C-0-1] DEBE garantizar que, cuando una aplicación llame a android.media.AudioManager.setCommunicationDevice() con un device compatible (como auriculares con cable, bocinas o auriculares integrados, o auriculares USB), se invoque la devolución de llamada android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() con ese dispositivo de audio en un plazo de 1,500 ms después de que la llamada a setCommunicationDevice() devuelva true.

Si las implementaciones de dispositivos declaran android.hardware.audio.output, DEBEN cumplir o superar los siguientes requisitos:

[C-1-1] Se quitó el requisito en Android 15.
[C-1-2] Latencia de salida en frío de 500 milisegundos o menos.
[C-1-3] La apertura de un flujo de salida con AAudioStreamBuilder_openStream() DEBE tardar menos de 1,000 milisegundos.
[C-1-4] Las latencias de ida y vuelta calculadas en función de las marcas de tiempo de entrada y salida que devuelve AAudioStream_getTimestamp DEBEN estar dentro de los 200 ms de la latencia de ida y vuelta medida para AAUDIO_PERFORMANCE_MODE_NONE y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY en el caso de bocinas, auriculares con cable y auriculares inalámbricos.
[C-SR-1] Se quitó el requisito en Android 15.
[C-SR-2] Se quitó el requisito en Android 15.
[C-SR-4] Se quitó el requisito en Android 15.
[C-SR-5] Se quitó el requisito en Android 15.
[C-SR-6] Se quitó el requisito en Android 15.
[C-SR-7] Se quitó el requisito en Android 15.
[C-2-1] Se quitó el requisito en Android 15.

Si las implementaciones del dispositivo incluyen android.hardware.microphone, DEBEN satisfacer estos requisitos de audio de entrada:

[C-3-1] Se quitó el requisito en Android 15.
[C-3-2] Latencia de entrada en frío de 500 milisegundos o menos.
[C-3-3] La apertura de un flujo de entrada con AAudioStreamBuilder_openStream() DEBE tardar menos de 1,000 milisegundos.
[C-SR-8] Se quitó el requisito en Android 15.
[C-SR-11] Se quitó el requisito en Android 15.
[C-SR-12] Se quitó el requisito en Android 15.

En la siguiente tabla, se definen los requisitos de RTL para las implementaciones de dispositivos de mano, según se definen en el 2.2.1 que declara android.hardware.audio.output y android.hardware.microphone.

Dispositivo y declaraciones	RTL (ms)	MAD (ms)	Rutas de bucle invertido
Dispositivo manual	200	25	bocina/micrófono, analógico de 3.5 mm (si es compatible), USB (si es compatible)
MPC_C (17) y versiones posteriores	65	10	todas las rutas de datos admitidas
>= MPC_T (13) a MPC_B (16)	80	15	al menos una ruta de acceso
FEATURE_AUDIO_LOW_LATENCY	50	10	al menos una ruta de acceso
FEATURE_AUDIO_PRO	25	5	al menos una ruta de acceso
FEATURE_AUDIO_PRO	20	5	Analógica (si es compatible)
FEATURE_AUDIO_PRO	25	5	USB (si no se admite el formato analógico)

En la siguiente tabla, se definen los requisitos del TTL para las implementaciones de dispositivos de mano, según se define en 2.2.1, que declaran android.hardware.audio.output y android.hardware.microphone.

Dispositivo y declaraciones	TTL (ms)
Dispositivo manual	250
MPC_C (17) y versiones posteriores	65
>= MPC_T (13) a MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

Si las implementaciones de dispositivos incluyen compatibilidad con spatial audio con monitoreo de cabeza y declaran la marca PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, deben hacer lo siguiente:

[C-4-1] DEBE exhibir una latencia máxima de seguimiento de la cabeza a actualización de audio de 300 ms.

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 una implementación de dispositivo debe admitir, la implementación del dispositivo debe cumplir con lo siguiente:

[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 siguiente tabla de formatos de segmentos de medios, a través del protocolo de borrador de HTTP Live Streaming, versión 7.
[C-1-3] DEBE admitir los formatos de carga útil de RTSP correspondientes, como se muestra en la siguiente tabla de RTSP. Para ver las excepciones, consulta las notas al pie de la tabla en la sección 5.1.

Formatos de segmentos de medios

Formatos de segmentos	Referencias	Compatibilidad con códecs obligatoria
MPEG-2 Transport Stream	ISO 13818	Códecs de video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sección 5.1.8 para obtener detalles sobre H264 AVC, MPEG2-4 SP y MPEG-2. Códecs de audio: AAC Consulta la sección 5.1.3 para obtener detalles sobre el AAC y sus variantes.
AAC con encuadre ADTS y etiquetas ID3	ISO 13818-7	Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.
WebVTT	WebVTT

Formatos de segmentos

Referencias

Compatibilidad con códecs obligatoria

MPEG-2 Transport Stream

ISO 13818

Códecs de video:

H264 AVC
MPEG-4 SP
MPEG-2

Consulta la sección 5.1.8 para obtener detalles sobre H264 AVC, MPEG2-4 SP
y MPEG-2.

Códecs de audio:

Consulta la sección 5.1.3 para obtener detalles sobre el AAC y sus variantes.

AAC con encuadre ADTS y etiquetas ID3

ISO 13818-7

Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.

WebVTT

RTSP (RTP, SDP)

Nombre del perfil	Referencias	Compatibilidad con códecs obligatoria
H264 AVC	RFC 6184	Consulta la sección 5.1.8 para obtener detalles sobre H264 AVC.
MP4A-LATM	RFC 6416	Consulta la sección 5.1.3 para obtener detalles sobre el AAC y sus variantes.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulta la sección 5.1.8 para obtener detalles sobre H263.
H263-2000	RFC 4629	Consulta la sección 5.1.8 para obtener detalles sobre H263.
AMR	RFC 4867	Consulta la sección 5.1.3 para obtener detalles sobre AMR-NB.
AMR-WB	RFC 4867	Consulta la sección 5.1.3 para obtener detalles sobre AMR-WB.
MP4V-ES	RFC 6416	Consulta la sección 5.1.8 para obtener detalles sobre MPEG-4 SP.
mpeg4-generic	RFC 3640	Consulta la sección 5.1.3 para obtener detalles sobre el AAC y sus variantes.
MP2T	RFC 2250	Consulta MPEG-2 Transport Stream en HTTP Live Streaming para obtener más detalles.

5.8. Medios seguros

Si las implementaciones de dispositivos admiten la salida de video segura y son capaces de admitir superficies seguras, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la compatibilidad con Display.FLAG_SECURE.

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y admiten el protocolo de pantalla inalámbrica, deben cumplir con lo siguiente:

[C-2-1] DEBE proteger la vinculación con un mecanismo criptográficamente sólido, 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 compatibilidad con Display.FLAG_SECURE y con pantallas externas con cable, deben cumplir con lo siguiente:

[C-3-1] DEBE admitir HDCP 1.2 o una versión posterior para todas las pantallas externas conectadas a través de un puerto con cable accesible para el usuario.

5.9. Interfaz digital de 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, deben hacer lo siguiente:

[C-1-1] DEBE admitir MIDI a través de todos los transportes de hardware compatibles con MIDI para los que proporcionan conectividad genérica no MIDI, en los que dichos transportes son los siguientes:
- Modo de host USB, sección 7.7
- MIDI a través de Bluetooth de bajo consumo que actúa como central, sección 7.4.3
[C-1-2] DEBE admitir el transporte de software MIDI entre apps (dispositivos MIDI virtuales)
[C-1-3] DEBE incluir libamidi.so (compatibilidad nativa con MIDI)
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 admiten la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager, deben hacer lo siguiente:

[C-1-1] DEBE informar la compatibilidad con la función android.hardware.audio.low_latency.
[C-1-2] DEBE cumplir con los requisitos de latencia para FEATURE_AUDIO_PRO, como se define en la sección 5.6 Latencia de audio .
[C-1-3] DEBE incluir uno o más puertos USB que admitan el modo de host USB y el modo de periférico USB.
[C-1-4] DEBE informar la compatibilidad con la función android.software.midi.
[C-1-5] DEBE cumplir con los requisitos de latencia de audio USB con la API de audio nativo de 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.

Si las implementaciones de dispositivos incluyen un conector de audio de 3.5 mm con 4 conductores, deben cumplir con lo siguiente:

[C-2-2] DEBE cumplir con la sección Especificaciones del dispositivo móvil (conector) de la Especificación de auriculares con cable (v1.1).

Si las implementaciones de dispositivos omiten un conector de audio de 3.5 mm con 4 conductores y, en cambio, incluyen puertos USB que admiten el modo de host USB, deben cumplir con lo siguiente:

[C-3-1] DEBE implementar la clase de audio USB.

5.11. Captura para sin procesar

Android incluye compatibilidad con 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 ajuste predeterminado de grabación SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si las implementaciones de dispositivos pretenden admitir la fuente de audio sin procesar y ponerla a disposición de las apps de terceros, deben hacer lo siguiente:

[C-1-1] DEBE informar la compatibilidad a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] DEBE exhibir características de amplitud en función de la frecuencia aproximadamente planas en el rango de frecuencias medias: específicamente ±10 dB de 100 Hz a 7,000 Hz para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.
[C-1-3] DEBE mostrar niveles de amplitud en el rango de frecuencias bajas: específicamente, de ±20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencias medias para todos y cada uno de los micrófonos que se usen para grabar la fuente de audio sin procesar.
[C-1-4] DEBE mostrar niveles de amplitud en el rango de alta frecuencia: específicamente, de ±30 dB desde 7,000 Hz hasta 22 kHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos que se usaron para grabar la fuente de audio sin procesar.
[C-1-5] DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz reproducida a un nivel de presión acústica (SPL) de 94 dB produzca una respuesta con un valor RMS de 520 para muestras de 16 bits (o -36 dB a escala completa para muestras de punto flotante o de doble precisión) para todos y cada uno de los micrófonos que se usen para grabar la fuente de audio sin procesar.
[C-1-6] DEBE tener una relación señal/ruido (SNR) de 60 dB o más para todos y cada uno de los micrófonos que se usen 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 del ruido propio, ponderado según 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 SPL de 90 dB en todos y cada uno de los micrófonos que se usen para grabar la fuente de audio sin procesar.
[C-1-8] NO DEBE tener ningún otro procesamiento de señales (p.ej., control de ganancia automático, filtro de paso alto o cancelación de eco) en la ruta de acceso, excepto un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:
- [C-1-9] Si hay algún procesamiento de señales en la arquitectura por algún motivo, DEBE inhabilitarse y, de hecho, no debe introducir ninguna demora ni latencia adicional en la ruta de la señal.
- [C-1-10] El multiplicador de nivel, si bien se permite que esté en la ruta, NO DEBE introducir retardo o latencia en la ruta de la señal.

Todas las mediciones de SPL se realizan directamente junto al micrófono que se está probando. En el caso de las configuraciones con varios micrófonos, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone, pero no admiten la fuente de audio sin procesar, ocurrirá lo siguiente:

[C-2-1] DEBE devolver null para el método de la API de AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), para indicar correctamente la falta de compatibilidad.
[C-SR-1] se RECOMIENDAN ENCARECIDAMENTE para satisfacer la mayor cantidad posible de requisitos de la ruta de señal de la fuente de grabación sin procesar.

5.12. Video HDR

Android 13 admite las tecnologías HDR, como se describe en un próximo documento.

Formato de píxel

Si un decodificador de video anuncia compatibilidad con COLOR_FormatYUVP010, se aplican las siguientes condiciones:

[C-1-1] DEBE admitir el formato P010 para la lectura de la CPU (ImageReader, MediaImage, ByteBuffer). En Android 13, P010 se relaja para permitir un avance arbitrario para los planos Y y UV.
[C-1-2] El búfer de salida P010 DEBE poder ser muestreado por la GPU (cuando se asigna con el uso de GPU_SAMPLING). Esto permite la composición de la GPU y la asignación de tonos personalizada por parte de las apps.

Si un decodificador de video anuncia compatibilidad con COLOR_Format32bitABGR2101010, debe hacer lo siguiente:

[C-2-1] DEBE admitir el formato RGBA_1010102 para la superficie de salida y la salida ByteBuffer legible por la CPU.

Si un codificador de video anuncia compatibilidad con COLOR_FormatYUVP010, significa que cumple con los siguientes requisitos:

[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 video anuncia compatibilidad con COLOR_Format32bitABGR2101010, significa que cumple con los siguientes requisitos:

[C-4-1] DEBE admitir el formato RGBA_1010102 para la superficie de entrada y la entrada grabable por CPU (ImageWriter, ByteBuffer). Nota: Los codificadores NO necesitan convertir entre las distintas curvas de transferencia.

Requisitos de captura HDR

Para todos los codificadores de video que admiten perfiles HDR, las implementaciones de dispositivos deben cumplir con lo siguiente:

[C-5-1] NO DEBE suponer que los metadatos de HDR son precisos. Por ejemplo, el fotograma codificado podría tener píxeles más allá del nivel de luminancia máximo, o el histograma podría no ser representativo del fotograma.
DEBEN agregar metadatos dinámicos de HDR para generar metadatos estáticos de HDR adecuados para los flujos codificados y deben generarlos al final de cada sesión de codificación.

Si las implementaciones de dispositivos admiten la captura HDR con las APIs de CamcorderProfile, deben cumplir con los siguientes requisitos:

[C-6-1] DEBE admitir la captura de HDR también a través de las APIs 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 los metadatos de HDR (si corresponde a la tecnología HDR) en el archivo de video capturado. En el caso de AV1, HEVC y Dolby Vision, 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 de HDR a SDR en el decodificador predeterminado acelerado por hardware para el perfil capturado. En otras palabras, si un dispositivo puede capturar HEVC HDR10+, el decodificador HEVC predeterminado DEBE poder decodificar el flujo capturado en SDR.

Requisitos de edición de HDR

Si las implementaciones de dispositivos incluyen codificadores de video que admiten la edición de HDR, deben cumplir con los siguientes requisitos:

DEBE usar una latencia mínima para generar los metadatos de HDR cuando no estén presentes y DEBE controlar con elegancia las 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 y el histograma reales del fotograma).

Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, esos códecs deben cumplir con los siguientes requisitos:

[C-7-1] DEBE admitir al menos un perfil HDR.
[C-7-2] DEBE admitir FEATURE_HdrEditing para todos los perfiles HDR que anuncie ese códec. En otras palabras, DEBE admitir la generación de metadatos HDR cuando no estén presentes para todos los perfiles HDR admitidos que usen metadatos HDR.
[C-7-3] DEBE admitir los siguientes formatos de entrada del codificador de video que conservan por completo el HDR decodificado:
- RGBA_1010102 (ya en la curva de transferencia objetivo) para la superficie de entrada y ByteBuffer, y DEBE anunciar la compatibilidad con COLOR_Format32bitABGR2101010.

Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, el dispositivo debe cumplir con lo siguiente:

[C-7-4] DEBE anunciar la compatibilidad con la extensión EXT_YUV_target de OpenGL.

Requisitos de la pantalla HDR

Si las implementaciones de dispositivos reciben contenido de búfer codificado con ADATASPACE_TRANSFER_HLG y ese contenido se envía a la pantalla a través de SurfaceControl.Transaction#setBuffer, deben hacer lo siguiente:

[C-8-1] DEBE seguir la recomendación de blancos gráficos en BT. 2408-7 y solo mostrar ese contenido para que sea, como máximo, 4.926 veces mayor que el contenido SDR.

6. Compatibilidad de las opciones y herramientas para desarrolladores

6.1. Herramientas para desarrolladores

Implementaciones de dispositivos:

[C-0-1] DEBE admitir las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.
Android Debug Bridge (adb)
[C-0-2] DEBE admitir adb según se documenta en el SDK de Android y los comandos de shell que se proporcionan en AOSP, que pueden usar los desarrolladores de apps, incluidos dumpsys, cmd stats y Simpleperf.
[C-0-11] DEBE admitir el comando de shell cmd testharness. Las implementaciones de dispositivos que se actualizan desde una versión anterior de Android sin un bloque de datos persistente PUEDEN estar exentas del requisito C-0-11.
[C-0-3] NO DEBE alterar el formato ni el contenido de los eventos del sistema del dispositivo (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados a través del comando dumpsys.
[C-0-10] DEBE registrar, sin omisiones, y hacer que los siguientes eventos estén disponibles y sean accesibles para el comando de shell cmd stats y la clase de la API del sistema StatsManager.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] El daemon de adb del dispositivo DEBE estar inactivo de forma predeterminada, y DEBE haber un mecanismo accesible para el usuario para activar Android Debug Bridge.
[C-0-5] DEBE admitir adb seguro. Android incluye compatibilidad con 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 anfitrión. Más precisamente, sucederá lo siguiente:

Si las implementaciones de dispositivos sin puerto USB admiten el modo periférico, deben cumplir con lo siguiente:

[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 con el protocolo adb.

Si las implementaciones de dispositivos admiten conexiones adb a una máquina anfitrión a través de Wi-Fi o Ethernet, deben cumplir con los siguientes requisitos:

[C-4-1] DEBE hacer que el método AdbManager#isAdbWifiSupported() devuelva true.

Si las implementaciones de dispositivos admiten conexiones adb a una máquina anfitrión a través de Wi-Fi o Ethernet, y si incluyen al menos una cámara, deben cumplir con lo siguiente:

[C-5-1] DEBE hacer que el método AdbManager#isAdbWifiQrSupported() devuelva true.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] DEBE admitir todas las funciones de ddms según se documentan 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.
Perfetto
- [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE exponer un archivo binario /system/bin/perfetto al usuario de la shell que cumpla con la documentación de Perfetto.
- [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que el archivo binario de 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 objeto binario de Perfetto escriba como resultado un seguimiento de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE que proporcionen, a través del objeto binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
Low Memory Killer
- [C-0-12] DEBE escribir un átomo LMK_KILL_OCCURRED_FIELD_NUMBER en el registro de statsd cuando el Low Memory Killer finaliza una app.
Modo de agente de prueba

Si las implementaciones de dispositivos admiten el comando de shell cmd testharness y ejecutan cmd testharness enable, hacen lo siguiente:
- [C-2-1] DEBE devolver true para ActivityManager.isRunningInUserTestHarness()
- [C-2-2] DEBE implementar el modo de agente de prueba como se describe en la documentación del modo de agente de prueba.
Información del 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 agregados de la GPU que devuelve el punto de seguimiento del kernel power/gpu_work_period, o bien no mostrar datos si no se admite el punto de seguimiento. La implementación del AOSP es frameworks/native/services/gpuservice/gpuwork/.

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o una versión posterior a través de las marcas de funciones android.hardware.vulkan.version, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el desarrollador de la app habilite o inhabilite las capas de depuración de GPU.
[C-1-2] DEBE, cuando las capas de depuración de la GPU están habilitadas, enumerar las capas en las bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte del paquete de la plataforma o la aplicación) que se encuentran en el directorio base de las aplicaciones depurables para admitir los métodos de API vkEnumerateInstanceLayerProperties() y vkCreateInstance().

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.gpu_frequency como true, hacen lo siguiente:

[C-6-1] DEBE informar un punto de seguimiento de frecuencia de GPU como se especifica en el formato power/gpu_frequency, según se define en power.proto.

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.gpu_counters como true, hacen lo siguiente:

[C-7-1] DEBE proporcionar un productor de datos de Perfetto para una fuente de datos llamada gpu.counters, que se puede consultar con perfetto --query.
[C-7-2] DEBE informar las descripciones de los contadores de GPU de conformidad con el proto del paquete de seguimiento del contador de GPU.
[C-7-3] DEBE informar valores conformes para los contadores de GPU del dispositivo según el proto del paquete de registro de contador de GPU.
[C-7-4] DEBE registrar las descripciones de texto para todos los contadores de GPU habilitados sin marca de tiempo en el registro de Perfetto.
[C-7-6] DEBE proporcionar un conjunto predeterminado no vacío de contadores de rendimiento de GPU para la generación de perfiles, como se especifica en GpuCounterSpec#select_by_default.
- DEBE ser posible habilitar todos estos contadores predeterminados al mismo tiempo.
- TODOS deben emitir valores a Perfetto cuando estén habilitados.
[C-7-7] DEBE reflejar el uso de GPU para al menos un contador seleccionado de forma predeterminada, con GpuCounterSpec#select_by_default.

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.gpu_counters.period como true, hacen lo siguiente:

[C-8-1] DEBE respetar counter_period_ns para la frecuencia de muestreo de los contadores de GPU. La tasa de muestreo admitida DEBE ser de 1 ms o más rápida.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que admitan una frecuencia de muestreo de 0.2 ms o más rápida.

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.gpu_counters.groups como true, hacen lo siguiente:

[C-9-1] DEBE tener al menos un contador en cada uno de los siguientes grupos de contadores de GPU, como se especifica en GpuCounterSpec: COMPUTE, FRAGMENTS, MEMORY, PRIMITIVES y VERTICES.

Si las implementaciones de dispositivos establecen las propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.gpu_counters.groups en true, y el dispositivo admite el trazado de rayos, se cumplen las siguientes condiciones:

[C-10-1] DEBE tener un contador en el grupo RAY_TRACING.

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.gpu_counters.zeroes_optimization como true, hacen lo siguiente:
[C-11-1] Dentro de la misma sesión de registro de Perfetto, los contadores de GPU SOLO DEBEN informar valores cero si el valor informado anterior o siguiente es distinto de cero.

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.render_stages como true, hacen lo siguiente:

[C-12-1] DEBE proporcionar un productor de datos de Perfetto para una fuente de datos llamada gpu.renderstages, que se puede consultar con perfetto --query.
[C-12-2] DEBE informar valores conformes para las etapas de renderización de la GPU según el proto del evento de etapa de renderización de la GPU.

Si las implementaciones de dispositivos configuran ambas propiedades del sistema graphics.gpu.profiler.support y graphics.gpu.profiler.support.render_stages.queue_submit como true, hacen lo siguiente:

[C-13-1] Para cada llamada de envío de la cola de Vulkan, el controlador de Vulkan DEBE emitir un evento de registro de Perfetto según la especificación del mensaje de evento de la API de Vulkan.
- Este evento DEBE contener un submission_id único y monótonamente creciente que coincida con el submission_id del evento de etapa de renderización de GPU correspondiente.

6.2. Opciones para desarrolladores

Android incluye compatibilidad para que los desarrolladores configuren los parámetros relacionados con el desarrollo de aplicaciones.

Las implementaciones de dispositivos DEBEN proporcionar una experiencia coherente para las Opciones para desarrolladores, de la siguiente manera:

[C-0-1] DEBE cumplir con el intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar la configuración relacionada con el desarrollo de aplicaciones. La implementación de Android upstream oculta el menú Opciones para desarrolladores de forma predeterminada y permite que los usuarios lo inicien después de presionar siete (7) veces el elemento de menú Configuración > Acerca del dispositivo > Número de compilación.
[C-0-2] MUST hide Developer Options by default.
[C-0-3] DEBE proporcionar un mecanismo claro que no dé un trato preferencial a una app de terceros en comparación con otra para habilitar las Opciones para desarrolladores. DEBE proporcionar un documento o sitio web visible públicamente que describa cómo habilitar las Opciones para desarrolladores. Se DEBE poder vincular este documento o sitio web desde los documentos del SDK de Android.
DEBE mostrar una notificación visual continua al usuario cuando las Opciones para desarrolladores estén habilitadas y la seguridad del usuario sea motivo de preocupación.
Es POSIBLE que se limite temporalmente el acceso al menú Opciones para desarrolladores, ya sea ocultándolo visualmente o inhabilitándolo, para evitar distracciones en situaciones en las que la seguridad del usuario sea una preocupación.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware en particular que tiene una API correspondiente para desarrolladores externos, se aplican las siguientes condiciones:

[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 del SDK interactúa con un componente de hardware que se indica como opcional y la implementación del dispositivo no posee ese componente, sucede lo siguiente:

[C-0-2] AÚN se deben presentar las definiciones de clase completas (como se documentan en el SDK) para las APIs de componentes.
[C-0-3] Los comportamientos de la API DEBEN implementarse como no-ops de alguna manera razonable.
[C-0-4] Los métodos de la API DEBEN devolver valores nulos cuando lo permita la documentación del SDK.
[C-0-5] Los métodos de la API DEBEN devolver implementaciones no op de clases en las que la documentación del SDK no permite valores nulos.
[C-0-6] Los métodos de la API NO DEBEN arrojar excepciones que no estén documentadas en la documentación del SDK.
[C-0-7] Las implementaciones de dispositivos DEBEN informar de forma coherente la 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 una situación en la que se aplican estos requisitos es la API de telefonía: incluso en dispositivos que no son teléfonos, estas APIs se deben implementar como no-ops razonables.

7.1. Pantalla y gráficos

Android incluye funciones que ajustan automáticamente los recursos de la aplicación y los diseños de la IU de forma adecuada para el dispositivo, lo que garantiza que las aplicaciones de terceros se ejecuten bien en una variedad de pantallas y configuraciones de hardware. Una pantalla compatible con Android es una pantalla que implementa todos los comportamientos y las APIs que se describen en Android Developers - Screen compatibility overview, esta sección (7.1) y sus subsecciones, así como cualquier comportamiento adicional específico del tipo de dispositivo que se documenta en la sección 2 de este CDD.

Implementaciones de dispositivos:

[C-0-1] DEBE, de forma predeterminada, renderizar aplicaciones de terceros solo en pantallas compatibles con Android.

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

Tamaño diagonal físico. Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
density Es la cantidad de píxeles que abarca un tramo lineal horizontal o vertical de 1", expresada como píxeles por pulgada (ppi o dpi). Cuando se indican los valores de PPI y DPI, ambos valores deben estar dentro del rango indicado.
relación de aspecto. Es la proporción de los píxeles de la dimensión más larga con respecto a la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480 × 854 píxeles tendría una relación de aspecto de 854 / 480 = 1.779, o aproximadamente "16:9".
píxel independiente de la densidad (dp). Es una unidad de píxel virtual normalizada para una densidad de pantalla de 160. Para una densidad determinada d y una cantidad de píxeles p, la cantidad de píxeles independientes de la densidad dp se calcula de la siguiente manera: dp = (160 / d) * p.

7.1.1. Configuración de pantalla

7.1.1.1. Tamaño y forma de la pantalla

El framework de IU 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 de 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, según se define en la documentación del SDK de Android. Específicamente, las implementaciones de dispositivos DEBEN informar las dimensiones correctas de la pantalla en píxeles lógicos independientes de la densidad (dp) como se indica a continuación:
- Los dispositivos con el parámetro Configuration.uiMode establecido en cualquier valor que no sea UI_MODE_TYPE_WATCH y que informen un tamaño de small para el parámetro Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
- Los dispositivos que informan un tamaño de normal para el Configuration.screenLayout DEBEN tener al menos 480 dp × 320 dp.
- Los dispositivos que informan un tamaño de large para el Configuration.screenLayout DEBEN tener al menos 640 dp x 480 dp.
- Los dispositivos que informan un tamaño de xlarge para el Configuration.screenLayout DEBEN tener al menos 960 dp x 720 dp.
[C-0-2] DEBE respetar correctamente la compatibilidad declarada de las aplicaciones con los 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 capaces de la configuración de tamaño UI_MODE_TYPE_NORMAL y usan pantallas físicas con esquinas redondeadas para renderizar estas pantallas, deben cumplir con lo siguiente:

[C-1-1] DEBE garantizar que se cumpla al menos uno de los siguientes requisitos para cada una de esas pantallas:
- El radio de las esquinas redondeadas es menor o igual a 38 dp.
- Cuando se ancla un cuadro de 18 dp por 18 dp en cada esquina de la pantalla lógica, se puede ver al menos un píxel de cada cuadro en la pantalla.
DEBE incluir la opción para que el usuario cambie al modo de visualización con las esquinas rectangulares.

Si las implementaciones de dispositivos solo son capaces de realizar la configuración del teclado NO_KEYS y tienen la intención de informar la compatibilidad con la configuración del modo de IU UI_MODE_TYPE_NORMAL, deben hacer lo siguiente:

[C-4-1] DEBE tener un tamaño de diseño, sin incluir los cortes de pantalla, de al menos 596 dp x 384 dp o más.

Para obtener detalles sobre la implementación correcta de las APIs de sidecar o de extensión, consulta la documentación pública de WindowManager de Jetpack.

[C-4-1] Se quitó el requisito en Android 15.

7.1.1.2. Relación de aspecto de la pantalla

Esta sección se quitó en Android 14.

7.1.1.3. Densidad de la pantalla

El framework de la IU de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientar los recursos de la aplicación.

Implementaciones de dispositivos:

[C-0-1] DEBE informar una de las densidades del framework de Android que se enumeran en DisplayMetrics a través de la API de DENSITY_DEVICE_STABLE, y este valor debe ser estático para cada pantalla física. Sin embargo, el dispositivo PUEDE informar un DisplayMetrics.density diferente según los cambios de configuración de la pantalla que realice el usuario (por ejemplo, el tamaño de visualización) después del arranque inicial.
DEBE definir la densidad estándar del framework de Android que sea numéricamente más cercana a la densidad física de la pantalla o un valor que se correlacionaría con las mismas mediciones equivalentes del campo de visión angular de un dispositivo portátil.

Si las implementaciones de dispositivos proporcionan una opción para cambiar el tamaño de visualización del dispositivo, deben cumplir con lo siguiente:

[C-1-1] NO DEBE escalar la pantalla a más de 1.5 veces DENSITY_DEVICE_STABLE ni producir una dimensión de pantalla mínima efectiva inferior a 320 dp (equivalente al calificador de recursos sw320dp), lo que ocurra primero.
[C-1-2] NO DEBE reducir la pantalla a menos de 0.85 veces el tamaño del DENSITY_DEVICE_STABLE.
Para garantizar una buena usabilidad y tamaños de fuente coherentes, se RECOMIENDA proporcionar el siguiente ajuste de escala de las opciones de pantalla nativa (sin incumplir los límites especificados anteriormente):
- Pequeño: 0.85x
- Valor predeterminado: 1x (escala de pantalla nativa)
- Grande: 1.15x
- Más grande: 1.3 veces
- Más grande 1.45x

7.1.2. Métricas de visualización

Si las implementaciones de dispositivos incluyen pantallas compatibles con Android o salida de video a pantallas compatibles con Android, deben cumplir con lo siguiente:

[C-1-1] DEBE informar los valores correctos para todas las métricas de pantalla compatibles con Android que se definen en la API de android.util.DisplayMetrics.

Si las implementaciones de dispositivos no incluyen una pantalla integrada o salida de video, deben cumplir con lo siguiente:

[C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android, como se define en la API de android.util.DisplayMetrics para el view.Display predeterminado emulado.

7.1.3. Orientación de pantalla

Implementaciones de dispositivos:

[C-0-1] DEBE informar qué orientaciones de pantalla admite (android.hardware.screen.portrait 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 una televisión o una laptop, SOLO DEBE informar android.hardware.screen.landscape.
[C-0-2] DEBE informar el valor correcto de la orientación actual del dispositivo, siempre que se consulte a través de ßandroid.content.res.Configuration.orientation, android.view.Display.getOrientation() o cualquier otra API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla, deben cumplir con lo siguiente:

[C-1-1] Se quitó el requisito en Android 16.
[C-1-2] NO DEBE cambiar el tamaño o la densidad de la pantalla informados cuando se cambia la orientación.
La MAY puede seleccionar la orientación vertical u horizontal como 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 compatibles de OpenGL ES (1.1, 2.0, 3.0, 3.1 y 3.2) a través de las APIs administradas (por ejemplo, con el método GLES10.getString()) y las APIs nativas.
[C-0-2] DEBE incluir la compatibilidad con todas las APIs administradas y nativas correspondientes para cada versión de OpenGL ES que se haya identificado como compatible.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir OpenGL ES 1.1, 2.0, 3.0 y 3.1, tal como se describe y detalla en la documentación del SDK de Android.
[C-SR-1] Se quitó el requisito en Android 15.
DEBE admitir OpenGL ES 3.2.

Las pruebas de dEQP de OpenGL ES se dividen en varias listas de pruebas, cada una con un número de versión o fecha asociado. Se encuentran en el árbol de fuentes de Android en external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Un dispositivo que admite OpenGL ES en un nivel autoinformado indica que puede superar las pruebas de dEQP en todas las listas de pruebas de este nivel y anteriores.

Si las implementaciones de dispositivos admiten alguna de las versiones de OpenGL ES, deben cumplir con lo siguiente:

[C-2-1] DEBE informar a través de las APIs administradas y nativas de OpenGL ES cualquier otra extensión de OpenGL ES que haya implementado y, a la inversa, NO DEBE informar cadenas de extensión que no admita.
[C-2-2] DEBE admitir las extensiones 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, EGL_ANDROID_recordable y EGL_ANDROID_GLES_layers.
[C-2-3] DEBE informar la versión máxima de las pruebas de dEQP de OpenGL ES admitidas a través de la marca de función android.software.opengles.deqp.level.
[C-2-4] DEBE admitir al menos la versión 132383489 (del 1 de marzo de 2020), como se indica en la marca de función android.software.opengles.deqp.level.
[C-2-5] DEBE aprobar todas las pruebas de dEQP de OpenGL ES en las listas de pruebas entre la versión 132383489 y la versión especificada en la marca de función android.software.opengles.deqp.level, para cada versión de OpenGL ES compatible.
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que admitan 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 admita, que suele ser 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, deben cumplir con lo siguiente:

[C-3-1] DEBE exportar los símbolos de función correspondientes para estas versiones, además de los símbolos de función de OpenGL ES 2.0 en la biblioteca libGLESv2.so.
[C-SR-3] Se RECOMIENDAN ENCARECIDAMENTE para admitir la extensión OES_EGL_image_external_essl3.

Si las implementaciones de dispositivos admiten OpenGL ES 3.2, deben cumplir con lo siguiente:

[C-4-1] DEBE admitir el Android Extension Pack para OpenGL ES en su totalidad.

Si las implementaciones de dispositivos admiten el Android Extension Pack de OpenGL ES en su totalidad, cumplen con los siguientes requisitos:

[C-5-1] DEBE identificar la compatibilidad a través de la marca de función android.hardware.opengles.aep.

Si las implementaciones de dispositivos exponen compatibilidad con la extensión EGL_KHR_mutable_render_buffer, deben cumplir con lo siguiente:

[C-6-1] TAMBIÉN debe admitir la extensión EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2. Vulkan

Android incluye compatibilidad con Vulkan, una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento.

Si las implementaciones de dispositivos admiten OpenGL ES 3.1, deben cumplir con lo siguiente:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE incluir compatibilidad con Vulkan 1.3.
[C-4-1] NO DEBE admitir una versión de variante de Vulkan (es decir, la parte de variante de la versión principal de Vulkan DEBE ser cero).

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que incluyan compatibilidad con Vulkan 1.3.

Las pruebas de dEQP de Vulkan se particionan en varias listas de pruebas, cada una con una fecha o versión asociada. Se encuentran en el árbol de fuentes de Android en external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un dispositivo que admite Vulkan en un nivel autoinformado indica que puede pasar las pruebas de dEQP en todas las listas de pruebas de este nivel y los anteriores.

Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE informar el valor entero correcto con los parámetros de configuració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 por completo las APIs de Vulkan 1.1 para cada VkPhysicalDevice enumerado.
[C-1-4] DEBE enumerar las capas, incluidas en las bibliotecas nativas denominadas libVkLayer*.so en el directorio de bibliotecas nativas del paquete de la aplicación, a través de las APIs nativas de Vulkan vkEnumerateInstanceLayerProperties() y vkEnumerateDeviceLayerProperties().

[C-1-5] NO DEBE enumerar las capas proporcionadas por bibliotecas fuera del paquete de la aplicación ni proporcionar otras formas de rastrear o interceptar la API de Vulkan, a menos que la aplicación tenga el atributo android:debuggable establecido como true o los metadatos com.android.graphics.injectLayers.enable establecidos como true , excepto para las capas de OEM y de la plataforma según la documentación de Implement Vulkan.

[C-1-6] DEBE informar todas las cadenas de extensión que admite a través de las APIs nativas de Vulkan y, a la inversa, NO DEBE informar las cadenas de extensión que no admite correctamente.

[C-1-7] DEBE admitir las siguientes extensiones:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] DEBE informar la versión máxima de las pruebas de dEQP de Vulkan compatibles a través de la marca de función android.software.vulkan.deqp.level.
[C-1-9] DEBE admitir al menos la versión 132317953 (a partir del 1 de marzo de 2019), como se indica en la marca de función android.software.vulkan.deqp.level.
[C-1-10] DEBE aprobar todas las pruebas de dEQP de Vulkan en las listas de pruebas entre la versión 132317953 y la versión especificada en la marca 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 que admitan las siguientes extensiones:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] NO DEBE enumerar la compatibilidad con la extensión VK_KHR_performance_query.
[C-SR-4] Se RECOMIENDA ENCARECIDAMENTE satisfacer los requisitos especificados por el perfil de Android Baseline 2022.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE que admitan VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory y VK_EXT_global_priority.
[C-SR-6] Se RECOMIENDA ENCARECIDAMENTE usar SkiaVk con HWUI.

Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan, deben cumplir con los siguientes requisitos:

[C-SR-8] Se RECOMIENDA ENCARECIDAMENTE no modificar el cargador de Vulkan.
[C-1-14] NO DEBE enumerar las extensiones de dispositivos Vulkan de tipo "KHR", "GOOGLE" o "ANDROID", a menos que estas extensiones se incluyan en la marca de función android.software.vulkan.deqp.level.

Si las implementaciones de dispositivos no incluyen compatibilidad con Vulkan 1.0, sucede lo siguiente:

[C-2-1] NO DEBE declarar ninguna de las marcas de funciones de Vulkan (p.ej., 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 de dispositivos incluyen compatibilidad con Vulkan 1.1 y declaran cualquiera de las marcas de funciones de Vulkan que se describen aquí o una versión posterior, deben cumplir con lo siguiente:

[C-3-1] DEBE exponer la compatibilidad con los tipos de identificadores y semáforos externos SYNC_FD, y la extensión VK_ANDROID_external_memory_android_hardware_buffer.
[C-SR-7] SE RECOMIENDA ENCARECIDAMENTE que la extensión VK_KHR_external_fence_fd esté disponible para aplicaciones de terceros y que se habilite la aplicación para exportar la carga útil de la zona de exclusión y, también, importar la carga útil de la zona de exclusión desde descriptores de archivos POSIX, como se describe aquí.

7.1.4.3. RenderScript

Implementaciones de dispositivos:

[C-0-1] DEBE 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 a nivel de la aplicación, la actividad, la ventana o la vista a través del uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas directas a la API.

Implementaciones de dispositivos:

[C-0-1] DEBE habilitar la aceleración de hardware de forma predeterminada y DEBE inhabilitarla si el desarrollador lo solicita configurando android:hardwareAccelerated="false" o inhabilitando la aceleración de hardware directamente a través de las APIs de Android View.
[C-0-2] DEBE exhibir un comportamiento coherente con la documentación del SDK de Android sobre la aceleración de hardware.

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas de OpenGL ES aceleradas por hardware como destinos de procesamiento en una jerarquía de IU.

Implementaciones de dispositivos:

[C-0-3] DEBE admitir la API de TextureView y DEBE exhibir un comportamiento coherente con la implementación de Android upstream.

7.1.4.5. Pantallas con amplia gama de colores

Si las implementaciones de dispositivos indican que admiten pantallas de amplia gama a través de Configuration.isScreenWideColorGamut(), deben cumplir con lo siguiente:

[C-1-1] DEBE tener una pantalla calibrada en color.
[C-1-2] DEBE tener una pantalla cuya gama cubra por completo la gama de colores sRGB en el espacio CIE 1931 xyY.
[C-1-3] DEBE tener una pantalla cuyo gamut 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 y registrarlo correctamente.
[C-1-5] DEBE anunciar la compatibilidad con las extensiones 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 y EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR-1] SE RECOMIENDAN ENCARECIDAMENTE para admitir GL_EXT_sRGB.

Por el contrario, si las implementaciones de dispositivos no admiten pantallas de amplia gama, deben cumplir con lo siguiente:

[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 con aplicaciones heredadas

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

7.1.6. Tecnología de pantalla

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

Todas las pantallas compatibles con Android de la implementación de un dispositivo:

[C-0-1] DEBE poder renderizar gráficos en color de 16 bits.
DEBE admitir pantallas capaces de mostrar gráficos en color de 24 bits.
[C-0-2] DEBE poder 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 en píxeles DEBE ser casi cuadrada (1.0) con una tolerancia del 10 al 15%.

7.1.7. Pantallas secundarias

Android incluye compatibilidad con pantallas secundarias compatibles con Android para habilitar las capacidades de uso compartido de contenido multimedia y las APIs para desarrolladores para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa a través de una conexión con cable, inalámbrica o una conexión de pantalla adicional integrada, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar el servicio del sistema y la API de DisplayManager como se describe en la documentación del SDK de Android.

7.2. Dispositivos de entrada

Implementaciones de dispositivos:

[C-0-1] DEBE incluir un mecanismo de entrada, como una pantalla táctil o una navegación sin contacto, para navegar entre los elementos de la IU.

7.2.1. Teclado

Si las implementaciones de dispositivos incluyen compatibilidad con aplicaciones de Editor de métodos de entrada (IME) de terceros, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar la marca de función android.software.input_methods.
[C-1-2] DEBE implementar por completo Input Management Framework
[C-1-3] DEBE tener un teclado en pantalla preinstalado.

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 del teclado en pantalla.
PUEDE incluir un teclado de hardware.

7.2.2. Navegación no táctil

Android incluye compatibilidad con el pad direccional, la bola de seguimiento y la rueda como mecanismos para la navegación sin contacto.

Implementaciones de dispositivos:

[C-0-1] DEBE informar el valor correcto para android.content.res.Configuration.navigation.

Si las implementaciones de dispositivos no tienen navegaciones sin contacto, sucede lo siguiente:

[C-1-1] DEBE proporcionar un mecanismo alternativo razonable de interfaz de usuario para la selección y edición de texto, compatible con los motores de administración de entrada. La implementación de código abierto de Android upstream incluye un mecanismo de selección adecuado para usar con dispositivos que no tienen entradas de navegación táctil.

7.2.3. Teclas de navegación

Las funciones Inicio, Recientes y Atrás, que suelen proporcionarse 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 una indicación visual para el usuario que permita lanzar aplicaciones instaladas que tengan una Activity con el valor <intent-filter> establecido en ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para las implementaciones de dispositivos de televisión. La función Inicio DEBE ser el mecanismo para esta capacidad de uso del usuario.
DEBE proporcionar botones para las funciones Recientes y Atrás.

Si se proporcionan las funciones de Inicio, Recientes o Atrás, se cumplen las siguientes condiciones:

[C-1-1] DEBE ser accesible con una sola acción (p.ej., presión, doble clic o gesto) cuando cualquiera de ellas sea accesible.
[C-1-2] DEBE proporcionar una indicación clara de qué acción única activaría cada función. Algunos ejemplos de este tipo de indicación son 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 paso a paso durante la experiencia de configuración inicial.

Implementaciones de dispositivos:

[C-SR-1] se RECOMIENDA ENCARECIDAMENTE que no proporcione el mecanismo de entrada para la función de menú, ya que se dejó de usar 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 de evitar que se ejecute la función de navegación (p. ej., volver a la casa, volver atrás, etcétera) si el deslizamiento no se suelta después de un umbral determinado.

Si las implementaciones de dispositivos proporcionan la función de menú, deben cumplir con lo siguiente:

[C-2-1] DEBE mostrar el botón de menú ampliado de acciones siempre que la ventana emergente del menú ampliado de acciones no esté vacía y la barra de acciones esté visible.
[C-2-2] NO DEBE modificar la posición de la ventana emergente de menú ampliado de acciones que se muestra cuando se selecciona el botón de menú ampliado en la barra de acciones, pero PUEDE renderizar la ventana emergente de menú ampliado de acciones en una posición modificada en la pantalla cuando se muestra al seleccionar la función Menú.

Si las implementaciones de dispositivos no proporcionan la función de menú, para garantizar la retrocompatibilidad, deben hacer lo siguiente:

[C-3-1] DEBE hacer que la función de menú esté disponible para las aplicaciones cuando targetSdkVersion sea inferior a 10, ya sea a través de un botón físico, una tecla de software o gestos. Se debe poder acceder a esta función de menú, a menos que se oculte junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función de Asistencia, deben cumplir con lo siguiente:

[C-4-1] DEBE hacer que la función de Asistencia sea accesible con una sola acción (p.ej., un toque, un doble clic o un gesto) cuando se pueda acceder a otras teclas de navegación.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE usar la función de mantener presionado en INICIO como esta interacción designada.

Si las implementaciones de dispositivos usan una parte distinta de la pantalla para mostrar las teclas de navegación, deben cumplir con lo siguiente:

[C-5-1] Las teclas de navegación DEBEN usar una parte distinta de la pantalla, que no esté disponible para las aplicaciones, y NO DEBEN obstruir ni interferir de ninguna otra manera 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 los parámetros establecidos por la app a través del método de la API de View.setSystemUiVisibility(), de modo que esta porción distinta de la pantalla (también conocida como barra de navegación) se oculte correctamente, como se documenta en el SDK.

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

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() SOLO se debe usar para informar el área de reconocimiento de gestos de la pantalla principal.
[C-6-2] Los gestos que comienzan dentro de un rectángulo de exclusión proporcionado por la aplicación en primer plano a través de View#setSystemGestureExclusionRects(), pero fuera de WindowInsets#getMandatorySystemGestureInsets(), NO SE DEBEN interceptar 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 app en primer plano un evento MotionEvent.ACTION_CANCEL una vez que se comiencen a interceptar los toques para un gesto del sistema, si anteriormente se envió a la app en primer plano un evento MotionEvent.ACTION_DOWN.
[C-6-4] DEBE proporcionar una indicación visual para que el usuario cambie a una navegación en pantalla basada en botones (por ejemplo, en Configuración).
DEBE proporcionar la función de Inicio como un deslizamiento hacia arriba desde el borde inferior de la orientación actual de la pantalla.
DEBE proporcionar la función Recientes como un deslizamiento hacia arriba y mantener antes de soltar, desde la misma área que el gesto de Inicio.
Los gestos que comienzan dentro de WindowInsets#getMandatorySystemGestureInsets() NO DEBEN verse afectados por los rectángulos de exclusión que proporciona la aplicación en 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, haz lo siguiente:

[C-7-1] La función de navegación DEBE ser Atrás y proporcionarse como un deslizamiento desde los bordes izquierdo y derecho de la orientación actual de la pantalla.
[C-7-2] Si se proporcionan paneles del sistema personalizados que se pueden deslizar en los bordes izquierdo o derecho, DEBEN colocarse en el tercio superior de la pantalla con una indicación visual clara y persistente de que arrastrar hacia adentro invocaría los paneles mencionados anteriormente y, por lo tanto, no volvería. Un usuario PUEDE configurar un panel del sistema de modo que se ubique por debajo del 1/3 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 app en primer plano tiene establecidos los parámetros View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, deslizar el dedo desde los bordes DEBE comportarse como se implementó en AOSP, lo que se documenta en el SDK.
[C-7-4] Cuando la app en primer plano tiene establecidos los parámetros View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, los paneles del sistema personalizados que se pueden deslizar DEBEN ocultarse hasta que el usuario muestre o quite el atenuado de las barras del sistema (es decir, la barra de navegación y la de estado) como se implementa en el AOSP.

Si se proporciona la función de navegación hacia atrás y el usuario cancela el gesto de atrás, sucede lo siguiente:

[C-8-1] Se DEBE llamar a OnBackInvokedCallback.onBackCancelled().
[C-8-2] NO se debe llamar a OnBackInvokedCallback.onBackInvoked().
[C-8-3] NO se debe enviar el evento KEYCODE_BACK.

Si se proporciona la función de navegación hacia atrás, pero la aplicación en primer plano NO tiene un OnBackInvokedCallback registrado, sucede lo siguiente:

El sistema DEBE proporcionar una animación para la aplicación en primer plano que sugiera que el usuario está volviendo, como se proporciona en el AOSP.

Si las implementaciones de dispositivos proporcionan compatibilidad con la API del sistema setNavBarMode para permitir que cualquier app del sistema con permiso de android.permission.STATUS_BAR establezca el modo de la barra de navegación, deben hacer lo siguiente:

[C-9-1] DEBE proporcionar compatibilidad con íconos aptos para niños o navegación basada en botones, como se proporciona en el código del AOSP.

7.2.4. Entrada táctil

Android incluye compatibilidad con una variedad de sistemas de entrada de puntero, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil simulada. Las implementaciones de dispositivos basadas en pantallas táctiles se asocian con una pantalla de modo que el usuario tenga la impresión de manipular directamente los elementos en la pantalla. Dado que el usuario toca la pantalla directamente, el sistema no requiere ninguna indicación visual adicional para indicar los objetos que se manipulan.

Implementaciones de dispositivos:

DEBE tener algún tipo de sistema de entrada de puntero (ya sea similar a un mouse o táctil).
DEBE admitir punteros con seguimiento completamente independiente.

Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor) en una pantalla principal compatible con Android, deben cumplir con lo siguiente:

[C-1-1] DEBE informar TOUCHSCREEN_FINGER para el campo de la API Configuration.touchscreen.
[C-1-2] DEBE informar las marcas de funciones android.hardware.touchscreen y android.hardware.faketouch.

Si las implementaciones de dispositivos incluyen una pantalla táctil que puede hacer un seguimiento de más de un toque en una pantalla principal compatible con Android, deben cumplir con lo siguiente:

[C-2-1] DEBE informar los parámetros de configuración de funciones adecuados android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct y android.hardware.touchscreen.multitouch.jazzhand que corresponden al tipo de pantalla táctil específica del dispositivo.

Si las implementaciones de dispositivos dependen de un dispositivo de entrada externo, como un mouse o una trackball (es decir, no tocan directamente la pantalla) para ingresar datos en una pantalla principal compatible con Android y cumplen con los requisitos de toque falso que se indican en la sección 7.2.5, deben hacer lo siguiente:

[C-3-1] NO DEBE informar ninguna marca de función que comience con android.hardware.touchscreen.
[C-3-2] SOLO debe informar android.hardware.faketouch.
[C-3-3] Se DEBE informar TOUCHSCREEN_NOTOUCH para el campo de la API de 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 las capacidades de la pantalla táctil. Por ejemplo, un mouse o un control remoto que hace funcionar 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 panel táctil, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el panel táctil multitáctil, pueden admitir interacciones táctiles falsas. Android incluye la constante de función android.hardware.faketouch, que corresponde a un dispositivo de entrada de alta fidelidad que no es táctil (basado en puntero), como un mouse o un panel táctil, que puede emular de forma adecuada la entrada basada en el tacto (incluida la compatibilidad con gestos básicos) y que indica que el dispositivo admite un subconjunto emulado de la funcionalidad de la pantalla táctil.

Si las implementaciones de dispositivos no incluyen una pantalla táctil, pero sí otro sistema de entrada de puntero que desean poner a disposición, deben hacer lo siguiente:

DEBE declarar la compatibilidad con la marca de función android.hardware.faketouch.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch, deben cumplir con lo siguiente:

[C-1-1] DEBE informar las posiciones absolutas X e Y de la pantalla de la ubicación del puntero 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 se produce en el puntero cuando se mueve hacia arriba o hacia abajo en la pantalla.
[C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto de la pantalla, lo que permite a los usuarios emular un toque en un objeto de la pantalla.
[C-1-4] DEBE admitir los eventos de puntero hacia abajo, puntero hacia arriba y puntero hacia abajo seguido de 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 el evento de puntero hacia abajo en un punto arbitrario de la pantalla, el movimiento del puntero a cualquier otro punto arbitrario de la pantalla y, luego, el evento de 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 que los usuarios muevan rápidamente el objeto a una posición diferente en la pantalla y, luego, el puntero hacia arriba en la pantalla, lo que permite que los usuarios deslicen un objeto en la pantalla.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct, deben cumplir con lo siguiente:

[C-2-1] DEBE declarar la compatibilidad con android.hardware.faketouch.
[C-2-2] DEBE admitir el seguimiento distinto de dos o más entradas de puntero independientes.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.jazzhand, deben cumplir con lo siguiente:

[C-3-1] DEBE declarar la compatibilidad con android.hardware.faketouch.
[C-3-2] DEBE admitir el seguimiento distinto de 5 (seguimiento de una mano de dedos) o más entradas de puntero de forma completamente independiente.

7.2.6. Compatibilidad con el control de juegos

7.2.6.1. Asignaciones de botones

Implementaciones de dispositivos:

[C-1-1] DEBE poder asignar eventos HID a las constantes InputEvent correspondientes, como se indica en las siguientes tablas. La implementación de Android upstream satisface este requisito.

Si las implementaciones de dispositivos incorporan un controlador o se envían con un controlador independiente en la caja que proporcionaría medios para ingresar todos los eventos que se enumeran en las siguientes tablas, deben cumplir con lo siguiente:

[C-2-1] DEBE declarar la marca de función android.hardware.gamepad

Botón	Uso de HID²	Botón de Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Arriba en el pad direccional¹ Abajo en el pad direccional¹	0x01 0x0039³	AXIS_HAT_Y⁴
Pad direccional izquierdo1 Pad direccional derecho¹	0x01 0x0039³	AXIS_HAT_X⁴
Botón izquierdo del hombro¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botón derecho del hombro¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic con el joystick izquierdo¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic con el joystick derecho¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Atrás¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores se deben declarar 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 del informe de 4. El valor lógico se define como la rotación en el sentido de las agujas del reloj desde el eje vertical. Por ejemplo, un valor lógico de 0 representa que no hay rotación y que se presionó el botón hacia arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionaron las teclas hacia arriba y hacia la izquierda.

4 MotionEvent

Controles analógicos¹	Uso de HID	Botón de Android
Gatillo izquierdo	0x02 0x00C5	AXIS_LTRIGGER
Gatillo derecho	0x02 0x00C4	AXIS_RTRIGGER
Joystick izquierdo	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick derecho	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Control remoto

Consulta la Sección 2.3.1 para conocer los requisitos específicos de cada dispositivo.

7.3. Sensores

Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos, la implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android y la documentación de Android Open Source 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 los sensores compatibles a través de SensorManager.getSensorList() y métodos similares.
[C-0-3] DEBE comportarse de manera razonable para todas las demás APIs de sensores (por ejemplo, devolviendo true o false según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamando a los objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etc.).

Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos, deben cumplir con lo siguiente:

[C-1-1] DEBE informar todas las mediciones de los sensores con los valores pertinentes del Sistema Internacional de Unidades (métrico) para cada tipo de sensor, según se define en la documentación del SDK de Android.
[C-1-2] DEBE informar los datos de sensores con una latencia máxima de 100 milisegundos + 2 * sample_time en el caso de un flujo de sensores con una latencia máxima solicitada de 0 ms cuando el procesador de aplicaciones está activo. Esta demora no incluye ninguna demora de filtrado.
[C-1-3] DEBE informar la primera muestra del sensor en un plazo de 400 milisegundos + 2 * sample_time después de que se active el sensor. Es aceptable que esta muestra tenga una precisión de 0.
[C-1-4] Para cualquier API que la documentación del SDK de Android indique que es un sensor continuo, las implementaciones del dispositivo DEBEN proporcionar de forma continua muestras de datos periódicas que DEBEN tener una fluctuación inferior al 3%, en la que 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 impida que la CPU del dispositivo entre en un estado de suspensión o se reactive desde un estado de suspensión.
[C-1-6] DEBE informar la hora del evento en nanosegundos, según 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 de SystemClock.elapsedRealtimeNano().
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que tengan un error de sincronización de marcas de tiempo inferior a 100 milisegundos y DEBEN tener un error de sincronización de marcas 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. Se debe considerar como autorizada la documentación del SDK de Android y la documentación de código abierto de Android sobre sensores.

Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos, deben cumplir con lo siguiente:

[C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores y registrar el valor a través del método de la API Sensor.getResolution().

Algunos tipos de sensores son compuestos, lo que significa que se pueden derivar de los datos proporcionados por uno o más sensores. (Entre los ejemplos, se incluyen el sensor de orientación y el sensor de aceleración lineal).

Implementaciones de dispositivos:

DEBE implementar estos tipos de sensores cuando incluyan los sensores físicos necesarios, como se describe en tipos de sensores.

Si las implementaciones de dispositivos incluyen un sensor compuesto, deben cumplir con lo siguiente:

[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 del dispositivo incluyen un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos y el sensor solo informa un valor, las implementaciones del dispositivo deben cumplir con lo siguiente:

[C-3-1] DEBE establecer la resolución en 1 para el sensor y registrar el valor a través del método de la API de Sensor.getResolution().

Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor se expone a desarrolladores externos, deben hacer lo siguiente:

[C-4-1] NO DEBE incluir ningún parámetro de calibración fijo 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 de giroscopio de 3 ejes o un sensor de magnetómetro, se aplican las siguientes condiciones:

[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 (p.ej., plegable), los ejes del sensor permanezcan alineados y coherentes con el sistema de coordenadas del sensor en todos los estados de transformación posibles del dispositivo.

7.3.1. Acelerómetro

Implementaciones de dispositivos:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que incluyan un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos incluyen un acelerómetro, deben cumplir con lo siguiente:

[C-1-1] DEBE poder informar eventos con una frecuencia de hasta 50 Hz como mínimo.
[C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android.
[C-1-4] DEBE poder medir desde la caída libre hasta cuatro veces la gravity(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 que 0.05 m/s², en la que la desviación estándar se debe calcular por eje en las muestras recopiladas durante un período de al menos 3 segundos con la frecuencia de muestreo más rápida.
DEBE informar eventos con una frecuencia de hasta 200 Hz como mínimo.
DEBE tener una resolución de al menos 16 bits.
DEBE calibrarse durante el uso si las características cambian durante el ciclo de vida y se compensan, y debe conservar los parámetros de compensación entre los reinicios del dispositivo.
DEBE tener compensación de temperatura.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE implementar y registrar el sensor TYPE_ACCELEROMETER.
[C-SR-4] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE implementar y registrar el sensor de 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 en la que este requisito podría ser OBLIGATORIO.
DEBE implementar los sensores compuestos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR y 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, deben cumplir con lo siguiente:

[C-3-1] DEBE implementar y registrar el sensor TYPE_ACCELEROMETER_LIMITED_AXES.
[C-SR-6] Se RECOMIENDA ENCARECIDAMENTE implementar y registrar el sensor de TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones del dispositivo incluyen un acelerómetro de 3 ejes y se implementa cualquiera de los sensores compuestos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR o TYPE_STEP_COUNTER, se deben cumplir los siguientes requisitos:

[C-4-1] La suma de su consumo de energía SIEMPRE debe ser inferior a 4 mW.
Cada uno DEBE ser inferior a 2 mW y 0.5 mW cuando el dispositivo se encuentra en una condición dinámica o estática.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor de giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[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 de giroscopio de 3 ejes y un sensor de magnetómetro, deben cumplir con lo siguiente:

[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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar el sensor TYPE_MAGNETIC_FIELD.
[C-1-2] DEBE poder informar eventos con una frecuencia de al menos 10 Hz y DEBERÍA 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 APIs de Android.
[C-1-4] DEBE poder medir entre -900 µT y +900 µT en cada eje antes de saturarse.
[C-1-5] DEBE tener un valor de compensación de hierro duro inferior a 700 µT y DEBERÍA tener un valor inferior a 200 µT, para lo cual se debe colocar el magnetómetro lejos de los campos magnéticos dinámicos (inducidos por corriente) y estáticos (inducidos por imanes).
[C-1-6] DEBE tener una resolución igual o más densa que 0.6 µT.
[C-1-7] DEBE admitir la calibración y la compensación en línea de la desviación por hierro duro, y conservar los parámetros de compensación entre los reinicios del dispositivo.
[C-1-8] DEBE tener aplicada la compensación de hierro blando. La calibración se puede realizar durante el uso o durante la producción del dispositivo.
[C-1-9] DEBE tener una desviación estándar, calculada por eje en muestras recopiladas durante un período de al menos 3 segundos a la frecuencia de muestreo más rápida, no superior a 1.5 µT; DEBE tener una desviación estándar no superior 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, deben cumplir con lo siguiente:

[C-2-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes y un acelerómetro, deben cumplir con lo siguiente:

PUEDE implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro y un sensor de TYPE_GEOMAGNETIC_ROTATION_VECTOR, deben cumplir con lo siguiente:

[C-3-1] DEBE consumir menos de 10 mW.
DEBE consumir menos de 3 mW cuando el sensor se registra para el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones de dispositivos:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que incluyan un receptor de GPS/GNSS.

Si las implementaciones de dispositivos incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir resultados de ubicación a una velocidad de al menos 1 Hz cuando se solicitan a través de LocationManager#requestLocationUpdate.
[C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, interferencia por trayectos múltiples insignificante, HDOP < 2) en un plazo de 10 segundos (tiempo hasta la primera corrección rápido) cuando se conecta a una conexión a Internet con una velocidad de datos de 0.5 Mbps o más rápida. Por lo general, este requisito se cumple con el uso de alguna forma de técnica de GPS/GNSS asistido o predictivo para minimizar el tiempo de fijación del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y la efemérides/reloj del satélite).
- [C-1-6] Después de realizar ese cálculo de ubicación, las implementaciones de dispositivos DEBEN determinar su ubicación, en cielo abierto, en un plazo de 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 realice sin una conexión de datos o después de un ciclo de energía.
En condiciones de cielo abierto, después de determinar la ubicación, ya sea que el vehículo esté detenido o se mueva con una aceleración inferior a 1 m/s²:
- [C-1-3] DEBE poder determinar la ubicación en un radio de 20 metros y la velocidad en un radio de 0.5 metros por segundo, al menos el 95% del tiempo.
- [C-1-4] DEBE hacer un seguimiento y generar informes de forma simultánea a través de GnssStatus.Callback de al menos 8 satélites de una constelación.
- DEBE poder hacer un seguimiento simultáneo de al menos 24 satélites de varias constelaciones (p.ej., GPS y al menos una de Glonass, Beidou o Galileo).
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que sigan proporcionando resultados de ubicación normales del GPS/GNSS a través de las APIs del proveedor de ubicación GNSS durante una llamada de emergencia.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE informar las mediciones del GNSS de todas las constelaciones rastreadas (como se informa en los mensajes de GnssStatus), con la excepción de SBAS.
[C-SR-4] Se RECOMIENDA ENCARECIDAMENTE informar el AGC y la frecuencia de medición del GNSS.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE que se registren todas las estimaciones de precisión (incluidas la orientación, la velocidad y la precisión vertical) como parte de cada ubicación del GPS o GNSS.
[C-SR-6] SE RECOMIENDA ENCARECIDAMENTE informar las mediciones de GNSS tan pronto como se encuentren, incluso si aún no se informó una ubicación calculada a partir del GPS o GNSS.
[C-SR-7] SE RECOMIENDA ENCARECIDAMENTE informar las seudoranges y las velocidades de seudorango del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras el dispositivo está estacionario o se mueve con una aceleración inferior a 0.2 m/s², son suficientes para calcular la posición con una precisión de 20 metros y la velocidad con una precisión de 0.2 m/s, al menos el 95% del tiempo.

7.3.4. Giroscopio

Implementaciones de dispositivos:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que incluyan un sensor de giroscopio.

Si las implementaciones de dispositivos incluyen un giroscopio, deben cumplir con los siguientes requisitos:

[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 durante el uso, y conservar los parámetros de compensación entre los reinicios del dispositivo.
[C-1-7] DEBE tener una varianza no mayor que 1e-7 rad² / s² por Hz (varianza por Hz o rad² / s). Se permite que la varianza varíe con la tasa de muestreo, pero DEBE estar restringida por este valor. En otras palabras, si mides la varianza del giroscopio a una frecuencia de muestreo de 1 Hz, NO debería ser mayor que 1e-7 rad²/s².
[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 que tengan una resolución de 16 bits o más.
DEBE informar eventos con una frecuencia de hasta 200 Hz como mínimo.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, deben cumplir con lo siguiente:

[C-2-1] DEBE implementar el sensor TYPE_GYROSCOPE.
[C-SR-4] Se recomienda implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un giroscopio con menos de 3 ejes, deben cumplir con lo siguiente:

[C-3-1] DEBE implementar y registrar el sensor TYPE_GYROSCOPE_LIMITED_AXES.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE implementar y registrar el sensor de TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, un sensor de acelerómetro y un sensor de magnetómetro, deben cumplir con lo siguiente:

[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 de giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[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 atmosférica).

Si las implementaciones de dispositivos incluyen un barómetro, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar y registrar 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] SE RECOMIENDA ENCARECIDAMENTE que se puedan informar mediciones de presión en el rango de 300 hPa a 1,100 hPa.
DEBE tener una precisión absoluta de 1 hPa.
DEBE tener una precisión relativa de 0.12 hPa en un rango de 20 hPa (lo que equivale a una precisión de ~1 m en un cambio de ~200 m a nivel del mar).

Implementaciones de dispositivos que declaran la propiedad del sistema sensor.barometer.high_quality.implemented:

[C-2-1] DEBE informar las mediciones de presión en el rango de 300 hPa a 1,100 hPa, con una precisión absoluta de +/- 1 hPa.
[C-2-2] DEBE tener una precisión relativa de 0.15 hPa en un rango de 100 hPa, lo que equivale a una precisión de ~1 m en un cambio de ~1,000 m a nivel del mar.
[C-2-3] DEBE ser estable dentro de +/- 0.5 hPa cuando el usuario presiona, aprieta o toca el dispositivo.
[C-2-4] DEBE ser estable dentro de +/- 0.15 hPa cuando el usuario camina con el dispositivo en la mano o en el bolsillo.
[C-2-5] NO DEBE suavizarse con una constante de tiempo superior a 300 ms para las activaciones superiores a 5 Hz, y el suavizado NO DEBE filtrarse entre las activaciones del sensor.
[C-2-6] DEBE ser estable dentro de +/- 0.15 hPa cuando se expone a la iluminación y las frecuencias de radio cotidianas que introducen fuentes comunes, como Bluetooth, conexión móvil o Wi-Fi.

7.3.6. Termómetro

Si las implementaciones de dispositivos incluyen un termómetro ambiental (sensor de temperatura), deben cumplir con lo siguiente:

[C-1-1] DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para el sensor de temperatura ambiente, y el sensor DEBE medir la temperatura ambiente (de la habitación o la 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 diferente de la temperatura ambiente, como la temperatura de la CPU, deben cumplir con lo siguiente:

[C-2-1] NO DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para el sensor de temperatura.

Si las implementaciones de dispositivos incluyen un sensor para monitorear la temperatura cutánea, deben cumplir con los siguientes requisitos:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que se admita la API de PowerManager.getThermalHeadroom.

7.3.7. Fotómetro

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

7.3.8. Sensor de proximidad

Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad.

Si las implementaciones de dispositivos incluyen un sensor de proximidad y solo informan una lectura binaria de "cerca" o "lejos", deben cumplir con lo siguiente:

[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 que el usuario está usando. Si las implementaciones de dispositivos 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 usar 0 centímetros como la lectura cercana y 5 centímetros como la lectura lejana.
[C-1-4] DEBE informar un rango y una 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 las apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE identificar la capacidad a través de la marca de función android.hardware.sensor.hifi_sensors.

Si las implementaciones de dispositivos declaran android.hardware.sensor.hifi_sensors, deben cumplir con lo siguiente:

[C-2-1] DEBE tener un sensor de TYPE_ACCELEROMETER que cumpla con los siguientes requisitos:
- DEBE tener un rango de medición de al menos -8 g y +8 g, y se RECOMIENDA ENCARECIDAMENTE que tenga un rango de medición de al menos -16 g y +16 g.
- DEBE tener una resolución de medición de al menos 2,048 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 más; DEBE admitir SensorDirectChannel RATE_VERY_FAST.
- DEBE tener un ruido de medición no superior a 400 μg/√Hz.
- DEBE implementar una forma de este sensor que no active el dispositivo, con una capacidad de almacenamiento en búfer de al menos 3,000 eventos del sensor.
- DEBE tener un consumo de energía por lotes no superior 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 caminata aleatoria de aceleración inferior a 30 μg/√Hz probada a temperatura ambiente.
- DEBE tener un cambio de sesgo en comparación con la temperatura de ≤ +/- 1 mg/°C.
- DEBE tener una no linealidad de la línea de mejor ajuste ≤ 0.5% y un cambio de sensibilidad en función de la temperatura ≤ 0.03%/°C.
- DEBE tener una sensibilidad entre ejes inferior al 2.5 % y una variación de la sensibilidad entre ejes inferior al 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 cumpla con los siguientes requisitos:
- DEBE tener un rango de medición de al menos -1,000 y +1,000 DPS.
- DEBE tener una resolución de medición de al menos 16 LSB/dps.
- DEBE tener una frecuencia de medición mínima de 12.5 Hz o menos.
- DEBE tener una frecuencia de medición máxima de 400 Hz o más; 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 caminata aleatoria de la velocidad inferior a 0.001 °/s √Hz probada a temperatura ambiente.
- DEBE tener un cambio de sesgo en comparación con la temperatura de ≤ +/- 0.05 °/ s / °C.
- DEBE tener un cambio de sensibilidad en comparación con la temperatura de ≤ 0.02% / °C.
- DEBE tener una no linealidad de la línea de mejor ajuste de ≤ 0.2%.
- DEBE tener una densidad de ruido ≤ 0.007°/s/√Hz.
- DEBE tener un error de calibración inferior a 0.002 rad/s en el rango de temperatura de 10 a 40 ℃ cuando el dispositivo está estacionario.
- DEBE tener una sensibilidad a la aceleración inferior a 0.1 °/s/g.
- DEBE tener una sensibilidad entre ejes inferior al 4.0 % y una variación de la sensibilidad entre ejes inferior al 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 cumpla con los siguientes requisitos:
- DEBE tener un rango de medición de 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 más.
- 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, cumplir con lo siguiente:
- DEBE implementar una forma de este sensor que no active el dispositivo, con una capacidad de almacenamiento en búfer de al menos 600 eventos del 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 informes es de 50 Hz o más.
[C-2-7] DEBE tener un sensor TYPE_PRESSURE que cumpla con los siguientes requisitos:
- DEBE tener un rango de medición de al menos 300 a 1,100 hPa.
- DEBE tener una resolución de medición de al menos 80 LSB/hPa.
- DEBE tener una frecuencia de medición mínima de 1 Hz o menos.
- DEBE tener una frecuencia de medición máxima de 10 Hz o más.
- DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
- DEBE implementar una forma de este sensor que no active el dispositivo, con una capacidad de almacenamiento en búfer de al menos 300 eventos del sensor.
- DEBE tener un consumo de energía por lotes no superior a 2 mW.
[C-2-8] DEBE tener un sensor de TYPE_GAME_ROTATION_VECTOR.
[C-2-9] DEBE tener un sensor TYPE_SIGNIFICANT_MOTION que cumpla con los siguientes requisitos:
- DEBE tener un consumo de energía no superior 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 cumpla con los siguientes requisitos:
- DEBE implementar una forma de este sensor que no active el dispositivo, con una capacidad de almacenamiento en búfer de al menos 100 eventos del sensor.
- DEBE tener un consumo de energía no superior 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 superior a 4 mW.
[C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER que cumpla con los siguientes requisitos:
- DEBE tener un consumo de energía no superior 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 de TILT_DETECTOR que cumpla con lo siguiente:
- DEBE tener un consumo de energía no superior 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 evento físico que informan el acelerómetro, el giroscopio y el magnetómetro DEBE tener una diferencia de 2.5 milisegundos como máximo entre sí. La marca de tiempo del evento físico que informan el acelerómetro y el giroscopio DEBE ser inferior a 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 con un error de 1 milisegundo.
[C-2-15] DEBE entregar muestras a las aplicaciones en un plazo de 5 milisegundos desde el momento en que los datos están disponibles en cualquiera de los sensores físicos mencionados anteriormente 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 se habilita cualquier combinación de los siguientes sensores:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] PUEDE tener un sensor de TYPE_PROXIMITY, pero, si lo tiene, DEBE tener una capacidad de búfer mínima de 100 eventos del sensor.

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

Si las implementaciones de dispositivos incluyen compatibilidad directa con sensores, deben cumplir con los siguientes requisitos:

[C-3-1] DEBE declarar correctamente la compatibilidad con los tipos de canales directos y el nivel de tasas de informes directos a través de las APIs de isDirectChannelTypeSupported y getHighestDirectReportRateLevel.
[C-3-2] DEBE admitir al menos uno de los dos tipos de canales directos del sensor para todos los sensores que declaren compatibilidad con el canal directo del sensor.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
DEBE admitir el registro de eventos a través del canal directo del sensor para el sensor principal (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 del desbloqueo biométrico, consulta la documentación sobre la medición de la seguridad biométrica.

Si las implementaciones de dispositivos incluyen una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:

DEBE incluir un sensor biométrico

Los sensores biométricos se pueden clasificar como de clase 3 (anteriormente, sólidos).

Clase 2 (anteriormente Débil) o Clase 1 (anteriormente Conveniencia) según sus tasas de aceptación de suplantación y de impostores, y la seguridad de la canalización biométrica. Esta clasificación determina las capacidades que tiene el sensor biométrico para interactuar con la plataforma y con las aplicaciones de terceros. Los sensores deben cumplir con requisitos adicionales, como se detalla a continuación, si desean clasificarse como clase 1, clase 2 o clase 3. Las biometrías de clase 2 y clase 3 obtienen capacidades adicionales, como se detalla a continuación.

Si las implementaciones de dispositivos ponen a disposición de las aplicaciones de terceros un sensor biométrico a través de android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt y android.provider.Settings.ACTION_BIOMETRIC_ENROLL, deben cumplir con lo siguiente:

[C-4-1] DEBE cumplir con los requisitos de un método biométrico de clase 3 o clase 2, según se define en este documento.
[C-4-2] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase Authenticators y cualquier combinación de ellos. Por el contrario, NO DEBE aceptar ni reconocer las constantes de números enteros que se pasan a los métodos canAuthenticate(int) y setAllowedAuthenticators(int) que no sean los que se documentan como constantes públicas en Authenticators y cualquier combinación de ellos.
[C-4-3] DEBE implementar la acción ACTION_BIOMETRIC_ENROLL en dispositivos que tengan datos biométricos de clase 3 o clase 2. Esta acción SOLO DEBE presentar los puntos de entrada de inscripción para los datos biométricos de clase 3 o clase 2.
[C-4-4] DEBE permitir que las aplicaciones agreguen contenido personalizado a BiometricPrompt con los formatos de visualización de contenido PromptContentView. Los formatos de visualización de contenido NO DEBEN extenderse para permitir imágenes, vínculos, contenido interactivo ni otros tipos de medios que aún no formen parte de la API de BiometricPrompt. Se pueden realizar ajustes de estilo que no alteren, oculten ni trunquen este contenido (como cambiar la posición, el padding, los márgenes y la tipografía).

Si las implementaciones de dispositivos admiten la biometría pasiva, deben cumplir con los siguientes requisitos:

[C-5-1] DEBE requerir, de forma predeterminada, un paso de confirmación adicional (p.ej., presionar un botón).
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que tengan un parámetro de configuración para permitir que los usuarios anulen la preferencia de la aplicación y siempre requieran un paso de confirmación complementario.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que la acción de confirmación esté protegida de modo que una vulneración del sistema operativo o del kernel no pueda suplantarla. 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 (GPIO) de uso general solo de entrada de un elemento seguro (SE) que no se puede controlar por ningún otro medio que no sea la presión de un botón físico.
[C-5-2] DEBE implementar, además, un flujo de autenticación implícita (sin paso de confirmación) correspondiente a setConfirmationRequired(boolean), que las aplicaciones pueden configurar para utilizar en los flujos de acceso.

Si las implementaciones de dispositivos tienen varios sensores biométricos, deben cumplir con los siguientes requisitos:

[C-7-1] DEBE, cuando un dato biométrico está bloqueado (es decir, el dato biométrico está inhabilitado hasta que el usuario lo desbloquea con la autenticación principal) o está bloqueado por un período (es decir, el dato biométrico está inhabilitado temporalmente hasta que el usuario espera un intervalo de tiempo) debido a demasiados intentos fallidos, también bloquear todos los demás datos biométricos de una clase biométrica inferior. En el caso de un bloqueo con límite de tiempo, el tiempo de espera para la verificación biométrica DEBE ser el tiempo de espera máximo de todos los datos biométricos en el bloqueo con límite de tiempo.
[C-SR-12] Se RECOMIENDA ENCARECIDAMENTE que, cuando un dato biométrico esté bloqueado (es decir, el dato biométrico esté inhabilitado hasta que el usuario lo desbloquee con la autenticación principal) o bloqueado por un período (es decir, el dato biométrico esté inhabilitado temporalmente hasta que el usuario espere un intervalo de tiempo) debido a demasiados intentos fallidos, también se bloqueen todos los demás datos biométricos de la misma clase biométrica. En el caso de un bloqueo con límite de tiempo, se RECOMIENDA ENCARECIDAMENTE que el tiempo de retirada para la verificación biométrica sea el tiempo de retirada máximo de todos los datos biométricos en el bloqueo con límite de tiempo.
[C-7-2] DEBE solicitar al usuario la autenticación principal recomendada (como PIN, patrón o contraseña) para restablecer el contador de bloqueo de un elemento biométrico bloqueado. Es POSIBLE que se permitan los datos biométricos de clase 3 para restablecer el contador de bloqueo de unos datos biométricos bloqueados de la misma clase o una inferior. NO se deben permitir los datos biométricos de clase 2 o clase 1 para completar una operación de bloqueo por restablecimiento de ningún dato biométrico.
[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE que se requiera la confirmación de un solo dato biométrico por autenticación (p.ej., si hay sensores de huella dactilar y de rostro disponibles en el dispositivo, se debe enviar onAuthenticationSucceeded después de que se confirme cualquiera de ellos).

Para que las implementaciones de dispositivos permitan el acceso a las claves del keystore a aplicaciones de terceros, deben cumplir con los siguientes requisitos:

[C-6-1] DEBE cumplir con los requisitos de 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 requiera BIOMETRIC_STRONG o cuando se invoque la autenticación con un CryptoObject.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 1 (anteriormente Conveniencia), deben hacer lo siguiente:

[C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0.002%.
[C-1-2] DEBE divulgar que este modo puede ser menos seguro que un PIN, un patrón o una contraseña seguros, y enumerar claramente los riesgos de habilitarlo si las tasas de aceptación de suplantación y de impostores son superiores al 7% según lo medido por los Protocolos de prueba de biometría de Android.
[C-1-9] DEBE solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón, contraseña) después de no más de veinte intentos fallidos y no menos de noventa segundos de tiempo de espera para la verificación biométrica, en los que un intento fallido es aquel con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un dato biométrico inscrito.
[C-SR-4] SE RECOMIENDA ENCARECIDAMENTE reducir la cantidad total de intentos fallidos para la verificación biométrica especificada en [C-1-9] si las tasas de aceptación de suplantación y de impostores son superiores al 7%, según se mide con los protocolos de prueba de biometría de Android.
[C-1-3] DEBE limitar la cantidad de intentos de verificación biométrica, en los que un intento falso es aquel con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un elemento biométrico registrado.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE limitar la velocidad de los intentos durante al menos 30 segundos después de cinco intentos fallidos de verificación biométrica para la cantidad máxima de intentos fallidos por [C-1-9], en los que un intento fallido es aquel con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con una biometría inscrita.
[C-SR-6] Se RECOMIENDA ENCARECIDAMENTE que toda la lógica de limitación de frecuencia esté en el TEE.
[C-1-10] DEBE inhabilitar la biometría una vez que se haya activado por primera vez la retirada de la autenticación principal, como se describe en [C-0-2] de la sección 9.11.
[C-1-11] DEBE tener una tasa de aceptación de suplantación y usurpación de identidad no superior al 30%, con (1) una tasa de aceptación de suplantación y usurpación de identidad para las especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 30%, y (2) una tasa de aceptación de suplantación y usurpación de identidad de las especies de PAI de nivel B no superior al 40%, según se mide con los Protocolos de prueba de biometría de Android.
[C-1-4] DEBE impedir que se agreguen nuevos datos biométricos sin antes establecer una cadena de confianza, lo que se logra cuando el usuario confirma las credenciales existentes o agrega una nueva credencial del dispositivo (PIN, patrón o contraseña) protegida por el TEE. La implementación del Proyecto de código abierto de Android proporciona el mecanismo en el framework para hacerlo.
[C-1-5] DEBE quitar por completo todos los datos biométricos identificables de un usuario cuando se quita su cuenta (incluso a través de un restablecimiento de la configuración de fábrica) o cuando se quita la autenticación principal recomendada (como PIN, patrón o contraseña).
[C-1-6] DEBE respetar la marca individual de ese dato 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 principal recomendada (como PIN, patrón o contraseña) una vez cada 24 horas o menos.
[C-1-8] DEBE solicitar al usuario la autenticación principal recomendada (como PIN, patrón o contraseña) o biométrica de clase 3 (FUERTE) después de que ocurra cualquiera de los siguientes eventos:
- Un período de tiempo de espera de inactividad de 4 horas.
- 3 intentos fallidos de autenticación biométrica
- El período de tiempo de espera por inactividad y el recuento de autenticaciones fallidas se restablecen después de cualquier confirmación exitosa de las credenciales del dispositivo.
[C-SR-7] Se RECOMIENDA ENCARECIDAMENTE usar la lógica del framework proporcionado por el Proyecto de código abierto de Android para aplicar las restricciones especificadas en [C-1-7] y [C-1-8] para los dispositivos nuevos.
[C-SR-8] Se RECOMIENDA ENCARECIDAMENTE que tengan una tasa de rechazo falsa inferior al 10%, según se mide en el dispositivo.
[C-SR-9] Se RECOMIENDA ENCARECIDAMENTE que tengan una latencia inferior a 1 segundo, medida desde el momento en que se detectan los datos biométricos hasta que se desbloquea la pantalla, para cada dato biométrico inscrito.
[C-1-12] DEBE tener una tasa de aceptación de suplantación y fraude no superior al 40% por especie de instrumento de ataque de presentación (PAI), según se mide en los Protocolos de prueba de biometría de Android.
[C-SR-13] Se RECOMIENDA ENCARECIDAMENTE que tengan una tasa de aceptación de suplantación y de impostor no superior al 30% por especie de instrumento de ataque de presentación (PAI), según se mide en los Protocolos de prueba de biometría de Android.
[C-SR-8] Se RECOMIENDA ENCARECIDAMENTE que tengan una tasa de rechazo falsa inferior al 10%, según se mide en el dispositivo.
[C-1-15] DEBE permitir que los usuarios quiten registros biométricos únicos o múltiples.
[C-SR-14] SE RECOMIENDA ENCARECIDAMENTE divulgar la clase biométrica del sensor biométrico y los riesgos correspondientes de habilitarlo.
[C-SR-17] Se RECOMIENDA ENCARECIDAMENTE implementar las nuevas interfaces de AIDL (como IFace.aidl y IFingerprint.aidl).

Si las implementaciones de dispositivos desean tratar un sensor biométrico como de clase 2 (anteriormente débil), deben hacer lo siguiente:

[C-2-1] DEBE cumplir con todos los requisitos de la Clase 1 mencionados anteriormente.
[C-2-2] DEBE tener una tasa de aceptación de suplantación y usurpación no superior al 20%, con (1) una tasa de aceptación de suplantación y usurpación para las especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 20% y (2) una tasa de aceptación de suplantación y usurpación de especies de PAI de nivel B no superior al 30%, según se mide en los Protocolos de prueba de biometría de Android.
[C-SR-15] SE RECOMIENDA ENCARECIDAMENTE que tengan una tasa de aceptación de suplantación y usurpación de identidad no superior al 20% por especie de instrumento de ataque de presentación (PAI), según se mide en los Protocolos de prueba de biometría de Android.
[C-2-3] DEBE realizar la coincidencia biométrica en un entorno de ejecución aislado fuera del espacio del usuario o del kernel de Android, como el entorno de ejecución confiable (TEE), en un chip con un canal seguro para el entorno de ejecución aislado o en una máquina virtual protegida que cumpla con los requisitos de la Sección 9.17.
[C-2-4] DEBE tener todos los datos identificables encriptados y autenticados de forma criptográfica para que no se puedan adquirir, leer ni alterar fuera del entorno de ejecución aislado o de un chip con un canal seguro para el entorno de ejecución aislado, como se documenta en los lineamientos de implementación en el sitio del Proyecto de código abierto de Android, o una máquina virtual protegida controlada por un hipervisor que cumpla con los requisitos de la Sección 9.17.
[C-2-5] En el caso de la biometría basada en la cámara, mientras se realiza la autenticación o la inscripción basadas en la biometría, se debe cumplir con lo siguiente:
- DEBE operar la cámara en un modo que impida que los fotogramas de la cámara se lean o alteren fuera del entorno de ejecución aislado, o bien un chip con un canal seguro para el entorno de ejecución aislado, o una máquina virtual protegida controlada por un hipervisor que cumpla con los requisitos de la Sección 9.17.
- En el caso de las soluciones de cámara única RGB, los fotogramas de la cámara PUEDEN ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para la inscripción, pero NO DEBEN ser alterables.
[C-2-6] NO DEBE permitir que las aplicaciones de terceros distingan entre las inscripciones biométricas individuales.
[C-2-7] NO DEBE permitir el acceso sin encriptar a datos biométricos identificables ni a ningún dato derivado de ellos (como las incorporaciones) al procesador de aplicaciones fuera del contexto del TEE o la máquina virtual protegida controlada por el hipervisor que cumpla con los requisitos de la Sección 9.17. Los dispositivos que se actualizan y que se lanzaron con la versión 9 de Android o una anterior no están exentos de [C-2-7].
[C-2-8] DEBE tener una canalización de procesamiento segura de modo que la vulneración del sistema operativo o del kernel no permita que se inserten datos directamente para autenticarse falsamente como el usuario.

Nota: Si las implementaciones de dispositivos ya se lanzaron en la versión 9 de Android o en una anterior y no pueden cumplir con el requisito [C-2-8] a través de una actualización de software del sistema, SE PUEDEN EXIMIR del requisito.
[C-SR-10] SE RECOMIENDA ENCARECIDAMENTE incluir la detección de vida para todas las modalidades biométricas y la detección de atención para la biometría facial.
[C-2-9] DEBE poner el sensor biométrico a disposición de las aplicaciones de terceros.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 3 (anteriormente Fuerte), deben hacer lo siguiente:

[C-3-1] DEBE cumplir con todos los requisitos de la clase 2 anteriores, excepto [C-1-7] y [C-1-8].
[C-3-2] DEBE tener una implementación del almacén de claves respaldado por hardware.
[C-3-3] DEBE tener una tasa de aceptación de suplantación y de impostor no superior al 7%, con (1) una tasa de aceptación de suplantación y de impostor para las especies de instrumentos de ataque a la presentación (PAI) de nivel A no superior al 7% y (2) una tasa de aceptación de suplantación y de impostor de las especies de PAI de nivel B no superior al 20%, según se mide con los Protocolos de prueba de biometría de Android.
[C-3-4] DEBE solicitar al usuario la autenticación principal recomendada (como PIN, patrón o contraseña) una vez cada 72 horas o menos.
[C-3-5] SE DEBE volver a generar el ID del autenticador para todos los datos biométricos de clase 3 admitidos en el dispositivo si se vuelve a inscribir alguno de ellos.
[C-3-6] Se deben habilitar las claves del almacén de claves respaldado por datos biométricos para las aplicaciones de terceros.
[C-SR-16] Se RECOMIENDA ENCARECIDAMENTE que tengan una tasa de aceptación de suplantación y fraude no superior al 7% por especie de instrumento de ataque de presentación (PAI), según se mide en los Protocolos de prueba de biometría de Android.

Si las implementaciones de dispositivos contienen un sensor de huellas dactilares debajo de la pantalla (UDFPS), deben cumplir con lo siguiente:

[C-SR-11] SE RECOMIENDA ENCARECIDAMENTE para evitar que el área táctil del UDFPS interfiera en la navegación con 3 botones (que algunos usuarios podrían necesitar por motivos de accesibilidad).

7.3.11. Sensor de posición

Implementaciones de dispositivos:

PUEDE admitir el sensor de posición con 6 grados de libertad.

Si las implementaciones de dispositivos admiten el sensor de posición con 6 grados de libertad, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar y registrar el sensor TYPE_POSE_6DOF.
[C-1-2] DEBE ser más preciso que el vector de rotación por sí solo.

7.3.12. Sensor de ángulo de bisagra

Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra, deben cumplir con los siguientes requisitos:

[C-1-1] Se DEBE implementar y registrar TYPE_HINGE_ANGLE.
[C-1-2] DEBE admitir al menos dos lecturas entre 0 y 360 grados (inclusive, es decir, incluidos 0 y 360 grados).
[C-1-3] DEBE devolver un sensor de activación para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Si las implementaciones de dispositivos incluyen compatibilidad con 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, deben cumplir con lo siguiente:

[C-1-2] DEBE informar la marca de función de hardware android.hardware.uwb.
[C-1-3] DEBE admitir todos los siguientes conjuntos de configuración (combinaciones predefinidas de parámetros de UCI de FIRA) definidos en la implementación de AOSP.
- CONFIG_ID_1: Intervalo de medición de STATIC STS DS-TWR de unidifusión definido por FiRa, modo diferido, intervalo de medición de 240 ms.
- CONFIG_ID_2: Intervalo de STATIC STS DS-TWR de uno a varios definido por FiRa, modo diferido, intervalo de medición de 200 ms. Caso de uso típico: Un smartphone interactúa con muchos dispositivos inteligentes.
- CONFIG_ID_3: Igual que CONFIG_ID_1, excepto que no se informan los datos del ángulo de llegada (AoA).
- CONFIG_ID_4: Igual que CONFIG_ID_1, excepto que el modo de seguridad de P-STS está habilitado.
- CONFIG_ID_5: Igual que CONFIG_ID_2, excepto que el modo de seguridad de P-STS está habilitado.
- CONFIG_ID_6: Igual que CONFIG_ID_3, excepto que el modo de seguridad de P-STS está habilitado.
- CONFIG_ID_7: Igual que CONFIG_ID_2, excepto que está habilitado el modo de clave de la entidad controlada individual de P-STS.
[C-1-4] DEBE proporcionar una indicación visual para que el usuario pueda activar o desactivar la radio UWB.
[C-1-5] DEBE aplicar que las apps que usan radio UWB tengan el permiso UWB_RANGING (en el grupo de permisos NEARBY_DEVICES).

Aprobar las pruebas de certificación y cumplimiento pertinentes definidas por las organizaciones de estándares, incluidas FIRA, CCC y CSA, ayuda a garantizar que 802.1.15.4 funcione correctamente.

7.3.14. Sensores personalizados

Para ayudar a proporcionar una experiencia diferenciada, las implementaciones de dispositivos PUEDEN incluir sensores adicionales no cubiertos por Android o Wear OS, a los que pueden acceder las apps precargadas.

Para estos sensores, el ID del sensor:

[C-0-1] MUST ser mayor que 65536.

Si el sensor personalizado se diseñó para fines relacionados con la salud o el estado físico, debe cumplir con los siguientes requisitos:

[C-0-2] DEBE estar protegido por un permiso de plataforma o un permiso del sistema.

7.4. Conectividad de datos

7.4.1. Telefonía

El término "telefonía" que usan las APIs de Android y este documento se refiere específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS, o el establecimiento de datos móviles a través de una red móvil (p.ej., GSM, CDMA, LTE, NR). Un dispositivo que admite "Telefonía" puede ofrecer algunos o todos los servicios de llamadas, mensajería y datos según se adapte al producto.

Android SE PUEDE usar 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, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la marca de función android.hardware.telephony y otras marcas de subfunciones según la tecnología.
[C-1-2] DEBE implementar la compatibilidad total con la API para esa tecnología.
DEBE permitir todos los tipos de servicios de telefonía celular disponibles (2G, 3G, 4G, 5G, etcétera) 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, deben cumplir con lo siguiente:

[C-2-1] DEBE implementar las APIs completas como no-ops.

Si las implementaciones de dispositivos admiten eUICCs o eSIMs/SIMs integradas y tienen un mecanismo propietario para que la funcionalidad de eSIM esté disponible para desarrolladores externos, deben cumplir con lo siguiente:

[C-3-1] DEBE declarar la marca de función android.hardware.telephony.euicc.

Si las implementaciones de dispositivos no configuran la propiedad del sistema ro.telephony.iwlan_operation_mode como legacy, deben hacer lo siguiente:

[C-4-1] NO DEBE informar NETWORK_TYPE_IWLAN a través de NetworkRegistrationInfo#getAccessNetworkTechnology() cuando NetworkRegistrationInfo#getTransportType() se informa como TRANSPORT_TYPE_WWAN para la misma instancia de NetworkRegistrationInfo.

Si las implementaciones de dispositivos admiten un solo registro del subsistema multimedia IP (IMS) para las funciones de servicio de telefonía multimedia (MMTEL) y servicio de comunicación enriquecida (RCS), y se espera que cumplan con los requisitos de los operadores de telefonía celular con respecto al uso de un solo registro de IMS para todo el tráfico de señalización de IMS, deben hacer lo siguiente:

[C-5-1] DEBE declarar la marca de función android.hardware.telephony.ims y proporcionar una implementación completa de la API de ImsService para la API de User Capability Exchange de MMTEL y RCS.
[C-5-2] DEBE declarar la marca de función android.hardware.telephony.ims.singlereg y proporcionar una implementación completa de la API de SipTransport, la API de GbaService, indicaciones de portador dedicadas con el HAL de IRadio 1.6 y el aprovisionamiento a través del servidor de configuración automática (ACS) o algún otro mecanismo de aprovisionamiento propietario con la API de IMS Configuration.

Si las implementaciones de dispositivos informan la función android.hardware.telephony, se aplican las siguientes condiciones:

[C-6-1] SmsManager#sendTextMessage y SmsManager#sendMultipartTextMessage DEBEN generar llamadas correspondientes a CarrierMessagingService para proporcionar la funcionalidad de mensajería de texto. SmsManager#sendMultimediaMessage y SmsManager#downloadMultimediaMessage DEBEN generar llamadas correspondientes a CarrierMessagingService para proporcionar funcionalidad de mensajería multimedia.
[C-6-2] La aplicación designada por android.provider.Telephony.Sms#getDefaultSmsPackage DEBE usar las APIs de SmsManager cuando envíe y reciba mensajes SMS y MMS. La implementación de referencia del AOSP en packages/apps/Messaging cumple con este requisito.
[C-6-3] La aplicación que responde a Intent#ACTION_DIAL DEBE admitir el ingreso de códigos de marcador arbitrarios con el formato *#*#CODE#*#* y activar una transmisión de TelephonyManager#ACTION_SECRET_CODE correspondiente.
[C-6-4] La aplicación que responde a Intent#ACTION_DIAL DEBE usar VoicemailContract.Voicemails#TRANSCRIPTION para mostrar a los usuarios la transcripción del buzón de voz visual si admite transcripciones de buzón de voz visual.
[C-6-5] DEBE representar todos los objetos SubscriptionInfo con UUID de grupo equivalentes como una sola suscripción en todas las opciones visibles para el usuario que muestran y controlan la información de la tarjeta SIM. Algunos ejemplos de estas ayudas incluyen interfaces de configuración que coinciden con Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS o EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] NO DEBE mostrar ni permitir el control de ningún SubscriptionInfo con un UUID de grupo y un bit oportunista no nulos en ninguna opción visible para el usuario que permita configurar o controlar los parámetros de configuración de la tarjeta SIM.

Si las implementaciones del dispositivo informan la función android.hardware.telephony y proporcionan una barra de estado del sistema, se deben cumplir las siguientes condiciones:

[C-7-1] DEBE seleccionar una suscripción activa representativa para un UUID de grupo determinado para mostrar al usuario en cualquier opción que proporcione información sobre el estado de la SIM. Algunos ejemplos de estas indicaciones son el ícono de señal celular de la barra de estado o la tarjeta de configuración rápida.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que la suscripción representativa sea la suscripción de datos activa, a menos que el dispositivo esté en una llamada de voz, en cuyo caso SE RECOMIENDA ENCARECIDAMENTE que la suscripción representativa sea la suscripción de voz activa.

Si las implementaciones de dispositivos informan la función android.hardware.telephony, se aplican las siguientes condiciones:

[C-6-7] DEBE ser capaz de abrir y utilizar de forma simultánea la cantidad máxima 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 apps de operador activas (según lo designado por TelephonyManager#getCarrierServicePackageName) de forma automática o sin la confirmación explícita del usuario:
- Revoca o limita el acceso a la red
- Cómo revocar permisos
- Restringir la ejecución de apps en primer plano o segundo plano más allá de las funciones de administración de energía existentes incluidas en el AOSP
- Inhabilita o desinstala la app

Si las implementaciones del dispositivo informan la función android.hardware.telephony y todas las suscripciones no oportunistas activas que comparten un UUID de grupo están inhabilitadas, se quitaron físicamente del dispositivo o se marcaron como oportunistas, entonces el dispositivo cumple con las siguientes condiciones:

[C-8-1] DEBE inhabilitar automáticamente todas las suscripciones oportunistas activas restantes del mismo grupo.

Si las implementaciones de dispositivos incluyen telefonía GSM, pero no telefonía CDMA, deben cumplir con los siguientes requisitos:

[C-9-1] NO DEBE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] DEBE arrojar un IllegalArgumentException cuando se intente establecer cualquier tipo de red 3GPP2 en las máscaras de bits de tipos de red preferidos o permitidos.
[C-9-3] DEBE devolver una cadena vacía de TelephonyManager#getMeid.

Si las implementaciones del dispositivo admiten eUICCs con varios puertos y perfiles, deben cumplir con lo siguiente:

[C-10-1] DEBE declarar la marca de función android.hardware.telephony.euicc.mep.

Si las implementaciones de dispositivos admiten conectividad de datos celulares, deben cumplir con lo siguiente:

[C-SR-11] Se RECOMIENDA ENCARECIDAMENTE declarar la función android.hardware.telephony.data.

Si las implementaciones de dispositivos informan android.hardware.telephony.data, cumplen con los siguientes requisitos:

[C-12-1] DEBE admitir al menos dos conexiones simultáneas a redes de datos celulares, como contextos de PDP, conexiones de PDN y conexiones de DN.

7.4.1.1. Compatibilidad con el bloqueo de números

Si las implementaciones de dispositivos informan la función android.hardware.telephony.calling, deben cumplir con lo siguiente:

[C-1-1] DEBE incluir compatibilidad con el bloqueo de números
[C-1-2] DEBE implementar por completo BlockedNumberContract y la API correspondiente, como se describe en la documentación del SDK.
[C-1-3] DEBE bloquear todas las llamadas y los mensajes de un número de teléfono en BlockedNumberProvider sin ninguna interacción con las apps. La única excepción es cuando se levanta temporalmente el bloqueo de números, como se describe en la documentación del SDK.
[C-1-4] DEBE escribir en el proveedor de registros de llamadas de la plataforma para una llamada bloqueada y DEBE filtrar las llamadas con BLOCKED_TYPE de la vista predeterminada del registro de llamadas en la app de marcador preinstalada.
[C-1-5] NO DEBE escribir en el proveedor de telefonía para un mensaje bloqueado.
[C-1-6] DEBE implementar una IU de administración de números bloqueados, que se abre con el intent que devuelve el método TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] NO DEBE permitir que los usuarios secundarios vean ni editen los números bloqueados en el dispositivo, ya que la plataforma de Android supone que el usuario principal tiene el control total de los servicios de telefonía, una sola instancia, en el dispositivo. TODA la IU relacionada con el bloqueo DEBE ocultarse para los usuarios secundarios, y la lista de usuarios bloqueados DEBE seguir respetándose.
DEBE migrar los números bloqueados al proveedor cuando un dispositivo se actualiza a Android 7.0.
DEBE proporcionar una opción para que el usuario vea las llamadas bloqueadas en la app de marcado preinstalada.

7.4.1.2. API de Telecom

Si las implementaciones de dispositivos declaran android.hardware.microphone y android.hardware.audio.output, y no declaran android.hardware.type.television, sucede lo siguiente:

[7.4.1.2/C-0-1] DEBE declarar la marca de función android.software.telecom.
[7.4.1.2/C-0-2] DEBE implementar el marco de trabajo de telecomunicaciones.

Si las implementaciones de dispositivos informan android.hardware.telephony.calling, cumplen con los siguientes requisitos:

[C-1-1] DEBE admitir las APIs de ConnectionService que se describen en el SDK.
[C-1-2] DEBE mostrar una nueva llamada entrante y proporcionar al usuario la posibilidad de aceptar o rechazar la llamada entrante cuando el usuario esté en una llamada en curso realizada por una app de terceros que no admita la función de espera 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 responder una llamada entrante interrumpirá una llamada en curso.

La implementación del AOSP cumple con estos requisitos a través de una notificación de atención que le indica al usuario que, si contesta una llamada entrante, se cortará la otra llamada.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE precargar la app de marcador predeterminada que muestra una entrada del registro de llamadas y el nombre de una app de terceros en su registro de llamadas cuando la app de terceros establece la clave de extras EXTRA_LOG_SELF_MANAGED_CALLS en su PhoneAccount como true.
[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE controlar los eventos KEYCODE_MEDIA_PLAY_PAUSE y KEYCODE_HEADSETHOOK de los auriculares de audio para las APIs de android.telecom de la siguiente manera:
- Llama a Connection.onDisconnect() cuando se detecta una presión breve del evento clave durante una llamada en curso.
- Llama a Connection.onAnswer() cuando se detecta una presión breve del evento clave durante una llamada entrante.
- Llama a Connection.onReject() cuando se detecta una presión prolongada del evento clave durante una llamada entrante.
- Activa o desactiva el estado de silencio de CallAudioState.

7.4.1.3. Aligeramiento de Keepalive de NAT-T celular

Implementaciones de dispositivos:

DEBE incluir compatibilidad con la descarga de Keepalive celular.

Si las implementaciones de dispositivos incluyen compatibilidad con la descarga de Keep-alive celular y exponen la funcionalidad a apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir la API de SocketKeepAlive.
[C-1-2] DEBE admitir al menos una ranura de Keep-Alive simultánea a través de la red celular.
[C-1-3] DEBE admitir tantas ranuras de Keep-Alive celulares simultáneas como las que admite el HAL de radio celular.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que admitan al menos tres ranuras de keep-alive celulares por instancia de radio.

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de la función de mantener activo el celular, se aplican las siguientes condiciones:

[C-2-1] DEBE devolver ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones de dispositivos:

DEBE incluir compatibilidad con una o más formas de 802.11.

Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 y exponen la funcionalidad a una aplicación de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar la API de Android correspondiente.
[C-1-2] DEBE informar la marca 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 mDNS y NO DEBE filtrar paquetes mDNS (224.0.0.251 o ff02::fb) en ningún momento de funcionamiento, incluso cuando la pantalla no esté en un estado activo, a menos que no se mantenga el bloqueo de multidifusión y los paquetes se filtren con APF. No es necesario que los paquetes satisfagan ninguna operación de mDNS que las aplicaciones soliciten actualmente a través de las APIs de NsdManager. Sin embargo, el dispositivo PUEDE filtrar paquetes mDNS si es necesario para cumplir con los rangos de consumo de energía requeridos por las reglamentaciones aplicables al mercado objetivo.
[C-1-5] NO DEBE tratar la llamada de método de la API de WifiManager.enableNetwork() como una indicación suficiente para cambiar el Network activo actualmente que se usa de forma predeterminada para el tráfico de la aplicación y que devuelven los métodos de la API de ConnectivityManager, como getActiveNetwork y registerDefaultNetworkCallback. En otras palabras, SOLO PUEDEN inhabilitar el acceso a Internet proporcionado por cualquier otro proveedor de red (p.ej., datos móviles) si validan correctamente que la red Wi-Fi proporciona acceso a Internet.
[C-1-6] Se RECOMIENDA ENCARECIDAMENTE que, cuando se llame al método de la API de ConnectivityManager.reportNetworkConnectivity(), se vuelva a evaluar el acceso a Internet en el Network y, una vez que la evaluación determine que el Network actual ya no proporciona acceso a Internet, se cambie a cualquier otra red disponible (p.ej., datos móviles) que proporcione acceso a Internet.
[C-1-7] Se DEBE aleatorizar la dirección MAC de origen y el número de secuencia de los tramas de solicitud de sondeo, una vez al comienzo de cada búsqueda, mientras la STA está desconectada.
[C-1-8] DEBE usar 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 la solicitud de sondeo de forma normal (secuencial) entre las solicitudes de sondeo en un análisis.
[C-1-10] DEBE aleatorizar el número de secuencia de la solicitud de sondeo entre la última solicitud de sondeo de un análisis y la primera solicitud de sondeo del siguiente análisis.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE aleatorizar la dirección MAC de origen que se usa para toda la comunicación de la STA con un punto de acceso (AP) durante la asociación y después de la asociación.
- El dispositivo DEBE usar 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 establecer el modo predeterminado para las nuevas configuraciones de Wi-Fi como aleatorio.
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que usen un BSSID aleatorio para cualquier AP que creen.
- La dirección MAC DEBE ser aleatoria y persistente por SSID que use el AP.
- El DISPOSITIVO PUEDE proporcionar al usuario una opción para inhabilitar esta función. Si se proporciona una opción de este tipo, la aleatorización DEBE estar habilitada de forma predeterminada.

Si las implementaciones de dispositivos incluyen compatibilidad con el modo de ahorro de energía de Wi-Fi según se define en el estándar IEEE 802.11, deben cumplir con lo siguiente:

DEBE desactivar el modo de ahorro de energía de Wi-Fi siempre que una app adquiera un bloqueo de WIFI_MODE_FULL_HIGH_PERF o WIFI_MODE_FULL_LOW_LATENCY a través de las APIs de 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 modo de bloqueo de alto rendimiento de Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE para minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere un bloqueo de baja latencia (WIFI_MODE_FULL_LOW_LATENCY) y entra en vigencia.

Si las implementaciones de dispositivos admiten Wi-Fi y lo usan para la búsqueda de ubicación, deben cumplir con lo siguiente:

[C-2-1] DEBE proporcionar una indicación visual para el usuario que permita habilitar o desactivar la lectura del valor a través del método de API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi directo

Implementaciones de dispositivos:

DEBE incluir compatibilidad con Wi-Fi Direct (Wi-Fi entre pares).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Direct, deben cumplir con lo siguiente:

[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 de Wi-Fi y Wi-Fi Direct de forma simultánea.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE aleatorizar la dirección MAC de origen para todas las conexiones Wi-Fi Direct recién formadas.

7.4.2.2. Configuración de la vinculación directa encapsulada por Wi-Fi

Implementaciones de dispositivos:

DEBE incluir compatibilidad con la configuración de vínculo directo con túnel Wi-Fi (TDLS), como se describe en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad con TDLS y la API de WifiManager habilita TDLS, se cumplen las siguientes condiciones:

[C-1-1] DEBE declarar la compatibilidad con TDLS a través de WifiManager.isTdlsSupported.
DEBE usar TDLS solo cuando sea posible Y beneficioso.
DEBE tener alguna heurística y NO usar TDLS cuando su rendimiento podría ser peor que el de la conexión a través del punto de acceso Wi-Fi.

7.4.2.3. Reconocimiento de Wi-Fi

Implementaciones de dispositivos:

DEBE incluir compatibilidad con Reconocimiento de Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y exponen la funcionalidad a apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar las APIs de WifiAwareManager como se describe en la documentación del SDK.
[C-1-2] DEBE declarar la marca de función android.hardware.wifi.aware.
[C-1-3] DEBE admitir operaciones de Wi-Fi y Wi-Fi Aware de forma simultánea.
[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 haya una operación de rango de Aware en curso o una ruta de datos de Aware activa (no se espera aleatorización mientras la ruta de datos esté activa).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y Wi-Fi Location, como se describe en la Sección 7.4.2.5, y exponen estas funcionalidades a apps de terceros, deben cumplir con lo siguiente:

[C-2-1] DEBE implementar las APIs de descubrimiento que tienen en cuenta la ubicación: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm y onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 (Wi-Fi), deben cumplir con lo siguiente:

DEBE incluir compatibilidad con Wi-Fi Passpoint.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Passpoint, deben cumplir con los siguientes requisitos:

[C-1-2] DEBE implementar las APIs de 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 en relación con la detección y selección de redes, como el servicio de publicidad genérico (GAS) y el protocolo de consulta de redes de acceso (ANQP).
[C-1-4] DEBE declarar el parámetro de función android.hardware.wifi.passpoint.
[C-1-5] DEBE seguir la implementación de AOSP para descubrir, hacer coincidir y asociar redes de Passpoint.
[C-1-6] DEBE admitir, al menos, el siguiente subconjunto de protocolos de provisión de dispositivo, según se define en Passpoint R2 de Wi-Fi Alliance: autenticación EAP-TTLS y SOAP-XML.
[C-1-7] DEBE procesar el certificado del servidor AAA como se describe en la especificación de 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 entre reinicios.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que admitan la función de aceptación de los términos y condiciones.
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que admitan la función de información del lugar.

Si se proporciona un interruptor de control del usuario para inhabilitar Passpoint de forma global, las implementaciones deben hacer lo siguiente:

[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:

DEBE incluir compatibilidad con la ubicación Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con la ubicación Wi-Fi y exponen la funcionalidad a apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar las APIs de WifiRttManager como se describe en la documentación del SDK.
[C-1-2] DEBE declarar la marca 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 ejecute mientras la interfaz Wi-Fi en la que se ejecuta el RTT no esté asociada a un punto de acceso.
[C-1-4] DEBE ser preciso dentro de un rango de 2 metros con un ancho de banda de 80 MHz en el percentil 68 (según el cálculo con la función de distribución acumulativa).
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que se informe con precisión dentro de un rango de 1.5 metros con un ancho de banda de 80 MHz en el percentil 68 (según se calcula con la función de distribución acumulada).

7.4.2.6. Descarga de Keepalive de Wi-Fi

Implementaciones de dispositivos:

DEBE incluir compatibilidad con la descarga de Wi-Fi keepalive.

Si las implementaciones de dispositivos incluyen compatibilidad con la descarga de Wi-Fi keepalive y exponen la funcionalidad a apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir la API de SocketKeepAlive.
[C-1-2] DEBE admitir al menos tres intervalos de conexión simultáneos a través de Wi-Fi

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de Wi-Fi Keep-Alive, se aplican las siguientes condiciones:

[C-2-1] DEBE devolver ERROR_UNSUPPORTED.

7.4.2.7. Easy Connect para Wi-Fi (protocolo de aprovisionamiento de dispositivos)

Implementaciones de dispositivos:

DEBE incluir compatibilidad con Easy Connect para Wi-Fi (DPP).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Easy Connect y exponen la funcionalidad a apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE tener el método WifiManager#isEasyConnectSupported() que muestre true.

7.4.2.8. Validación del certificado del servidor Wi-Fi empresarial

Si no se valida el certificado del servidor Wi-Fi o no se configura el nombre de dominio del servidor Wi-Fi, las implementaciones del dispositivo deben hacer lo siguiente:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE no proporcionar al usuario una opción para agregar manualmente una red Wi-Fi empresarial en la app de Configuración.

7.4.2.9. Confianza en el primer uso (TOFU)

Si las implementaciones de dispositivos admiten la confianza en el primer uso (TOFU) y permiten que el usuario defina configuraciones WPA/WPA2/WPA3-Enterprise, deben cumplir con lo siguiente:

[C-4-1] DEBE proporcionar al usuario una opción para seleccionar el uso de TOFU.

7.4.2.10. Detección de proximidad de Wi-Fi

Si las implementaciones de dispositivos incluyen compatibilidad con la detección de proximidad Wi-Fi, deben cumplir con lo siguiente:

[C-1-1] DEBE incluir compatibilidad con la Detección de proximidad.
[C-1-2] DEBE declarar la marca de función android.hardware.wifi.rtt.
[C-1-3] DEBE hacer que el método WifiRttManager#getProximityDetectionCharacteristics() muestre un valor no nulo.
[C-1-4] DEBE implementar las APIs de WifiRttManager de rango continuo.
[C-1-5] DEBE admitir operaciones de Wi-Fi y detección de proximidad de Wi-Fi de forma simultánea.
[C-1-6] DEBE tener una precisión de 2 metros dentro del percentil 68 con un ancho de banda de 80 MHz (según el cálculo con la función de distribución acumulativa).
[C-1-7] DEBE realizar el rango de detección de proximidad (PD) en la banda de frecuencia disponible más alta (6 GHz, 5 GHz o 2.4 GHz) con el ancho de banda máximo admitido en el siguiente orden de prioridad: 160 MHz, 80 MHz, 40 MHz y 20 MHz.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que se informe con precisión dentro de un rango de 1.5 metros con un ancho de banda de 80 MHz en el percentil 68 (según se calcula con la función de distribución acumulada).
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que admitan el rango de NTB 802.11az.

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth, deben cumplir con lo siguiente:

DEBE admitir códecs de audio avanzados y códecs de audio Bluetooth (p.ej., LDAC).

Si las implementaciones de dispositivos admiten HFP, A2DP y AVRCP, deben cumplir con los siguientes requisitos:

DEBE admitir al menos 5 dispositivos conectados en total.

Si las implementaciones de dispositivos declaran la función android.hardware.vr.high_performance, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth de bajo consumo.

Android incluye compatibilidad con Bluetooth y Bluetooth de bajo consumo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo, deben cumplir con lo siguiente:

[C-2-1] DEBE declarar las funciones de la plataforma pertinentes (android.hardware.bluetooth y android.hardware.bluetooth_le, respectivamente) y, luego, implementar las APIs de la plataforma.
DEBE implementar perfiles de Bluetooth pertinentes, como A2DP, AVRCP, OBEX, HFP, etc., según corresponda al dispositivo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo (BLE), deben cumplir con lo siguiente:

[C-3-1] DEBE declarar la función de hardware android.hardware.bluetooth_le.
[C-3-2] DEBE habilitar las APIs de Bluetooth basadas en GATT (perfil de atributo genérico) como se describe en la documentación del SDK y android.bluetooth.
[C-3-3] DEBE informar el valor correcto para BluetoothAdapter.isOffloadedFilteringSupported() para indicar si se implementó la lógica de filtrado para las clases de la API de ScanFilter.
[C-3-4] DEBE informar el valor correcto para BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo.
[C-3-5] DEBE implementar un tiempo de espera de dirección privada resoluble (RPA) que no supere los 15 minutos y rotar la dirección al agotarse el tiempo de espera para proteger la privacidad del usuario cuando el dispositivo esté usando BLE de forma activa para la búsqueda o la publicidad. Para evitar ataques de sincronización, los intervalos de tiempo de espera TAMBIÉN DEBEN ser aleatorios y estar entre 5 y 15 minutos.
DEBE admitir la descarga de la lógica de filtrado en el chipset de Bluetooth cuando se implementa la API de ScanFilter.
DEBE admitir la descarga del análisis por lotes en el chipset de Bluetooth.
DEBE admitir varios anuncios con al menos 4 espacios.

Si las implementaciones de dispositivos admiten Bluetooth de bajo consumo y lo usan para la búsqueda de ubicación, deben cumplir con lo siguiente:

[C-4-1] DEBE proporcionar una indicación visual para el usuario que permita habilitar o inhabilitar la lectura del valor a través de la API del sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo y el perfil de audífonos, como se describe en Compatibilidad con audífonos a través de Bluetooth de bajo consumo, deben cumplir con lo siguiente:

[C-5-1] DEBE devolver true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo, deben cumplir con lo siguiente:

[C-6-1] DEBE restringir el acceso a cualquier metadato de Bluetooth (como los resultados de la búsqueda) que se pueda usar para derivar la ubicación del dispositivo, a menos que la app solicitante supere correctamente una verificación de permisos de android.permission.ACCESS_FINE_LOCATION según su estado actual en primer plano o en segundo plano.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo, y el manifiesto de la app no incluye una declaración del desarrollador que indique que no deriva la ubicación del Bluetooth, se aplican las siguientes condiciones:

[C-6-2] Se DEBE restringir el acceso al Bluetooth con android.permission.ACCESS_FINE_LOCATION.

Si las implementaciones de dispositivos devuelven true para la API de BluetoothAdapter.isLeAudioSupported(), deben hacer lo siguiente:

[C-7-1] DEBE admitir clientes de transmisión unidifusión.
[C-7-2] DEBE admitir PHY de 2 M.
[C-7-3] DEBE admitir la publicidad extendida de LE.
[C-7-4] DEBE admitir al menos 2 conexiones de CIS en un CIG.
[C-7-5] Se DEBEN habilitar simultáneamente el cliente de transmisión por unidifusión de BAP, el coordinador del conjunto de CSIP, el servidor de MCP, el controlador de VCP y el servidor de CCP.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE habilitar el cliente de transmisión unidifusión de HAP.

Si las implementaciones de dispositivos devuelven true para la API de BluetoothAdapter.isLeAudioBroadcastSourceSupported(), deben hacer lo siguiente:

[C-8-1] DEBE admitir al menos 2 vínculos de BIS en un BIG.
[C-8-2] DEBE habilitar la fuente de transmisión de BAP y el asistente de transmisión de BAP de forma simultánea.
[C-8-3] DEBE admitir la publicidad periódica de LE.

Si las implementaciones de dispositivos devuelven true para la API de BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), deben hacer lo siguiente:

[C-9-1] DEBE admitir PAST (Periodic Advertising Sync Transfer).
[C-9-2] DEBE admitir la publicidad periódica de LE.

Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE, deben cumplir con lo siguiente:

[C-10-1] Las mediciones de RSSI DEBEN estar 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 de 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 usan varias), se encuentren dentro de +/-3 dB entre sí para el 95% de las mediciones.

Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, deben cumplir con lo siguiente:

[C-11-1] DEBE informar la marca de función de hardware android.hardware.bluetooth_le.channel_sounding.
[C-11-2] DEBE informar el rango con precisión dentro de +/- 0.5 m en el percentil 90, según se calcula con la función de distribución acumulada, a la distancia de 1 m.

Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE, deben cumplir con lo siguiente:

[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE medir y compensar la compensación de Rx para garantizar que la mediana del RSSI de BLE sea de -60 dBm +/- 10 dB a 1 m de distancia de un dispositivo de referencia que transmita a ADVERTISE_TX_POWER_HIGH, donde los dispositivos estén orientados de modo que se encuentren en "planos paralelos" con las pantallas orientadas en la misma dirección.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE medir y compensar la compensación de Tx para garantizar que la mediana del RSSI de BLE sea de -60 dBm +/- 10 dB cuando se realice la búsqueda desde un dispositivo de referencia ubicado a 1 m de distancia y que transmita a ADVERTISE_TX_POWER_HIGH, donde los dispositivos estén orientados de modo que se encuentren en "planos paralelos" con las pantallas orientadas en la misma dirección.

SE RECOMIENDA ENCARECIDAMENTE seguir los pasos de configuración de la medición que se especifican en Requisitos de calibración de presencias.

7.4.4. Comunicaciones de campo cercano

Implementaciones de dispositivos:

DEBE incluir un transceptor y hardware relacionado para la comunicación de campo cercano (NFC).
[C-0-1] DEBE implementar las APIs de android.nfc.NdefMessage y android.nfc.NdefRecord, incluso si no incluyen compatibilidad con 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 apps de terceros, deben hacer lo siguiente:

[C-1-1] DEBE informar la función android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature().
DEBE poder leer y escribir mensajes NDEF a través de los siguientes estándares de NFC:
[C-1-2] DEBE poder actuar como lector/grabador de NFC Forum (según se define en la especificación técnica de NFC Forum NFCForum-TS-DigitalProtocol-1.0) a través de los siguientes estándares de NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NFCF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tipos de etiquetas 2, 3, 4 y 5 del NFC Forum (definidos por el NFC Forum)
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que sea capaz de leer y escribir mensajes NDEF, así como datos sin procesar a través de los siguientes estándares de NFC. Ten en cuenta que, si bien los estándares de NFC se indican como ALTAMENTE RECOMENDADOS, se prevé que la Definición de compatibilidad para una versión futura cambie estos estándares a OBLIGATORIOS. Estos estándares son opcionales en esta versión, pero serán obligatorios en versiones futuras. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecuten esta versión de Android cumplan con estos requisitos ahora para que puedan actualizarse a las versiones futuras de la plataforma.
[C-1-13] DEBE sondear todas las tecnologías admitidas mientras se encuentra en el modo de detección de NFC.
DEBE estar en modo de detección de NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.
DEBE poder leer el código de barras y la URL (si están codificados) de los productos Thinfilm NFC Barcode.

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

Android incluye compatibilidad con el modo de emulación de tarjeta de host (HCE) de NFC.

Si las implementaciones de dispositivos incluyen un chipset de controlador NFC capaz de HCE (para NfcA o NfcB) y admiten el enrutamiento del ID de aplicación (AID), deben cumplir con lo siguiente:

[C-2-1] DEBE informar la constante de función android.hardware.nfc.hce.
[C-2-2] DEBE admitir las APIs de HCE de NFC según se definen en el SDK de Android.

Si las implementaciones de dispositivos incluyen un chipset de controlador NFC capaz de HCE para NfcF y, además, implementan la función para aplicaciones de terceros, deben cumplir con lo siguiente:

[C-3-1] DEBE informar la constante de función android.hardware.nfc.hcef.
[C-3-2] DEBE implementar las APIs de emulación de tarjetas NfcF según se definen en el SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad general con NFC, como se describe en esta sección, y admiten tecnologías MIFARE (MIFARE Classic, MIFARE Ultralight y NDEF en MIFARE Classic) en el rol de lector/grabador, deben cumplir con lo siguiente:

[C-4-1] DEBE implementar las APIs de Android correspondientes según lo documenta el SDK de Android.
[C-4-2] DEBE informar la función com.nxp.mifare desde el método android.content.pm.PackageManager.hasSystemFeature(). Ten en cuenta que esta no es una función estándar de Android y, como tal, no aparece como una constante en la clase android.content.pm.PackageManager.

7.4.5. APIs y protocolos de redes

7.4.5.1. Capacidad de red mínima

Implementaciones de dispositivos:

[C-0-1] DEBE incluir compatibilidad con una o más formas de redes de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos capaz de alcanzar los 200 Kbit/s o más. Entre las tecnologías que satisfacen este requisito, se incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet y PAN de Bluetooth.
También DEBE incluir compatibilidad con al menos un estándar de datos inalámbricos común, como 802.11 (Wi-Fi), cuando un estándar de redes físicas (como Ethernet) sea 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 con las APIs administradas, como java.net.Socket y java.net.URLConnection, así como las APIs 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 la IPv4, por ejemplo:
[C-0-4] DEBE mantener la conectividad IPv6 en el modo de suspensión.
[C-0-5] La limitación de velocidad NO DEBE provocar que el dispositivo pierda la conectividad IPv6 en ninguna red compatible con IPv6 que use tiempos de vida de RA de al menos 180 segundos.
[C-0-6] DEBE proporcionar a las aplicaciones de terceros conectividad IPv6 directa a la red cuando se conecten a una red IPv6, sin que se produzca ninguna forma de traducción de direcciones o puertos de forma local en el dispositivo. Tanto las APIs administradas, como Socket#getLocalAddress o Socket#getLocalPort, como las APIs del NDK, como getsockname() o IPV6_PKTINFO, DEBEN devolver la dirección IP y el puerto que se usan realmente para enviar y recibir paquetes en la red, y que son visibles como la IP y el puerto de origen para los 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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el funcionamiento de pila doble y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos admiten Ethernet, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE admitir el funcionamiento de pila doble y solo IPv6 en Ethernet.

Si las implementaciones de dispositivos admiten datos móviles, deben cumplir con los siguientes requisitos:

[C-3-1] DEBE admitir el funcionamiento de IPv6 (solo IPv6 y, posiblemente, pila doble) en redes celulares.

Si las implementaciones de dispositivos admiten más de un tipo de red (p.ej., Wi-Fi y datos celulares), deben cumplir con lo siguiente:

[C-4-1] DEBE cumplir simultáneamente con 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 es una red que requiere acceso para obtener conexión a Internet.

Si las implementaciones de dispositivos proporcionan una implementación completa de android.webkit.Webview API, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una aplicación de portal cautivo para controlar el intent ACTION_CAPTIVE_PORTAL_SIGN_IN y mostrar la página de acceso del portal cautivo, enviando ese intent, en la llamada a la API del sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] DEBE realizar la detección de portales cautivos y admitir el acceso a través de la aplicación de portal cautivo cuando el dispositivo esté conectado a cualquier tipo de red, incluidas las redes celulares o móviles, Wi-Fi, Ethernet o Bluetooth.
[C-1-3] DEBE admitir el acceso a portales cautivos con DNS de texto no cifrado cuando el dispositivo esté configurado para usar el modo estricto de DNS privado.
[C-1-4] DEBE usar DNS encriptado 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 comunique de forma explícita con el portal cautivo.
[C-1-5] DEBE garantizar que, mientras el usuario accede a un portal cautivo, la red predeterminada que usan las aplicaciones (como la que devuelven ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback y la que usan de forma predeterminada las APIs de redes de Java, como java.net.Socket, y las APIs nativas, como connect()) sea 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 activado el parámetro de configuración de sincronización automática principal de forma predeterminada para que el método getMasterSyncAutomatically() devuelva "true".

7.4.7. Ahorro de datos

Si las implementaciones de dispositivos incluyen una conexión medida, se aplican las siguientes condiciones:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar el modo de ahorro de datos.

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir todas las APIs 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, deben hacer lo siguiente:

[C-2-1] DEBE devolver el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
[C-2-2] NO DEBE emitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos seguros

Si las implementaciones de dispositivos admiten elementos seguros compatibles con la API de Open Mobile y los ponen a disposición de las apps de terceros, deben hacer lo siguiente:

[C-1-1] DEBE enumerar los lectores de elementos seguros disponibles a través de la API de android.se.omapi.SEService.getReaders().
[C-1-2] DEBE declarar los parámetros de configuración correctos de las funciones a través de android.hardware.se.omapi.uicc para el dispositivo con elementos seguros basados en UICC, android.hardware.se.omapi.ese para el dispositivo con elementos seguros basados en eSE y android.hardware.se.omapi.sd para el dispositivo con elementos seguros basados en SD.

7.4.9. UWB

Si las implementaciones de dispositivos incluyen compatibilidad con 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar la API de Android correspondiente en android.uwb.
[C-1-2] DEBE informar la marca de función de hardware android.hardware.uwb.
[C-1-3] DEBE admitir todos los perfiles de UWB pertinentes definidos en la implementación de Android.
[C-1-4] DEBE proporcionar una indicación visual para que el usuario pueda activar o desactivar la radio UWB.
[C-1-5] DEBE aplicar que las apps que usan radio UWB tengan el permiso UWB_RANGING (en el grupo de permisos NEARBY_DEVICES).
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que superen las pruebas de certificación y cumplimiento pertinentes definidas por las organizaciones de estándares, incluidas FIRA, CCC y CSA.
[C-1-6] DEBE garantizar que las mediciones de distancia se encuentren dentro de +/-15 cm para el 95% de las mediciones en el entorno de 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 del dispositivo de referencia se encuentre dentro del rango [0.75 m, 1.25 m], en el que la distancia real se mide desde el borde superior del DUT.
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE seguir los pasos de configuración de la medición especificados en Requisitos de calibración de presencia.

7.5. Cámaras

Si las implementaciones de dispositivos incluyen al menos una cámara, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la marca de función android.hardware.camera.any.
[C-1-2] La aplicación DEBE poder asignar simultáneamente 3 mapas de bits de 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 la vista previa básica y la captura de fotos.
[C-1-3] DEBE garantizar que la aplicación de cámara predeterminada preinstalada que controla los intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE sea responsable de quitar la ubicación del usuario en los metadatos de la imagen antes de enviarla a la aplicación receptora cuando esta no tenga ACCESS_FINE_LOCATION.

Si las implementaciones de dispositivos incluyen al menos una cámara y la aplicación de cámara preinstalada controla los intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE o MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, se deben cumplir los siguientes requisitos:

[C-1-4] DEBE garantizar que, cuando se controlen estos intents, la app de cámara preinstalada quite la ubicación del usuario en los metadatos de la imagen antes de enviarla a las aplicaciones receptoras que no tengan ACCESS_FINE_LOCATION.
[C-1-5] DEBE garantizar que la foto en movimiento devuelta use la especificación del formato de Foto en movimiento 1.0.

[C-1-6] SE DEBE etiquetar cada tipo de dispositivo de cámara con el campo CameraCharacteristics.INFO_DEVICE_TYPE como BUILT_IN, EXTERNAL o VIRTUAL. También DEBE etiquetar cada fotograma de salida de la cámara con el campo CaptureResult.INFO_DEVICE_TYPE.
Asegurarse de que CaptureResult.INFO_DEVICE_TYPE esté etiquetado correctamente es especialmente importante en situaciones en las que el ID de la cámara se reasigna de forma dinámica a una fuente de cámara diferente.

Si las implementaciones de dispositivos admiten la capacidad de salida de HDR de 10 bits, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir al menos el perfil HDR HLG 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 trasera o la cámara principal frontal.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que admitan la salida de 10 bits para ambas cámaras principales.
[C-2-3] DEBE admitir los mismos perfiles HDR para todas las cámaras secundarias físicas compatibles con BACKWARD_COMPATIBLE de una cámara lógica y para la cámara lógica en sí.

En el caso de los dispositivos de cámara lógica que admiten HDR de 10 bits y que implementan la API de android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, se aplican las siguientes condiciones:

[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 posterior

Una cámara trasera es una cámara orientada al mundo que capta imágenes de escenas en el lado opuesto del dispositivo, como una cámara tradicional. En los dispositivos portátiles, es una cámara ubicada en el lado del dispositivo opuesto a la pantalla.

Implementaciones de dispositivos:

DEBE incluir una cámara posterior.

Si las implementaciones de dispositivos incluyen al menos una cámara trasera, deben cumplir con lo siguiente:

[C-1-1] DEBE informar las marcas 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 para el software de la aplicación).
PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
PUEDE incluir un flash.

Si la cámara incluye un flash, haz lo siguiente:

[C-2-1] La lámpara del flash NO DEBE encenderse mientras se haya registrado una instancia de android.hardware.Camera.PreviewCallback en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un objeto Camera.Parameters. Ten en cuenta que esta restricción no se aplica a la aplicación de cámara integrada en el sistema del dispositivo, sino solo a las aplicaciones de terceros que usan Camera.PreviewCallback.

7.5.2. Cámara frontal

Una cámara frontal es una cámara orientada al usuario que se suele usar para tomar imágenes del usuario, por ejemplo, para videoconferencias y aplicaciones similares. En los dispositivos portátiles, es una cámara ubicada en el mismo lado del dispositivo que la pantalla.

Implementaciones de dispositivos:

PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, deben cumplir con lo siguiente:

[C-1-1] DEBE informar las marcas de función android.hardware.camera.any y android.hardware.camera.front.
[C-1-2] DEBE tener una resolución de al menos VGA (640 × 480 píxeles).
[C-1-3] NO DEBE usar una cámara frontal como la predeterminada para la API de Camera y NO DEBE configurar la API para que trate una cámara frontal como la cámara trasera predeterminada, incluso si es la única cámara del dispositivo.
[C-1-4] La vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación especificada por la aplicación cuando la aplicación actual solicitó explícitamente que la pantalla de la cámara se rotara a través de una llamada al método android.hardware.Camera.setDisplayOrientation(). Por el contrario, la vista previa DEBE duplicarse a lo largo del eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicita explícitamente que la pantalla de la cámara se rote a través de una llamada al método android.hardware.Camera.setDisplayOrientation().
[C-1-5] NO DEBE duplicar la imagen estática final capturada ni los flujos de video que se devuelven a las devoluciones de llamada de la aplicación o que se confirman en el almacenamiento de medios.
[C-1-6] DEBE reflejar la imagen que muestra la vista previa de la publicación de la misma manera que el flujo de imágenes de la vista previa de la cámara.
PUEDE incluir funciones (como enfoque automático, flash, etcétera) disponibles para las cámaras posteriores, como se describe en la sección 7.5.1.

Si las implementaciones de dispositivos pueden rotarse por el usuario (por ejemplo, automáticamente a través de un acelerómetro o manualmente a través de 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

Una cámara externa es una cámara que se puede conectar o desconectar físicamente de la implementación del dispositivo en cualquier momento y puede apuntar en cualquier dirección, como las cámaras USB.

Implementaciones de dispositivos:

PUEDE incluir compatibilidad con una cámara externa que no necesariamente está siempre conectada.

Si las implementaciones de dispositivos incluyen compatibilidad con una cámara externa, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar las marcas de funciones de la plataforma android.hardware.camera.external y android.hardware camera.any.
[C-1-2] DEBE admitir la clase de video USB (UVC 1.0 o posterior) si la cámara externa se conecta a través del puerto de host USB.
[C-1-3] DEBE aprobar las pruebas de CTS de la cámara con un dispositivo de cámara externa física conectado. Los detalles de las pruebas de CTS de la cámara están disponibles en source.android.com.
DEBE admitir compresiones de video, como MJPEG, para permitir la transferencia de transmisiones sin codificar de alta calidad (es decir, transmisiones de imágenes sin procesar o comprimidas de forma independiente).
El MAY puede admitir varias cámaras.
PUEDE admitir la codificación de video basada en la cámara.

Si se admite la codificación de video basada en la cámara, haz lo siguiente:

[C-2-1] La implementación del dispositivo DEBE poder acceder a una transmisión simultánea sin codificar o MJPEG (resolución QVGA o superior).

7.5.4. Comportamiento de la API de Camera

Android incluye dos paquetes de APIs para acceder a la cámara. La API de android.hardware.camera2 más reciente expone el control de la cámara de nivel inferior a la app, incluidos los flujos eficientes de ráfaga o transmisión sin copia y los controles por fotograma de exposición, ganancia, ganancias de balance de blancos, conversión de color, reducción de ruido, nitidez y mucho más.

El paquete de API anterior, android.hardware.Camera, se marcó como en desuso en Android 5.0, pero debería seguir disponible para que las apps lo usen. Las implementaciones de dispositivos Android DEBEN garantizar la compatibilidad continua con la API, como se describe en esta sección y en el SDK de Android.

Todas las funciones que son comunes entre la clase android.hardware.Camera obsoleta y el paquete android.hardware.camera2 más reciente DEBEN tener un rendimiento y una calidad equivalentes en ambas APIs. Por ejemplo, con la misma configuración, la velocidad y la 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 funciones que dependen de la diferente semántica de las dos APIs tengan la misma velocidad o calidad, pero DEBEN coincidir lo más posible.

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara, en todas las cámaras disponibles. Implementaciones de dispositivos:

[C-0-1] DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para los datos de vista previa proporcionados a las devoluciones de llamada de la aplicación cuando una aplicación nunca llamó a android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] DEBE estar en formato de codificación NV21 cuando una aplicación registra una instancia de android.hardware.Camera.PreviewCallback, el sistema llama al método onPreviewFrame() y el formato de vista previa es YCbCr_420_SP, los datos en el byte[] que se pasa a onPreviewFrame(). Es decir, NV21 DEBE ser el valor predeterminado.
[C-0-3] DEBE admitir el formato YV12 (como lo indica la constante android.graphics.ImageFormat.YV12) para las vistas previas de la cámara frontal y posterior para android.hardware.Camera. (El codificador de video y la cámara de hardware 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 de android.media.ImageReader para los dispositivos android.hardware.camera2 que anuncian la capacidad de REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities.
[C-0-5] DEBE implementar la API de Camera completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático por hardware o cualquier otra capacidad. Por ejemplo, las cámaras que no tienen enfoque automático DEBEN llamar a las instancias de android.hardware.Camera.AutoFocusCallback registradas (aunque esto no sea relevante para una cámara sin enfoque automático). Ten en cuenta que esto se aplica a las cámaras frontales. Por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API deben "simularse" 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 reconocer ni tener en cuenta las constantes de cadena que se pasan al método android.hardware.Camera.setParameters(), excepto las que se documentan como constantes en android.hardware.Camera.Parameters. Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de la cámara estándar si el hardware lo permite y NO DEBEN admitir tipos de parámetros de la cámara personalizados. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes con técnicas de imágenes de alto rango dinámico (HDR) DEBEN admitir el parámetro de la cámara Camera.SCENE_MODE_HDR.
[C-0-7] DEBE informar el nivel de compatibilidad adecuado con la propiedad android.info.supportedHardwareLevel, como se describe en el SDK de Android, y los marcas de funciones del framework correspondientes.
[C-0-8] TAMBIÉN DEBE declarar las capacidades individuales de la cámara de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar las marcas de función adecuadas; DEBE definir la marca de función si alguno de los dispositivos de cámara adjuntos admite la función.
[C-0-9] DEBE transmitir la intención Camera.ACTION_NEW_PICTURE cada vez que la cámara tome una foto nueva y se agregue la entrada de la foto al almacén de medios.
[C-0-10] DEBE transmitir la intención Camera.ACTION_NEW_VIDEO cada vez que la cámara grabe un video nuevo y se agregue la entrada de la imagen al almacén de medios.
[C-0-11] Todas las cámaras a las que se puede acceder a través de la API android.hardware.Camera obsoleta TAMBIÉN deben ser accesibles a través de la API android.hardware.camera2.
[C-0-12] DEBE garantizar que la apariencia facial NO se altere, lo que incluye, sin limitaciones, la alteración de la geometría facial, el tono de piel facial o el suavizado de la piel facial para cualquier API de android.hardware.camera2 o android.hardware.Camera.
[C-SR-1] En el caso de los dispositivos con varias cámaras RGB muy cerca y orientadas en la misma dirección, se RECOMIENDA ENCARECIDAMENTE admitir un dispositivo de cámara lógica que incluya la capacidad CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, que consta de todas las cámaras RGB orientadas en esa dirección como subdispositivos físicos.

Si las implementaciones de dispositivos proporcionan una API de cámara propietaria a apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar esa API de cámara con la API de android.hardware.camera2.
PUEDE proporcionar etiquetas o extensiones del proveedor a la API de android.hardware.camera2.

Si las implementaciones de dispositivos ajustan su canalización de cámara de terceros para que sea equivalente a su canalización de cámara integrada para la cámara frontal principal y la cámara posterior principal, hacen lo siguiente:

[C-2-1] DEBE declarar la propiedad del sistema ro.camera.default_app_social_media_parity_enabled.

7.5.5. Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o posterior, estas cámaras deben cumplir con los siguientes requisitos:

[C-1-1] DEBE orientarse de modo que la dimensión larga de la cámara se alinee con la dimensión larga de la pantalla. Es decir, cuando el dispositivo se 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 los dispositivos con orientación horizontal principal como a los dispositivos con orientación vertical principal.

Los dispositivos que cumplen con cualquiera de los siguientes criterios están exentos de este requisito:
- El dispositivo implementa pantallas de geometría variable, como pantallas plegables o con bisagras, Y cuando cambia el estado de plegado o de bisagra del dispositivo, este cambia entre las orientaciones vertical principal y horizontal principal (o viceversa).
- Implementaciones de dispositivos que el usuario no puede rotar, como los dispositivos para automóviles.

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 poder descargar archivos individuales de al menos 100 MB de tamaño en la ubicación predeterminada de "caché".

7.6.2. Almacenamiento compartido de la aplicación

Implementaciones de dispositivos:

[C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, también conocido como "almacenamiento externo compartido", "almacenamiento compartido de aplicaciones" o por la ruta de Linux "/sdcard" en la que se monta.
[C-0-2] DEBE configurarse con el almacenamiento compartido activado de forma predeterminada, es decir, "listo para usar", independientemente de si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (p.ej., ranura para tarjeta Secure Digital).
[C-0-3] DEBE montar el almacenamiento compartido de la aplicación directamente en la ruta de Linux sdcard o incluir un vínculo simbólico de Linux desde sdcard hasta el punto de montaje real.
[C-0-4] DEBE habilitar el almacenamiento específico de forma predeterminada para todas las apps que se segmenten para el nivel de API 29 o superior, excepto en la siguiente situación:
- Cuando la app solicitó android:requestLegacyExternalStorage="true" en su manifiesto
[C-0-5] DEBE ocultar los metadatos de ubicación, como las etiquetas Exif de GPS, almacenados en archivos multimedia cuando se accede a ellos a través de MediaStore, excepto cuando la app que realiza la llamada tiene el permiso ACCESS_MEDIA_LOCATION.

Las implementaciones de dispositivos PUEDEN cumplir con los requisitos anteriores con cualquiera de las siguientes opciones:

Almacenamiento extraíble al que puede acceder el usuario, como una ranura para tarjetas Secure Digital (SD).
Es una parte del almacenamiento interno (no extraíble) tal como se implementa en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones de dispositivos usan almacenamiento extraíble para satisfacer los requisitos anteriores, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar una interfaz de usuario de aviso o ventana emergente que advierta al usuario cuando no haya ningún medio de almacenamiento insertado en la ranura.
[C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (p.ej., una tarjeta SD) o mostrar en la caja y en otro material disponible en el momento de la compra que el medio de almacenamiento se debe comprar por separado.

Si las implementaciones de dispositivos usan una parte del almacenamiento no extraíble para satisfacer los requisitos anteriores, deben hacer lo siguiente:

DEBE usar la implementación del AOSP del almacenamiento compartido interno de la aplicación.
PUEDE compartir el espacio de almacenamiento con los datos privados de la aplicación.

Si las implementaciones de dispositivos tienen un puerto USB con compatibilidad con el modo periférico USB, deben cumplir con lo siguiente:

[C-3-1] DEBE proporcionar un mecanismo para acceder a los datos del almacenamiento compartido de la aplicación desde una computadora host.
DEBE exponer 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 el 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, deben cumplir con lo siguiente:

DEBE ser compatible con el host de referencia de MTP de Android, 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 móvil, a diferencia de la televisión, las implementaciones del dispositivo son las siguientes:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlo accidentalmente puede provocar la pérdida o 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 o de otra cubierta protectora, las implementaciones del dispositivo son las siguientes:

[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE implementar el almacenamiento adoptable.

7.7. USB

Definiciones

El modo de host USB se da cuando la implementación de un dispositivo actúa como host USB, proporciona energía al bus y se comunica con los periféricos.
El modo de dispositivo USB (también conocido como modo periférico USB) se produce cuando una implementación de dispositivo actúa como periférico USB, se conecta a un host a través de un puerto ascendente y responde a las solicitudes del host.
Un puerto USB se define como un mecanismo para proporcionar conectividad USB, ya sea un receptáculo USB físico o una interfaz no estándar (por ejemplo, pines de conexión).

Si las implementaciones de dispositivos tienen un puerto USB, deben cumplir con lo siguiente:

DEBE admitir el modo de dispositivo USB.
DEBE admitir el modo host USB.
DEBE admitir la inhabilitación de la señalización de datos por USB.

7.7.1. Modo de dispositivo USB

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de dispositivo periférico, haz lo siguiente:

[C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar de tipo A o tipo C.
[C-1-2] DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo estándar de 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 de Type-C y DEBE detectar cambios en el anuncio si admiten USB Type-C.

[C-SR-1] El puerto DEBE usar 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 las versiones futuras de la plataforma.

[C-SR-2] El puerto DEBE ubicarse en la parte inferior del dispositivo (según la orientación natural) o habilitar la rotación de pantalla por software para todas las apps (incluida la pantalla principal), de modo que la pantalla se dibuje correctamente cuando el dispositivo se oriente 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 versiones futuras de la plataforma.
[C-SR-3] DEBE implementar la compatibilidad para extraer una corriente de 1.5 A durante el chirrido de HS y el tráfico, como se especifica en la especificación de carga de batería por USB, revisión 1.2. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a los futuros lanzamientos de la plataforma.
[C-SR-4] SE RECOMIENDA ENCARECIDAMENTE que no admitan métodos de carga propietarios que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o que alteren los roles de fuente o receptor, ya que esto puede generar problemas de interoperabilidad con los cargadores o dispositivos que admiten los métodos estándar de USB Power Delivery. Si bien se indica como "ALTAMENTE RECOMENDADO", en futuras versiones de Android, es posible que EXIJAMOS que todos los dispositivos tipo C admitan la interoperabilidad completa con los cargadores tipo C estándar.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE que admitan Power Delivery para el intercambio de roles de datos y alimentación cuando admitan USB Type-C y el modo de host USB.
DEBE admitir Power Delivery para la carga de alto voltaje y los modos alternativos, como la salida de pantalla.
DEBE implementar la API y la especificación de Android Open Accessory (AOA) como se documenta en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen un puerto USB y cumplen con la especificación de AOA, deben hacer lo siguiente:

[C-2-1] DEBE declarar la 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 cadena iInterface de descripción de la interfaz del almacenamiento masivo USB.

7.7.2. Modo de host USB

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de host, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar la API de host USB de Android como se documenta en el SDK de Android y DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.host.
[C-1-2] DEBE implementar compatibilidad para conectar periféricos USB estándar. DEBE tener uno de los siguientes documentos:
- Un puerto USB Type-C integrado en el dispositivo o que se envíe con cables que adapten un puerto propietario integrado en el dispositivo a un puerto USB Type-C estándar (dispositivo USB Type-C).
- Un puerto USB tipo A integrado en el dispositivo o cables que adapten un puerto propietario integrado en el dispositivo a un puerto USB tipo A estándar
- Un puerto micro-AB USB integrado en el dispositivo, que DEBE incluir un cable adaptador a un puerto USB estándar de tipo A.
[C-1-3] NO DEBE incluir un adaptador que convierta puertos USB tipo A o micro-AB en un puerto USB 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 de host, anunciar una corriente de fuente de al menos 1.5 A como se especifica en la sección Termination Parameters de la USB Type-C Cable and Connector Specification Revision 1.2 para los conectores USB Type-C o usar el rango de corriente de salida del puerto de carga descendente (CDP) como se especifica en las especificaciones de carga de batería USB, revisión 1.2 para los conectores Micro-AB.
DEBE implementar y admitir los estándares de USB Type-C.

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de host y la clase de audio USB, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir la clase HID de USB.
[C-2-2] DEBE admitir la detección y la asignación de los siguientes campos de datos HID especificados en las Tablas de uso de HID de USB y la Solicitud de uso de comandos por voz a las constantes de KeyEvent como se indica 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 de host y el framework de acceso al almacenamiento (SAF), deben cumplir con lo siguiente:

[C-3-1] DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia de medios) conectado de forma remota 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 de host y USB Type-C, deben cumplir con lo siguiente:

[C-4-1] DEBE implementar la funcionalidad de alimentación de doble función (DRP) según se define en la especificación de USB Type-C (sección 4.5.1.3.3). En el caso de los puertos DRP, en los dispositivos que incluyen un conector de audio de 3.5 mm, es POSIBLE que la detección del receptor de alimentación USB (modo host) esté desactivada de forma predeterminada, pero el usuario DEBE poder habilitarla.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que admitan DisplayPort.
- DEBE admitir velocidades de datos USB SuperSpeed.
- SE RECOMIENDAN ENCARECIDAMENTE para admitir Power Delivery para el intercambio de roles de datos y energía.
[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE NO admitir el modo de accesorio de adaptador de audio, como se describe en el Apéndice A de la Especificación de conector y cable USB Type-C, revisión 1.2.
DEBE implementar el modelo Try.* más adecuado para el factor de forma del dispositivo. Por ejemplo, un dispositivo de mano DEBE implementar el modelo Try.SNK.

7.7.3. USB Power Delivery

Si las implementaciones de dispositivos incluyen un puerto USB Type-C, deben cumplir con lo siguiente:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar la clase de conector USB Type-C del kernel y los nodos necesarios que describen las conexiones USB Type-C y los roles de alimentación y datos. Consulta la documentación sobre el conector USB Type-C de Android para obtener detalles sobre la implementación.

Si las implementaciones de dispositivos incluyen un puerto USB Type-C y admiten Power Delivery, deben cumplir con lo siguiente:

[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE implementar todos los nodos que describen USB Power Delivery. Consulta la documentación sobre USB PD de Android para obtener detalles de la implementación.

Si las implementaciones de dispositivos incluyen un puerto USB Type-C y admiten modos alternativos, deben cumplir con lo siguiente:

[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE implementar los modos alternativos y las propiedades relacionadas con la identidad de la clase de conector USB Type-C del kernel. Consulta la documentación sobre el conector USB Type-C de Android para obtener detalles sobre la implementación.

Si las implementaciones de dispositivos incluyen un puerto USB Type-C y admiten el modo alternativo Thunderbolt 3, deben cumplir con lo siguiente:

[C-SR-4] Se RECOMIENDA ENCARECIDAMENTE implementar la capacidad de anular el modo alternativo actual a través de la clase de conector tipo C.

7.8. Audio

7.8.1. Micrófono

Si las implementaciones de dispositivos incluyen un micrófono, deben cumplir con lo siguiente:

[C-1-1] DEBE informar la constante de función android.hardware.microphone.
[C-1-2] DEBE cumplir con los requisitos de grabación de audio que se indican en la sección 5.4.
[C-1-3] DEBE cumplir con los requisitos de latencia de audio que se indican en la sección 5.6.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que admitan la grabación de cerca del ultrasonido, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos omiten un micrófono, deben cumplir con lo siguiente:

[C-2-1] NO DEBE informar la constante de función android.hardware.microphone.
[C-2-2] DEBE implementar la API de grabación de audio al menos como no-ops, según la sección 7.

7.8.2. Salida de audio

Si las implementaciones de dispositivos incluyen una bocina o un puerto de salida de audio o multimedia para un periférico de salida de audio, como un conector de audio de 3.5 mm de 4 conductores o un puerto en modo host USB que use la clase de audio USB, deben cumplir con lo siguiente:

[C-1-1] DEBE informar la constante de función android.hardware.audio.output.
[C-1-2] DEBE cumplir con los requisitos de reproducción de audio que se indican en la sección 5.5.
[C-1-3] DEBE cumplir con los requisitos de latencia de audio que se indican en la sección 5.6.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE admitir la reproducción de sonido casi ultrasónico como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos no incluyen una bocina o un puerto de salida de audio, deben cumplir con lo siguiente:

[C-2-1] NO DEBE informar la función android.hardware.audio.output.
[C-2-2] DEBE implementar las APIs relacionadas con la salida de audio como no-ops, al menos.

Para los fines 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 en modo host USB con clase de audio USB. La compatibilidad con la salida de audio a través de protocolos basados en radio, como Bluetooth, Wi-Fi o redes celulares, no se considera como la inclusión de un "puerto de salida".

7.8.2.1. Puertos de audio analógicos

Para que sean compatibles con los auriculares y otros accesorios de audio que usan el conector de audio de 3.5 mm en todo el ecosistema de Android, si las implementaciones de dispositivos incluyen uno o más puertos de audio analógicos, deben cumplir con lo siguiente:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE que se incluya al menos un puerto de audio que sea un conector de audio de 3.5 mm con 4 conductores.

Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm con 4 conductores, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares con micrófono.
[C-1-2] DEBE admitir conectores de audio TRRS con el orden de pines de CTIA.
[C-1-3] DEBE admitir la detección y la asignación a los códigos de teclas de los siguientes 3 rangos de impedancia equivalente entre los conductores del micrófono y de tierra en el conector de audio:
- 70 ohmios o menos: KEYCODE_HEADSETHOOK
- 210 a 290 ohm: KEYCODE_VOLUME_UP
- 360 a 680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] DEBE activar ACTION_HEADSET_PLUG cuando se inserta un conector, pero solo después de que todos los contactos del conector toquen sus segmentos correspondientes en el conector hembra.
[C-1-5] DEBE poder generar al menos 150 mV ± 10% de voltaje de salida en una impedancia de bocina de 32 ohmios.
[C-1-6] DEBE tener un voltaje de polarización del micrófono entre 1.8 V y 2.9 V.
[C-1-7] DEBE detectar y asignar el código de tecla para el siguiente rango de impedancia equivalente entre los conductores del micrófono y de tierra en el conector de audio:
- 110 a 180 ohm: KEYCODE_VOICE_ASSIST
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que admitan conectores de audio con el orden de pines OMTP.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE que admitan 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 con 4 conductores y admiten un micrófono, y transmiten android.intent.action.HEADSET_PLUG con el micrófono de valor adicional establecido en 1, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir la detección del micrófono en el accesorio de audio conectado.

7.8.2.2. Puertos de audio digital

Consulta la sección 2.2.1 para conocer los requisitos específicos de cada dispositivo.

7.8.3. Cercano al ultrasonido

El audio casi ultrasónico se encuentra en la banda de 18.5 a 20 kHz.

Implementaciones de dispositivos:

DEBE informar correctamente la compatibilidad con la capacidad de audio cercano al ultrasonido a través de la API de AudioManager.getProperty de la siguiente manera:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es "true", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED DEBEN cumplir con los siguientes requisitos:

[C-1-1] La respuesta de potencia media del micrófono en la banda de 18.5 kHz a 20 kHz NO DEBE ser más de 15 dB inferior a la respuesta a 2 kHz.
[C-1-2] La relación señal-ruido no ponderada del micrófono en el rango de 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS DEBE ser de al menos 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es "true", haz lo siguiente:

[C-2-1] La respuesta media del altavoz en el rango de 18.5 kHz a 20 kHz NO DEBE ser 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 se define con cero fallas medidas durante una prueba de un minuto por ruta. Realiza pruebas con OboeTester "Prueba de fallas automatizada".

La prueba requiere un adaptador de bucle invertido de audio, que se usa directamente en un conector de 3.5 mm y/o en combinación con un adaptador de USB-C a 3.5 mm. Se DEBEN probar todos los puertos de salida de audio.

Actualmente, OboeTester admite rutas de AAudio, por lo que se DEBEN probar las siguientes combinaciones para detectar fallas con AAudio:

Modo de rendimiento	Uso compartido	Tasa de muestreo de salida	En Chans	Canales externos
LOW_LATENCY	EXCLUSIVO	SIN ESPECIFICAR	1	2
LOW_LATENCY	EXCLUSIVO	SIN ESPECIFICAR	2	1
LOW_LATENCY	COMPARTIDO	SIN ESPECIFICAR	1	2
LOW_LATENCY	COMPARTIDO	SIN ESPECIFICAR	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 una onda sinusoidal de 2,000 Hz.

Transductor	THD	SNR
Bocina integrada principal, medida con un micrófono de referencia externo	< 3.0%	>= 50 dB
Micrófono integrado principal, medido con una bocina de referencia externa	< 3.0%	>= 50 dB
conectores analógicos integrados de 3.5 mm, probados con un adaptador de bucle	< 1%	>= 60 dB
Adaptadores USB incluidos con el teléfono, probados con el adaptador de bucle	< 1.0%	>= 60 dB

7.9. Realidad virtual

Android incluye APIs y herramientas para compilar aplicaciones de "realidad virtual" (RV), incluidas experiencias de RV móvil de alta calidad. Las implementaciones de dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

7.9.1. Modo de realidad virtual

Android incluye compatibilidad con el modo VR, una función que controla la renderización estereoscópica de las notificaciones y que inhabilita los componentes de la IU del sistema monoculares mientras una aplicación de VR tiene el enfoque del usuario.

7.9.2. Modo de realidad virtual: Alto rendimiento

Si las implementaciones de dispositivos admiten el modo de RV, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE tener al menos 2 núcleos físicos.
[C-1-2] DEBE declarar la función android.hardware.vr.high_performance.
[C-1-3] DEBE admitir el modo de rendimiento sostenido.
[C-1-4] DEBE admitir OpenGL ES 3.2.
[C-1-5] DEBE admitir android.hardware.vulkan.level 0.
DEBE admitir android.hardware.vulkan.level 1 o una versión posterior.
[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 y exponer las extensiones en la lista de extensiones de 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 de GL disponibles.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array y GL_OVR_multiview_multisampled_render_to_texture, y exponer las extensiones en la lista de extensiones de GL disponibles.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que admitan Vulkan 1.1.
[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing y 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 filas de Vulkan en la que flags contenga tanto VK_QUEUE_GRAPHICS_BIT como 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 renderización con ojos alternados del contenido de RV a 60 FPS con dos contextos de renderización se muestre sin artefactos de desgarro visibles.
[C-1-9] DEBE implementar la compatibilidad con las marcas 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 la compatibilidad con AHardwareBuffers con cualquier combinación de las marcas de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para, al menos, los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM y AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] SE RECOMIENDA ENCARECIDAMENTE que admitan la asignación de AHardwareBuffers con más de una capa y marcas y formatos especificados en C-1-10.
[C-1-11] DEBE admitir la decodificación H.264 de al menos 3840 x 2160 a 30 FPS, comprimida a un promedio de 40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 FPS y 10 Mbps o 2 instancias de 1920 x 1080 a 60 FPS y 20 Mbps).
[C-1-12] DEBE admitir HEVC y VP9, DEBE ser capaz de decodificar al menos 1920 x 1080 a 30 FPS comprimido a un promedio de 10 Mbps y DEBE ser capaz de decodificar 3840 x 2160 a 30 FPS y 20 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 FPS y 5 Mbps).
[C-1-13] DEBE admitir la API de HardwarePropertiesManager.getDeviceTemperatures y devolver valores precisos para la temperatura cutánea.
[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 que tengan una resolución de pantalla de al menos 2560 x 1440.
[C-1-15] La pantalla DEBE actualizarse a una frecuencia de al menos 60 Hz en el modo de VR.
[C-1-17] La pantalla DEBE admitir un modo de baja persistencia con una persistencia ≤ 5 milisegundos. La persistencia se define como la cantidad de tiempo durante la cual un píxel emite luz.
[C-1-18] DEBE admitir Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth de bajo consumo sección 7.4.3.
[C-1-19] DEBE admitir y registrar correctamente 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 que admitan el tipo de canal directo TYPE_HARDWARE_BUFFER para todos los tipos de canales directos mencionados anteriormente.
[C-1-21] DEBE cumplir con los requisitos relacionados con el giroscopio, el acelerómetro y el 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 no superior a 28 milisegundos.
[C-SR-9] Se RECOMIENDA ENCARECIDAMENTE que la latencia de movimiento a fotón de extremo a extremo no sea superior a 20 milisegundos.
[C-1-23] DEBE tener una relación de primer fotograma, que es la relación entre el brillo de los píxeles en el primer fotograma después de una transición de negro a blanco y el brillo de los píxeles blancos en estado estable, de al menos el 85%.
[C-SR-10] SE RECOMIENDA ENCARECIDAMENTE que tengan una proporción de primer fotograma de, al menos, el 90%.
PUEDE proporcionar un núcleo exclusivo a la aplicación en primer plano y PUEDE admitir la API de Process.getExclusiveCores para devolver la cantidad de núcleos de CPU que son exclusivos de la aplicación en primer plano superior.

Si se admite el uso exclusivo del núcleo, este debe cumplir con los siguientes requisitos:

[C-2-1] NO DEBE permitir que se ejecuten otros procesos del espacio del usuario (excepto los controladores de dispositivos que usa la aplicación), pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.

7.10. Tecnología háptica

Los dispositivos que se sostienen o se usan en la mano pueden incluir un actuador háptico de uso general, disponible para las aplicaciones con fines como llamar la atención a través de tonos de llamada, alarmas, notificaciones y comentarios táctiles generales.

Si las implementaciones de dispositivos NO incluyen un actuador háptico de uso general, deben cumplir con lo siguiente:

[7.10/C] DEBE devolver falso para Vibrator.hasVibrator().

Si las implementaciones de dispositivos INCLUYEN al menos un actuador háptico de uso general, deben cumplir con lo siguiente:

[C-1-1] DEBE devolver verdadero para Vibrator.hasVibrator().
NO DEBE usar un actuador háptico (vibrador) de masa rotatoria excéntrica (ERM).
DEBE implementar todas las constantes públicas para la tecnología táctil clara en android.view.HapticFeedbackConstants, es decir, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START y GESTURE_END).
DEBE implementar todas las constantes públicas para la háptica clara en android.os.VibrationEffect, es decir, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK y EFFECT_DOUBLE_CLICK) y todas las constantes públicas factibles de PRIMITIVE_* para la háptica enriquecida en android.os.VibrationEffect.Composition, es decir, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Algunas de estas primitivas, como LOW_TICK y SPIN, solo pueden ser factibles si el vibrador admite frecuencias relativamente bajas.
DEBE seguir la orientación para asignar constantes públicas en android.view.HapticFeedbackConstants a las constantes android.os.VibrationEffect recomendadas, con las relaciones de amplitud correspondientes.
DEBE usar estas asignaciones de constantes hápticas vinculadas.
DEBE seguir la evaluación de calidad para las APIs de createOneShot() y createWaveform().
DEBE verificar que el resultado de la API pública android.os.Vibrator.hasAmplitudeControl() refleje correctamente las capacidades del vibrador.
DEBE verificar las capacidades de escalabilidad de la amplitud ejecutando android.os.Vibrator.hasAmplitudeControl().

Si las implementaciones de dispositivos siguen la asignación de constantes hápticas, sucede lo siguiente:

DEBE verificar el estado de la implementación ejecutando las APIs de android.os.Vibrator.areAllEffectsSupported() y android.os.Vibrator.arePrimitivesSupported().
DEBE realizar una evaluación de calidad para las constantes hápticas.
DEBE verificar y actualizar, si es necesario, la configuración de resguardo para los elementos primitivos no admitidos, como se describe en la guía de implementación para las constantes.
DEBE proporcionar compatibilidad de resguardo para mitigar el riesgo de falla, como se describe aquí.

7.11. Clase de rendimiento de medios

La clase de rendimiento del contenido multimedia de la implementación del dispositivo se puede obtener de la API de android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Los requisitos de la clase de rendimiento del contenido multimedia se definen para cada versión de Android a partir de R (versión 30). El valor especial 0 designa que el dispositivo no pertenece a una clase de rendimiento de medios.

Si las implementaciones de dispositivos devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

[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 de mano.
[C-1-3] DEBE cumplir con todos los requisitos de la "Clase de rendimiento del contenido multimedia" que se describen en la sección 2.2.7.

En otras palabras, la clase de rendimiento del contenido multimedia en Android T solo se define para dispositivos portátiles en las versiones T, S o R.

Consulta la sección 2.2.7 para conocer los requisitos específicos de cada dispositivo.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y potencia son fundamentales para la experiencia del usuario y afectan las suposiciones básicas que los desarrolladores tendrían al crear una app.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si se cumplen ciertos requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta coherentes para las aplicaciones y los juegos. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener requisitos medibles 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 de E/S de archivos

Proporcionar un valor de referencia común para un rendimiento coherente 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 ayude al diseño de su software. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener ciertos requisitos que se describen en la sección 2 para las siguientes operaciones de lectura y escritura:

Rendimiento de escritura secuencial Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 10 MB.
Rendimiento de escritura aleatoria Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 4 KB.
Rendimiento de lectura secuencial Se mide leyendo un archivo de 256 MB con un búfer de escritura de 10 MB.
Rendimiento de lectura aleatoria Se mide leyendo un archivo de 256 MB con 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 (p.ej., segmento de App Standby, Doze) o extienden las funciones para aplicar restricciones más estrictas que el segmento de App Standby RESTRINGIDO, deben cumplir con lo siguiente:

[C-1-1] NO DEBE desviarse de la implementación del AOSP para los algoritmos de activación, mantenimiento y activación, ni para el uso de la configuración global del sistema o de 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 la configuración global o DeviceConfig para administrar la limitación de tareas, alarmas y redes para las apps en cada bucket de App standby.
[C-1-3] NO DEBE desviarse de la implementación del AOSP para la cantidad de intervalos App Standby que se usan para App Standby.
[C-1-4] DEBE implementar App Standby Buckets y Descanso 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 una indicación visual para ver todas las apps que están exentas de los modos de ahorro de energía App Standby y Descanso, o de cualquier optimización de batería, y DEBE implementar el intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para solicitar al usuario que permita que una app ignore las optimizaciones de batería.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar al usuario la posibilidad de habilitar y desactivar la función de Ahorro de batería.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE proporcionar a los usuarios la posibilidad de ver todas las apps que están exentas de los modos de ahorro de energía App Standby y Descanso.

Si las implementaciones de dispositivos extienden las funciones de administración de energía que se incluyen en AOSP y esa extensión aplica restricciones más estrictas que el segmento de App Standby Poco frecuentes, consulta 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 de suspensión definidos por la Interfaz avanzada de configuración y energía (ACPI).

Si las implementaciones de dispositivos implementan estados de energía S4 según lo define ACPI, deben cumplir con lo siguiente:

[C-1-1] DEBE ingresar a este estado solo después de que el usuario realice una acción explícita para poner el dispositivo en un estado inactivo (p.ej., cerrar una tapa que forma parte física del dispositivo o apagar un vehículo o una televisión) y antes de que el usuario reactive el dispositivo (p.ej., abrir la tapa o volver 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, deben hacer lo siguiente:

[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 (p.ej., la pantalla o 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 en ejecución 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 realizado una acción explícita para poner el dispositivo en un estado inactivo. Por el contrario, en el momento en que se activa una tarea que las apps de terceros implementan a través de JobScheduler o se entrega Firebase Cloud Messaging a las apps de terceros, el dispositivo DEBE salir del estado S3, a menos que el usuario lo haya puesto en un estado inactivo. Estos no son ejemplos exhaustivos, y el AOSP implementa una gran cantidad de indicadores de activación que activan el dispositivo desde este estado.

8.4. Contabilización del consumo de energía

Un registro y un informe más precisos del consumo de energía proporcionan al desarrollador de apps 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 de corriente para cada componente de hardware y la descarga aproximada de la batería que causan los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
[C-SR-2] SE 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 UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo del kernel uid_cputime.
[C-SR-4] SE RECOMIENDA ENCARECIDAMENTE que este uso de energía esté disponible a través del comando de shell adb shell dumpsys batterystats para el desarrollador de apps.
DEBE atribuirse al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

8.5. Rendimiento coherente

El rendimiento puede fluctuar drásticamente en el caso de las apps de alto rendimiento y larga duración, ya sea por las otras apps que se ejecutan en segundo plano o por la regulación de la CPU debido a los límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea capaz, la aplicación en primer plano superior pueda solicitar que el sistema optimice la asignación de los recursos para abordar esas fluctuaciones.

Implementaciones de dispositivos:

[C-0-1] DEBE informar con precisión la compatibilidad con el modo de rendimiento sostenido a través del método de la API de PowerManager.isSustainedPerformanceModeSupported().
DEBE admitir el modo de rendimiento sostenido.

Si las implementaciones de dispositivos informan la compatibilidad con el modo de rendimiento sostenido, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar a la aplicación en primer plano superior un nivel de rendimiento constante durante al menos 30 minutos, cuando la app lo solicite.
[C-1-2] DEBE cumplir con la API de Window.setSustainedPerformanceMode() y otras APIs relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, deben cumplir con lo siguiente:

DEBE proporcionar al menos un núcleo exclusivo que pueda reservar la aplicación en primer plano superior.

Si las implementaciones de dispositivos admiten la reserva de un núcleo exclusivo para la aplicación en primer plano superior, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE informar a través del método de la API de Process.getExclusiveCores() los números de ID de los núcleos exclusivos que puede reservar la aplicación en primer plano principal.
[C-2-2] NO DEBE permitir ningún proceso de espacio del usuario, excepto los controladores de dispositivos que usa la aplicación para ejecutarse en los núcleos exclusivos, pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.

Si las implementaciones de dispositivos no admiten un núcleo exclusivo, deben cumplir con lo siguiente:

[C-3-1] DEBE devolver una lista vacía a través del método de la API de Process.getExclusiveCores().

8.6. Límites de memoria de la app

MemoryLimiter, un nuevo componente de ActivityManagerService, y los límites de memoria predeterminados de las apps, que se derivan de la memoria física disponible, impondrán límites en la cantidad de DRAM que se usa por proceso de app individual. Esta restricción se aplica a toda la memoria asignada dentro del proceso de la app, lo que garantiza que los límites funcionen como un comportamiento contractual crítico con los desarrolladores de apps.

Implementaciones de dispositivos:

[C-0-1] NO DEBE usar ningún método, lista de entidades permitidas ni política para eludir los límites de memoria de tiempo de ejecución establecidos para las aplicaciones.

9. Compatibilidad del modelo de seguridad

Implementaciones de dispositivos:

[C-0-1] DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, tal como se define en el documento de referencia de Seguridad y permisos en las APIs de la documentación para desarrolladores de Android.
[C-0-2] DEBE admitir la instalación de aplicaciones autofirmadas sin requerir permisos o certificados adicionales de terceros o autoridades.

Si las implementaciones de dispositivos declaran la función android.hardware.security.model.compatible, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir los requisitos que se indican 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 definen en la documentación para desarrolladores de Android. Específicamente, DEBEN aplicar cada permiso y rol definidos como se describe en la documentación del SDK. No se pueden omitir, alterar ni ignorar permisos ni roles.
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 se deben otorgar a las apps preinstaladas en las rutas privilegiadas de la imagen del sistema (así como a los archivos APEX) y deben estar dentro del subconjunto de permisos incluidos explícitamente en la lista de entidades permitidas para cada app. La implementación de AOSP cumple con este requisito leyendo y respetando los permisos incluidos en la lista de entidades permitidas para cada app de los archivos en la ruta de acceso etc/permissions/ y usando la ruta de acceso system/priv-app como la ruta de acceso privilegiada.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que los permisos con un protectionLevel de PROTECTION_SIGNATURE se otorguen solo a uno de los siguientes elementos:
- Apps preinstaladas en la imagen del sistema (así como archivos APEX)
- Las apps incluidas en la lista de entidades permitidas con permisos permitidos si no se incluyen en la imagen del sistema.
Nota: La implementación del AOSP cumple con este requisito leyendo y respetando los permisos incluidos en la lista de entidades permitidas para cada app desde los archivos en la ruta de acceso etc/permissions/.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 los solicitan durante el tiempo de ejecución.

Implementaciones de dispositivos:

[C-0-3] DEBE mostrar una interfaz exclusiva para que el usuario decida si otorga los permisos solicitados durante el tiempo de ejecución y también proporcionar una interfaz para que el usuario administre los permisos durante el tiempo de ejecución.
[C-0-5] NO DEBE otorgar permisos de tiempo de ejecución a las apps, a menos que se cumpla una de las siguientes condiciones:
- Se instalan en el momento del envío del dispositivo.
- El consentimiento del usuario se puede obtener antes de que la aplicación use el permiso.
O
- Los permisos de tiempo de ejecución se otorgan según la política de otorgamiento de permisos predeterminada o por tener un rol de la plataforma.
[C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo a las apps del sistema que registren un agente de recuperación correctamente protegido. Un agente de recuperación correctamente protegido se define como un agente de software integrado en el dispositivo que se sincroniza con un almacenamiento remoto fuera del dispositivo, que está equipado con hardware seguro con protección equivalente o superior a la que se describe en el Servicio de Key Vault de Google Cloud para evitar ataques de fuerza bruta en el factor de conocimiento de la pantalla de bloqueo.

Implementaciones de dispositivos:

[C-0-7] DEBE cumplir con las propiedades del permiso de ubicación de Android cuando una app solicita los datos de ubicación o datos de actividad física a través de la API estándar de Android o un mecanismo propietario. Estos datos incluyen, sin limitaciones, los siguientes:
- Ubicación del dispositivo (p.ej., latitud y longitud), como se describe en el Artículo 9.8.8.
- Información que se puede usar para determinar o estimar la ubicación del dispositivo (p. ej., SSID, BSSID, ID de celda 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.

Específicamente, las implementaciones de dispositivos:

[C-0-8] DEBE obtener el consentimiento del usuario para permitir que una app acceda a los datos de ubicación o actividad física.
[C-0-9] DEBE otorgar un permiso de tiempo de ejecución SOLO a la app que tenga el permiso suficiente, como se describe en el SDK. Por ejemplo, TelephonyManager#getServiceState requiere android.permission.ACCESS_FINE_LOCATION.

Las únicas excepciones a las propiedades de permisos de ubicación de Android mencionadas anteriormente son para las apps que no acceden a la ubicación para derivar o identificar la ubicación del usuario, específicamente:

Cuando las apps tienen el permiso RADIO_SCAN_WITHOUT_LOCATION
Para la configuración y los ajustes del dispositivo, en los que las apps del sistema tienen el permiso NETWORK_SETTINGS o NETWORK_SETUP_WIZARD

Los permisos se pueden marcar como restringidos, lo que altera su comportamiento.

[C-0-10] Los permisos marcados con la marca hardRestricted NO DEBEN otorgarse a una app, a menos que se cumpla una de las siguientes condiciones:
- El archivo APK de la app está en la partición del sistema.
- El usuario asigna un rol asociado con los permisos de hardRestricted a una app.
- El instalador otorga el permiso hardRestricted a una app.
- Se otorga hardRestricted a una app en una versión anterior de Android.
[C-0-11] Las apps que tienen un permiso de softRestricted SOLO DEBEN obtener acceso limitado y NO DEBEN obtener acceso completo hasta que se incluyan en la lista de entidades permitidas, como se describe en el SDK, en el que se define el acceso completo y limitado para cada permiso de softRestricted (por ejemplo, READ_EXTERNAL_STORAGE).
[C-0-12] NO DEBE proporcionar ninguna función o API personalizada para eludir las restricciones de permisos definidas en las APIs de setPermissionPolicy y setPermissionGrantState.
[C-0-13] DEBE usar las APIs de AppOpsManager para registrar y hacer un seguimiento de todos y cada uno de los accesos programáticos a los datos protegidos por permisos peligrosos desde las actividades y los servicios de Android.
[C-0-14] SOLO se DEBEN asignar roles a las aplicaciones con funcionalidades que cumplan con los requisitos del rol.
[C-0-15] NO DEBE definir roles que sean duplicados o que tengan una funcionalidad de superconjunto de los roles definidos por la plataforma.

Si los dispositivos incluyen sensores de datos que exponen datos biométricos relacionados con la salud, como la frecuencia cardíaca o la temperatura cutánea, esos datos biométricos deben cumplir con los siguientes requisitos:

[C-0-16] DEBE estar protegido por permisos de la plataforma de android.permission-group.HEALTH si hay un permiso correspondiente en HealthPermissions.
[C-0-17] DEBE estar protegido por un permiso del sistema personalizado si ningún permiso de la plataforma coincide con el tipo de datos deseado. (Por ejemplo, ELECTROCARDIOGRAM).

Si los dispositivos informan android.software.managed_users, significa que:

[C-1-1] NO DEBE tener los siguientes permisos otorgados de forma silenciosa por el administrador:
- Ubicación (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
- Cámara (CAMERA)
- Micrófono (RECORD_AUDIO)
- Sensor corporal (BODY_SENSORS)
- Salud (HealthPermissions)
- Actividad física (ACTIVITY_RECOGNITION)

Si los dispositivos informan android.software.managed_users, significa que:

[C-1-1] NO DEBE tener los siguientes permisos otorgados de forma silenciosa por el administrador:
- Ubicación (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
- Cámara (CAMERA)
- Micrófono (RECORD_AUDIO)
- Sensor corporal (BODY_SENSORS)
- Actividad física (ACTIVITY_RECOGNITION)

Si las implementaciones del dispositivo proporcionan una indicación visual para que el usuario elija qué apps pueden dibujar sobre otras apps con una actividad que controle el intent ACTION_MANAGE_OVERLAY_PERMISSION, deben cumplir con lo siguiente:

[C-2-1] DEBE garantizar que todas las actividades con filtros de intents para el intent ACTION_MANAGE_OVERLAY_PERMISSION tengan la misma pantalla de IU, independientemente de la app que inicie la actividad o de la información que proporcione.

Si las implementaciones de dispositivos informan android.software.device_admin, cumplen con los siguientes requisitos:

[C-3-1] DEBE mostrar una renuncia de responsabilidad durante la configuración del dispositivo completamente administrado (configuración del propietario del dispositivo) en la que se indique que el administrador de TI podrá permitir que las apps controlen la configuración del teléfono, incluidos el micrófono, la cámara y la ubicación, con opciones para que el usuario continúe con la configuración o salga de ella, A MENOS que el administrador haya inhabilitado el control de los permisos en el dispositivo.

Si las implementaciones de dispositivos preinstalan paquetes que contienen cualquiera de los roles de Inteligencia de la IU del sistema, Inteligencia de audio ambiental del sistema, Inteligencia de audio del sistema, Inteligencia de notificaciones del sistema, Inteligencia de texto del sistema o Inteligencia visual del sistema, los paquetes deben cumplir con los siguientes requisitos:

[C-4-1] DEBE cumplir con todos los requisitos que se describen para las implementaciones de dispositivos en las secciones 9.8.6. Datos a nivel del SO y datos ambientales y 9.8.15. Implementaciones de APIs en zona de pruebas.

9.2. Aislamiento de procesos y UID

Implementaciones de dispositivos:

[C-0-1] DEBE admitir el modelo de zona de pruebas de la aplicación para Android, en el que cada aplicación se ejecuta como un UID único de estilo Unix y en un proceso independiente.
[C-0-2] DEBE admitir la ejecución de varias 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:

[C-0-1] DEBE admitir el modelo de permisos de acceso a archivos de Android, como se define en la referencia de Seguridad y permisos.

9.4. Entornos de ejecución alternativos

Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de seguridad y permisos de Android, incluso si incluyen entornos de ejecución que ejecutan aplicaciones con algún otro software o tecnología que no sean el formato ejecutable de Dalvik o el código nativo. En otras palabras:

[C-0-1] Los tiempos de ejecución alternativos DEBEN ser aplicaciones para 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] Los tiempos de ejecución alternativos NO DEBEN tener acceso a los recursos protegidos por permisos que no se solicitaron 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 usen funciones protegidas por la Protección de Android restringidos a las 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 con un tiempo de ejecución alternativo NO DEBEN reutilizar la zona de pruebas de ninguna otra app 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 entornos de ejecución alternativos NO DEBEN iniciarse con las zonas de pruebas correspondientes a otras aplicaciones para Android, ni otorgar o recibir acceso a ellas.
[C-0-6] Los tiempos de ejecución alternativos NO DEBEN iniciarse con privilegios de superusuario (root) o de cualquier otro ID de usuario, ni otorgar o recibir privilegios de superusuario (root) o de cualquier otro ID de usuario de otras aplicaciones.
[C-0-7] Cuando los archivos .apk de los tiempos de ejecución alternativos se incluyen en la imagen del sistema de las implementaciones de dispositivos, DEBEN firmarse con una clave distinta de la que se usa para firmar otras aplicaciones incluidas en las implementaciones de dispositivos.
[C-0-8] Cuando se instalan aplicaciones, los entornos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que usa la aplicación.
[C-0-9] Cuando una aplicación necesita usar un recurso del dispositivo para el que hay un permiso de Android correspondiente (como la cámara, el GPS, etcétera), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.
[C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, DEBE enumerar todos los permisos que tiene el entorno de ejecución cuando se instala cualquier aplicación que use ese entorno.
Los tiempos de ejecución alternativos DEBEN instalar apps a través de PackageManager en zonas de pruebas de Android separadas (IDs de usuario de Linux, etc.).
Los tiempos de ejecución alternativos PUEDEN proporcionar un único espacio aislado de Android compartido por todas las aplicaciones que usan el tiempo de ejecución alternativo.

9.5. Compatibilidad con múltiples usuarios

Android incluye compatibilidad con varios usuarios y proporciona compatibilidad con el aislamiento completo de usuarios y la clonación de perfiles de usuarios con aislamiento parcial (es decir, un solo 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 usan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones de dispositivos incluyen compatibilidad con varios usuarios, deben cumplir con los siguientes requisitos:

[C-1-2] Para cada usuario, DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, tal como se define en el documento de referencia de Seguridad y permisos en las APIs.
[C-1-3] DEBE tener directorios de almacenamiento de aplicaciones compartidos separados y aislados (también conocidos como /sdcard) 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 ni escribir en los archivos que pertenecen a cualquier otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
[C-1-5] DEBE encriptar el contenido de la tarjeta SD cuando se habilita el modo multiusuario con una clave almacenada solo en medios no extraíbles a los que solo puede acceder el sistema si las implementaciones del dispositivo usan medios extraíbles para las APIs de almacenamiento externo. Como esto hará que la PC host no pueda leer el contenido multimedia, las implementaciones de dispositivos deberán cambiar a MTP o a un sistema similar para proporcionar a las PCs host acceso a los datos del usuario actual.

Si las implementaciones de dispositivos incluyen compatibilidad con varios usuarios, entonces, para todos los usuarios, excepto los que se crearon específicamente para ejecutar instancias duales de la misma app, se cumplen las siguientes condiciones:

[C-2-1] DEBE tener directorios de almacenamiento de aplicaciones compartidos separados y aislados (también conocidos como /sdcard) 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 ni escribir en los archivos que pertenecen a cualquier otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.

Las implementaciones de dispositivos PUEDEN crear un solo perfil de usuario adicional de tipo android.os.usertype.profile.CLONE para el usuario principal (y solo para el usuario principal) con el propósito de ejecutar instancias duales de la misma app. Estas instancias duales comparten almacenamiento parcialmente aislado, se presentan al usuario final en el selector al mismo tiempo y aparecen en la misma vista de Recientes. Por ejemplo, se podría usar para permitir que el usuario instale dos instancias separadas de una sola app en un dispositivo con doble SIM.

Si las implementaciones de dispositivos crean el perfil de usuario adicional que se mencionó anteriormente, deben cumplir con lo siguiente:

[C-3-1] SOLO DEBE proporcionar acceso al almacenamiento o a los datos a los que ya se puede acceder desde el perfil de usuario principal o que son 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 apps privadas aislados de la cuenta de usuario principal.
[C-3-4] NO DEBE permitir que se cree el perfil de usuario adicional si se aprovisionó un propietario del dispositivo (consulta la sección 3.9.1) ni permitir que se aprovisione un propietario del dispositivo sin quitar primero el perfil de usuario adicional.

Si las implementaciones de dispositivos crean el perfil de usuario adicional que se mencionó anteriormente, deben cumplir con lo siguiente:

[C-4-1] DEBE permitir que las aplicaciones del usuario principal en el dispositivo controlen los siguientes intents que se originan en el perfil adicional:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] DEBE heredar todas las restricciones del usuario de la política del dispositivo y el restrictions(list below) no relacionado con el usuario seleccionado que se aplicó al usuario principal del dispositivo en este perfil de usuario adicional.
[C-4-3] SOLO DEBE permitir la escritura de contactos desde este perfil adicional a través de los siguientes intents:
[C-4-4] NO DEBE tener sincronizaciones de contactos en ejecución para las aplicaciones que se ejecutan en este perfil de usuario adicional.
[C-4-5] SOLO DEBE permitir que las aplicaciones del perfil adicional que tengan una actividad de inicio accedan a los contactos a los que ya puede acceder el perfil de usuario principal.

Si las implementaciones del dispositivo crean el perfil de usuario adicional que se mencionó anteriormente, incluyen al menos una cámara y la aplicación de cámara preinstalada controla los intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE o MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, deben cumplir con lo siguiente:

[C-5-1] DEBE permitir que las aplicaciones del usuario principal controlen estos intents que se originan en ese perfil de usuario adicional.

9.6. Advertencia de SMS premium

Android incluye compatibilidad para advertir a los usuarios sobre cualquier mensaje SMS premium saliente. Los mensajes SMS Premium son mensajes de texto que se envían a un servicio registrado con un operador y que pueden generar cargos para el usuario.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony, deben cumplir con lo siguiente:

[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 upstream proporciona una implementación que satisface este requisito.

9.7. Funciones de seguridad

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad en el kernel y la plataforma, como se describe a continuación.

La zona de pruebas de Android incluye funciones que usan el sistema de control de acceso obligatorio (MAC) de Security-Enhanced Linux (SELinux), la zona de pruebas de seccomp 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 se implementen SELinux o cualquier otra función de seguridad debajo del framework de Android.
[C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta y bloquea correctamente un incumplimiento de seguridad con la función de seguridad implementada debajo del framework de Android, pero PUEDE tener una interfaz de usuario visible cuando se produce un incumplimiento de seguridad no bloqueado que resulta en un aprovechamiento exitoso.
[C-0-3] NO DEBE permitir que el usuario o el desarrollador de apps configuren SELinux ni ninguna otra función de seguridad implementada por debajo del framework de Android.
[C-0-4] NO DEBE permitir que una aplicación que pueda afectar a otra a través de una API (como una API de administración de dispositivos) configure una política que interrumpa la compatibilidad.
[C-0-5] DEBE dividir el framework de medios en varios procesos para que sea posible otorgar acceso de forma más limitada 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 aislamiento de aplicaciones del kernel que permita filtrar las llamadas al sistema con una política configurable de programas multiproceso. El Proyecto de código abierto de Android upstream cumple con este requisito habilitando seccomp-BPF con sincronización de grupos de subprocesos (TSYNC), como se describe en la sección Configuración del kernel de source.android.com.

Las funciones de integridad y autoprotección del kernel son fundamentales para la seguridad de Android. Implementaciones de dispositivos:

[C-0-7] SE DEBEN implementar mecanismos de protección contra desbordamiento de búfer de pila del kernel. CC_STACKPROTECTOR_REGULAR y CONFIG_CC_STACKPROTECTOR_STRONG son ejemplos de estos mecanismos.
[C-0-8] DEBE implementar protecciones estrictas de la memoria del kernel en las que el código ejecutable sea de solo lectura, los datos de solo lectura no sean ejecutables ni se puedan escribir, y los datos que se puedan escribir no sean ejecutables (por ejemplo, se deben habilitar rodata y 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 copias entre el espacio del usuario y el espacio del kernel (p.ej., CONFIG_HARDENED_USERCOPY) en dispositivos que se lanzaron originalmente con el nivel de API 28 o superior.
[C-0-10] NO DEBE ejecutar memoria del espacio del usuario cuando se ejecuta en el modo kernel (p.ej., PXN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se lanzaron originalmente con el nivel de API 28 o superior.
[C-0-11] NO DEBE leer ni escribir en la memoria del espacio del usuario en el kernel fuera de las APIs de acceso normales de usercopy (p.ej., PAN de hardware o emulación a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se lanzaron originalmente 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 lanzaron originalmente con el nivel de API 28 o superior (p.ej., CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] DEBE implementar el endurecimiento de la predicción de ramas si el hardware es vulnerable a CVE-2017-5715 en todos los dispositivos que se lanzaron originalmente con el nivel de API 28 o superior (p.ej., CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] 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 (p.ej., __ro_after_init).
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE aleatorizar el diseño del código del kernel y la memoria, y evitar las exposiciones que comprometan la aleatorización (p.ej., CONFIG_RANDOMIZE_BASE con entropía del cargador de arranque a través de /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).
[C-SR-3] 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 (p.ej., CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK).
[C-SR-4] Se RECOMIENDA ENCARECIDAMENTE no inhabilitar la integridad del flujo de control (CFI), la pila de llamadas de sombra (SCS) ni la sanitización de desbordamiento de enteros (IntSan) en los componentes que la tengan habilitada.
[C-SR-5] SE RECOMIENDA ENCARECIDAMENTE habilitar CFI, SCS y IntSan para cualquier componente adicional del espacio del usuario sensible a la seguridad, como se explica en CFI y IntSan.
[C-SR-6] 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 suponer el valor que usa el compilador para inicializar las variables locales.
[C-SR-7] SE RECOMIENDA ENCARECIDAMENTE habilitar la inicialización del montón en el kernel para evitar el uso de asignaciones del montón no inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) y NO DEBEN suponer el valor que usa el kernel para inicializar esas asignaciones.

Si las implementaciones de dispositivos usan un kernel de Linux que admite SELinux, deben cumplir con lo siguiente:

[C-1-1] SE DEBE implementar SELinux.
[C-1-2] DEBE establecer SELinux en modo de aplicación global.
[C-1-3] Se DEBEN configurar todos los dominios en modo de aplicación. No se permiten dominios en modo permisivo, incluidos los dominios específicos de un dispositivo o proveedor.

[C-1-4] NO DEBE:
- Modificar, omitir o reemplazar las reglas neverallow presentes en la carpeta system/sepolicy proporcionada en el Proyecto de código abierto de Android (AOSP) upstream
- Se agregan de forma incorrecta etiquetas de SELinux de AOSP a componentes que no son de AOSP
La política DEBE compilarse con todas las reglas neverallow presentes, tanto para los dominios SELinux de AOSP como para los dominios específicos del dispositivo o del proveedor.

[C-1-5] DEBE ejecutar aplicaciones de terceros segmentadas para el nivel de API 28 o superior en zonas de pruebas de SELinux por aplicación con restricciones de SELinux por app en el directorio de datos privados de cada aplicación.
DEBE conservar la política de SELinux predeterminada que se proporciona en la carpeta system/sepolicy del proyecto de código abierto de Android upstream y solo agregar más a esta política para su propia configuración específica del dispositivo.

Si las implementaciones de dispositivos usan un kernel que no sea Linux o Linux sin SELinux, deben cumplir con lo siguiente:

[C-2-1] DEBE usar un sistema de control de acceso obligatorio que sea equivalente a SELinux.

Si las implementaciones de dispositivos usan dispositivos de E/S capaces de DMA, deben cumplir con lo siguiente:

[C-SR-9] SE RECOMIENDA ENCARECIDAMENTE aislar cada dispositivo de E/S capaz de DMA con una IOMMU (p.ej., la SMMU de ARM).

Android contiene varias funciones de defensa en profundidad que son fundamentales para la seguridad del dispositivo. Además, Android se enfoca en reducir las clases clave de errores comunes que contribuyen a la baja calidad y seguridad.

Para reducir los errores de memoria, las implementaciones de dispositivos deben cumplir con lo siguiente:

[C-SR-10] Se RECOMIENDA ENCARECIDAMENTE que se prueben con herramientas de detección de errores de memoria del espacio del usuario, como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ o ASan para otros tipos de dispositivos.
[C-SR-11] SE RECOMIENDA ENCARECIDAMENTE que se prueben con 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 usar herramientas de detección de errores de memoria en producción, como MTE, GWP-ASan y KFENCE.

Si las implementaciones de dispositivos usan un TEE basado en Arm TrustZone, deben cumplir con lo siguiente:

[C-SR-13] Se RECOMIENDA ENCARECIDAMENTE usar un protocolo estándar para el uso compartido de la memoria entre Android y el TEE, como Arm Firmware Framework para Armv8-A (FF-A).
[C-SR-14] SE RECOMIENDA ENCARECIDAMENTE restringir las aplicaciones de confianza para que solo accedan a la memoria que se haya 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 particiones seguras debe aplicar esta configuración. De lo contrario, el SO del TEE debería aplicar esta restricción.

Una tecnología de seguridad de la memoria es aquella que mitiga al menos las siguientes clases de errores con una probabilidad alta (superior al 90%) en las aplicaciones que usan la opción de manifiesto android:memtagMode:

Desbordamiento del búfer del montón
uso después de liberación
Doble libre
wild free (liberación de un puntero que no es malloc)

Implementaciones de dispositivos:

[C-SR-15] Se RECOMIENDA ENCARECIDAMENTE establecer ro.arm64.memtag.bootctl_supported.

Si las implementaciones de dispositivos establecen la propiedad del sistema ro.arm64.memtag.bootctl_supported como verdadera, deben hacer lo siguiente:

[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: Se habilitó una tecnología de seguridad de la memoria como se definió anteriormente.
- memtag-once: Una tecnología de seguridad de la memoria, como se definió anteriormente, se habilita de forma transitoria y se inhabilita automáticamente en el próximo reinicio.
- memtag-off: Se inhabilitó una tecnología de seguridad de la memoria, como se definió anteriormente.
[C-3-2] DEBE permitir que el usuario del 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 en el estado solicitado actualmente durante el inicio. 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 mostrar un parámetro de configuración para desarrolladores que establezca memtag-once y reinicie el dispositivo. Con un cargador de arranque compatible, el Proyecto de código abierto de Android cumple con los requisitos anteriores a través del protocolo del cargador de arranque MTE.

Si un dispositivo declara android.hardware.telephony, admite la capacidad de radio CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK y tiene un módem celular que admite conexiones 2G, la implementación del dispositivo debe cumplir con lo siguiente:

[C-SR-17] SE RECOMIENDA ENCARECIDAMENTE proporcionar al usuario la posibilidad de inhabilitar y habilitar 2G.
[C-SR-18] SE RECOMIENDA ENCARECIDAMENTE no anular la capacidad del usuario para inhabilitar y habilitar 2G a través de cualquier otra entidad del dispositivo, excepto por un administrador del dispositivo que use UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] Se RECOMIENDA ENCARECIDAMENTE llamar a TelephonyManager.setAllowedNetworkTypesForReason con el motivo ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G para cumplir con este requisito.
[C-SR-20] Se RECOMIENDA ENCARECIDAMENTE llamar a TelephonyManager.getSupportedRadioAccessFamily para determinar la compatibilidad del módem celular con 2G. Consulta Cómo inhabilitar 2G para obtener más información.

9.8. Privacidad

9.8.1. Historial de uso

Android almacena el historial de las elecciones del usuario y lo administra con UsageStatsManager.

Implementaciones de dispositivos:

[C-0-1] DEBE mantener un período de retención razonable de dicho historial del usuario.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE mantener el período de retención de 14 días tal como está configurado de forma predeterminada en la implementación del AOSP.

Android almacena los eventos del sistema con los identificadores StatsLog y administra ese historial a través de la API de sistema StatsManager y IncidentManager.

Implementaciones de dispositivos:

[C-0-2] SOLO DEBE incluir 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 usar los identificadores de eventos del sistema para registrar ningún otro evento que no sea el que se describe en los documentos del SDK de StatsLog. Si se registran eventos adicionales del sistema, ES POSIBLE que usen 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 (p.ej., pulsaciones de teclas, texto que se muestra en la pantalla, bugreport) fuera del dispositivo sin el consentimiento del usuario ni notificaciones claras y continuas.
[C-0-2] DEBE mostrar una advertencia al usuario y obtener su consentimiento explícito para permitir que se capture toda la información sensible que se muestre en su pantalla cada vez que se habilite una sesión para capturar la transmisión o grabación de pantalla a través de MediaProjection.createVirtualDisplay() o APIs propietarias.
[C-0-3] DEBE mostrar una notificación continua al usuario mientras la transmisión o grabación de pantalla estén habilitadas. El AOSP cumple con este requisito mostrando un ícono de notificación continua en la barra de estado.
[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE mostrar una advertencia al usuario que sea exactamente el mismo mensaje que se implementó en AOSP, pero SE PUEDE ALTERAR siempre y cuando el mensaje advierta claramente al usuario que se captura cualquier información sensible que aparezca en la pantalla del usuario.
[C-0-4] Se quitó el requisito en Android 16.

Implementaciones de dispositivos:

[C-0-7] NO DEBE grabar, proyectar ni transmitir información sensible, como la siguiente:
- Contenido sensible de la notificación que se indica en la Sección 3.8.3.4 Protección de notificaciones sensibles
- Ventanas de actividad de la app que contienen contraseñas de un solo uso
- Contenido sensible, como nombres de usuario, contraseñas y datos de tarjetas de crédito

Si las implementaciones de dispositivos incluyen funciones en el sistema que capturan el contenido que se muestra en la pantalla o graban la transmisión de audio que se reproduce en el dispositivo, excepto a través de la API del sistema ContentCaptureService, o bien otros medios propietarios que se describen en la Sección 9.8.6 Datos a nivel del SO y del entorno, deben cumplir con lo siguiente:

[C-1-1] DEBE mostrar una notificación continua al usuario cada vez que esta función esté habilitada y capture o grabe de forma activa.

Si las implementaciones de dispositivos incluyen un componente habilitado de forma predeterminada que puede grabar audio ambiental o el audio que se reproduce en el dispositivo para inferir información útil sobre el contexto del usuario, deben cumplir con lo siguiente:

[C-2-1] NO DEBE almacenar en el almacenamiento persistente integrado en el dispositivo ni transmitir fuera del dispositivo el audio sin procesar grabado ni ningún formato que se pueda convertir en el audio original o en una copia casi exacta, excepto con el consentimiento explícito del usuario.

Un "indicador de micrófono" hace referencia a una vista en la pantalla, que es visible constantemente para el usuario y no se puede ocultar, que los usuarios entienden como que el micrófono está en uso(a través de texto, color, ícono o alguna combinación únicos).

Un "indicador de acceso a la cámara" hace referencia a una vista en la pantalla que es visible constantemente para el usuario y no se puede ocultar, y que los usuarios entienden que la cámara está en uso (a través de texto, color, ícono o alguna combinación únicos).

Después del primer segundo de visualización, un indicador puede cambiar visualmente, por ejemplo, volverse más pequeño, y no es necesario que se muestre como se presentó y entendió originalmente.

El indicador de micrófono se puede combinar con un indicador de cámara que se muestre de forma activa, siempre que el texto, los íconos o los colores indiquen al usuario que comenzó el uso del micrófono.

El indicador de acceso a la cámara se puede combinar con un indicador del micrófono que se muestre de forma activa, siempre que el texto, los íconos o los colores indiquen al usuario que comenzó el uso de la cámara.

Si las implementaciones de dispositivos declaran android.hardware.microphone, deben cumplir con lo siguiente:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE mostrar el indicador de micrófono cuando una app accede a los datos de audio del micrófono, pero no cuando solo acceden al micrófono HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o las apps que tienen los roles que se mencionan en la sección 9.1 Permisos con identificador de CDD [C-3-X].
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE mostrar la lista de apps recientes y activas que usan el micrófono, según lo que devuelve PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados.
[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE no ocultar el indicador de micrófono para las apps 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, deben cumplir con lo siguiente:

[C-SR-4] SE RECOMIENDA ENCARECIDAMENTE mostrar el indicador de acceso a la cámara cuando una app accede a datos de la cámara en vivo, pero no cuando solo se accede a la cámara desde las apps que tienen los roles que se mencionan en la sección 9.1 Permisos con el identificador de CDD [C-3-X].
[C-SR-5] SE RECOMIENDA ENCARECIDAMENTE mostrar las apps recientes y activas que usan la cámara, según lo que se devuelve de PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados.
[C-SR-6] SE RECOMIENDA ENCARECIDAMENTE no ocultar el indicador de acceso a la cámara en las apps del sistema que tienen interfaces de usuario visibles o interacción del usuario directa.

9.8.3. Conectividad

Si las implementaciones de dispositivos tienen un puerto USB con compatibilidad con el modo periférico USB, deben cumplir con lo siguiente:

[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] Se DEBEN preinstalar los mismos certificados raíz para el almacén de la autoridad certificadora (CA) de confianza del sistema que los proporcionados en el proyecto de código abierto de Android upstream.
[C-0-2] DEBE incluir un almacén de AC raíz del usuario vacío.
[C-0-3] DEBE mostrar una advertencia al usuario que indique que se puede supervisar el tráfico de red cuando se agrega una CA raíz del usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones del dispositivo deben cumplir con lo siguiente:

[C-1-1] DEBE mostrar una advertencia al usuario que indique una de las siguientes opciones:
- Es posible que se supervise ese tráfico de red.
- Ese tráfico de red se enruta a través de la aplicación de 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 red a través de un servidor proxy o una puerta de enlace de VPN (por ejemplo, precargando un servicio de VPN con android.permission.CONTROL_VPN otorgado), deben cumplir con lo siguiente:

[C-2-1] DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de política de dispositivo habilite esa VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage(), en cuyo caso el usuario no necesita proporcionar un consentimiento independiente, sino que SOLO DEBE recibir una notificación.

Si las implementaciones de dispositivos incluyen una indicación visual para activar o desactivar la función "VPN siempre activa" de una app de VPN de terceros, deben cumplir con lo siguiente:

[C-3-1] DEBE inhabilitar esta opción para el usuario en las apps que no admiten el servicio de VPN siempre encendida 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, al IMEI/MEID, al número de serie de la SIM y a la identidad internacional de suscriptor móvil (IMSI) desde una app, a menos que cumpla con uno de los siguientes requisitos:
- es una app de operador firmada y verificada por los fabricantes de dispositivos.
- Se le otorgó el permiso READ_PRIVILEGED_PHONE_STATE.
- Tiene privilegios de operador como se define en Privilegios de operador de UICC.
- Es el propietario del dispositivo o del perfil al que se le otorgó el permiso READ_PHONE_STATE.
- (Solo para el número de serie de la SIM o el ICCID) Tiene el requisito de las reglamentaciones locales de que la app detecte cambios en la identidad del suscriptor.

9.8.6. Protector de datos a nivel del SO y de datos ambientales

A través de las APIs del sistema, Android admite un mecanismo para que las implementaciones de dispositivos capturen los siguientes datos sensibles:

Texto y gráficos renderizados en la pantalla, incluidas, sin limitaciones, las notificaciones y los datos de asistencia a través de la API de AssistStructure, las actividades de captura de búfer de pantalla y la grabación del contenido de la pantalla de un dispositivo.

Datos multimedia, como audio o video, grabados o reproducidos por el dispositivo
Eventos de entrada (p. ej., teclado, mouse, gestos, voz, video y accesibilidad)
Cualquier pantalla o dato que se envíe a través de AugmentedAutofillService al sistema.
Cualquier pantalla o dato al que se pueda acceder a través de las APIs de Content Capture
Cualquier dato de la aplicación que se pase al sistema a través de la API de AppSearchManager y al que se pueda acceder a través de AppSearchGlobalManager.query.
Cualquier texto o dato que se envíe a través de TextClassifier API al TextClassifier del sistema, es decir, al servicio del sistema para comprender el significado del texto, así como generar las siguientes acciones predichas basadas en el texto.
Datos indexados por la implementación de AppSearch de la plataforma, incluidos, sin limitaciones, texto, gráficos, datos multimedia o datos similares
Son los datos de audio obtenidos como resultado del uso de SpeechRecognizer#onDeviceSpeechRecognizer() por parte de la implementación del reconocedor de voz.
Datos de audio obtenidos en segundo plano (de forma continua) a través de AudioRecord, SoundTrigger o cualquier otra API de Audio, y que no generan un indicador visible para el usuario
Datos de la cámara obtenidos en segundo plano (de forma continua) a través de CameraManager o de otras APIs de Camera, y que no generan un indicador visible para el usuario

Cualquier dato capturado por DynamicInstrumentationEventService

Si las implementaciones de dispositivos capturan o comparten cualquiera de los datos sensibles mencionados anteriormente, deben hacer lo siguiente: Sin una intención del usuario clara y discreta, o un indicador de privacidad visible para el usuario, los datos SE DEBEN procesar en un entorno de ejecución protegido. Este entorno:

[C-1-1] DEBE encriptar todos esos datos cuando se almacenan en el dispositivo o en tránsito. Esta encriptación SE PUEDE llevar a cabo con la encriptación basada en archivos de Android o con cualquiera de los algoritmos de encriptación que se indican para la versión de API 26 y versiones posteriores, como se describe en el SDK de Cipher.
[C-1-2] NO DEBE crear copias de seguridad de datos sin procesar o encriptados con métodos de copia de seguridad de Android ni con ningún otro método de copia de seguridad de datos sensibles, como se describió anteriormente.

[C-1-3] NO DEBE enviar esos datos fuera del dispositivo, excepto en uno de los siguientes casos:
- Cuando el usuario inicia explícitamente la intención ^* para el cálculo específico cada vez que se comparten los datos
- Cuando se usa un mecanismo que preserva la privacidad, como las tecnologías de privacidad diferencial, como RAPPOR o los cálculos federados confidenciales
- Cuando los datos se procesan en un entorno de ejecución protegido que los protege del proveedor de servicios y la infraestructura, como la ausencia de acceso de administrador, la VM confidencial, la certificación remota, la ausencia de salida de datos privados, el registro inhabilitado, el ocultamiento de IP y la encriptación.
  - Cualquier implementación que use este método debe proporcionar una opción para que los usuarios rechacen el uso de la información.

[C-1-3] MAY procesa los datos a través de un entorno de nube de base informática de confianza que los protege del proveedor de servicios y la infraestructura (p.ej., sin acceso de administrador, VM confidencial, certificación remota, sin salida de datos privados, registro inhabilitado, ocultamiento de IP y encriptación). Cualquier implementación que use este método:
- DEBE proporcionar una opción para que los usuarios rechacen la recopilación, y
- DEBE proporcionar a los usuarios un método para generar registros accesibles y completos que detallen el ingreso y egreso de datos del entorno.

[C-1-4] NO DEBE asociar esos datos con ninguna identidad de usuario (como Account) en el dispositivo, excepto con el consentimiento explícito del usuario cada vez que se asocien los datos.

[C-1-4] PUEDE mostrar estos datos en las superficies de la IU propiedad del sistema.

[C-1-5] NO DEBE compartir ni asociar esos datos con ninguna identidad de usuario (como Account), excepto con el consentimiento explícito del usuario cada vez que se compartan cada vez que se asocien los datos, o la asociación no saldrá a otros componentes del SO que no cumplan con los requisitos que se describen en esta sección (9.8.6 Datos a nivel del SO y datos ambientales), cada vez que se compartan. A menos que esa funcionalidad se cree como una API del SDK de Android (AmbientContext, HotwordDetectionService).
[C-1-6] DEBE proporcionar al usuario la indicación visual para borrar los datos que la implementación o los medios propiedad de recopilan cuando los datos se almacenan de cualquier forma en el dispositivo o en el entorno de nube de la base informática de confianza. Si el usuario elige borrar los datos, se DEBEN quitar todos los datos históricos recopilados.

[C-1-7] DEBE proporcionar una opción para que el usuario inhabilite la visualización de los datos recopilados a través de AppSearch o medios propios en la plataforma de Android (p.ej., el selector).

[C-1-8] DEBE proporcionar un método para generar registros accesibles y completos que detallen la entrada y salida de datos del entorno.
[C-1-9] NO DEBE tener acceso directo a Internet.
[C-1-10] PUEDE mostrar la IU de forma remota, siempre y cuando no se muestren datos en el APK del host que muestra la IU.
[C-1-11] DEBE mantener los servicios separados de otros componentes del sistema (p.ej., no vincular el servicio ni compartir IDs de proceso con implementaciones que no estén en el entorno de ejecución protegido).
[C-1-12] SOLO DEBE permitir que salgan los datos sensibles en los siguientes casos:
- Se inicia explícitamente por la intención del usuario* para el cálculo específico cada vez que se comparten los datos.
- Usar un mecanismo que preserva la privacidad (p. ej., tecnologías de privacidad diferencial como RAPPOR o cálculos federados confidenciales)
[C-1-13] SOLO DEBE permitir la filtración de datos sensibles a través de los siguientes medios:
- Un servicio del sistema que se incluye en la lista de entidades permitidas del servicio del sistema de PCCSandbox Y que cumple con los requisitos para un entorno de ejecución protegido (9.8.6) por sí mismo
- Un APK de puerta de enlace de Private Compute Core (PCC) designado (definido en 9.8.15).
[C-1-14] NO DEBE realizar copias de seguridad en la nube de los datos que se infieran a partir de datos sensibles, a menos que estén encriptados de extremo a extremo (p.ej., con el servicio de copias de seguridad de Android).

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE NO solicitar el permiso de INTERNET.
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que solo se acceda a Internet a través de APIs estructuradas respaldadas por implementaciones de código abierto disponibles públicamente.
[C-SR-4] SE RECOMIENDA ENCARECIDAMENTE que se implementen con la API del SDK de Android o un repositorio de código abierto similar propiedad del OEM, o bien que se realicen en una implementación en zona de pruebas (consulta el punto 9.8.15 Implementaciones de API en zona de pruebas).

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService o cualquier servicio propietario que capture los datos como se describió anteriormente, deben cumplir con lo siguiente:

[C-2-1] NO DEBE permitir que los usuarios reemplacen los servicios con una aplicación o servicio instalable por el usuario, y SOLO DEBE permitir que los servicios preinstalados capturen esos datos.
[C-2-2] NO DEBE permitir que ninguna app, excepto el mecanismo de servicios preinstalados, pueda capturar esos datos.
[C-2-3] DEBE proporcionar una indicación visual clara y accesible para el usuario para inhabilitar los servicios.
[C-2-4] NO DEBE omitir la indicación visual del usuario para administrar los permisos de Android que tienen los servicios y seguir 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 (p.ej., no vincular el servicio ni compartir IDs de proceso), excepto en los siguientes casos:
- Telefonía, Contactos, IU del sistema y Multimedia

9.8.7. Acceso al portapapeles

Implementaciones de dispositivos:

[C-0-1] NO DEBE devolver datos recortados del portapapeles (p.ej., a través de la API de ClipboardManager) a menos que la app de terceros sea el IME predeterminado o la app que tiene el foco actualmente.
[C-0-2] DEBE borrar los datos del portapapeles como máximo 60 minutos después de que se hayan colocado o leído por última vez en un portapapeles.

9.8.8. Ubicación

La ubicación incluye información en la clase Location de Android( como latitud, longitud y altitud), así como identificadores que se pueden convertir en Location. La ubicación puede ser tan precisa como la del DGPS (Sistema de posicionamiento global diferencial) o tan general como la de las ubicaciones a nivel del país (como la ubicación del código de país móvil, MCC).

A continuación, se incluye una lista de los tipos de ubicación que derivan directamente la ubicación de un usuario o que se pueden convertir en la ubicación de un usuario. Esta no es una lista exhaustiva, pero se debe usar como ejemplo de lo que se puede derivar de la ubicación de forma directa o indirecta:

GPS/GNSS/DGPS/PPP
- Solución de posicionamiento global, sistema global de navegación por satélite o solución de posicionamiento global diferencial
- También incluye las mediciones GNSS sin procesar y el estado del GNSS.
  - La ubicación precisa se puede derivar de las mediciones GNSS sin procesar
Tecnologías inalámbricas con identificadores únicos, como las siguientes:
- Puntos de acceso Wi-Fi (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, etc., incluidas todas las tecnologías futuras de módem celular que tengan identificadores únicos)

Como punto de referencia principal, consulta las APIs de Android que requieren permisos de ACCESS_FINE_Location o ACCESS_COARSE_Location.

Implementaciones de dispositivos:

[C-0-1] NO DEBE activar ni desactivar la configuración de ubicación del dispositivo ni la configuración de análisis de Wi-Fi o Bluetooth sin el consentimiento explícito del usuario o sin que este inicie la acción.
[C-0-2] DEBE proporcionar la capacidad de acceso del usuario a la información relacionada con la ubicación, incluidas las solicitudes de ubicación recientes, los permisos a nivel de la app y el uso de la búsqueda de dispositivos Wi-Fi o Bluetooth para determinar la ubicación.
[C-0-3] DEBE garantizar que la aplicación que usa la API de Emergency Location Bypass LocationRequest.setLocationSettingsIgnored() sea una sesión de emergencia iniciada por el usuario (p.ej., marcar el 911 o enviar un mensaje de texto al 911). Sin embargo, en el caso de Automotive, 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 conservar la capacidad de las APIs de omisión de ubicación de emergencia para omitir la configuración de ubicación del dispositivo sin cambiarla.
[C-0-5] DEBE programar una notificación que le recuerde al usuario que una app en segundo plano accedió a su ubicación con el permiso ACCESS_BACKGROUND_LOCATION.

Cuando una app en primer plano que no es del sistema accede a la ubicación precisa de un dispositivo, este hace lo siguiente:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE mostrar un indicador visible para el usuario

9.8.9. Apps instaladas

De forma predeterminada, las apps para Android que se segmentan para el nivel de API 30 o superior no pueden ver detalles sobre otras apps instaladas (consulta Visibilidad de paquetes en la documentación del SDK de Android).

Implementaciones de dispositivos:

[C-0-1] NO DEBE exponer a ninguna app que se oriente al nivel de API 30 o superior detalles sobre cualquier otra app instalada, a menos que la app ya pueda ver detalles sobre la otra app instalada a través de las APIs administradas. Esto incluye, sin limitaciones, los detalles expuestos por cualquier API personalizada que agregue el implementador del dispositivo o a la que se pueda acceder a través del sistema de archivos.
[C-0-2] NO DEBE otorgar a ninguna app acceso de lectura o escritura a los archivos en el directorio dedicado y específico de la app de ninguna otra app dentro del almacenamiento externo. Las únicas excepciones son las siguientes:
- Es la autoridad del proveedor de almacenamiento externo (p.ej., apps como DocumentsUI).
- Download Provider que usa la autoridad del proveedor "descargas" para descargar archivos en el almacenamiento de la app.
- Apps del protocolo de transferencia multimedia (MTP) firmadas por la plataforma que usan el permiso privilegiado ACCESS_MTP para habilitar la transferencia de archivos a otro dispositivo.
- Las apps que instalan otras apps y tienen el permiso INSTALL_PACKAGES solo pueden acceder a los directorios "obb" para administrar los archivos de expansión APK.

9.8.10. Informe de errores de conectividad

Si las implementaciones de dispositivos declaran la marca de función android.hardware.telephony, deben cumplir con lo siguiente:

[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 use BUGREPORT_MODE_TELEPHONY para generar un informe y NO DEBE solicitarle al usuario que dé su consentimiento para todas las solicitudes futuras de la aplicación.
[C-1-3] NO DEBE devolver el informe generado a la app solicitante sin el consentimiento explícito del usuario.
[C-1-4] Los informes generados con BUGREPORT_MODE_TELEPHONY DEBEN contener, al menos, la siguiente información:
- TelephonyDebugService volcar
- TelephonyRegistry volcar
- WifiService volcar
- ConnectivityService volcar
- Es un volcado de la instancia CarrierService del paquete de llamada (si está vinculada).
- Búfer de registro de radio
- SubscriptionManagerService volcar
[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 la conectividad
- Registros de tráfico de cualquier tipo de aplicación instalada por el usuario o perfiles detallados de aplicaciones/paquetes instalados por el usuario (los UID están bien, los nombres de paquetes no).
PUEDE incluir información adicional que no esté asociada con ninguna identidad de usuario. (p.ej., registros de proveedores).

Si las implementaciones de dispositivos incluyen información adicional (p.ej., registros de proveedores) en los informes de errores y esa información tiene un impacto en la privacidad, la seguridad, la batería, el almacenamiento o la memoria, deben hacer lo siguiente:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que tengan un parámetro de configuración del desarrollador inhabilitado de forma predeterminada. La implementación de referencia del AOSP cumple con este requisito, ya que proporciona la opción Enable verbose vendor logging en la configuración para desarrolladores para incluir registros adicionales de proveedores específicos del dispositivo en los informes de errores.

9.8.11. Uso compartido de BLOB de datos

A través de BlobStoreManager, Android permite que las apps aporten BLOB de datos al sistema para compartirlos con un conjunto seleccionado de apps.

Si las implementaciones de dispositivos admiten blobs de datos compartidos, como se describe en la documentación del SDK, deben cumplir con lo siguiente:

[C-1-1] NO DEBE compartir blobs de datos que pertenezcan a apps más allá de lo que se pretendía permitir (es decir, el alcance del acceso predeterminado y los otros modos de acceso que se pueden especificar con BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() o BlobStoreManager.session#allowPublicAccess() NO SE DEBEN modificar). La implementación de referencia del AOSP cumple con estos requisitos.
[C-1-2] NO DEBE enviar fuera del dispositivo ni compartir con otras apps los hashes seguros de los BLOB de datos (que se usan para controlar el acceso).

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 el reconocimiento de música, dado un registro de audio, y deleguen el reconocimiento de música a una app privilegiada que implemente la API de MusicRecognitionService.

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema MusicRecognitionManager o cualquier servicio propietario que transmita datos de audio como se describió anteriormente, deben cumplir con lo siguiente:

[C-1-1] DEBE aplicar que el llamador de MusicRecognitionManager tenga el permiso MANAGE_MUSIC_RECOGNITION.
[C-1-2] DEBE aplicar que una sola aplicación de reconocimiento de música preinstalada implemente MusicRecognitionService.
[C-1-3] NO DEBE permitir que los usuarios reemplacen MusicRecognitionManagerService o MusicRecognitionService por una aplicación o un servicio que se pueda instalar.
[C-1-4] DEBE garantizar que, cuando MusicRecognitionManagerService acceda a la grabación de audio y la reenvíe a la aplicación que implementa MusicRecognitionService, el acceso al audio se haga un seguimiento a través de las invocaciones de AppOpsManager.noteOp / startOp.

Si las implementaciones de MusicRecognitionManagerService o MusicRecognitionService en el dispositivo almacenan datos de audio capturados, deben cumplir con lo siguiente:

[C-2-1] NO DEBE almacenar ningún audio sin procesar ni huellas de audio en el disco, ni en la memoria durante más de 14 días.
[C-2-2] NO DEBE compartir esos datos fuera de MusicRecognitionService, excepto con el consentimiento explícito del usuario cada vez que se compartan.

9.8.13. SensorPrivacyManager

Si las implementaciones del dispositivo proporcionan al usuario una ayuda de software para desactivar la entrada de la cámara o el micrófono para la implementación del dispositivo, deben cumplir con lo siguiente:

[C-1-1] DEBE devolver con precisión "verdadero" para el método de la API de supportsSensorToggle() pertinente.
[C-1-2] DEBE, cuando una app intenta acceder a un micrófono o una cámara bloqueados, presentarle al usuario una indicación visual no descartable que indique claramente que el sensor está bloqueado y que requiere una elección para seguir bloqueando o desbloquear, según la implementación de AOSP que cumple con este requisito.
[C-1-3] DEBE pasar solo datos de audio y cámara en blanco (o falsos) a las apps y no informar un código de error debido a que el usuario no activó la cámara ni el micrófono a través de la indicación visual para el usuario que se presenta según [C-1-2] anterior.

9.8.14. N/A

9.8.15. Implementaciones de Private Compute Core y de la aplicación de puerta de enlace

Android, a través de un conjunto de APIs de delegación, proporciona un mecanismo para procesar datos seguros a nivel del SO y datos ambientales. Este procesamiento se puede delegar en un APK preinstalado con acceso privilegiado y capacidades de comunicación reducidas, conocido como implementación de API en zona de pruebas.

Se RECOMIENDA ENCARECIDAMENTE que las implementaciones de dispositivos que incluyen aplicaciones que realizan el procesamiento integrado en el dispositivo de datos sensibles que se describen en la sección 9.8.6 (datos a nivel del SO y datos ambientales) usen el framework de Private Compute Core (PCC) que se describe a continuación.

Cualquier componente de implementación de la API de Sandboxed en el entorno del PCC:

[C-0-1] NO DEBE solicitar el permiso de INTERNET.

[C-0-1] Se DEBE declarar con un atributo android:isPrivateComputeCoreProcess="true" en su declaración de manifiesto.

[C-0-2] SOLO DEBE acceder a Internet a través de APIs estructuradas respaldadas por implementaciones de código abierto disponibles públicamente que usen mecanismos que preserven la privacidad o de forma indirecta a través de las APIs del SDK de Android. El mecanismo que preserva la privacidad se define como "aquellos que solo permiten el análisis de forma agregada y evitan la correlación de eventos registrados o resultados derivados con usuarios individuales", para evitar que se pueda inspeccionar cualquier dato por usuario (p.ej., implementado con una tecnología de privacidad diferencial como RAPPOR).

[C-0-2] DEBE estar precargada en la imagen del sistema del dispositivo.

[C-0-3] DEBE mantener los servicios separados de otros componentes del sistema (p.ej., no vincular el servicio ni compartir IDs de proceso excepto en los siguientes casos:
- Telefonía, Contactos, IU del sistema y Multimedia con implementaciones que no se ejecutan como un UID de PCC).
[C-0-4] NO DEBE permitir que los usuarios reemplacen los servicios con una aplicación o servicio instalable por el usuario
[C-0-5] SOLO DEBE permitir que los servicios preinstalados designados por el OEM (que tengan un rol de sistema adecuado definido en el servicio del sistema de PCC Manager) y con los permisos correspondientes capturen esos datos. A menos que la capacidad de reemplazo esté integrada en AOSP (p. ej., para las apps de asistente digital) datos ambientales sensibles como se describe en 9.8.6
[C-0-6] NO DEBE permitir que ninguna app, excepto el mecanismo de servicios preinstalados, pueda capturar esos datos. A menos que esa capacidad de captura se implemente con una API del SDK de Android.
[C-0-7] DEBE proporcionar al usuario la posibilidad de inhabilitar los servicios.
[C-0-8] NO DEBE omitir la indicación visual del usuario para administrar los permisos de Android que tienen los servicios y debe seguir el modelo de permisos de Android como se describe en la Sección 9.1. Permiso.

[C-0-9] DEBE ejecutarse en un proceso dedicado con un UID único asignado por el framework, independiente del proceso principal de la aplicación y otros componentes de zona de pruebas.

Todo acceso a la red que requieran los componentes del entorno de PCC DEBE realizarse a través de un APK designado que actúe como aplicación de puerta de enlace de PCC. Los componentes designados:

[C-1-1] DEBE tener el permiso con privilegios android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. Este permiso designa la aplicación como una aplicación de puerta de enlace de PCC.
[C-1-2] DEBE tener su código fuente disponible para la verificación pública.
[C-1-3] DEBE utilizar mecanismos que preserven la privacidad para cualquier salida de datos, como se define en la sección 9.8.6.
[C-1-4] DEBE admitir el modo de auditoría del marco de PCC, que incluye el registro de solicitudes de red, extremos del servidor y otros datos relevantes para verificar el comportamiento que preserva la privacidad cuando está habilitado.

9.8.16. Datos continuos de audio y cámara

Si las implementaciones del dispositivo capturan alguno de los datos que se describen en la sección 9.8.2 o la sección 9.8.6, y si dichas implementaciones usan datos de audio obtenidos en segundo plano (de forma continua) a través de AudioRecord, SoundTrigger o cualquier otra API de Audio, O datos de la cámara obtenidos en segundo plano (de forma continua) a través de CameraManager o cualquier otra API de Cámara, deben cumplir con lo siguiente:

[C-0-1] DEBE aplicar un indicador correspondiente (cámara o micrófono, según la sección 9.8.2 Grabación), a menos que se cumpla una de las siguientes condiciones:
- Este acceso se realiza en una implementación de zona de pruebas (consulta 9.8.15 Implementación de la API en zona de pruebas) a través de un paquete que contiene uno o más de los siguientes roles: Inteligencia de la IU del sistema, Inteligencia de audio ambiental del sistema, Inteligencia de audio del sistema, Inteligencia de notificaciones del sistema, Inteligencia de texto del sistema o Inteligencia visual del sistema.
- El acceso se realiza a través de una zona de pruebas, que se implementa y aplica a través de mecanismos en AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
- La aplicación de Asistente digital realiza el acceso al audio con fines de asistencia, y proporciona SOURCE_HOTWORD como fuente de audio.
- El sistema realiza el acceso y lo implementa con código de código abierto.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE solicitar el consentimiento del usuario para cada función que utilice dichos datos y que estén inhabilitadas de forma predeterminada.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE aplicar el mismo tratamiento (es decir, seguir las restricciones que se describen en 9.8.2 Grabación, 9.8.6 Datos a nivel del SO y ambientales, 9.8.15 Implementaciones de APIs en zona de pruebas y 9.8.16 Datos continuos de audio y cámara) a los datos de la cámara que provienen de un dispositivo wearable remoto.

Si las implementaciones de dispositivos reciben datos de la cámara o el micrófono de un dispositivo wearable remoto y se accede a los datos de forma no encriptada fuera del SO Android, la implementación en zona de pruebas o una funcionalidad en zona de pruebas creada por WearableSensingManager, deben cumplir con lo siguiente:

[C-1-1] DEBE indicar al dispositivo wearable remoto que muestre un indicador adicional.

Si los dispositivos brindan la capacidad de interactuar con una aplicación de asistente digital sin la palabra clave asignada (ya sea controlando consultas genéricas del usuario o analizando la presencia del usuario a través de la cámara), deben cumplir con lo siguiente:

[C-2-1] DEBE garantizar que un paquete que tenga el rol de android.app.role.ASSISTANT proporcione esa implementación.
[C-2-2] DEBE garantizar que dicha implementación utilice las APIs de Android HotwordDetectionService o VisualQueryDetectionService.

9.8.17. Telemetría

Android almacena los registros del sistema y de las apps con las APIs de StatsLog. Estos registros se administran a través de las APIs de StatsManager, que pueden usar las aplicaciones del sistema con privilegios.

StatsManager también proporciona una forma de recopilar datos clasificados como sensibles a la privacidad de dispositivos con un mecanismo de preservación de la privacidad. En particular, la API de StatsManager::query proporciona la capacidad de consultar categorías de métricas restringidas definidas en StatsLog.

Cualquier implementación que consulte y recopile métricas restringidas de StatsManager:

[C-0-1] DEBE ser la única aplicación o implementación en el dispositivo y tener el permiso READ_RESTRICTED_STATS.
[C-0-2] SOLO DEBE enviar datos de telemetría y el registro del dispositivo a través de un mecanismo que preserve la privacidad. El mecanismo que preserva la privacidad se define como "aquellos que solo permiten el análisis agregado y evitan la correlación de eventos registrados o resultados derivados con usuarios individuales", para evitar que se puedan inspeccionar los datos por usuario (p.ej., implementados con una tecnología de privacidad diferencial como RAPPOR).
[C-0-3] NO DEBE asociar esos datos con ninguna identidad de usuario (como una Cuenta) en el dispositivo.
[C-0-4] NO DEBE compartir esos datos con otros componentes del SO que no cumplan con los requisitos que se describen en esta sección (9.8.17. Telemetría).
[C-0-5] DEBE proporcionar una opción para el usuario que permita habilitar o inhabilitar la recopilación, el uso y el uso compartido de datos de telemetría que preserven la privacidad.
[C-0-6] DEBE proporcionar al usuario la posibilidad de borrar los datos que recopila la implementación si estos se almacenan de alguna forma en el dispositivo. Si el usuario eligió borrar los datos, SE DEBEN quitar todos los datos almacenados actualmente en el dispositivo.
[C-0-7] Se DEBE divulgar la implementación del protocolo subyacente que preserva la privacidad en un repositorio de código abierto.
[C-0-8] DEBE aplicar las políticas de transferencia de datos en esta sección para controlar la recopilación de datos en las categorías de métricas restringidas definidas en StatsLog.

9.8.18. Privacidad de las funciones de agente

Implementaciones de dispositivos:

[C-0-1] DEBE garantizar que todos los componentes que ejecuten AppFunctions tengan el permiso EXECUTE_APP_FUNCTIONS o EXECUTE_APP_FUNCTIONS_SYSTEM.
[C-0-2] DEBE invocar una llamada a AppFunction solo como resultado directo de una acción explícita del usuario, y esto DEBE indicarle claramente al usuario qué aplicación se invoca y qué acción principal se realizará dentro de esa aplicación.
[C-0-3] NO DEBE actuar como proxy ni modificar la solicitud de una app de terceros para descubrir o ejecutar AppFunctions, a menos que se cumplan [C-0-1] y [C-0-2].
[C-0-4] NO DEBE permitir que los componentes del sistema usen datos sensibles a nivel del SO o del entorno (como se define en 9.8.6 Protecciones de datos a nivel del SO y del entorno) ni sus derivados para generar o parametrizar sugerencias, a menos que los componentes del sistema operen en un entorno de ejecución protegido, como se define en 9.8.6.

Término clave: Se define "sugerencia" como un punto de entrada generado de forma proactiva en una app desde una plataforma del sistema que se inicia sin una acción del usuario directamente anterior. Las sugerencias orientan a los usuarios hacia una acción sin restringir su libertad de elección.

9.9. Encriptación del almacenamiento de datos

Todos los dispositivos DEBEN cumplir con los requisitos de la sección 9.9.1. Los dispositivos que se lanzaron con un nivel de API anterior al de este documento están exentos de los requisitos de las secciones 9.9.2 y 9.9.3. En cambio, DEBEN cumplir con los requisitos de la sección 9.9 del documento de Definición de compatibilidad con Android correspondiente al nivel de API con el que se lanzó el dispositivo.

9.9.1. Modo de inicio directo

Implementaciones de dispositivos:

[C-0-1] DEBE implementar las APIs del modo de inicio directo, incluso si no admiten la encriptación de almacenamiento.
[C-0-2] Los intents ACTION_LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED AÚN se deben transmitir para indicar a las aplicaciones compatibles con el inicio directo que las ubicaciones de almacenamiento encriptado por dispositivo (DE) y encriptado por credenciales (CE) están disponibles para el usuario.

9.9.2. Requisitos de encriptación

Implementaciones de dispositivos:

[C-0-1] DEBE encriptar 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 la encriptación del almacenamiento de datos de forma predeterminada en el momento en que el usuario haya completado la experiencia de configuración inicial.
[C-0-3] DEBE cumplir con el requisito de encriptación de almacenamiento de datos anterior implementando uno de los siguientes dos métodos de encriptación:
- Encriptación basada en archivos (FBE) y encriptación de metadatos, como se describe en la sección 9.9.3.1
- Encriptación a nivel de bloque por usuario, como se describe en la sección 9.9.3.2

9.9.3. Métodos de encriptación

Si las implementaciones de dispositivos están encriptadas, cumplen con los siguientes requisitos:

[C-1-1] DEBE iniciarse sin solicitarle credenciales al usuario y permitir que las apps compatibles con el inicio directo accedan al almacenamiento encriptado del dispositivo (DE) después de que se transmita el mensaje ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] NO DEBE permitir el acceso al almacenamiento de credenciales encriptadas (CE) hasta que se cumplan las siguientes condiciones:
- El usuario desbloquea el dispositivo con un método de autenticación principal (como una contraseña, un patrón o un PIN).
- Se transmite el mensaje ACTION_USER_UNLOCKED.
[C-1-13] NO DEBE ofrecer ningún método para desbloquear el almacenamiento protegido por CE sin las credenciales proporcionadas por el usuario, una clave de depósito registrada o una implementación de reanudación en el reinicio que cumpla con los requisitos de la sección 9.9.4.
[C-1-4] DEBE usar el inicio verificado.

9.9.3.1. Encriptación basada en archivos con encriptación de metadatos

Si las implementaciones de dispositivos usan la encriptación basada en archivos con encriptación de metadatos, deben cumplir con lo siguiente:

[C-1-5] DEBE encriptar el contenido de los archivos y los metadatos del sistema de archivos con AES-256-XTS o Adiantum. AES-256-XTS hace referencia al Estándar de encriptación avanzada con una longitud de clave de cifrado de 256 bits, que funciona en modo XTS. La longitud completa de la clave es de 512 bits. Adiantum hace referencia a Adiantum-XChaCha12-AES, como se especifica en https://github.com/google/adiantum. Los metadatos del sistema de archivos son datos como los tamaños de los archivos, la propiedad, los modos y los atributos extendidos (xattrs).
[C-1-6] DEBE encriptar los nombres de archivos con AES-256-CBC-CTS, AES-256-HCTR2 o Adiantum.
[C-1-12] Si el dispositivo tiene instrucciones del Estándar de Encriptación Avanzada (AES) (como las extensiones de criptografía ARMv8 en dispositivos basados en ARM o AES-NI en dispositivos basados en x86), se DEBEN usar las opciones basadas en AES anteriores para la encriptación del nombre de archivo, el contenido del archivo y los metadatos del sistema de archivos, y no Adiantum.
[C-1-13] Se DEBE usar una función de derivación de claves criptográficamente sólida y no reversible (p.ej., HKDF-SHA512) para derivar las subclaves necesarias (p.ej., claves por archivo) de las claves CE y DE. "Criptográficamente sólida y no reversible" significa que la función de derivación de claves tiene una solidez de seguridad de al menos 256 bits y se comporta como una familia de funciones seudoaleatorias en sus entradas.
[C-1-14] NO DEBE usar las mismas claves o subclaves de File Based Encryption (FBE) para diferentes propósitos criptográficos (p.ej., para la encriptación y la derivación de claves, o para dos algoritmos de encriptación diferentes).
[C-1-15] DEBE garantizar que todos los bloques no borrados de contenido de archivos encriptados en el almacenamiento persistente se hayan encriptado con combinaciones de clave de encriptación y vector de inicialización (IV) que dependan tanto del archivo como del desplazamiento dentro del archivo. Además, todas estas combinaciones DEBEN ser distintas, excepto cuando la encriptación se realice con hardware de encriptación intercalada que solo admita una longitud de IV de 32 bits.
[C-1-16] DEBE garantizar que todos los nombres de archivos encriptados no borrados en el almacenamiento persistente en directorios distintos se hayan encriptado con combinaciones distintas de clave de encriptación y vector de inicialización (IV).
[C-1-17] DEBE garantizar que todos los bloques de metadatos del sistema de archivos encriptados en el almacenamiento persistente se hayan encriptado con combinaciones distintas de clave de encriptación y vector de inicialización (IV).
Claves que protegen las áreas de almacenamiento de CE y DE, y los metadatos del sistema de archivos:
- [C-1-7] DEBE estar vinculada de forma criptográfica a un almacén de claves respaldado por hardware. Este almacén de claves DEBE estar vinculado al inicio verificado y a la raíz de confianza del hardware del dispositivo.
- [C-1-8] Las claves de CE DEBEN estar vinculadas a las credenciales de la pantalla de bloqueo del usuario.
- [C-1-9] Las claves de CE DEBEN estar vinculadas a una contraseña predeterminada cuando el usuario no haya especificado credenciales de pantalla de bloqueo.
- [C-1-10] DEBE ser único y distinto, es decir, la clave de CE o DE de ningún usuario debe coincidir con la clave de CE o DE de ningún otro usuario.
- [C-1-11] DEBE usar los algoritmos de cifrado, las longitudes de clave y los modos admitidos de forma obligatoria.
- [C-1-12] SE DEBE borrar de forma segura durante el desbloqueo y bloqueo del bootloader, como se describe aquí.
DEBE hacer que las apps esenciales preinstaladas (p.ej., Alarma, Teléfono y Mensajes) sean compatibles con el inicio directo.

El proyecto de código abierto de Android upstream proporciona una implementación preferida de la encriptación basada en archivos basada en la función de encriptación "fscrypt" del kernel de Linux y de la encriptación de metadatos basada en la función "dm-default-key" del kernel de Linux.

9.9.3.2. Encriptación a nivel de bloque por usuario

Si las implementaciones de dispositivos usan la encriptación a nivel de bloque por usuario, deben cumplir con lo siguiente:

[C-1-1] DEBE habilitar la compatibilidad multiusuario, como se describe en la sección 9.5.
[C-1-2] DEBE proporcionar particiones por usuario, ya sea con particiones sin procesar o volúmenes lógicos.
[C-1-3] DEBE usar claves de encriptación únicas y distintas por usuario para encriptar los dispositivos de bloques subyacentes.
[C-1-4] DEBE usar AES-256-XTS para la encriptación a nivel de bloque de las particiones del usuario.
Las claves que protegen los dispositivos encriptados a nivel de bloque por usuario:
- [C-1-5] DEBE estar vinculado de forma criptográfica a un almacén de claves respaldado por hardware. Este almacén de claves DEBE estar vinculado al inicio verificado y a la raíz de confianza del hardware del dispositivo.
- [C-1-6] DEBE estar vinculado a las credenciales de la pantalla de bloqueo del usuario correspondiente.

La encriptación a nivel de bloque por usuario se puede implementar con la función "dm-crypt" del kernel de Linux en particiones por usuario.

9.9.4. Reanudar después del reinicio

La función Reanudar después del reinicio permite desbloquear el almacenamiento de CE de todas las apps, incluidas las que aún no admiten el inicio directo, después de un reinicio iniciado por una actualización inalámbrica. Esta función permite que los usuarios reciban notificaciones de las apps instaladas después del reinicio.

Una implementación de Reanudar tras reiniciar debe seguir garantizando que, cuando un dispositivo cae en manos de un atacante, sea extremadamente difícil para este recuperar los datos encriptados con CE del usuario, incluso si el dispositivo está encendido, el almacenamiento CE está desbloqueado y el usuario desbloqueó el dispositivo después de recibir una OTA. Para la resistencia a ataques internos, también suponemos que el atacante obtiene acceso a las claves de firma criptográfica de transmisión.

Más precisamente, sucederá lo siguiente:

[C-0-1] El almacenamiento de CE NO DEBE ser legible, ni siquiera para el atacante que tiene físicamente el dispositivo y, luego, tiene estas capacidades y limitaciones:
- Puede usar la clave de firma de cualquier proveedor o empresa para firmar mensajes arbitrarios.
- Puede hacer que el dispositivo reciba una actualización OTA.
- Puede modificar el funcionamiento de cualquier hardware (AP, flash, etc.), excepto como se detalla a continuación, pero dicha modificación implica una demora de al menos una hora y un ciclo de energía que destruye el contenido de la RAM.
- No se puede modificar el funcionamiento del hardware resistente a manipulaciones (p. ej., Titan M).
- No se puede leer la RAM del dispositivo activo.
- No se puede obtener la credencial del usuario (PIN, patrón, contraseña) ni hacer que se ingrese.

A modo de ejemplo, una implementación de dispositivo que implemente y cumpla con todas las descripciones que se encuentran aquí cumplirá con [C-0-1].

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan la transparencia del estado de la integridad del dispositivo. Implementaciones de dispositivos:

[C-0-1] DEBE informar correctamente a través del método de la API del sistema PersistentDataBlockManager.getFlashLockState() si el estado del bootloader permite escribir en la memoria flash de la imagen del sistema.
[C-0-2] DEBE admitir el inicio verificado para la integridad del dispositivo.

Si las implementaciones de dispositivos ya se lanzaron sin admitir el inicio verificado en una versión anterior de Android y no pueden agregar compatibilidad con esta función con una actualización de software del sistema, ES POSIBLE que se eximan del requisito.

[C-1-1] DEBE declarar la marca de función de la plataforma android.software.verified_boot.
[C-1-2] DEBE realizar la verificación en cada secuencia de inicio.
[C-1-3] DEBE iniciar la verificación desde una llave física inmutable que sea la raíz de confianza y llegar hasta la partición del sistema.
[C-1-4] DEBE implementar cada etapa de verificación para comprobar la integridad y autenticidad de todos los bytes en la siguiente etapa antes de ejecutar el código en la siguiente etapa.
[C-1-5] DEBE usar algoritmos de verificación tan sólidos como las recomendaciones actuales del NIST para los algoritmos de hash (SHA-256) y los tamaños de clave pública (RSA-2048).
[C-1-6] NO DEBE permitir que se complete el inicio cuando falla la verificación del sistema, a menos que el usuario acepte intentar el inicio de todos modos, en cuyo caso NO se deben usar los datos de los bloques de almacenamiento no verificados.
[C-1-7] NO DEBE permitir que se modifiquen las particiones verificadas en el dispositivo, a menos que el usuario haya desbloqueado explícitamente el bootloader.
[C-1-8] DEBE usar almacenamiento a prueba de manipulaciones: para almacenar si el cargador de arranque está desbloqueado. El almacenamiento a prueba de manipulaciones significa que el bootloader puede detectar si se manipuló el almacenamiento desde el interior de Android.
[C-1-9] DEBE solicitarle al usuario, mientras usa el dispositivo, y requerir confirmación física antes de permitir una transición del modo de bootloader bloqueado al modo de bootloader desbloqueado.
[C-1-10] Se DEBE implementar la protección contra reversión para las particiones que usa Android (p.ej., particiones de arranque y del sistema) y usar almacenamiento a prueba de manipulaciones para almacenar los metadatos que se usan para determinar la versión mínima permitida del SO.
[C-1-11] DEBE borrar de forma segura todos los datos del usuario durante el desbloqueo y bloqueo del bootloader, según el artículo 9.12. Borrado de datos" (incluida la partición de datos del usuario y cualquier espacio de NVRAM).
[C-1-14] Se DEBE verificar la firma al menos una vez por inicio para los paquetes incluidos en la lista de entidades permitidas que se indican como require-strict-signature en la configuración del sistema.
[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE verificar todos los archivos APK de apps con privilegios con una cadena de confianza basada en particiones protegidas por el inicio verificado.
[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE verificar cualquier artefacto ejecutable que cargue una app privilegiada desde fuera de su archivo APK (como código cargado de forma dinámica o código compilado) antes de ejecutarlo o se RECOMIENDA ENCARECIDAMENTE no ejecutarlo en absoluto.
DEBE implementar protección contra reversión para cualquier componente con firmware persistente (p.ej., módem, cámara) y DEBE usar almacenamiento a prueba de manipulaciones para almacenar los metadatos que se usan para determinar la versión mínima permitida.

El Proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función en el repositorio external/avb/, que se puede integrar en el bootloader que se usa para cargar Android.

Si las implementaciones de dispositivos tienen la capacidad de verificar el contenido de los archivos por página, deben hacer lo siguiente:

[C-2-1] Admite la verificación criptográfica del contenido del archivo sin leerlo por completo.
[C-2-2] NO DEBE permitir que las solicitudes de lectura en un archivo protegido se realicen correctamente cuando el contenido de lectura no se verifique según [C-2-1] anterior.
[C-2-4] DEBE devolver la suma de verificación del archivo en O(1) para los archivos habilitados.

Si las implementaciones de dispositivos ya se lanzaron sin la capacidad de verificar el contenido del archivo con una clave de confianza en una versión anterior de Android y no pueden agregar compatibilidad con esta función con una actualización de software del sistema, ES POSIBLE que se eximan del requisito. El proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función basada en la función fs-verity del kernel de Linux.

9.11. Claves y credenciales

El sistema Android Keystore permite que los desarrolladores de apps almacenen claves criptográficas en un contenedor y las usen en operaciones criptográficas a través de la API de KeyChain o la API de Keystore. Implementaciones de dispositivos:

[C-0-1] DEBE permitir la importación o generación de al menos 8,192 claves.
[C-0-2] La autenticación de la pantalla de bloqueo DEBE implementar un intervalo de tiempo entre los intentos fallidos. Con n como el recuento de intentos fallidos, el intervalo de tiempo DEBE ser de al menos 30 segundos para 9 < n < 30. Para n > 29, el valor del intervalo de tiempo DEBE ser de al menos 30*2^floor((n-30)/10) segundos o al menos 24 horas, el que sea menor.
NO DEBE limitar la cantidad de claves que se pueden generar.

Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, sucede lo siguiente:

[C-1-1] DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.

[C-1-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA, ECDH (si se admite IKeyMintDevice), 3DES y HMAC, y funciones hash MD5, SHA-1 y de la familia SHA-2 los algoritmos criptográficos y las funciones hash que requiere la versión compatible de IKeyMintDevice o IKeymasterDevice para admitir correctamente los algoritmos compatibles del sistema Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito usando la implementación de 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.

[C-1-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislado y solo cuando se realice correctamente, permitir que se usen 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 upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
[C-1-4] DEBE admitir la certificación de claves en la que la clave de firma de certificación esté protegida por hardware seguro y la firma se realice en hardware seguro. Se DEBE evitar que las claves de firma de la certificación se usen como identificadores permanentes del dispositivo.

Nota: Para cumplir con este requisito, debes compartir la misma clave de certificación para un SKU determinado, a menos que se produzcan al menos 100,000 unidades de ese SKU. Si se producen más de 100,000 unidades de ese SKU, se PUEDE usar una clave diferente para cada grupo de 100,000 unidades después de eso. Como alternativa, se puede usar la solución de Remote Key Provisioning para aprovisionar claves de certificación de corta duración en el dispositivo.

[C-1-5] DEBE permitir que el usuario elija el tiempo de espera de suspensión para la transición del estado desbloqueado al bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos. Los dispositivos para automóviles que bloquean la pantalla cada vez que se apaga la consola central o se cambia de usuario NO DEBEN tener la configuración de tiempo de espera de suspensión.
[C-1-6] DEBE admitir IKeymasterDevice 3.0 o una versión posterior, o IKeyMintDevice versión 1 o una versión posterior.

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que apliquen un intervalo de tiempo mínimo entre los intentos fallidos únicos para sus métodos de autenticación principales (como PIN, patrón o contraseña), según lo siguiente:

Cantidad de intentos únicos fallidos	Tiempo de espera mínimo
0-4	0
5	1 minuto
6	5 minutos
7	15 minutos
8	30 minutos
9	90 minutos
10	4 horas
11	12 horas
12	24 horas
13	4 días
14	13 días
15	41 días
16	123 días
17	1 año
18	3 años
19	9 años

9.11.1. Bloqueo seguro de pantalla, autenticación y dispositivos virtuales

La implementación del AOSP sigue un modelo de autenticación por niveles en el que una autenticación principal basada en un factor de conocimiento puede respaldarse con una autenticación biométrica secundaria sólida o con modalidades terciarias más débiles.

Implementaciones de dispositivos:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE establecer solo uno de los siguientes métodos como el método de autenticación principal:
- Un PIN numérico
- Una contraseña alfanumérica
- Un patrón de deslizamiento en una cuadrícula de exactamente 3 x 3 puntos
Ten en cuenta que los métodos de autenticación anteriores se consideran los métodos de autenticación principales recomendados en este documento.
[C-0-1] DEBE limitar la cantidad de intentos fallidos de autenticación principal.
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE implementar un límite superior de 20 intentos fallidos de autenticación principal y, si los usuarios dan su consentimiento y habilitan la función, realizar un "restablecimiento de la configuración de fábrica" después de superar el límite de intentos fallidos de autenticación principal.

Si las implementaciones del dispositivo establecen un PIN numérico como el método de autenticación principal recomendado, se deben cumplir las siguientes condiciones:

[C-SR-6] SE RECOMIENDA ENCARECIDAMENTE que el PIN tenga al menos 6 dígitos o, lo que es equivalente, una entropía de 20 bits.
[C-SR-7] NO SE RECOMIENDA PERMITIR el ingreso automático sin interacción del usuario para un PIN de menos de 6 dígitos, ya que se podría revelar la longitud del PIN.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación principales recomendados y usan un nuevo método de autenticación como una forma segura de bloquear la pantalla, el nuevo método de autenticación debe cumplir con los siguientes requisitos:

[C-2-1] DEBE ser el método de autenticación del usuario como se describe en Solicita la autenticación del usuario para el uso de la clave.

Si las implementaciones del dispositivo agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo en función de un secreto conocido y usan un nuevo método de autenticación para que se considere una forma segura de bloquear la pantalla, haz lo siguiente:

[C-3-1] La entropía de la longitud más corta permitida de las entradas DEBE ser mayor que 10 bits.
[C-3-2] La entropía máxima de todas las entradas posibles DEBE ser superior a 18 bits.
[C-3-3] El nuevo método de autenticación NO DEBE reemplazar ninguno de los métodos de autenticación principales recomendados (es decir, PIN, patrón, contraseña) implementados y proporcionados en AOSP.
[C-3-4] El nuevo método de autenticación DEBE inhabilitarse cuando la aplicación de controlador de política de dispositivo (DPC) haya establecido la política de requisitos de contraseña a través de DevicePolicyManager.setRequiredPasswordComplexity() con una constante de complejidad más restrictiva que PASSWORD_COMPLEXITY_NONE o a través del método DevicePolicyManager.setPasswordQuality() con una constante más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] Los métodos de autenticación nuevos DEBEN recurrir a los métodos de autenticación principales recomendados (es decir, PIN, patrón, contraseña) cada 72 horas o menos, O bien divulgar claramente al usuario que no se realizará una copia de seguridad de algunos datos para preservar la privacidad de sus datos.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación principales recomendados para desbloquear la pantalla de bloqueo y usan un nuevo método de autenticación basado en datos biométricos para que se considere una forma segura de bloquear la pantalla, el nuevo método debe cumplir con los siguientes requisitos:

[C-4-1] DEBE cumplir con todos los requisitos descritos en la sección 7.3.10 para la Clase 1 (anteriormente Comodidad).
[C-4-2] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados que se basa en un secreto conocido.
[C-4-3] DEBE inhabilitarse y solo permitir la autenticación principal recomendada para desbloquear la pantalla cuando la aplicación del controlador de políticas de dispositivo (DPC) haya establecido la política de funciones de Keyguard llamando al método DevicePolicyManager.setKeyguardDisabledFeatures() con cualquiera de los indicadores biométricos asociados (es decir, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Si los métodos de autenticación biométrica no cumplen con los requisitos de la clase 3 (anteriormente segura) como se describe en la sección 7.3.10, haz lo siguiente:

[C-5-1] Los métodos DEBEN inhabilitarse si la aplicación del controlador de política de dispositivo (DPC) estableció la política de calidad de requisitos de contraseña a través de DevicePolicyManager.setRequiredPasswordComplexity() con un bucket de complejidad más restrictivo que PASSWORD_COMPLEXITY_LOW o con el método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] Se DEBE solicitar al usuario la autenticación principal recomendada (como PIN, patrón o contraseña) como se describe en [C-1-7] y [C-1-8] en la sección 7.3.10.
[C-5-3] Los métodos NO DEBEN tratarse como una pantalla de bloqueo segura y DEBEN cumplir con los requisitos que comienzan con C-8 en esta sección a continuación.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo y un nuevo método de autenticación se basa en un token físico o la ubicación, se deben cumplir los siguientes requisitos:

[C-6-1] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados que se basa en un secreto conocido y cumple con los requisitos para considerarse una pantalla de bloqueo segura.
[C-6-2] El nuevo método DEBE inhabilitarse y solo permitir uno de los métodos de autenticación principales recomendados para desbloquear la pantalla cuando la aplicación del controlador de políticas de dispositivos (DPC) haya establecido la política con una de las siguientes opciones:
- El método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).
- El método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_NONE.
- El método DevicePolicyManager.setRequiredPasswordComplexity() con un bucket de complejidad más restrictivo que PASSWORD_COMPLEXITY_NONE.
[C-6-3] Se DEBE solicitar al usuario que utilice uno de los métodos de autenticación principales recomendados (como PIN, patrón o contraseña) al menos una vez cada 4 horas o menos. Cuando un token físico cumple con los requisitos para las implementaciones de TrustAgent en C-X, se aplican las restricciones de tiempo de espera definidas en [C-9-5].
[C-6-4] El nuevo método NO DEBE tratarse como una pantalla de bloqueo segura y DEBE cumplir con las restricciones que se indican en C-8 a continuación.

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y uno o más agentes de confianza que implementan la API de TrustAgentService System, deben cumplir con lo siguiente:

[C-7-1] DEBE tener una indicación clara en el menú de configuración y en la pantalla de bloqueo cuando el bloqueo del dispositivo se pospone o se puede desbloquear con agentes de confianza. Por ejemplo, el AOSP cumple con este requisito mostrando una descripción de texto para los parámetros de configuración "Bloqueo automático" y "Bloquear con el botón de encendido" en el menú de configuración, y un ícono distinguible en la pantalla de bloqueo.
[C-7-2] DEBE respetar y, por completo, implementar todas las APIs de agentes de confianza en la clase DevicePolicyManager, como la constante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NO DEBE implementar por completo la función TrustAgentService.addEscrowToken() en un dispositivo que se use como dispositivo personal principal (p.ej., de mano), pero PUEDE implementar por completo la función en implementaciones de dispositivos que suelen ser compartidos (p.ej., Android TV o dispositivo para automóviles).
[C-7-4] DEBE encriptar todos los tokens almacenados que se agreguen con TrustAgentService.addEscrowToken().
[C-7-5] NO DEBE almacenar la clave de encriptación ni el token de depósito en garantía en el mismo dispositivo en el que se usa la clave. Por ejemplo, se permite que una llave almacenada en un teléfono desbloquee una cuenta de usuario en una TV. En el caso de los dispositivos para automóviles, no se permite que el token de depósito se almacene en ninguna parte del vehículo.
[C-7-6] DEBE informar al usuario sobre las implicaciones de seguridad antes de habilitar el token de depósito en garantía para desencriptar el almacenamiento de datos.
[C-7-7] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados.
[C-7-9] Se DEBE solicitar al usuario que use uno de los métodos de autenticación principal recomendados (como PIN, patrón o contraseña) que se describen en [C-1-7] y [C-1-8] en la sección 7.3.10, a menos que la seguridad del usuario (p.ej., distracción del conductor) sea un problema.
[C-7-10] NO DEBE tratarse como una pantalla de bloqueo segura y DEBE cumplir con las restricciones que se indican en C-8 a continuación.
[C-7-11] NO DEBE permitir que los agentes de confianza en dispositivos personales principales (p. ej., de mano) desbloqueen el dispositivo, y solo puede usarlos para mantener un dispositivo ya desbloqueado en el estado de desbloqueo durante un máximo de 4 horas. La implementación predeterminada de TrustManagerService en AOSP cumple con este requisito.
[C-7-12] DEBE usar un canal de comunicación seguro a nivel criptográfico (p. ej., UKEY2) para pasar el token de depósito del dispositivo de almacenamiento al dispositivo de destino.

Si las implementaciones del dispositivo agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo que no es una pantalla de bloqueo segura como se describió anteriormente, y usan un nuevo método de autenticación para desbloquear el keyguard, haz lo siguiente:

[C-8-1] El nuevo método DEBE inhabilitarse cuando la aplicación del controlador de políticas del dispositivo (DPC) haya establecido la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_NONE o a través de DevicePolicyManager.setRequiredPasswordComplexity() con una constante de complejidad más restrictiva que PASSWORD_COMPLEXITY_NONE.
[C-8-2] NO DEBEN restablecer los temporizadores de caducidad de contraseñas establecidos por DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] NO DEBEN exponer una API para que las apps de terceros la usen para cambiar el estado de bloqueo.

Si las implementaciones de dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y no admiten eventos de entrada asociados, como a través de VirtualDeviceManager, deben cumplir con lo siguiente:

[C-9-1] DEBE bloquear estas pantallas virtuales secundarias cuando se bloquee la pantalla predeterminada del dispositivo y desbloquearlas cuando se desbloquee la pantalla predeterminada del dispositivo.

Si las implementaciones de dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y admitan eventos de entrada asociados, por ejemplo, a través de VirtualDeviceManager, deben cumplir con lo siguiente:

[C-10-1] DEBE admitir estados de bloqueo separados por dispositivo virtual
[C-10-2] Se quitó el requisito en Android 16.
[C-10-3] Se quitó el requisito en Android 16.
[C-10-4] DEBE bloquear todas las pantallas cuando el usuario inicie un bloqueo, incluso a través de la indicación visual de bloqueo requerida para dispositivos de mano (consulta la Sección 2.2.5[9.11/H-1-2]).
[C-10-5] DEBE tener instancias de dispositivos virtuales separadas por usuario
[C-10-6] DEBE inhabilitar la transmisión de la app como lo indica DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] Se quitó el requisito en Android 16.
[C-10-11] DEBE inhabilitar la IU de autenticación en dispositivos virtuales, lo que incluye la entrada del factor de conocimiento y la solicitud biométrica.
[C-10-12] Se quitó el requisito en Android 16.
[C-10-13] NO DEBE usar un estado de bloqueo del dispositivo virtual como autorización de autenticación del usuario con el sistema Android Keystore. Consulta KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] DEBE proporcionar una indicación visual para que el usuario habilite el uso compartido del portapapeles entre dispositivos antes de compartir datos del portapapeles entre dispositivos físicos y virtuales si el dispositivo implementa un portapapeles compartido.
[C-10-15] DEBE mostrar notificaciones cuando se acceda a los datos del portapapeles tanto en el dispositivo desde el que se accedió como en el dispositivo desde el que se originó el portapapeles.

Cuando las implementaciones de dispositivos permiten que el usuario transfiera el factor de conocimiento de autenticación principal de un dispositivo fuente a un dispositivo de destino, como para la configuración inicial del dispositivo de destino, deben cumplir con lo siguiente:

[C-11-1] DEBE encriptar el factor de conocimiento con garantías de protección similares a las que se describen en el informe de seguridad de Google Cloud Key Vault Service cuando se transfiera el factor de conocimiento del dispositivo de origen al dispositivo de destino, de modo que el factor de conocimiento no se pueda desencriptar de forma remota ni usar para desbloquear de forma remota ninguno de los dispositivos.
[C-11-2] DEBE, en el dispositivo de origen , pedirle al usuario que confirme el factor de conocimiento del dispositivo de origen antes de transferirlo al dispositivo de destino.
[C-11-3] DEBE, en un dispositivo de destino que carezca de cualquier factor de conocimiento de autenticación principal establecido, pedirle al usuario que confirme un factor de conocimiento transferido en el dispositivo de destino antes de establecer ese factor de conocimiento como el factor de conocimiento de autenticación principal para el dispositivo de destino y antes de poner a disposición cualquier dato transferido desde un dispositivo fuente.

[C-12-1] SOLO se DEBE llamar a grantTrust() con la marca cuando se conecta a un dispositivo físico cercano con su propia pantalla de bloqueo y cuando el usuario autenticó su identidad en esa pantalla de bloqueo. Los dispositivos cercanos pueden usar mecanismos de detección en la muñeca o de transporte después de que el usuario desbloquee el dispositivo por única vez para satisfacer el requisito de autenticación del usuario.
[C-12-2] DEBE colocar la implementación del dispositivo en el estado TrustState.TRUSTABLE cuando la pantalla esté apagada (por ejemplo, a través de una presión del botón o un tiempo de espera de la pantalla) y TrustAgent no haya revocado la confianza. AOSP satisface este requisito.
[C-12-3] SOLO DEBE cambiar el dispositivo del estado TrustState.TRUSTABLE al estado TrustState.TRUSTED si TrustAgent sigue otorgando confianza según los requisitos de [C-12-1].

[C-12-4] DEBE llamar a TrustManagerService.revokeTrust() si las implementaciones no usan un rango preciso y seguro a nivel criptográfico, como se define en [C-12-5]:
- Después de un máximo de 24 horas de haber otorgado la confianza
- Después de un período de inactividad de 8 horas
- Si las implementaciones no usan un rango preciso y seguro desde el punto de vista criptográfico, como se define en [C-12-5], cuando se pierde la conexión subyacente con el dispositivo físico cercano.

[C-12-5] Las implementaciones que dependen de un rango seguro y preciso para cumplir con los requisitos de [C-12-4] DEBEN usar una de las siguientes soluciones:
- Implementaciones que usan UWB:
  - DEBE cumplir con los requisitos de conformidad, certificación, precisión y calibración para UWB que se describen en 7.4.9.
  - DEBE usar uno de los modos de seguridad de P-STS que se indican en 7.4.9.
- Implementaciones que usan Neighbor Awareness Networking (NAN) de Wi-Fi:
  - DEBE cumplir con los requisitos de exactitud que se indican en 2.2.1 [7.4.2.5/H-SR-1], usar el ancho de banda de 160 MHz (o superior) y seguir los pasos de configuración de medición que se especifican en Calibración de presencia.
  - DEBE usar LTF seguro, como se define en IEEE 802.11az.

[C-13-8] DEBE impedir que se inicien en el dispositivo virtual las actividades con el atributo android:canDisplayOnRemoteDevices o los metadatos android.activity.can_display_on_remote_devices establecidos en falso.
[C-13-9] DEBE bloquear las actividades que no habiliten explícitamente la transmisión y que indiquen que muestran contenido sensible, incluso a través de SurfaceView#setSecure y FLAG_SECURE, para que no se inicien en el dispositivo virtual.

Si las implementaciones de dispositivos admiten estados de energía de pantalla separados a través de DeviceStateManager Y admiten estados de bloqueo de pantalla separados a través de KeyguardDisplayManager, deben cumplir con lo siguiente:

[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE utilizar una credencial que cumpla con los requisitos definidos en la sección 9.11.1 o una reunión biométrica que cumpla al menos con las especificaciones de Clase 1 definidas en la sección 7.3.10 para permitir el desbloqueo independiente de la pantalla predeterminada del dispositivo.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE restringir el desbloqueo de la pantalla independiente a través de un tiempo de espera de la pantalla definido.
[C-SR-4] Se RECOMIENDA ENCARECIDAMENTE permitir que el usuario bloquee de forma global todas las pantallas a través del bloqueo desde el dispositivo de mano principal.

9.11.2. StrongBox

El sistema Android Keystore permite a los desarrolladores de apps almacenar claves criptográficas en un procesador seguro dedicado, así como en el entorno de ejecución aislado que se describió anteriormente. Este procesador seguro exclusivo se denomina "StrongBox". Los requisitos C-1-3 a C-1-11 que se indican a continuación definen los requisitos que debe cumplir un dispositivo para calificar como StrongBox.

Implementaciones de dispositivos que tienen un procesador seguro dedicado:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir StrongBox. Es probable que StrongBox se convierta en un requisito en una versión futura.

Si las implementaciones de dispositivos admiten StrongBox, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] DEBE proporcionar hardware seguro dedicado que se use para respaldar el almacén de claves y la autenticación segura del usuario. El hardware seguro dedicado también se puede usar para otros fines.
[C-1-3] DEBE tener una CPU discreta que no comparta caché, DRAM, coprocesadores ni otros recursos principales con el procesador de aplicaciones (AP).
[C-1-4] DEBE garantizar que los periféricos compartidos con el AP no puedan alterar el procesamiento de StrongBox de ninguna manera ni obtener información de StrongBox. El AP PUEDE inhabilitar o bloquear el acceso a StrongBox.
[C-1-5] DEBE tener un reloj interno con una precisión razonable (+/- 10%) que sea inmune a la manipulación por parte del AP.
[C-1-6] DEBE tener un generador de números aleatorios reales que produzca resultados impredecibles y distribuidos de manera uniforme.
[C-1-7] DEBE tener resistencia a la manipulación, incluida la resistencia a la penetración física y a las fallas.
[C-1-8] DEBE tener resistencia a los canales laterales, incluida la resistencia a la filtración de información a través de los canales laterales de energía, tiempo, radiación electromagnética y radiación térmica.
[C-1-9] DEBE tener almacenamiento seguro que garantice la confidencialidad, integridad, autenticidad, coherencia y actualidad del contenido. El almacenamiento NO DEBE poder leerse ni alterarse, excepto según lo permitan las APIs de StrongBox.

Para validar el cumplimiento de [C-1-3] a [C-1-9], las implementaciones de dispositivos deben hacer lo siguiente:

[C-1-10] DEBE incluir el hardware certificado según el perfil de protección de CI seguro BSI-CC-PP-0084-2014 o BSI-CC-PP-0117-2022, o bien debe ser evaluado por un laboratorio de pruebas acreditado a nivel nacional que incorpore una evaluación de vulnerabilidades con alto potencial de ataque según los Criterios Comunes para la aplicación del potencial de ataque a tarjetas inteligentes.
[C-1-11] DEBE incluir el firmware que evalúa un laboratorio de pruebas acreditado a nivel nacional que incorpora una evaluación de vulnerabilidad con alto potencial de ataque según los Criterios Comunes para la Aplicación del Potencial de Ataque a Tarjetas Inteligentes.
[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que se incluya el hardware que se evalúa con un objetivo de seguridad, un nivel de garantía de evaluación (EAL) 5 y que se complementa con AVA_VAN.5. Es probable que la certificación EAL 5 se convierta en un requisito en una versión futura.
[C-SR-3] SE RECOMIENDA ENCARECIDAMENTE que proporcionen resistencia a ataques internos (IAR), lo que significa que un empleado interno con acceso a las claves de firma de firmware no puede producir firmware que haga que StrongBox filtre secretos, eluda los requisitos de seguridad funcionales o permita el acceso a datos sensibles del usuario. La forma recomendada de implementar IAR es permitir las actualizaciones de firmware solo cuando se proporciona la contraseña del usuario principal a través del HAL de IAuthSecret.

9.11.3. Credencial de identidad

El sistema de credenciales de identidad se define y se logra implementando todas las APIs en el paquete android.security.identity.*. Estas APIs permiten que los desarrolladores de apps almacenen y recuperen documentos de identidad del usuario. Implementaciones de dispositivos:

[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar el sistema de credenciales de identidad.

Si las implementaciones de dispositivos implementan el sistema de credenciales de identidad, deben hacer lo siguiente:

[C-1-1] DEBE devolver un valor no nulo para el método IdentityCredentialStore#getInstance().
[C-1-2] DEBE implementar el sistema de credenciales de identidad (p.ej., las APIs de android.security.identity.*) con código que se comunique con una aplicación de confianza en un área que esté aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA.
[C-1-3] Las operaciones criptográficas necesarias para implementar el sistema de credenciales de identidad (p.ej., las APIs de android.security.identity.*) DEBEN realizarse por completo en la aplicación de confianza, y el material de la clave privada NUNCA debe salir del entorno de ejecución aislado, a menos que las APIs de nivel superior lo requieran específicamente (p.ej., el método createEphemeralKeyPair()).
[C-1-4] La aplicación de confianza DEBE implementarse de manera tal que sus propiedades de seguridad no se vean afectadas (p.ej., los datos de credenciales no se liberan a menos que se cumplan las condiciones de control de acceso, no se pueden producir MAC para datos arbitrarios) incluso si Android se comporta de forma incorrecta o está comprometido.

El proyecto de código abierto de Android upstream proporciona una implementación de referencia de una aplicación de confianza (libeic) que se puede usar para implementar el sistema de Identity Credential.

9.12. Eliminación de Datos

Todas las implementaciones de dispositivos:

[C-0-1] DEBE proporcionar a los usuarios un mecanismo para realizar un "restablecimiento de la configuración de fábrica".
[C-0-2] DEBE borrar todos los datos del sistema de archivos userdata cuando se realice un "restablecimiento de la configuración de fábrica".
[C-0-3] DEBE borrar los datos de manera que satisfaga los estándares de la industria pertinentes, como NIST SP800-88, cuando se realice un "restablecimiento de datos de fábrica".
[C-0-4] DEBE activar el proceso de "Restablecimiento de la configuración de fábrica" anterior cuando la app de controlador de política de dispositivo del usuario principal llame a la API de DevicePolicyManager.wipeData().
PUEDE proporcionar una opción de borrado rápido de datos que solo realice un borrado lógico de datos.

9.13. Modo de inicio seguro

Android proporciona el modo seguro, que permite a los usuarios iniciar el dispositivo en un modo en el que solo se pueden ejecutar las apps del sistema preinstaladas y se inhabilitan todas las apps de terceros. Este modo, conocido como "Modo de inicio seguro", le permite al usuario desinstalar apps de terceros potencialmente dañinas.

Las implementaciones de dispositivos son las siguientes:

[C-SR-1] SE RECOMIENDA ENCARECIDAMENTE implementar el modo de inicio seguro.

Si las implementaciones de dispositivos implementan el modo de inicio seguro, deben hacer lo siguiente:

[C-1-1] DEBE proporcionar al usuario una opción para ingresar al modo seguro de forma tal que no se interrumpa desde las apps de terceros instaladas en el dispositivo, excepto cuando la app de terceros sea un controlador de políticas del dispositivo y haya establecido la marca UserManager.DISALLOW_SAFE_BOOT como verdadera.
[C-1-2] DEBE proporcionar al usuario la capacidad de desinstalar cualquier app de terceros en el modo seguro.
DEBE proporcionar al usuario una opción para ingresar al Modo seguro desde el menú de arranque con un flujo de trabajo diferente al de un arranque normal.

9.14. Aislamiento del sistema del vehículo automotriz

Se espera que los dispositivos Android Automotive intercambien datos con subsistemas críticos del vehículo a través del HAL del vehículo para enviar y recibir mensajes a través de redes del vehículo, como el bus CAN.

El intercambio de datos se puede proteger implementando funciones de seguridad por debajo de las capas del framework de Android para evitar la interacción maliciosa o no intencional con estos subsistemas.

9.15. Planes de suscripción

Los "planes de suscripción" hacen referencia a los detalles del plan de relación de facturación que proporciona un operador de telefonía celular a través de SubscriptionManager.setSubscriptionPlans().

Todas las implementaciones de dispositivos:

[C-0-1] DEBE devolver los planes de suscripción solo a la app del operador de telefonía celular que los proporcionó originalmente.
[C-0-2] NO DEBE crear copias de seguridad de forma remota ni subir planes de suscripción.
[C-0-3] SOLO DEBE permitir anulaciones, como SubscriptionManager.setSubscriptionOverrideCongested(), desde la app del operador de telefonía celular que actualmente proporciona planes de suscripción válidos.

9.16. Migración de datos de la aplicación

Si las implementaciones de dispositivos incluyen una capacidad para migrar datos de un dispositivo a otro y no limitan los datos de la aplicación que copian a lo que configuró el desarrollador de la aplicación en el manifiesto a través del atributo android:fullBackupContent, deben cumplir con lo siguiente:

[C-1-1] NO DEBE iniciar transferencias de datos de la aplicación desde dispositivos en los que el usuario no haya establecido una autenticación principal, como se describe en 9.11.1 Bloqueo seguro de pantalla y autenticación.
[C-1-2] DEBE confirmar de forma segura la autenticación principal en el dispositivo fuente y confirmar con la intención del usuario de copiar los datos en el dispositivo fuente antes de que se transfieran los datos.
[C-1-3] DEBE usar la certificación de claves de seguridad para garantizar que tanto el dispositivo de origen como el dispositivo de destino en la migración de dispositivo a dispositivo sean dispositivos Android legítimos y tengan un bootloader bloqueado.
[C-1-4] SOLO SE DEBEN migrar los datos de la aplicación a la misma aplicación en el dispositivo de destino, con el mismo nombre de paquete Y certificado de firma.
[C-1-5] DEBE mostrar una indicación de que el dispositivo fuente migró datos a través de una migración de datos de dispositivo a dispositivo en el menú de configuración. Un usuario NO DEBE poder quitar esta indicación.

9.17. Android Virtualization Framework

Las APIs de Android Virtualization Framework (AVF) (android.system.virtualmachine.*) permiten que las aplicaciones creen máquinas virtuales (VM) integradas en el dispositivo, protegidas (pVM) y no protegidas (non-pVM), que cargan y ejecutan archivos binarios nativos como cargas útiles.

Si las implementaciones de dispositivos establecen FEATURE_VIRTUALIZATION_FRAMEWORK en true, hacen lo siguiente:

[C-1-1] DEBE garantizar que android.system.virtualmachine.VirtualMachineManager.getCapabilities() devuelva uno de los siguientes valores:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Verificación de programador

Implementaciones de dispositivos que declaran el nivel de API 36.1 o superior:

PUEDE incluir compatibilidad con un servicio de verificación de desarrolladores para certificar que las aplicaciones provienen de un desarrollador conocido.

Implementaciones de dispositivos que declaran el nivel de API 36.1 o superior y configuran un verificador de desarrollador definiendo config_developerVerificationServiceProviderPackageName en config.xml:

[9.18/C-1-1] DEBE invocar el android.content.pm.verify.developer.DeveloperVerifierService configurado para cada instalación de paquete de aplicación, lo que incluye las instalaciones nuevas y las actualizaciones de las aplicaciones existentes.

Implementaciones de dispositivos que declaran el nivel de API 36.1 o superior:

También PUEDE configurar un delegado para establecer la política activa definiendo config_developerVerificationPolicyDelegatePackageName en config.xml.

Si se configura un verificador de desarrolladores, las implementaciones del dispositivo deben hacer lo siguiente:

[9.18/C-2-1] SOLO DEBE permitir que el verificador del desarrollador o su delegado configurado establezcan la política de instalación como se define en android.content.pm.PackageInstaller.

Si se invoca un verificador como parte de una sesión de instalación de paquetes, las implementaciones del dispositivo deben hacer lo siguiente:

[9.18/C-3-1] DEBE impedir la instalación de un paquete de aplicación en los siguientes casos:
- La instalación no pasa la verificación de identidad del desarrollador.
- La política de verificación del desarrollador para la sesión de instalación se establece en cualquier valor que no sea DEVELOPER_VERIFICATION_POLICY_NONE.
- A menos que se aplique el artículo 9.18/C-3-2 o el 9.18/C-3-3.

[9.18/C-3-2] NO DEBE impedir la instalación de un paquete de aplicación, independientemente de la política o el estado de verificación, en los siguientes casos:
- El paquete se instala a través de Android Debug Bridge (ADB).
- El paquete es el verificador de desarrolladores configurado o su instalador.

[9.18/C-3-3] NO DEBE impedir la instalación de un paquete de aplicación cuando se cumplan todas las siguientes condiciones:
- La política se establece en DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN o DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- Se informa que la verificación está incompleta.
- El instalador indica que el usuario solicitó explícitamente que se continúe con la instalación informando DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

PUEDE permitir la instalación de un paquete de aplicación independientemente de la política o el estado de verificación para las instalaciones iniciadas por el propietario del dispositivo en un dispositivo administrado o el propietario del perfil en un perfil administrado, pero se RECOMIENDA ENCARECIDAMENTE evitar las instalaciones como se describe en 9.18/C-3-1.

10. Pruebas de compatibilidad de software

Las implementaciones de dispositivos DEBEN aprobar todas las pruebas que se describen en esta sección. Sin embargo, ten en cuenta que ningún paquete de pruebas de software es completamente integral. Por este motivo, se RECOMIENDA ENCARECIDAMENTE a los implementadores de dispositivos que realicen la menor cantidad posible de cambios en la implementación de referencia y preferida de Android disponible en el Proyecto de código abierto de Android. Esto minimizará el riesgo de introducir errores que creen incompatibilidades que requieran volver a trabajar y posibles actualizaciones del dispositivo.

10.1. Conjunto de pruebas de compatibilidad (CTS)

Implementaciones de dispositivos:

[C-0-1] DEBE aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el Proyecto de código abierto de Android, con el software final de envío en el dispositivo.
[C-0-2] DEBE garantizar la compatibilidad en casos de ambigüedad en el CTS y para cualquier reimplementación de partes del código fuente de referencia.

El CTS está diseñado para ejecutarse en un dispositivo real. Al igual que cualquier software, el CTS puede contener errores. El CTS tendrá versiones independientes de esta Definición de compatibilidad, y es posible que se lancen varias revisiones del CTS para Android 17.

Implementaciones de dispositivos:

[C-0-3] DEBE aprobar la versión más reciente de las CTS disponible en el momento en que se completa el software del dispositivo.
DEBE usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible.

10.2. Verificador del CTS

El verificador del CTS se incluye en el Conjunto de pruebas de compatibilidad y un operador humano debe ejecutarlo para probar la funcionalidad que no puede probar un sistema automatizado, como el funcionamiento correcto de una cámara y los sensores.

Implementaciones de dispositivos:

[C-0-1] DEBE ejecutar correctamente todos los casos aplicables en el verificador de CTS.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluido algunos que son opcionales.

Implementaciones de dispositivos:

[C-0-2] DEBE aprobar todas las pruebas del hardware que posea. Por ejemplo, si un dispositivo tiene un acelerómetro, DEBE ejecutar correctamente el caso de prueba del acelerómetro en el CTS Verifier.

Los casos de prueba para las funciones que se indican como opcionales en este documento de Definición de compatibilidad SE PUEDEN omitir.

[C-0-2] Todos los dispositivos y todas las compilaciones DEBEN ejecutar correctamente el CTS Verifier, como se indicó anteriormente. Sin embargo, dado que muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten explícitamente el CTS Verifier en compilaciones que solo difieran de manera trivial. Específicamente, las implementaciones de dispositivos que difieren de una implementación que aprobó el verificador del CTS solo por el conjunto de configuraciones regionales incluidas, la marca, etcétera, PUEDEN omitir la prueba del verificador del CTS.

11. Software actualizable

[C-0-1] Las implementaciones de dispositivos DEBEN incluir un mecanismo para reemplazar la totalidad del software del sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, ES POSIBLE que se requiera un reinicio del dispositivo. Se puede usar cualquier método, siempre y cuando pueda reemplazar la totalidad del software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques satisfará este requisito:
- Descargas "inalámbricas (OTA)" con actualización sin conexión a través de un reinicio.
- Actualizaciones "vinculadas" a través de USB desde una PC host
- Actualizaciones “sin conexión” a través de un reinicio y una actualización desde un archivo en un almacenamiento extraíble
[C-0-2] El mecanismo de actualización que se use DEBE admitir actualizaciones sin borrar los datos del usuario. Es decir, el mecanismo de actualización DEBE preservar los datos privados de la aplicación y los datos compartidos de la aplicación. Ten en cuenta que el software de Android upstream incluye un mecanismo de actualización que satisface este requisito.
[C-0-3] Toda la actualización DEBE estar firmada, y el mecanismo de actualización integrado en el dispositivo DEBE verificar la actualización y la firma con una clave pública almacenada en el dispositivo.
[C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que el mecanismo de firma genere un hash de la actualización con SHA-256 y valide el hash con la clave pública usando ECDSA NIST P-256.

Si las implementaciones del dispositivo incluyen compatibilidad con una conexión de datos no medida, como el perfil de red de área personal (PAN) 802.11 o Bluetooth, entonces:

[C-1-1] DEBE admitir descargas OTA con actualización sin conexión a través del reinicio.

Las implementaciones de dispositivos DEBEN verificar que la imagen del sistema sea idéntica en formato binario al resultado esperado después de una OTA. La implementación de OTA basada en bloques en el Proyecto de código abierto de Android upstream, que se agregó desde Android 5.1, satisface este requisito.

Además, las implementaciones de dispositivos DEBEN admitir actualizaciones del sistema A/B. El AOSP implementa esta función con el HAL de control de arranque.

Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro de su vida útil razonable, que se determina en consulta con el equipo de compatibilidad de Android y que afecta la compatibilidad de las aplicaciones de terceros, se hará lo siguiente:

[C-2-1] El implementador del dispositivo DEBE corregir el error a través de una actualización de software disponible que se pueda aplicar según el mecanismo que se acaba de describir.

Android incluye funciones que permiten que la app de propietario del dispositivo (si está presente) controle la instalación de actualizaciones del sistema. Si el subsistema de actualización del sistema para dispositivos informa android.software.device_admin, entonces:

[C-3-1] DEBE implementar el comportamiento que se describe en la clase SystemUpdatePolicy.

12. Registro de cambios del documento

A partir de Android 16, no hay un registro de cambios que se mantenga por separado. Todos los cambios de la versión anterior se resaltan en este documento.

13. Comunícate con nosotros

Puedes unirte al foro de compatibilidad con Android y pedir aclaraciones o plantear cualquier problema que creas que el documento no aborda.

Definición de compatibilidad con Android 17 [VERSIÓN PRELIMINAR] Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

1. Introducción

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

1.1.2. ID del requisito

1.1.3. ID de requisito en la sección 2

2. Tipos de dispositivos

2.1 Configuraciones del dispositivo

2.2. Requisitos para dispositivos portátiles

2.2.1. Hardware

2.2.2. Multimedia

2.2.3. Software

2.2.3. Software

2.2.4. Rendimiento y potencia

2.2.5. Modelo de seguridad

Configuración restringida

2.2.6. Compatibilidad de las opciones y herramientas para desarrolladores

2.2.7. Clase de rendimiento del contenido multimedia manual

2.2.7.1. Medios

2.2.7.2. Cámara

2.2.7.3. Hardware

2.2.7.4. Rendimiento

2.2.7.5. Gráficos

2.3. Requisitos de la televisión

2.3.1. Hardware

2.3.2. Multimedia

2.3.3. Software

2.3.4. Rendimiento y potencia

2.3.5. Modelo de seguridad

2.3.6. Compatibilidad de las opciones y herramientas para desarrolladores

2.4. Requisitos del reloj

2.4.1. Hardware

2.4.2. Multimedia

2.4.3. Software

2.4.4. Rendimiento y potencia

2.4.5. Modelo de seguridad

2.5. Requisitos para la industria automotriz

2.5.1. Hardware

2.5.2. Multimedia

2.5.3. Software

2.5.4. Rendimiento y potencia

2.5.5. Modelo de seguridad

2.5.6. Compatibilidad de las opciones y herramientas para desarrolladores

2.6. Requisitos de la tablet

2.6.1. Hardware

2.6.2. Modelo de seguridad

2.6.2. Software

3. Software

3.1. Compatibilidad de la API administrada

3.1.1. Extensiones de Android

3.1.2. Biblioteca de Android

3.2. Compatibilidad de API flexible

3.2.1. Permisos

3.2.2. Parámetros de compilación

3.2.3. Compatibilidad de intents

3.2.3.1. Intents de aplicaciones comunes

3.2.3.2. Resolución de intents

3.2.3.3. Espacios de nombres de intents

3.2.3.4. Intents de transmisión

3.2.3.5. Intents de la aplicación condicionales

3.2.4. Actividades en pantallas secundarias o múltiples

3.3. Compatibilidad con la API nativa

3.3.1. Interfaces binarias de aplicaciones

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

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

3.4.2. Compatibilidad del navegador

3.5. Compatibilidad de comportamiento de la API

3.5.1. Restricción de aplicación

3.5.2. Hibernación de aplicaciones

3.6. Espacios de nombres de la API

3.7. Compatibilidad con el entorno de ejecución

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Selector (pantalla principal)

3.8.2. Widgets

3.8.3. Notificaciones

3.8.3.1. Presentación de notificaciones

3.8.3.2. Servicio de detección de notificaciones

3.8.3.3. DND (No interrumpir) o modo de prioridad

3.8.3.4. Protección de notificaciones sensibles

Definición de compatibilidad con Android 17 [VERSIÓN PRELIMINAR]