Definición de compatibilidad de Android 14

1. Introducción

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

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

Como se usa en este documento, un "implementador de dispositivos" o "implementador" es una persona o una organización que desarrolla una solución de hardware o software con Android 14. Una "implementación de dispositivos" o "implementación" es la solución de hardware o software así desarrollada.

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

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

Por este motivo, el Proyecto de código abierto de Android es la referencia y la implementación preferida de Android. Se RECOMIENDA QUE los implementadores de dispositivos basen sus implementaciones en la mayor medida posible en el código fuente "ascendente" disponible en el Proyecto de código abierto de Android. Si bien algunos componentes pueden reemplazarse de manera hipotética con implementaciones alternativas, se recomienda no seguir esta práctica, ya que pasar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluida el Conjunto de pruebas de compatibilidad y fuera de ella. Por último, ten en cuenta que en este documento se prohíben explícitamente algunas sustituciones y modificaciones de componentes.

Muchos de los recursos vinculados en este documento se derivan directa o indirectamente del SDK de Android y serán funcionalmente idénticos a la información en la documentación del SDK. En los casos en los que esta definición de compatibilidad o el Conjunto de pruebas de compatibilidad no estén de acuerdo con la documentación del SDK, la documentación del SDK se considera autorizada. Cualquier detalle técnico que se proporcione en los recursos vinculados en este documento se considerará por inclusión como parte de esta definición de compatibilidad.

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

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

Todos los demás requisitos, que se aplican universalmente a cualquier implementación de dispositivos Android, se enumeran en las secciones posteriores a la Sección 2. Estos requisitos se mencionan como “Requisitos principales” en este documento.

1.1.2. ID de requisito

El ID de requisito se asignó para los requisitos MUST.

• El ID se asigna solo para los requisitos MUST.
• Los requisitos ESPECIAMENTE RECOMENDADOS se marcan como [SR], pero no se asigna el ID.
• El ID consta de lo siguiente : 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 del tipo de dispositivo (obtén más información en 2. Tipos de dispositivo)
  • C: Core (requisitos que se aplican a todas las implementaciones de dispositivos Android)
  • H: Dispositivo de mano Android
  • T: dispositivo de televisión Android
  • A: 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 a la 1a condición, y el número se incrementa en 1 dentro de la misma sección y el mismo tipo de dispositivo.
• ID de requisito
  • Este ID comienza desde 1 y aumenta de a 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 los requisitos en la Sección 2 tienen dos partes. El primero corresponde a un ID de sección, como se describió anteriormente. La segunda parte identifica el factor de forma y sus requisitos específicos.

seguida del ID de requisito descrito anteriormente.

• El ID de la sección 2 consta de lo siguiente: ID de la sección / ID del tipo de dispositivo - ID de condición - ID de requisito (p.ej., 7.4.3/A-0-1).

2. Tipos de dispositivo

El Proyecto de código abierto de Android proporciona una pila de software que se puede usar para diferentes 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 de kernel alternativo, se ejecute en un entorno seguro, como se describe en la sección 9 y en otras secciones de este CDD. Hay 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, y los requisitos y las recomendaciones adicionales aplicables para cada uno.

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

2.1 Configuraciones del dispositivo

Para conocer las principales diferencias en la configuración de hardware por tipo de dispositivo, consulta los requisitos específicos de cada dispositivo que se incluyen 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 en un dispositivo Android que, por lo general, se usa cuando se lo sostiene en la mano, como un reproductor de mp3, un teléfono o una tablet.

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

• Tener una fuente de alimentación que brinde movilidad, como una batería
• Tener un tamaño de pantalla diagonal físico de 4 pulgadas 3.3 pulgadas (o 2.5 pulgadas para las implementaciones en dispositivos que se incluyeron en el nivel de API 29 o versiones anteriores) a 8 pulgadas
• Tener una interfaz de entrada con pantalla táctil

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

2.2.1. Hardware

Implementaciones en dispositivos de mano:

• [7.1.1.1/H-0-1] DEBE tener al menos una pantalla compatible con Android que cumpla con todos los requisitos descritos en este documento. pantalla que mida al menos 2.2" en el borde corto y 3.4" en el borde largo.

• [7.1.1.3/H-SR-1] SE RECOMIENDA IMPORTANTEMENTE que les brinden a los usuarios una indicación para cambiar el tamaño de visualización (densidad de pantalla).

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

Si las implementaciones de dispositivos de mano declaran la compatibilidad con pantallas de alto rango dinámico a través de Configuration.isScreenHdr() , sucede lo siguiente:

• [7.1.4.5/H-1-1] SE 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 en dispositivos de mano:

• [7.1.4.6/H-0-1] SE 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 la compatibilidad mediante una propiedad del sistema graphics.gpu.profiler.support, sucede lo siguiente:

• [7.1.4.6/H-1-1] SE DEBE informar como resultado un seguimiento de protobuf que cumpla con el esquema para los contadores de GPU y las etapas de renderización de GPU definidas en la documentación de Perfetto.
• [7.1.4.6/H-1-2] DEBE informar los valores correspondientes a los contadores de GPU del dispositivo según el proto proto del paquete de seguimiento del contador de GPU.
• [7.1.4.6/H-1-3] DEBE informar los valores correspondientes a las RenderStages de la GPU del dispositivo según el proto proto del paquete de seguimiento de la etapa de renderización.
• [7.1.4.6/H-1-4] SE DEBE informar un punto de seguimiento de frecuencia de la GPU, como se especifica en el formato power/gpu_frequency.

Implementaciones en dispositivos de mano:

• [7.1.5/H-0-1] DEBE incluir compatibilidad con el modo de compatibilidad de aplicaciones heredadas como se implementa en el código fuente abierto de Android. Es decir, las implementaciones en dispositivos NO DEBEN alterar los activadores o los umbrales en los que se activa el modo de compatibilidad, ni el comportamiento del modo de compatibilidad en sí.
• [7.2.1/H-0-1] DEBE incluir compatibilidad con aplicaciones de terceros del Editor de método de entrada (IME).
• [7.2.3/H-0-2] SE DEBE enviar el evento de mantener presionado y de mantener presionado de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano. El sistema NO DEBE consumir estos eventos y pueden activarse 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 proporcionan 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 ser compatible con la entrada de pantalla táctil.
• [7.2.4/H-SR-1] SE RECOMIENDA EJECUTARMENTE iniciar la aplicación de asistencia seleccionada por el usuario, es decir, la aplicación que implementa VoiceInteractionService o una actividad que controla ACTION_ASSIST al mantener presionado KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no controla esos eventos de presión prolongada.
• [7.3.1/H-SR-1] SE RECOMIENDA ES IMPORTANTE que incluyan un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos de mano incluyen un acelerómetro de 3 ejes, sucederá lo siguiente:

• [7.3.1/H-1-1] SE 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 e informan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, sucederá lo siguiente:

• [7.3.3/H-2-1] SE DEBE informar las mediciones de GNSS apenas se encuentran, incluso si aún no se informa una ubicación calculada a partir del GPS/GNSS.
• [7.3.3/H-2-2] DEBEN informar pseudorrangos y pseudorrangos GNSS que, en condiciones a cielo abierto después de determinar la ubicación, mientras el dispositivo se mueve con menos de 0.2 metros por segundo al cuadrado de aceleración, son suficientes para calcular la posición dentro de los 20 metros y la velocidad dentro de los 0.29 metros por segundo, al menos, del 0.25% de tiempo por segundo.

Si las implementaciones de dispositivos de mano incluyen un giroscopio de 3 ejes, sucederá lo siguiente:

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

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

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

Implementaciones en dispositivos de mano:

• [7.3.11/H-SR-1] SE RECOMIENDA ENERCMENTE que admitan el sensor de postura con 6 grados de libertad.
• [7.4.3/H] SE DEBE incluir compatibilidad con Bluetooth y Bluetooth LE.

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

• [7.4.2.5/H-1-1] DEBE informar el rango con precisión dentro de +/-1 metro a 160 MHz de ancho de banda en el percentil 68 (como se calcula con la función de distribución acumulativa), +/-2 metros a 80 MHz en el percentil 68, +/-4 m a 40 MHz de ancho de banda observado en el percentil 68-10 MHz, y -4 m a 8 m MHz en el percentil 68 MHz, y un ancho de banda de +/-4 MHz en el percentil 68 MHz, y 8 m MHz a 8 m MHz, inicia 68 m MHz y un ancho de banda de 68 MHz a 8 mR.

• Se recomienda [7.4.2.5/H-SR-1] que informen el rango con precisión dentro de +/-1 metro a 160 MHz en el percentil 90 (como se calcula con la función de distribución acumulativa), +/-2 metros a 80 MHz en el ancho de banda a 80 MHz en el percentil 90, y +/-4 MHz en el percentil 90 MHz, y +/-4 MHz en el percentil 90 MHz.

Te recomendamos que sigas los pasos para configurar la medición que se especifican en Calibración de presencias.

Si las implementaciones de dispositivos de mano incluyen un dispositivo de cámara lógico que enumera las capacidades mediante CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, sucederá lo siguiente:

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

Implementaciones en 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 conocido como partición “/data”).
• [7.6.1/H-0-2] SE DEBE mostrar "true" para ActivityManager.isLowRamDevice() cuando hay menos de 1 GB de memoria disponible para el kernel y el espacio de usuario.

Si las implementaciones de dispositivos de mano declaran solo la compatibilidad con una ABI de 32 bits:

• [7.6.1/H-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 416 MB si la pantalla predeterminada usa resoluciones del 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 de 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 de usuario DEBE ser de al menos 896 MB si la pantalla predeterminada usa resoluciones del 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 de 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 la compatibilidad con cualquier ABI de 64 bits (con o sin alguna ABI de 32 bits), haz lo siguiente:

• [7.6.1/H-5-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 816 MB si la pantalla predeterminada 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 de 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 de 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 de usuario" anterior hace referencia al espacio de memoria proporcionado además de cualquier memoria que ya esté dedicada a componentes de hardware, como radio, video, etc., que no estén bajo el control del kernel en las implementaciones en dispositivos.

Si las implementaciones de dispositivos de mano incluyen 1 GB de memoria disponible para el kernel y el espacio del usuario, o más, suceden lo siguiente:

• [7.6.1/H-9-1] SE 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, suceden 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 conocido como partición “/data”).
• SE DEBE declarar la marca de función android.hardware.ram.normal.

Si las implementaciones de dispositivos de mano incluyen 2 GB o más de 4 GB de memoria disponibles para el kernel y el espacio de usuario, deben hacer lo siguiente:

• [7.6.1/H-SR-1] SE RECOMIENDA ES IMPORTANTE que solo admitan un 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 del usuario, sucederán lo siguiente:

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

Implementaciones en dispositivos de mano:

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

Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con el modo periférico, sucederá lo siguiente:

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

Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con el modo de host, harán lo siguiente:

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

Implementaciones en 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 pueden cumplir con todos los requisitos de rendimiento para admitir el modo de RV y, además, incluirla, sucederá lo siguiente:

• [7.9.1/H-1-1] SE 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 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 de host e implementan (clase de audio USB), además de los requisitos de la sección 7.7.2, hacen lo siguiente:

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

Función	Asignaciones	La importancia	Comportamiento
R.	Página de uso de HID: 0x0C Uso de HID: 0x0CD Clave de kernel: KEY_PLAYPAUSE Clave de Android: KEYCODE_MEDIA_PLAY_PAUSE	Reproducción de contenido multimedia	Entrada: Presionar brevemente Salida: Reproducir o pausar
			Entrada: Mantener presionado Salida: Iniciar comando por voz Envíos: android.speech.action.VOICE_SEARCH_HANDS_FREE si el dispositivo está bloqueado o su pantalla está apagada. De lo contrario, envía android.speech.RecognizerIntent.ACTION_WEB_SEARCH.
		Llamada entrante	Entrada: Presionar brevemente Salida: Aceptar llamada
			Entrada: Mantener presionado Resultado: Rechazar llamada
		Llamada en curso	Entrada: Presionar brevemente Salida: Finalizar llamada
			Entrada: Mantener presionado Salida: Silenciar o activar el sonido del micrófono
millones	Página de uso de HID: 0x0C Uso de HID: 0x0E9 Clave de kernel: KEY_VOLUMEUP Clave de Android: VOLUME_UP	Reproducción de contenido multimedia, llamada en curso	Entrada: Mantén presionado el botón Salida: Aumenta el volumen del sistema o de los auriculares.
C	Página de uso de HID: 0x0C Uso de HID: 0x0EA Clave de kernel: KEY_VOLUMEDOWN Clave de Android: VOLUME_DOWN	Reproducción de contenido multimedia, llamada en curso	Entrada: Mantén presionado el botón Salida: Disminuye el volumen del sistema o de los auriculares.
D	Página de uso de HID: 0x0C Uso de HID: 0x0CF Clave de kernel: KEY_VOICECOMMAND Clave de Android: KEYCODE_VOICE_ASSIST	Todo. Se puede activar en cualquier instancia.	Entrada: Mantén presionado Salida: Inicia un comando por voz

• [7.8.2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG cuando se inserta un enchufe, 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 detecta el tipo de terminal de audio USB 0x0302, sucede lo siguiente:

• [7.8.2.2/H-2-1] SE DEBE transmitir el intent ACTION_HEADSET_PLUG con el valor adicional "microphone" establecido en 0.

Cuando se detecta el tipo de terminal de audio USB 0x0402, se realizan las siguientes acciones:

• [7.8.2.2/H-3-1] SE DEBE transmitir el intent ACTION_HEADSET_PLUG con el valor adicional "microphone" establecido en 1.

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

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

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

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

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

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

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

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

• [7.8.2.2/H-SR-1] Se RECOMIENDEN EXITOSAMENTE cuando se conecta un periférico de audio USB-C para realizar la enumeración de los descriptores USB, identificar los tipos de terminal y transmitir el intent ACTION_HEADSET_PLUG en menos de 1, 000 milisegundos.

Si las implementaciones de dispositivos de mano declaran android.hardware.audio.output y android.hardware.microphone, hacen lo siguiente:

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

• [5.6/H-1-2] DEBE tener una latencia promedio de Tono para presionar de 300 milisegundos o menos en al menos 5 mediciones en la ruta de acceso de datos de la bocina al micrófono.

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

Si las implementaciones de dispositivos de mano incluyen al menos un accionador de resonante lineal 7.10 de uso general, sucederá lo siguiente:

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

Si las implementaciones de dispositivos de mano tienen un accionador táctil de uso general que es un accionador de resonante lineal del eje X (LRA), hacen lo siguiente:

• [7.10/H] DEBE tener que la frecuencia resonante del eje X LRA sea inferior a 200 Hz.

Si las implementaciones de dispositivos de mano siguen la asignación de constantes táctiles, harán lo siguiente:

• [7.10/H]* SE DEBE verificar el estado de implementación ejecutando las APIs de android.os.Vibrator.areAllEffectsSupported() y android.os.Vibrator.arePrimitivesSupported().

• [7.10/H]* SE DEBE realizar una evaluación de calidad para las constantes táctiles.

• [7.10/H]* SE DEBE verificar y actualizar, si es necesario, la configuración de resguardo para primitivas no compatibles, como se describe en la guía de implementación para constantes.

2.2.2. Multimedia

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

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

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

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

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

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

2.2.3. Software

Implementaciones en 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 e ACTION_CREATE_DOCUMENT, como se describe en los documentos del SDK, y que proporcione al usuario la posibilidad de acceder a los datos del proveedor de documentos con la API de DocumentsProvider.
• [3.2.3.1/H-0-2]* SE DEBE precargar una o más aplicaciones o componentes del servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de aplicación enumerados aquí.
• [3.2.3.1/H-SR-1] SE RECOMIENDA COMPLETAMENTE la precarga de una aplicación de correo electrónico que pueda controlar los intents 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 del usuario general.
• [3.8.1/H-SR-1] SE RECOMIENDA COMPLETAMENTE implementar un selector predeterminado que admita la fijación de accesos directos, widgets y widgetFeatures en la app.
• [3.8.1/H-SR-2] SE RECOMIENDA COMPLETAMENTE implementar un selector predeterminado que proporcione acceso rápido a accesos directos adicionales proporcionados por apps de terceros a través de la API de shortManager.
• [3.8.1/H-SR-3] SE RECOMIENDA COMPLETAMENTE incluir una app de selector predeterminada que muestre insignias para los íconos de las apps.
• [3.8.2/H-SR-1] SE RECOMIENDA ENERGMENTE para 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 notables 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 de atención.
• [3.8.3/H-0-4] DEBE incluir un panel de notificaciones que le permita al usuario controlar directamente (p.ej., responder, posponer, descartar o bloquear) las notificaciones a través de la indicación visual del usuario, como botones de acción o el panel de control, como se implementa en el AOSP.
• [3.8.3/H-0-5] SE 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 MUY BIEN 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 MUY BIEN mostrar todas las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el panel de notificaciones cuando el usuario expande todas las notificaciones en el panel.
• [3.8.3.1/H-SR-1] SE RECOMIENDA COMPLETAMENTE mostrar acciones para las que Notification.Action.Builder.setContextual esté configurado como true en línea con las respuestas que muestra Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] SE RECOMIENDA COMPLETAMENTE implementar un asistente en el dispositivo para realizar la acción de asistencia.

Si las implementaciones de dispositivos de mano admiten notificaciones MediaStyle, hacen lo siguiente:

• [3.8.3.1/H-SR-2] SE RECOMIENDA ESTAR EN VEZ para proporcionar una indicación visual de usuario (por ejemplo, un selector de salida) a la que se acceda desde la IU del sistema que les permita cambiar entre las rutas de contenido multimedia correspondientes (por ejemplo, dispositivos Bluetooth y rutas proporcionadas a MediaRouter2Manager) cuando una app publica una notificación MediaStyle con un token MediaSession.

Si las implementaciones de dispositivos de mano admiten la acción de asistencia, sucederá lo siguiente:

• [3.8.4/H-SR-2] SE RECOMIENDA ENcarecidamente mantener presionada la tecla HOME como la interacción designada para iniciar la app de asistencia, como se describe en la sección 7.2.3. DEBE iniciar la app de asistencia seleccionada por el usuario; en otras palabras, la app 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 independiente de alertas y notificaciones silenciosas sin conversación, sucederá lo siguiente:

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

Si las implementaciones de dispositivos de mano Android admiten una pantalla de bloqueo, sucederá lo siguiente:

• [3.8.10/H-1-1] SE DEBE mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificaciones multimedia.

Si las implementaciones de dispositivos de mano admiten una pantalla de bloqueo segura, sucederá lo siguiente:

• [3.9/H-1-1] SE DEBE implementar la gama completa de políticas de administración de dispositivos que se definen 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 aplicaciones de terceros publiquen controles de dispositivos, sucederá lo siguiente:

• [3.8.16/H-1-1] SE DEBE declarar la marca de función android.software.controls y establecerla en true.
• [3.8.16/H-1-2] DEBE brindarle al usuario la posibilidad de agregar, editar, seleccionar y operar los controles de dispositivo 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 del usuario en un plazo de tres interacciones desde un Selector predeterminado.

• [3.8.16/H-1-4] DEBE renderizar con precisión el nombre y el ícono de cada app de terceros que proporcione controles mediante la API de ControlsProviderService, así como cualquier campo especificado que proporcionen las APIs de Control, en esta indicación visual.

• [3.8.16/H-1-5] DEBE brindarle al usuario la posibilidad de inhabilitar los controles de dispositivos triviales de autenticación designados de la app de los controles registrados por las aplicaciones de terceros a través de la API de ControlsProviderService y la API de Control.isAuthRequired de Control.

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

• [3.8.16/H-2-1] SE DEBE informar null para las APIs de ControlsProviderService y Control.
• [3.8.16/H-2-2] SE DEBE declarar la marca de función android.software.controls y establecerla en false.

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

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

Implementaciones en dispositivos de mano:

• [3.10/H-0-1] DEBE admitir servicios de accesibilidad de terceros.
• [3.10/H-SR-1] SE RECOMIENDA RECOMENDADAMENTE que precargan los servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de Accesibilidad con interruptores y TalkBack (para idiomas compatibles con el motor de texto a voz preinstalado) como se proporciona 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 COMPLETAMENTE incluir un motor de TTS compatible con los idiomas disponibles en el dispositivo.
• [3.13/H-SR-1] SE RECOMIENDA INCREÍBLEMENTE que incluyan 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, harán 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:

• [7.2.3/H] La zona de reconocimiento de gestos para la función principal DEBE tener una altura no 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 parte 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 2 GB de memoria disponibles o más para el kernel y el espacio del usuario, sucederá lo siguiente:

• [3.9/H-1-2] SE 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, harán lo siguiente:

• [7.5.4/H-1-1] DEBE respetar el intent android.media.action.STILL_IMAGE_CAMERA y android.media.action.STILL_IMAGE_CAMERA_SECURE, e iniciar la cámara en modo de imagen estática como se describe en el SDK.
• [7.5.4/H-1-2] DEBE respetar el intent android.media.action.VIDEO_CAMERA para 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 de dispositivos implementa una funcionalidad de división mediante la incorporación de actividades, hará lo siguiente:

• [3.2.3.1/ H-1-1] DEBE tener una actividad que controle el intent Settings#ACTION_CONFIG_EMBED_DEEP_LINK_ACTIVITY cuando la función 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_CONFIG_EMBEDDED_DEEP_LINK_INTENT_URI.

2.2.4. Rendimiento y potencia

• [8.1/H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas incoherente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia a 5 fotogramas por segundo, y SE DEBE ser inferior a 1 fotograma en un segundo.
• [8.1/H-0-2] Latencia de la interfaz de usuario. Las implementaciones del dispositivo DEBEN garantizar una experiencia del usuario de baja latencia desplazando una lista de 10,000 entradas de lista según lo que define el Conjunto de pruebas de compatibilidad (CTS) de Android en menos de 36 segundos.
• [8.1/H-0-3] Cambio de tareas. Cuando se inician varias aplicaciones, volver a iniciar una aplicación que ya está en ejecución DEBE tardar menos de 1 segundo.

Implementaciones en 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 aleatorio 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 extender las funciones incluidas en el AOSP, sucederá lo siguiente:

• [8.3/H-1-1] DEBE proporcionar la indicación visual del usuario para habilitar e inhabilitar la función de ahorro de batería.
• [8.3/H-1-2] DEBE proporcionar la indicación visual del usuario para mostrar todas las apps exentas de los modos de ahorro de energía App Standby y Descanso.

Implementaciones en dispositivos de mano:

• [8.4/H-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual de cada componente de hardware y el agotamiento aproximado de la batería causado por 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 DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
• [8.4/H-0-3] DEBE informar el consumo de energía de la CPU según el UID de cada proceso. El Proyecto de código abierto de Android cumple con los requisitos mediante la implementación del módulo de kernel uid_cputime.
• [8.4/H-0-4] DEBE hacer que este uso de energía esté disponible para el desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.
• [8.4/H] SE DEBE atribuir al componente de hardware si no se puede atribuir el uso de energía de un componente de hardware a una aplicación.

Si las implementaciones para dispositivos de mano incluyen una salida de pantalla o de video, sucederá lo siguiente:

• [8.4/H-1-1] DEBE respetar el intent android.intent.action.POWER_USAGE_SUMMARY y mostrar un menú de configuración que indique este uso de energía.

Implementaciones en dispositivos de mano:

• [8.5/H-0-1] DEBE proporcionar una indicación visual del usuario en el menú Configuración para ver todas las apps con servicios activos en primer plano o tareas iniciadas por el usuario, incluida la duración de cada uno de estos servicios, ya que comenzaron como se describe en el documento del SDK. y la capacidad de detener una app que está ejecutando un servicio en primer plano para ver todas las apps con servicios activos en primer plano o tareas iniciadas por el usuario, incluida la duración de cada uno de estos servicios, ya que comenzaron como se describe en el documento del SDK. y la capacidad de detener una app que está ejecutando un servicio en primer plano y que tiene la capacidad de detener {/1 si el documento está activo y la capacidad de un servicio iniciado por el usuario
  • Es posible que algunas apps estén exentas de detenerse o de mostrarse en tal condición de usuario, como se describe en el documento del SDK.

2.2.5. Modelo de seguridad

Implementaciones en 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 otorgue o revoque el acceso a esas apps en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementaciones en dispositivos de mano:

• [9.11/H-0-2] SE DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
• [9.11/H-0-3] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones de hash de la familia MD5, SHA1 y SHA-2 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 versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos mediante los cuales el kernel o el código del espacio del usuario podrían acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) ascendente cumple con este requisito mediante 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 un hipervisor son opciones alternativas.
• [9.11/H-0-4] SE DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislado y, solo cuando se realiza con éxito, permitir el uso de las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android ascendente proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para cumplir con este requisito.
• [9.11/H-0-5] DEBE admitir la certificación de claves en los casos en que la clave de firma de certificación esté protegida por hardware seguro y la firma se realice en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad de dispositivos lo suficientemente grande para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la misma clave de certificación, a menos que se produzcan al menos 100,000 unidades de un SKU determinado. Si se producen más de 100,000 unidades de un SKU, PUEDE usar una clave diferente para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se inició en una versión anterior de Android, ese dispositivo estará 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 requiera 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, en 15 segundos o menos.
• [9.11/H-1-2] DEBE proporcionar la indicación visual del usuario para ocultar notificaciones e inhabilitar todas las formas de autenticación, excepto la autenticación principal descrita en 9.11.1 Pantalla de bloqueo segura. AOSP cumple con el requisito del modo de bloqueo.

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 con rapidez entornos separados para que los usuarios adicionales trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

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

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

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

Si las implementaciones de dispositivos de mano admiten la API del sistema HotwordDetectionService o algún otro mecanismo para la detección de palabras clave sin indicación de acceso al micrófono, sucederá 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 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 al servidor del sistema a través de la API de HotwordDetectionService o a ContentCaptureService a través de la API de ContentCaptureManager.
• [9.8/H-1-3] NO DEBE suministrar al servicio de detección de palabras clave audio del micrófono que dure más de 30 segundos para una solicitud individual activada por hardware.
• [9.8/H-1-4] NO DEBE suministrar el audio del micrófono almacenado en búfer con más de 8 segundos de antigüedad 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 más de 30 segundos de antigüedad al servicio de interacción de voz o a una entidad similar.
• [9.8/H-1-6] NO DEBE permitir que se transmitan más de 100 bytes de datos fuera del servicio de detección de palabras clave en cada resultado exitoso de palabra clave, excepto los datos de audio que se pasan a través de HotwordAudioStream.
• [9.8/H-1-7] NO DEBE permitir que se transmitan más de 5 bits de datos fuera del servicio de detección de palabras clave en cada resultado negativo de palabra 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 desde el 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 aparecer en la IU cuantitativos sobre el uso del micrófono por parte del servicio de detección de palabras clave.
• [9.8/H-1-11] SE DEBE registrar la cantidad de bytes incluidos en cada transmisión del servicio de detección de palabras clave para permitir que los investigadores de seguridad puedan inspeccionarlo.
• [9.8/H-1-12] DEBE admitir un modo de depuración que registre contenido sin procesar de cada transmisión desde el servicio de detección de palabras clave para permitir que los investigadores de seguridad puedan inspeccionarlo.
• [9.8/H-1-14] DEBE mostrar el indicador del micrófono, como se describe en la sección 9.8.2, cuando se transmite un resultado exitoso de palabra clave al servicio de interacción de voz o a una entidad similar.

• [9.8/H-SR-1] SE RECOMIENDA MUY BIEN notificar a los usuarios antes de configurar una aplicación como el proveedor del servicio de detección de palabras clave.
• [9.8/H-SR-2] SE RECOMIENDEN IMPORTANTE para inhabilitar la transmisión de datos no estructurados fuera del servicio de detección de palabras clave.
• [9.8/H-SR-3] SE RECOMIENDA IMPORTANTEMENTE 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 de 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 indicar el uso del micrófono, la aplicación hará lo siguiente:

• [9.8/H-2-1] DEBE proporcionar un aviso explícito al usuario para cada frase de palabra clave compatible.
• [9.8/H-2-2] NO DEBE conservar datos de audio sin procesar, o 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, los datos de audio, los datos que se pueden usar para reconstruir (total o parcialmente) el audio ni los contenidos de audio que no estén relacionados con la palabra clave, excepto a ContentCaptureService o al servicio de reconocimiento de voz en el dispositivo.

Si las implementaciones de dispositivos de mano declaran android.hardware.microphone, hacen lo siguiente:

• [9.8.2/H-4-1] DEBE mostrar el indicador del micrófono cuando una app accede a datos de audio desde el micrófono, pero no cuando solo acceden HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService o apps que tienen las funciones llamadas en la sección 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 como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensaje de atribución asociado a ellas.

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

• [9.8.2/H-5-1] DEBE mostrar el indicador de la cámara cuando una app accede a datos de la cámara en vivo, pero no cuando solo las apps que tienen las funciones mencionadas en la sección 9.1 con el identificador del CDD [C-4-X] acceden a la cámara.
• [9.8.2/H-5-2] SE DEBE mostrar las apps recientes y activas que usan la cámara como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensaje de atribución asociado a ellas.

2.2.6. Compatibilidad de las Herramientas y opciones para desarrolladores

Implementaciones en dispositivos de mano (* No aplicable para tablets):

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

Implementaciones en dispositivos de mano (* No aplicable para tablets):

• Perfetto
  • [6.1/H-0-2]* DEBE exponer un objeto binario /system/bin/perfetto al usuario de shell que cmdline cumple 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 objeto binario de perfetto DEBE escribir como salida un seguimiento 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 perfetto, al menos las fuentes de datos descritas en la documentación de perfetto.
  • [6.1/H-0-6]* El daemon rastreado con perfetto DEBE habilitarse de forma predeterminada (propiedad del sistema persist.traced.enable).

2.2.7. Clase de rendimiento del contenido multimedia portátil

Consulta la sección 7.11 para ver la definición de clase de rendimiento del contenido multimedia.

2.2.7.1. Contenido multimedia

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucederá lo siguiente:

• DEBE cumplir con los requisitos de contenido multimedia que se indican en la sección 2.2.7.1 del CDD de Android 13.

2.2.7.2. Cámara

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucederá lo siguiente:

• DEBE cumplir con los requisitos de contenido multimedia que se indican en la sección 2.2.7.2 del CDD de Android 13.

2.2.7.3 Hardware

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucederá lo siguiente:

• DEBE cumplir con los requisitos de contenido multimedia que se indican en la sección 2.2.7.3 del CDD de Android 13.

2.2.7.4. Rendimiento

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucederá lo siguiente:

• DEBE cumplir con los requisitos de rendimiento que se enumeran en la sección 2.2.7.4 del CDD de Android 13.

2.3. Requisitos de televisión

Un dispositivo de televisión Android hace referencia a una implementación de dispositivo Android que es una interfaz de entretenimiento para consumir contenido multimedia digital, películas, juegos, apps o TV en vivo para usuarios que están sentados a unos tres metros de distancia (una "interfaz de usuario inclinada" o "interfaz de usuario de 10 pies").

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

• Proporcionaron un mecanismo para controlar de forma remota la interfaz de usuario renderizada en la pantalla, que podría ubicarse a tres metros de distancia del usuario.
• Tener una pantalla de pantalla incorporada 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 en el resto de esta sección son específicos para las implementaciones en dispositivos de Android Television.

2.3.1. Hardware

Implementaciones de dispositivos de televisión:

• [7.2.2/T-0-1] DEBE ser compatible con el pad direccional.
• [7.2.3/T-0-1] SE DEBE proporcionar las funciones Inicio y Atrás.
• [7.2.3/T-0-2] SE DEBE enviar el evento de mantener presionado y de mantener presionado 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 la marca de función android.hardware.gamepad.
• [7.2.7/T] SE DEBE proporcionar un control remoto desde el cual los usuarios puedan acceder a la navegación no táctil y a las entradas de las teclas de navegación principales.

Si las implementaciones de dispositivos de televisión incluyen un giroscopio de 3 ejes, sucederá 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 ser capaz de 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 ser compatible con Bluetooth y Bluetooth LE.
• [7.6.1/T-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocido como partición “/data”).

Si las implementaciones de dispositivos de televisión incluyen un puerto USB compatible con el modo de host, harán 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 no necesariamente está conectada siempre.

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

• [7.6.1/T-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si se 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 extragrandes

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

• [7.6.1/T-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 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 extragrandes

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

Implementaciones de dispositivos de televisión:

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

2.3.2. Multimedia

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

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

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

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

Implementaciones de dispositivos de televisión:

• [5.2.2/T-SR-1] SE RECOMIENDA ELECTRÓNICA que admitan la codificación H.264 de videos con resoluciones de 720p y 1080p a 30 fotogramas por segundo.

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] AVC H.264
• [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

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación de MPEG-2, como se detalla en la Sección 5.3.1, con resoluciones y velocidades de fotogramas de video estándar hasta los siguientes valores:

• [5.3.1/T-1-1] HD 1080p a 29.97 fotogramas por segundo con perfil principal de alto nivel.
• [5.3.1/T-1-2] HD 1080i a 59.94 fotogramas por segundo con el perfil principal de alto nivel. DEBE desentrelazar el video MPEG-2 entrelazado y ponerlo a disposición de aplicaciones de terceros.

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación H.264, como se detalla en la Sección 5.3.4, con resoluciones y velocidades de fotogramas de video estándar hasta los siguientes valores:

• [5.3.4/T-1-1] HD 1080p a 60 fotogramas por segundo con perfil de Baseline
• [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 alto perfil nivel 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, con velocidades y resoluciones de fotogramas de video estándar que incluyan lo siguiente:

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

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

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

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación de VP8, como se detalla en la Sección 5.3.6, con resoluciones y velocidades de fotogramas de video estándar que incluyan lo siguiente:

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

Las implementaciones de dispositivos de televisión con decodificadores de hardware de VP9 DEBEN admitir la decodificación de VP9, como se detalla en la sección 5.3.7, con velocidades y resoluciones de fotogramas de video estándar hasta las siguientes:

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

Si las implementaciones de dispositivos de televisión con decodificadores de hardware de VP9 admiten la decodificación de VP9 y el perfil de decodificación UHD, sucederá 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 ENERCMENTE 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 la salida de transferencia de audio comprimido (en la que no se realiza una decodificación de audio en el dispositivo).

Si las implementaciones de dispositivos de televisión no tienen una pantalla integrada, pero admiten una pantalla externa conectada a través de HDMI, sucederá lo siguiente:

• [5.8/T-0-1] DEBES configurar 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. SE DEBE configurar el modo de salida HDMI para seleccionar la resolución máxima compatible con una frecuencia de actualización de 50 Hz o 60 Hz.
• [5.8/T-SR-1] SE RECOMIENDAN ENcarecidamente para proporcionar un selector de frecuencia de actualización HDMI configurable por el usuario.
• [5.8] SE DEBE configurar 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.

Si las implementaciones de dispositivos de televisión no tienen una pantalla integrada, pero admiten una pantalla externa conectada a través de HDMI, sucederá lo siguiente:

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

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

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

2.3.3. Software

Implementaciones de dispositivos de televisión:

• [3/T-0-1] SE DEBE declarar las funciones android.software.leanback y android.hardware.type.television.
• [3.2.3.1/T-0-1] DEBE precargar una o más aplicaciones o componentes del servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de aplicación 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 de Android Television admiten una pantalla de bloqueo,sucederá lo siguiente:

• [3.8.10/T-1-1] SE DEBE mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificaciones multimedia.

Implementaciones de dispositivos de televisión:

• [3.8.14/T-SR-1] SE RECOMIENDAN ELECTRÓNICAMENTE para admitir el modo multiventana en pantalla (PIP).
• [3.10/T-0-1] DEBE admitir servicios de accesibilidad de terceros.
• [3.10/T-SR-1] SE RECOMIENDA RECOMENDADAMENTE que precargan los servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de Accesibilidad con interruptores y TalkBack (para idiomas compatibles con el motor de texto a voz preinstalado) como se proporciona 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, sucederá lo siguiente:

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

Implementaciones de dispositivos de televisión:

• [3.12/T-0-1] DEBE ser compatible con el marco de trabajo de entrada de TV.

2.3.4. Rendimiento y potencia

• [8.1/T-0-1] Latencia de fotogramas coherente. La latencia de fotogramas incoherente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia a 5 fotogramas por segundo, y SE DEBE ser inferior a 1 fotograma en un 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 aleatorio 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 incluidas en el AOSP o para extender las funciones incluidas en el AOSP, sucederá lo siguiente:

• [8.3/T-1-1] DEBE proporcionar la indicación visual del usuario para habilitar e inhabilitar la función de ahorro de batería.

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

• [8.3/T-1-2] SE DEBE registrar el dispositivo como uno sin batería, según se describe en Cómo brindar compatibilidad con dispositivos sin batería.

Si las implementaciones de dispositivos de televisión tienen una batería, sucederá lo siguiente:

• [8.3/T-1-3] DEBE proporcionar la indicación visual del usuario para mostrar todas las apps exentas de los modos de ahorro de energía 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 de cada componente de hardware y el agotamiento aproximado de la batería causado por los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
• [8.4/T-0-2] SE DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
• [8.4/T-0-3] DEBE informar el consumo de energía de la CPU según el UID de cada proceso. El Proyecto de código abierto de Android cumple con los requisitos mediante la implementación del módulo de kernel uid_cputime.
• [8.4/T] SE DEBE atribuir al componente de hardware si no se puede atribuir el uso de energía de un componente de hardware a una aplicación.
• [8.4/T-0-4] DEBE hacer que este uso de energía esté disponible para el desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.

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.
• [9.11/T-0-1] SE DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
• [9.11/T-0-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones de hash de la familia MD5, SHA1 y SHA-2 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 versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos mediante los cuales el kernel o el código del espacio del usuario podrían acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) ascendente cumple con este requisito mediante 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 un 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 realiza con éxito, permitir el uso de las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android ascendente proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para cumplir con este requisito.
• [9.11/T-0-4] DEBE admitir la certificación de claves cuando la clave de firma de certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad de dispositivos lo suficientemente grande para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la misma clave de certificación, a menos que se produzcan al menos 100,000 unidades de un SKU determinado. Si se producen más de 100,000 unidades de un SKU, PUEDE usar una clave diferente para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se inició en una versión anterior de Android, ese dispositivo estará 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 requiera un almacén de claves respaldado por un entorno de ejecución aislado.

Si las implementaciones de dispositivos de televisión admiten una pantalla de bloqueo segura, sucederá lo siguiente:

• [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, sucederá 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 con rapidez entornos separados para que los usuarios adicionales trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

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

• [9.5/T-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir 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, sucede lo siguiente:

• [9.8.2/T-4-1] SE DEBE mostrar el indicador del micrófono cuando una app accede a datos de audio desde él, pero no cuando solo se accede al micrófono mediante HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o las apps que tienen las funciones mencionadas en la sección 9.1 Permisos con 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 con el usuario.

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

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

2.3.6. Compatibilidad de las Herramientas y opciones para desarrolladores

Implementaciones de dispositivos de televisión:

• Perfetto
  • [6.1/T-0-1] DEBE exponer un objeto binario /system/bin/perfetto al usuario de shell que cmdline cumple 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 salida un seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/T-0-4] DEBE proporcionar, a través del objeto binario perfetto, al menos las fuentes de datos descritas en la documentación de perfetto.

2.4. Requisitos para el reloj

El término dispositivo Android Watch hace referencia a la implementación de dispositivos Android para llevar en el cuerpo, por ejemplo, en la muñeca.

Las implementaciones en dispositivos Android se clasifican como un reloj si cumplen con todos los siguientes criterios:

• Asegúrate de tener una pantalla con una longitud diagonal física de 1.1 a 2.5 pulgadas.
• Tienen un mecanismo proporcionado para su uso en el cuerpo.

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

2.4.1. Hardware

Implementaciones de dispositivos de reloj:

• [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 de inicio disponible para el usuario y la función de retroceso, excepto cuando está en UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] DEBE ser compatible con la entrada de pantalla táctil.

• [7.3.1/W-SR-1] SE RECOMIENDA ES IMPORTANTE que incluyan un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos de reloj incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, sucederá lo siguiente:

• [7.3.3/W-1-1] SE DEBE informar las mediciones de GNSS en cuanto se encuentran, incluso si aún no se informa una ubicación calculada a partir del GPS/GNSS.
• [7.3.3/W-1-2] DEBEN informar pseudorrangos y pseudorrangos GNSS que, en condiciones a cielo abierto después de determinar la ubicación, mientras el dispositivo se mueve con menos de 0.2 metros por segundo al cuadrado de aceleración, son suficientes para calcular la posición dentro de los 20 metros y la velocidad dentro de los 0.29 metros por segundo, al menos, del 0.25% de tiempo por segundo.

Si las implementaciones en dispositivos de reloj incluyen un giroscopio de 3 ejes, sucederá lo siguiente:

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

Implementaciones de dispositivos de reloj:

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

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

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

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

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

2.4.2. Multimedia

Sin requisitos adicionales.

2.4.3. Software

Implementaciones de dispositivos de reloj:

• [3/W-0-1] SE 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] DEBE precargar una o más aplicaciones o componentes del servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de aplicación enumerados aquí.

Implementaciones de dispositivos de reloj:

• [3.8.4/W-SR-1] SE RECOMIENDA COMPLETAMENTE implementar un asistente en el dispositivo para realizar la acción de asistencia.

Implementaciones de dispositivos de reloj 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 RECOMENDADAMENTE que precargan los servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de Accesibilidad con interruptores y TalkBack (para idiomas compatibles con el motor de texto a voz preinstalado) como se proporciona en el proyecto de código abierto de TalkBack.

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

• [3.11/W-SR-1] SE RECOMIENDA INCREÍBLEMENTE que incluyan un motor de TTS compatible con 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 de reloj incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en el AOSP o extender las funciones incluidas en el AOSP, sucederá lo siguiente:

• [8.3/W-SR-1] SE RECOMIENDAN ENERGENTE para que los usuarios tengan la opción de mostrar todas las apps exentas de los modos de ahorro de energía App Standby y Descanso.
• [8.3/W-SR-2] SE RECOMIENDAN IMPORTANTES para brindar al usuario la opción de habilitar o inhabilitar la función de ahorro de batería.

Implementaciones de dispositivos de reloj:

• [8.4/W-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual de cada componente de hardware y el agotamiento aproximado de la batería causado por 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 informar todos los valores de consumo de energía en miliamperios-hora (mAh).
• [8.4/W-0-3] DEBE informar el consumo de energía de la CPU según el UID de cada proceso. El Proyecto de código abierto de Android cumple con los requisitos mediante la implementación del módulo de kernel uid_cputime.
• [8.4/W-0-4] DEBE hacer que este uso de energía esté disponible para el desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.
• [8.4/W] SE DEBE atribuir al componente de hardware si no se puede atribuir el uso de energía de un componente de hardware a una aplicación.

2.4.5. Modelo de seguridad

Implementaciones de dispositivos de reloj:

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

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

• [9.5/W-1-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 con rapidez entornos separados para que los usuarios adicionales trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

Si las implementaciones en dispositivos de reloj incluyen varios usuarios y declaran la marca de función android.hardware.telephony, harán lo siguiente:

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

2.5 Requisitos de la industria automotriz

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

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

• Estén incorporados en un vehículo automotor o se puedan conectar a él
• Usan una pantalla en la fila del asiento del conductor como pantalla principal.

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

2.5.1. Hardware

Implementaciones en dispositivos de Automotive:

• [7.1.1.1/A-0-1] DEBE tener una pantalla de al menos 6 pulgadas de tamaño diagonal físico.
• [7.1.1.1/A-0-2] DEBE tener un diseño de tamaño de pantalla de al menos 750 dp x 480 dp.
• [7.2.3/A-0-1] DEBE proporcionar la función Inicio y PUEDE proporcionar las funciones Atrás y Recientes.
• [7.2.3/A-0-2] SE DEBE enviar el evento de mantener presionado y de mantener presionado de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
• [7.3/A-0-1] SE DEBE implementar y, luego, informar 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 diurno/nocturno del panel y SE DEBE basarse en la entrada del sensor de luz ambiente. Es posible que el sensor de luz ambiente subyacente sea el mismo que el Fotómetro.
• [7.3/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] ES POSIBLE que la ubicación se cree fusionando el GPS/GNSS con sensores adicionales. Si no se considera la ubicación, se RECOMIENDA implementar y, luego, informar los tipos de sensor o los IDs de propiedad del vehículo correspondientes que se usen.

• [7.3/A-0-4] La ubicación solicitada a través de LocationManager#requestLocationUpdates() NO DEBE coincidir con el mapa.

• [7.3.1/A-0-4] DEBE cumplir con el sistema de coordenadas del sensor de vehículos de Android.

• [7.3/A-SR-1] Tienen la opción StrongLY_RECOMMENDED para incluir un acelerómetro de 3 ejes y un giroscopio de 3 ejes.

• [7.3/A-SR-2] SON StrongLY_RECOMMENDED para implementar y, luego, informar el sensor TYPE_HEADING.

Si las implementaciones de dispositivos Automotive admiten OpenGL ES 3.1, sucederán lo siguiente:

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

Si las implementaciones en dispositivos de Automotive incluyen un acelerómetro, harán lo siguiente:

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

Si las implementaciones en dispositivos incluyen un acelerómetro de 3 ejes, sucederá lo siguiente:

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

Si las implementaciones en dispositivos de Automotive incluyen un acelerómetro con menos de 3 ejes, sucederá lo siguiente:

• [7.3.1/A-1-3] SE DEBE implementar y, luego, informar el sensor TYPE_ACCELEROMETER_LIMITED_AXES.
• [7.3.1/A-1-4] SE DEBE implementar y, luego, informar el sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones en dispositivos de Automotive incluyen un giroscopio, sucederá lo siguiente:

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

Si las implementaciones en dispositivos de Automotive incluyen un giroscopio de 3 ejes, sucederá lo siguiente:

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

Si las implementaciones de dispositivos Automotive incluyen un giroscopio con menos de 3 ejes, sucederá lo siguiente:

• [7.3.4/A-4-1] SE DEBE implementar y, luego, informar el sensor TYPE_GYROSCOPE_LIMITED_AXES.
• [7.3.4/A-4-2] SE DEBE implementar y, luego, informar el sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones en dispositivos de Automotive incluyen un receptor de GPS/GNSS, pero no incluyen la conectividad de datos basada en la red móvil, sucederá lo siguiente:

• [7.3.3/A-3-1] DEBE determinar la ubicación la primera vez que se enciende el receptor de GPS/GNSS o después de 4 días o más dentro de 60 segundos.
• [7.3.3/A-3-2] DEBE cumplir con los criterios de tiempo para la primera corrección que se describen 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 sean la primera vez o que transcurran más de 4 días). Por lo general, se cumple el requisito 7.3.3/C-1-2 en vehículos sin conectividad de datos basada en la red móvil, ya sea usando predicciones de órbita de GNSS calculadas en el receptor o usando la ubicación más reciente del vehículo junto con la capacidad de reconocimiento muerto durante al menos 60 segundos con una precisión de posición que cumpla con 7.3.3/C-1-3, o bien una combinación de ambas.

Si las implementaciones en dispositivos de Automotive incluyen un sensor TYPE_HEADING, sucederá 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 usa STRONGLY_RECOMMENDED para informar eventos hasta una frecuencia de al menos 10 Hz.
• DEBE hacer referencia al norte geográfico.
• DEBERÍA estar disponible incluso cuando el vehículo está quieto.
• DEBE tener una resolución de al menos 1 grado.

Implementaciones en dispositivos de Automotive:

• [7.4.3/A-0-1] DEBE ser compatible con Bluetooth y DEBE ser compatible con Bluetooth LE.
• [7.4.3/A-0-2] Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles de Bluetooth:
  • Llamadas telefónicas a través del perfil de manos libres (HFP)
  • Reproducción de contenido multimedia a través del perfil de distribución de audio (A2DP)
  • Control de reproducción de contenido multimedia a través del perfil de control remoto (AVRCP).
  • Uso compartido de contactos mediante el perfil de acceso a la agenda telefónica (PBAP)

• [7.4.3/A-SR-1] SE RECOMIENDA ES IMPORTANTE para admitir el perfil de acceso a mensajes (MAP).

• [7.4.5/A] SE DEBE incluir compatibilidad con la conectividad de datos basada en redes móviles.

• [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.

Implementaciones en dispositivos de Automotive:

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

• [7.6.1/A] SE DEBE formatear la partición de datos para ofrecer un rendimiento y una longevidad mejorados en el almacenamiento flash, por ejemplo, con el sistema de archivos f2fs.

Si las implementaciones en dispositivos de Automotive proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble, sucederá lo siguiente:

• [7.6.1/A-SR-1] SE RECOMIENDEN IMPORTANTEMENTE para reducir la sobrecarga de E/S en las operaciones realizadas en el almacenamiento externo, por ejemplo, mediante SDCardFS.

Si las implementaciones en dispositivos de Automotive son de 64 bits, sucede lo siguiente:

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

  • 280 dpi o menos en pantallas pequeñas o normales
  • ldpi o inferior en pantallas extragrandes
  • mdpi o inferior en pantallas grandes

• [7.6.1/A-2-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si se usa alguna de las siguientes densidades:

  • xhdpi o superior en pantallas pequeñas o normales
  • hdpi o más alta en pantallas grandes
  • mdpi o superior en pantallas extragrandes

• [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 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 extragrandes

• [7.6.1/A-2-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1,824 MB 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 extragrandes

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

Implementaciones en dispositivos de Automotive:

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

Implementaciones en dispositivos de Automotive:

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

Implementaciones en dispositivos de Automotive:

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

2.5.2. Multimedia

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

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

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

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

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

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

Se RECOMIENDA ELEGIR las implementaciones en dispositivos de Automotive para admitir la siguiente decodificación de video:

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

2.5.3. Software

Implementaciones en dispositivos de Automotive:

• [3/A-0-1] SE 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 en dispositivos de Automotive proporcionan una API de propiedad a través de android.car.CarPropertyManager con android.car.VehiclePropertyIds, sucederá 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 las usen.
• [3/A-1-2] NO DEBE replicar una propiedad de vehículo que ya existe en el SDK.

Implementaciones en dispositivos de Automotive:

• [3.2.1/A-0-1] SE DEBE admitir y aplicar todas las constantes de permisos según lo documentado en la página de referencia sobre permisos de Automotive.

• [3.2.3.1/A-0-1] DEBE precargar una o más aplicaciones o componentes del servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de aplicación que se enumeran aquí.

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

• [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 que implementes un asistente en el dispositivo para realizar la acción de asistencia.

Si las implementaciones en dispositivos de Automotive incluyen un botón de presionar para hablar, hacen lo siguiente:

• [3.8.4/A-1-1] SE DEBE presionar brevemente el botón de presionar para hablar como la interacción designada para iniciar la aplicación de asistencia seleccionada por el usuario; en otras palabras, la aplicación que implementa VoiceInteractionService.

Implementaciones en dispositivos de Automotive:

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

Si las implementaciones de dispositivos de Automotive admiten propiedades de HAL del usuario, sucederán lo siguiente:

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

Implementaciones en dispositivos de Automotive:

• [3.14/A-0-1] DEBE incluir un framework de IU para admitir apps de terceros con las APIs de contenido multimedia, como se describe en la sección 3.14.
• [3.14/A-0-2] DEBE permitir que el usuario interactúe de manera segura con aplicaciones multimedia mientras conduce.
• [3.14/A-0-3] DEBE admitir la acción de intent implícita CAR_INTENT_ACTION_MEDIA_TEMPLATE con el extra CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] DEBE proporcionar una indicación visual para navegar a la actividad de preferencia de una aplicación de música, pero DEBE habilitarla solo cuando las restricciones de UX del vehículo no estén vigentes.
• [3.14/A-0-5] SE DEBE mostrar los mensajes de error establecidos por las aplicaciones de contenido multimedia y DEBE admitir los extras 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 apps que admiten esa función.
• [3.14/A-0-7] DEBE respetar las definiciones de CONTENT_STYLE_BROWSABLE_HINT y CONTENT_STYLE_PLAYABLE_HINT cuando se muestra la jerarquía de MediaBrowser.

Si las implementaciones de dispositivos de Automotive incluyen una app de selector predeterminada, harán lo siguiente:

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

Implementaciones en dispositivos de Automotive:

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

2.5.4. Rendimiento y potencia

Implementaciones en dispositivos de Automotive:

• [8.2/A-0-1] SE DEBE informar la cantidad de bytes leídos y escritos en el almacenamiento no volátil según 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 los requisitos mediante el módulo de kernel uid_sys_stats.
• [8.3/A-1-3] DEBE admitir el modo garaje.
• [8.3/A] SE DEBE estar en modo garaje durante al menos 15 minutos después de cada viaje, a menos que ocurra lo siguiente:
  • Se agotó la batería.
  • No se programaron trabajos inactivos.
  • El conductor sale del modo garaje.
• [8.4/A-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual de cada componente de hardware y el agotamiento aproximado de la batería causado por 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 DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
• [8.4/A-0-3] DEBE informar el consumo de energía de la CPU según el UID de cada proceso. El Proyecto de código abierto de Android cumple con los requisitos mediante la implementación del módulo de kernel uid_cputime.
• [8.4/A] SE DEBE atribuir al componente de hardware si no se puede atribuir el uso de energía de un componente de hardware a una aplicación.
• [8.4/A-0-4] DEBE hacer que este uso de energía esté disponible para el desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.

2.5.5. Modelo de seguridad

Si las implementaciones en dispositivos de Automotive admiten varios usuarios, sucederán lo siguiente:

• [9.5/A-1-1] NO DEBE permitir que los usuarios interactúen ni cambiar al usuario del sistema sin interfaz gráfica, excepto por el aprovisionamiento de dispositivos.
• [9.5/A-1-2] DEBE cambiar a un usuario secundario antes del BOOT_COMPLETED.
• [9.5/A-1-3] DEBE admitir la capacidad de crear un usuario invitado incluso cuando se alcanzó la cantidad máxima de usuarios en un dispositivo.

Si las implementaciones de dispositivos Automotive declaran android.hardware.camera.any, hacen lo siguiente:

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

Implementaciones en dispositivos de Automotive:

• [9/A-0-1] DEBE declarar la función android.hardware.security.model.compatible.
• [9.11/A-0-1] SE DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
• [9.11/A-0-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de la familia MD5, SHA1 y SHA-2 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 versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos mediante los cuales el kernel o el código del espacio del usuario podrían acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) ascendente cumple con este requisito mediante 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 un 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 realiza de forma correcta, permitir el uso de claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android ascendente proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para cumplir con este requisito.
• [9.11/A-0-4] SE 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 realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad de dispositivos lo suficientemente grande para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la misma clave de certificación, a menos que se produzcan al menos 100,000 unidades de un SKU determinado. Si se producen más de 100,000 unidades de un SKU, PUEDE usar una clave diferente para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se inició en una versión anterior de Android, ese dispositivo estará 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 requiera un almacén de claves respaldado por un entorno de ejecución aislado.

Implementaciones en dispositivos de Automotive:

• [9.14/A-0-1] DEBEN conservar los mensajes de los subsistemas del vehículo del framework de Android, p.ej., incluir en la lista de entidades permitidas tipos de mensajes y fuentes de mensajes permitidos.
• [9.14/A-0-2] DEBE UN perro guardián contra ataques de denegación del servicio del framework de Android o apps de terceros. Esto brinda protección contra software malicioso que inunda de tráfico la red del vehículo, lo que puede provocar el mal funcionamiento de los subsistemas del vehículo.

2.5.6. Compatibilidad de las Herramientas y opciones para desarrolladores

Implementaciones en dispositivos de Automotive:

• Perfetto
  • [6.1/A-0-1] DEBE exponer un objeto binario /system/bin/perfetto al usuario de shell que cmdline cumple con la documentación de perfetto.
  • [6.1/A-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/A-0-3] El objeto binario de perfetto DEBE escribir como salida un seguimiento 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 perfetto, al menos las fuentes de datos descritas en la documentación de perfetto.

2.6. Requisitos de las tabletas

El término tablet Android hace referencia a una implementación de dispositivo Android que, por lo general, cumple con todos los siguientes criterios:

• Se usa con ambas manos.
• No tiene una configuración convertible ni convencional.
• Implementaciones de teclado físico que se usan con el dispositivo se conectan mediante una conexión estándar (p.ej., USB o Bluetooth).

• Tenga una fuente de alimentación que proporcione movilidad, como una batería.

• Tiene un tamaño de pantalla superior a 7" y menor que 18", medido de forma diagonal.

Las implementaciones en dispositivos de tablets tienen requisitos similares a los de las implementaciones en dispositivos de mano. Las excepciones se indican con un * en esa sección y se indican como referencia en esta sección.

2.6.1. Hardware

Giroscopio

Si las implementaciones en dispositivos de tablets incluyen un giroscopio de 3 ejes, sucederá lo siguiente:

• [7.3.4/Tab-1-1] DEBE ser capaz de 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 para dispositivos portátiles no se aplican a tablets.

Modo periférico USB (sección 7.7.1)

Si las implementaciones en dispositivos de tablets incluyen un puerto USB compatible con el modo periférico, sucederá lo siguiente:

• [7.7.1/Tab] PUEDE implementar la API de Open Accessory (AOA) de Android.

Modo de realidad virtual (sección 7.9.1)

Realidad virtual con alto rendimiento (Artículo 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 en dispositivos de tablets incluyen varios usuarios y no declaran la marca de función android.hardware.telephony, harán lo siguiente:

• [9.5/T-1-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 con rapidez entornos separados para que los usuarios adicionales trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

Si las implementaciones en dispositivos de tablets incluyen varios usuarios y declaran la marca de función android.hardware.telephony, sucederá lo siguiente:

• [9.5/T-2-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir 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 una o más aplicaciones o componentes del servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de aplicación que se enumeran aquí.

3. Software

3.1. Compatibilidad con APIs administradas

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

Implementaciones en 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 ascendente de Android.

• [C-0-2] DEBE admitir o preservar 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 esta definición de compatibilidad lo permita específicamente.

• [C-0-4] DE todas maneras DEBE mantener las APIs presentes y comportarse de manera razonable, incluso cuando se omitan algunas funciones de hardware para las cuales Android incluye APIs. Consulta la sección 7 para conocer los requisitos específicos para esta situación.

• [C-0-5] NO DEBE permitir que apps de terceros usen interfaces que no pertenezcan al SDK, las cuales están definidas como métodos y campos en los paquetes de lenguaje Java que se encuentran en la ruta de clase de inicio en AOSP y que no forman parte del SDK público. Esto incluye las APIs decoradas con la anotación @hide, pero no con un @SystemAPI, como se describe en los documentos del SDK y en los miembros de las clases privadas y de paquetes privados.

• [C-0-6] SE DEBE enviar con todas y cada una de las interfaces que no pertenecen al SDK en las mismas listas restringidas proporcionadas en las marcas provisionales y de listas de bloqueo en la ruta prebuilts/runtime/appcompat/hiddenapi-flags.csv para la rama de nivel de API correspondiente en el 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 mediante la incorporación de la configuración firmada en cualquier APK con las claves públicas existentes presentes en el AOSP.

  Sin embargo, lograron lo siguiente:

  • MAYOR, 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 u omitirla de todas las listas restringidas.
  • ES POSIBLE, si una API oculta aún no existe en el AOSP, agrégala a cualquiera de las listas restringidas.

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 mediante la actualización de la versión de la extensión para ese nivel. La API de android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) muestra la versión de extensión del apiLevel proporcionado si hay extensiones para ese nivel de API.

Implementaciones en dispositivos Android:

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

• [C-0-2] Solo DEBE mostrar el número de versión de extensión válido definido por el AOSP.

• [C-0-3] DEBE admitir todas las APIs definidas por las versiones de extensión que muestra android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la misma manera que otras APIs administradas, de acuerdo con 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 tienen las siguientes características:

• [C-0-1] NO DEBE colocar la biblioteca org.apache.http.legacy en la ruta de arranque.
• [C-0-2] DEBE agregar la biblioteca org.apache.http.legacy a la ruta de clase de la aplicación solo si esta cumple con una de las siguientes condiciones:
  • Se orienta al nivel de API 28 o versiones anteriores.
  • Configura el atributo android:name de <uses-library> en org.apache.http.legacy para declarar en su manifiesto que necesita la biblioteca.

La implementación de AOSP cumple con estos requisitos.

3.2. Compatibilidad con la API de Soft

Además de las APIs administradas de la sección 3.1, Android también incluye una API "secundaria" significativa de solo tiempo de ejecución, en forma de intents, permisos y aspectos similares de aplicaciones para Android que no se pueden aplicar durante 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, tal como se indica en la página de referencia de permisos. Ten en cuenta que en la sección 9 se enumeran los requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de compilación

Las APIs de Android incluyen una serie de constantes en la clase android.os.Build que 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 que las implementaciones de dispositivos DEBEN cumplir.

Parámetro	Detalles
VERSION.LANZAMIENTO	Es la versión del sistema Android en ejecución actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en las Strings de versión permitidas para Android 14.
VERSION.SDK	Es la versión del sistema Android en ejecución actualmente, en un formato accesible para el código de la aplicación de terceros. Para Android 14, este campo DEBE tener el valor entero 14_INT.
VERSION.SDK_INT	Es la versión del sistema Android en ejecución actualmente, en un formato accesible para el código de la aplicación de terceros. Para Android 14, este campo DEBE tener el valor entero 14_INT.
VERSION.INCREMENTAL	Es un valor que elige el implementador de dispositivos que designa la compilación específica del sistema Android en ejecución actualmente, en un formato legible por humanos. Este valor NO SE DEBE volver a usar en diferentes compilaciones que se ponen a disposición de los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de fuente se usó para generar la compilación. El valor de este campo SE DEBE codificar como ASCII imprimible de 7 bits y coincidir con la expresión regular “^[^ :\/~]+$”.
JUEGOS DE MESA	Es un valor que elige el implementador del dispositivo para identificar el hardware interno específico que usa el dispositivo, en un formato legible por humanos. Este campo puede usarse para indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SEGURIDAD	Es un valor que refleja el nombre de la marca asociada con el dispositivo, como lo conocen los usuarios finales. DEBE tener un formato legible por humanos y DEBERÍA representar al fabricante del dispositivo o a la marca de la empresa con la que se comercializa. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ABIS_COMPATIBLES	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con API nativas.
ABIS_COMPATIBLES_32_BIT	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con API nativas.
ABIS_COMPATIBLES_64_BIT	Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con API nativas.
ABI_de_CPU	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con API nativas.
ABI2 de CPU	Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con API nativas.
DISPOSITIVO	Es un valor que elige el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno que identifica la configuración de las características del hardware y el diseño industrial del dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este dispositivo NO DEBE cambiar durante el ciclo de vida del producto.
IMPRESIÓN DE DEDOS	Es una cadena que identifica esta compilación de forma única. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por ejemplo: acme/myproduct/ mydevice:14/LMYXX/3359:userdebug/test-keys La huella digital NO DEBE incluir caracteres de espacio en blanco. El valor de este campo SE DEBE codificar como ASCII de 7 bits.
HARDWARE	Es el nombre del hardware (de la línea de comandos del kernel o /proc). DEBE ser razonablemente legible por humanos. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ORGANIZADOR	Es una cadena que identifica de forma única el host en el que se compiló la compilación, en un formato legible. No 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 que elige el implementador de dispositivos para hacer referencia a una versión específica, en un formato legible. Este campo puede ser el mismo que el de android.os.Build.VERSION.INCREMENTAL, pero DEBERÍA ser un valor lo suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE	Es el nombre comercial del fabricante del equipo original (OEM) del producto. No hay requisitos sobre el formato específico de este campo, con la excepción de que NO DEBE ser nulo ni la cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
FABRICANTE_SOC	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 cuál es la constante correcta que debes usar. El valor de este campo SE DEBE codificar como ASCII de 7 bits, DEBE coincidir con la expresión regular “^([0-9A-Za-z ]+)”, NO DEBE comenzar o terminar con un espacio en blanco y NO ser igual a “desconocido”. Este campo NO DEBE cambiar durante el ciclo de vida del producto.
SOC_MODEL	El nombre del modelo del sistema principal en un chip (SOC) que se usa en el producto. Los dispositivos con el mismo modelo de SOC deben usar el mismo valor constante. Solicita al fabricante del SOC la constante correcta que debes usar. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^([0-9A-Za-z ._/+-]+)$”, NO DEBE comenzar ni terminar con un espacio en blanco y NO ser igual a “desconocido”. Este campo NO DEBE cambiar durante la vida útil del producto.
MODELO.	Es un valor elegido por el implementador de dispositivos que contiene el nombre del dispositivo como lo conoce el usuario final. Debe ser el mismo nombre con el que el dispositivo se comercializa y vende a usuarios finales. No hay requisitos sobre el formato específico de este campo, con la excepción de que NO DEBE ser nulo ni la cadena vacía (""). Este campo NO DEBE cambiar durante el ciclo de vida del producto.
PRODUCTO	Es un valor que elige el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente para que los usuarios finales puedan verlo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre del producto NO DEBE cambiar durante su ciclo de vida.
SKU_ODM	Es un valor opcional que elige el implementador de dispositivos que contiene el SKU (Stock Keeping Unit) que se usa para realizar un seguimiento de configuraciones específicas del dispositivo, por ejemplo, cualquier periférico incluido con el dispositivo cuando se vende. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “[0-9A-Za-z.,_-])”
SERIE	SE DEBE mostrar "UNKNOWN".
ETIQUETAS	Una lista de etiquetas separadas por comas que elige el implementador de dispositivos que distingue aún más la compilación. Las etiquetas DEBEN poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+” y DEBEN tener uno de los valores correspondientes a las tres configuraciones de firma típicas de la plataforma de Android: claves de lanzamiento, claves de desarrollo y claves de prueba.
TIEMPO	Un valor que representa la marca de tiempo del momento en que se produjo la compilación.
MÁQUINA DE ESCRIBIR	Es un valor que elige el implementador de dispositivos que especifica la configuración del tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: user, userdebug o eng.
USUARIO	Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No existen requisitos sobre el formato específico de este campo, con la excepción de que NO DEBE ser nulo ni la cadena vacía ("").
PANTALLA_SEGURIDAD	Es un valor que indica el nivel de parche de seguridad de una compilación. DEBE indicar que la compilación no es vulnerable de ninguna manera a ninguno de los problemas descritos en el Boletín de seguridad pública de Android designado. DEBE tener el formato [YYYY-MM-DD], que coincida con una cadena definida documentada en el Boletín de seguridad pública de Android o en el Asesor de seguridad de Android, por ejemplo, "2015-11-01".
BASE_SO	Es un valor que representa el parámetro FINGERPRINT de la compilación que es idéntico a esta compilación, excepto por los parches que se proporcionan en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si tal compilación no existe, informa una cadena vacía ("").
CARGADOR DE ARRANQUE	Es un valor que elige el implementador del dispositivo para identificar la versión específica del bootloader interno que se usa en el dispositivo, en un formato legible por humanos. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion(),	DEBE (ser o mostrar) un valor elegido por el implementador del dispositivo que identifique la versión interna de radio/módem específica utilizada en el dispositivo, en un formato legible por humanos. Si un dispositivo no tiene una radio/módem interna, DEBE mostrar NULL. El valor de este campo SE DEBE codificar 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 MANUFACTURER. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9]+$”.

3.2.3. Compatibilidad con intents

3.2.3.1. Intents de aplicaciones comunes

Los intents de Android permiten que los componentes de la aplicación soliciten funciones 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 en dispositivos:

• [C-SR-1] SE RECOMIENDA ENERGARSE que precargan una o más aplicaciones o componentes de servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de aplicación enumerados aquí y proporcionar entregas, es decir, cumplir con las expectativas del desarrollador para estos intents de aplicación comunes como se describe en el SDK.

Consulta la Sección 2 para conocer los intents de aplicación obligatorios 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 aplicaciones de terceros anulen cada patrón de intents al que se hace referencia en la sección 3.2.3.1, excepto la de Configuración. La implementación ascendente de código abierto de Android lo permite 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 con estos patrones y asuman el control sobre ellos. Esta prohibición incluye, entre otros aspectos, la inhabilitación de la interfaz de usuario del "Selector", que permite al usuario elegir entre varias aplicaciones que controlan el mismo patrón de intents.

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

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

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

• [C-0-4] SE DEBE intentar validar cualquier filtro de intents. Para ello, se deben realizar los pasos de validación definidos en la especificación de Vínculos de recursos digitales, tal como la implementó el Administrador de paquetes en el Proyecto de código abierto de Android ascendente.
• [C-0-5] DEBE intentar la validación de los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de URI validados correctamente como controladores de app predeterminados para sus URI.
• PUEDE establecer filtros de intents de URI específicos como controladores predeterminados de la app para sus URI si se verifican correctamente, pero otros filtros de URI candidatos fallan la verificación. Si la implementación de un dispositivo hace esto, DEBE proporcionar las anulaciones de patrones por URI apropiadas para el usuario en el menú de configuración.
• DEBE proporcionar al usuario controles de App Links por app en 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 apps para que una app sea siempre abierta, siempre preguntar o nunca abierta, lo que debe aplicarse 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 brindar al usuario la capacidad de anular filtros de intents de URI candidatos específicos que se verificaron correctamente, según los filtros de intents.
  • [C-0-8] La implementación del dispositivo DEBE permitir que los usuarios vean y anulen filtros de intents de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros candidatos de intents de URI tengan éxito en la verificación, mientras que otros pueden fallar.

3.2.3.3 Espacios de nombres de intents

• [C-0-1] Las implementaciones del dispositivo NO DEBEN incluir ningún componente de Android que respete un intent nuevo o patrón de intent de transmisión con una cadena de clave ACTION, CATEGORY, o bien otra cadena de clave en el espacio de nombres android.* o com.android.*.
• [C-0-2] Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete un intent nuevo o patrón de intent de transmisión con una cadena de clave ACTION, CATEGORY, o bien otra cadena de claves en un espacio de paquete 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 con espacios de nombres asociados de forma clara y asociada con su propia organización. Esta prohibición es análoga a la especificada para las clases de lenguaje Java en la sección 3.6.

3.2.3.4. Intents de transmisión

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

Implementaciones en dispositivos:

• [C-0-1] DEBE transmitir los intents de transmisión pública enumerados aquí en respuesta a los eventos del sistema apropiados, como se describe en la documentación del SDK. Ten en cuenta que este requisito no entra en conflicto con la sección 3.5, ya que las limitaciones para las aplicaciones en segundo plano también se describen en la documentación del SDK. Además, ciertos intents de transmisión son condicionales a la compatibilidad de hardware. Si el dispositivo admite el hardware necesario, DEBEN transmitir los intents y proporcionar el comportamiento alineado con la documentación del SDK.

3.2.3.5 Intents de aplicaciones condicionales

Android incluye parámetros de configuración que les proporcionan a los usuarios una manera fácil de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla principal o los SMS.

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

Si las implementaciones de dispositivos informan android.software.home_screen, sucederá lo siguiente:

• [C-1-1] DEBE respetar el intent 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, sucederá lo siguiente:

• [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 cambie la aplicación de SMS predeterminada.

• [C-2-2] DEBE respetar el intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar un diálogo que permita al usuario cambiar la aplicación de teléfono predeterminada.

  • DEBE usar la IU predeterminada de la app de Teléfono seleccionada por el usuario para las llamadas entrantes y salientes, excepto las de emergencia, que usarían la app de Teléfono preinstalada.

• [C-2-3] DEBE respetar el intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para proporcionar al usuario la opción de configurar la ConnectionServices asociada con PhoneAccounts, así como una PhoneAccount predeterminada que el proveedor de servicios de telecomunicaciones usará para realizar llamadas salientes. La implementación del AOSP cumple con este requisito, ya que incluye el menú "Calling Accounts" dentro del menú de configuración "Calls".

• [C-2-4] DEBE permitir android.telecom.CallRedirectionService para una app que contiene la función android.app.role.CALL_REDIRECTION.

• [C-2-5] DEBE proporcionar al usuario la posibilidad de elegir una app que contenga el rol 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 COMPLETAMENTE para respetar 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 puede controlar estos intents y proporcionar entregas como en el SDK.

Si las implementaciones de dispositivos informan android.hardware.nfc.hce, sucederá lo siguiente:

• [C-3-1] DEBE respetar la intención de android.settings.NFC_PAYMENT_g mostrar un menú de configuración predeterminado de la app para pagos sin contacto.
• [C-3-2] DEBE respetar el intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT para mostrar una actividad que abra un diálogo en el que se le pida 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, sucederá lo siguiente:

• [C-4-1] DEBE respetar 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 del desarrollador para estos intents, como se describe en el SDK.

Si las implementaciones de dispositivos informan android.hardware.bluetooth, sucederá lo siguiente:

• [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 el Bluetooth.
• [C-5-2] DEBE respetar el intent "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" y mostrar una actividad del sistema que solicite el modo detectable.

Si las implementaciones de dispositivos admiten la función de No interrumpir, sucederá lo siguiente:

• [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 denegar a la app el acceso a configuraciones de políticas de DND.

Si las implementaciones en dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, sucederá lo siguiente:

• [C-7-1] DEBE proporcionar un mecanismo accesible para el usuario a fin de 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, sucederá lo siguiente:

• El [C-8-1] DEBE respetar el intent android.settings.ACCESSIBILITY_SETTINGS para proporcionar un mecanismo accesible para el usuario que permita habilitar o 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, harán 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, sucederá lo siguiente:

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

Si las implementaciones de dispositivos no proporcionan el modo de Ahorro de datos, sucederá 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 no-op.

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

• [C-12-3] DEBE controlar y solo 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, sucederá lo siguiente:

• [C-13-1] DEBE respetar el intent android.app.action.ADD_DEVICE_ADMIN para invocar una IU que ayude al usuario a agregar el administrador del dispositivo al sistema (o permitirle rechazarlo).

• [C-13-2] DEBE respetar los 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 que proporcione la entrega de estos intents aquí.

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

• [C-14-1] DEBE implementar por completo las APIs de AutofillService y AutofillManager, y respetar el intent android.settings.REQUEST_SET_AUTOFILL_SERVICE de mostrar un menú de configuración predeterminado de la app para habilitar e inhabilitar la función Autocompletar y cambiar el servicio de autocompletado predeterminado para el usuario.

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

• Los [C-SR-2] se RECOMIENDAN ELIMINARMENTE y proporcionan un mecanismo al que el usuario pueda acceder para otorgar o revocar el acceso a las estadísticas de uso en respuesta al intent android.settings.ACTION_USAGE_ACCESS_CONFIGURACIÓN para las apps que declaran el permiso android.permission.PACKAGE_USAGE_STATS.

Si las implementaciones en dispositivos impiden que alguna app, incluidas las preinstaladas, acceda a las estadísticas de uso, hará lo siguiente:

• [C-15-1] DEBE tener una actividad que controle el patrón de intent android.settings.ACTION_USAGE_ACCESS_CONFIGURACIÓN, pero DEBE implementarlo como una no-op, es decir, tener un comportamiento equivalente a cuando el usuario rechaza el acceso.

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, harán lo siguiente:

• [C-16-1] DEBE mostrar estos 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, suceden lo siguiente:

• [C-18-1] DEBE respetar el intent 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, hará lo siguiente:

• [C-SR-3] SE RECOMIENDA COMPLETAMENTE honrar android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA y los intents android.speech.tts.engine.GET_SAMPLE_TEXT tienen una actividad que proporciona entregas para estos intents, como se describe en el SDK aquí.

Android incluye compatibilidad con protectores de pantalla interactivos, conocidos anteriormente como Sueños. Los protectores de pantalla permiten a los usuarios interactuar con aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o en un conector para escritorio. Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con protectores de pantalla y proporcionar una opción de configuración para que los usuarios los configuren en respuesta al intent android.settings.DREAM_SETTINGS.

3.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, sucederá 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 manera similar a una actividad que se ejecuta en la pantalla principal.
• [C-1-3] DEBE colocar 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 por medio de la API de ActivityOptions.setLaunchDisplayId().
• [C-1-4] SE DEBE destruir todas las actividades cuando se quita una pantalla con la marca Display.FLAG_PRIVATE.
• [C-1-5] DEBE ocultar de manera segura el contenido en todas las pantallas cuando el dispositivo está bloqueado con una pantalla de bloqueo segura, a menos que la app acepte aparecer en la parte superior de la pantalla de bloqueo con la API de Activity#setShowWhenLocked().
• SE RECOMIENDA 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 una pantalla secundaria.

Si las implementaciones de dispositivos permiten iniciar actividades de Android normales en pantallas secundarias y una pantalla secundaria tiene la marca android.view.Display.FLAG_PRIVATE:

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

3.3. Compatibilidad con APIs nativas

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

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

3.3.1. Interfaces binarias de la aplicación

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

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con una o más ABI 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, mediante la semántica estándar de la interfaz nativa de Java (JNI).
• [C-0-3] DEBE ser compatible con la fuente (es decir, con el encabezado) y con el formato binario (para la ABI) con cada biblioteca obligatoria de la siguiente lista.
• [C-0-5] DEBE informar con precisión la interfaz binaria de la aplicación (ABI) nativa compatible con el dispositivo, a través de los parámetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS y android.os.Build.SUPPORTED_64_BIT_ABIS, cada uno de ellos como una lista de ABI separadas por comas 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 ABI, y NO DEBE informar ninguna ABI que no esté en la lista.

  • armeabi (ya no se admite como destino en el NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (compatibilidad con audio nativo de AAudio)
  • libamidi.so (compatibilidad nativa con MIDI, si se reclama 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 superficie nativa de OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (registro de Android)
  • libmediandk.so (compatibilidad con APIs de medios nativos)
  • libm (biblioteca de matemáticas)
  • libneuralnetworks.so (API de redes neuronales)
  • libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
  • libOpenSLES.so (compatibilidad con audio de OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (compatibilidad mínima con C++)
  • libvulkan.so (Vulkan)
  • libz (compresión Zlib)
  • Interfaz JNI

• [C-0-8] NO DEBE agregar ni quitar las funciones públicas de las bibliotecas nativas enumeradas anteriormente.

• [C-0-9] DEBE enumerar las bibliotecas adicionales que no pertenecen al AOSP expuestas directamente a 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 apps de terceros orientadas al nivel de API 24 o versiones posteriores, ya que están reservadas.

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

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

• SE DEBE compilar con el código fuente y los archivos de encabezado disponibles en el Proyecto de código abierto de Android ascendente.

Ten en cuenta que las versiones futuras de Android podrían incorporar compatibilidad con ABI adicionales.

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

Si las implementaciones de dispositivos informan la compatibilidad de la ABI armeabi, harán lo siguiente:

• [C-3-1] también DEBE admitir armeabi-v7a e informar su compatibilidad, ya que armeabi solo es compatible con versiones anteriores de apps más antiguas.

Si las implementaciones de dispositivos informan la compatibilidad de la ABI armeabi-v7a, en el caso de las apps que usan esta ABI, sucederá lo siguiente:

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

  • Features:, seguido de una lista de cualquier función opcional de la CPU ARMv7 compatible con el dispositivo.
  • CPU architecture:, seguido de un valor entero que describe la arquitectura ARM compatible más alta del dispositivo (p.ej., "8" para dispositivos ARMv8).

• [C-2-2] siempre DEBE tener las siguientes operaciones disponibles, 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 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 SIMD avanzada (también conocida como NEON).

3.4. Compatibilidad con la Web

3.4.1. Compatibilidad con WebView

Si las implementaciones en dispositivos proporcionan una implementación completa de la API de android.webkit.Webview, harán lo siguiente:

• [C-1-1] DEBE informar android.software.webview.
• [C-1-2] SE DEBE usar la compilación del proyecto Chromium del Proyecto de código abierto de Android ascendente en la rama de Android 14 para la implementación de la API de android.webkit.WebView.

• [C-1-3] La cadena de usuario-agente informada por WebView DEBE tener el siguiente formato:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, como Gecko) versión/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • El valor de la cadena $(VERSION) DEBE ser el mismo que el de android.os.Build.VERSION.release.
  • La cadena $(MODEL) PUEDE estar vacía, pero si no lo está, DEBE tener el mismo valor que android.os.Build.MODEL.
  • PUEDE omitirse "Build/$(BUILD)", pero si está presente, la string $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID.
  • El valor de la cadena $(CHROMIUM_VER) DEBE ser la versión de Chromium en el Proyecto de código abierto de Android ascendente.
  • Las implementaciones de dispositivos PUEDEN omitir a dispositivos móviles en la string de usuario-agente.

• El componente de WebView DEBE incluir compatibilidad con tantas funciones HTML5 como sea posible. Si es compatible, 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 diferente de la aplicación que crea una instancia de WebView. Específicamente, el proceso del procesador independiente DEBE tener un privilegio inferior, 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 del AOSP cumple con este requisito.

Ten en cuenta que, si las implementaciones en dispositivos son de 32 bits o declaran la marca de función android.hardware.ram.low, estarán exentas de C-1-3.

3.4.2. Compatibilidad del navegador

Si las implementaciones en dispositivos incluyen una aplicación de navegador independiente para la navegación web general, sucederá lo siguiente:

• [C-1-1] DEBE admitir cada una de estas APIs asociadas con HTML5:
  • la caché de la aplicación/operación sin conexión
  • Etiqueta<video>
  • ubicación geográfica
• [C-1-2] DEBE admitir la API de Webstorage HTML5/W3C, y DEBE admitir la API de IndexedDB de HTML5/W3C. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web hacen la transición para favorecer a IndexedDB sobre el almacenamiento web, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.
• PUEDE enviar una cadena de usuario-agente personalizada a la aplicación independiente del navegador.
• SE DEBE implementar la compatibilidad con la mayor cantidad de archivos HTML5 posible en la aplicación de navegador independiente (ya sea basada en la aplicación ascendente del navegador WebKit o en un reemplazo de terceros).

Sin embargo, si las implementaciones en dispositivos no incluyen una aplicación de navegador independiente, sucederá lo siguiente:

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

3.5 Compatibilidad de comportamiento de las APIs

Implementaciones en dispositivos:

• [C-0-9] DEBE garantizar que se aplique la compatibilidad del 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 seleccionadas por implementadores de dispositivos.

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

• [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent 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, en el caso de las apps en segundo plano:
  • [C-0-4] DEBEN dejar de ejecutar devoluciones de llamada registradas por 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 API LocationManager o el método WifiManager.startScan().
  • [C-0-6] Si la app se orienta al nivel de API 25 o superior, NO DEBEN permitir el registro de receptores de emisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la app, a menos que el intent de transmisión requiera un permiso "signature" o "signatureOrSystem" protectionLevel o que se encuentren en la lista de exenciones.
  • [C-0-7] Si la app se orienta al nivel de API 25 o superior, DEBEN detener los servicios en segundo plano, como si esta hubiera llamado al método stopSelf() de los servicios, a menos que se la coloque en una lista de entidades permitidas temporal para controlar una tarea que el usuario puede ver.
  • [C-0-8]: si la app tiene como objetivo un nivel de API 25 o superior, se DEBEN liberar los bloqueos de activación que contiene.
• [C-0-11] Los dispositivos DEBEN mostrar los siguientes proveedores de seguridad como los primeros siete valores de array del método Security.getProviders(), en el orden indicado y con los nombres y las clases (como los devuelve Provider.getName()), a menos que la app haya modificado la lista a través de insertProviderAt() o removeProvider(). ES POSIBLE que los dispositivos muestren 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. AndroidKeyStoreBCMétodo alternativo: 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) analiza la compatibilidad de comportamiento de partes significativas de la plataforma, pero no todas. El implementador es responsable de garantizar la compatibilidad del 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 aplicaciones

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

• [C-1-1] DEBE permitir que el usuario vea la lista de apps restringidas.
• [C-1-2] DEBE proporcionar la indicación visual del usuario para activar o desactivar todas estas restricciones de propiedad en cada app.

• [C-1-3] no DEBE aplicar automáticamente estas restricciones de propiedad sin evidencia de un comportamiento deficiente del estado del sistema, pero PUEDE aplicarlas en las apps después de detectar el comportamiento deficiente en el estado del sistema, como bloqueos de activación sostenidos, servicios de larga duración y otros criterios. Los criterios PUEDEN estar determinados por los implementadores del dispositivo, pero DEBEN estar relacionados con el impacto de la app en el estado del sistema. NO DEBEN usarse como criterios otros criterios que no se relacionan puramente 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 de propiedad para las apps cuando un usuario las desactivó de forma manual, y PUEDE sugerirle que las aplique.

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

• [C-1-6] DEBE mostrar 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 que usa explícitamente el usuario.

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

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

  • Condiciones de activación para restricciones de propiedad.
  • Qué y cómo se puede restringir una app
  • Cómo se puede excluir una app de esas restricciones
  • Cómo una app puede solicitar una exención de restricciones de propiedad si admiten esa 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, [C-1-3] [C-1-5] quedan exentas.

Si las implementaciones de dispositivos extienden las restricciones de apps que se implementan en el AOSP, ocurrirá 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 extienden la función incluida en el AOSP, sucederá lo siguiente:

• [C-1-1] DEBE cumplir con todos los requisitos de la sección 3.5.1, excepto para [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 ese usuario no usó la app durante un tiempo determinado. Se RECOMIENDA QUE esta duración sea de un mes o más. El uso DEBE definirse por una interacción explícita del usuario a través de la API de UsageStats#getLastTimeVisible() o por cualquier otra acción que haga que una app abandone el estado de detención forzada, incluidas las vinculaciones de servicios, las vinculaciones con proveedores de contenido, transmisiones explícitas, etc., a las que se hará un seguimiento con una nueva API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] solo DEBE aplicar restricciones que afecten a todos los usuarios del dispositivo cuando haya evidencia de que NINGÚN usuario usó el paquete durante cierto período. SE RECOMIENDA 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 servicios, solicitudes de proveedores de contenido o transmisiones explícitas.

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

3.6 Espacios de nombres de API

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

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

Es decir, ellos hacen lo siguiente:

• [C-0-1] NO DEBE modificar las APIs expuestas públicamente en la plataforma de Android cambiando ningún método o firma de clase, 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 upstream de Android.

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

• [C-0-3] NO DEBE afectar el comportamiento indicado ni la firma en lenguaje Java de las APIs expuestas públicamente.
• [C-0-4] NO DEBE anunciarse ni exponerse 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 haga referencia a otra. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* o uno similar: solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a los espacios de nombres de otras empresas.
• [C-0-6] SE DEBE empaquetar en una biblioteca compartida de Android para que solo las apps que los usan de manera explícita (a través del mecanismo <uses-library>) se vean afectadas por el aumento en el 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:

• [C-1-1] NO DEBE estar en una biblioteca de 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 funciones nuevas útiles a una API existente o agregando una API nueva), el implementador DEBE visitar source.android.com y comenzar el proceso de contribuir con cambios y código, según la información de ese sitio.

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

3.7 Compatibilidad del entorno de ejecución

Implementaciones en dispositivos:

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

• [C-0-2] SE DEBE configurar los tiempos de ejecución de Dalvik para asignar memoria en función de la plataforma de Android ascendente, y según lo especificado en la siguiente tabla. (Consulta la sección 7.1.1 para obtener definiciones de tamaño de pantalla y densidad de pantalla).

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

• SE RECOMIENDA ejecutar pruebas de fuzz 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 que se especifican a continuación se consideran valores mínimos y que las implementaciones en dispositivos PUEDEN asignar más memoria por aplicación.

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

3.8. Compatibilidad con la interfaz de usuario

3.8.1. Selector (pantalla principal)

Android incluye una aplicación de selector (pantalla principal) y compatibilidad con aplicaciones de terceros para reemplazar el selector de dispositivos (pantalla principal).

Si las implementaciones de dispositivos permiten que aplicaciones de terceros reemplacen su pantalla principal:

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

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

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

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

• [C-3-1] SE DEBE informar false de 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 shortManager, sucede lo siguiente:

• [C-4-1] DEBE admitir todas las funciones de atajos documentadas (p.ej., combinaciones de teclas estáticas y dinámicas, y fijar combinaciones de teclas) y, además, 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 las apps, sucederá lo siguiente:

• [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 estableció como true y no muestres ningún esquema de insignias de íconos de la app cuando todos los canales de notificaciones de la app hayan establecido el valor como false.
• PUEDE anular las insignias del ícono de la app con su esquema de insignias propio cuando las aplicaciones de terceros indiquen compatibilidad con este esquema mediante el uso de APIs propias, pero DEBERÍA usar los recursos y valores proporcionados a través de las APIs de insignias de notificación descritas en el SDK, como Notification.Builder.setNumber() y las APIs de Notification.Builder.setBadgeIconType().

Si las implementaciones de dispositivos admiten íconos monochrome, haz lo siguiente:

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

3.8.2. Widgets

Android admite widgets de apps de terceros definiendo un tipo de componente y la API y el 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, sucederán lo siguiente:

• [C-1-1] SE DEBE declarar la compatibilidad con la función android.software.app_widgets de la plataforma.

• [C-1-2] DEBE incluir compatibilidad integrada con AppWidgets y exponer las condiciones de la interfaz de usuario para agregar, configurar, ver y quitar AppWidgets.

• [C-1-3] DEBE ser capaz de renderizar widgets de 4 x 4 en el tamaño de cuadrícula estándar. Para obtener más información, consulta los Lineamientos de diseño de widgets de apps en la documentación del SDK de Android.

• PUEDE admitir widgets de apps 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, sucederá lo siguiente:

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

3.8.3. Notificaciones

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

3.8.3.1. Presentación de notificaciones

Si las implementaciones en dispositivos permiten que apps de terceros notifiquen a los usuarios sobre eventos importantes, sucederá lo siguiente:

• El [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 la implementación de un dispositivo incluye un vibrador, DEBE implementar correctamente las APIs de vibración. Si la implementación de un dispositivo no tiene hardware, las APIs correspondientes DEBEN implementarse como 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.) proporcionados en las APIs o en la guía de estilo de íconos de la barra de estado/sistema, aunque PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de código abierto de Android de referencia.
• [C-1-3] DEBE respetar e implementar correctamente los comportamientos descritos para que las APIs actualicen, quiten y agrupen las notificaciones.
• [C-1-4] DEBE proporcionar el comportamiento completo de la API de NotificationChannel documentado en el SDK.
• [C-1-5] DEBE proporcionar una indicación visual del usuario para bloquear y modificar una notificación de una app de terceros determinada por cada canal y nivel de paquete de app.
• [C-1-6] también DEBE proporcionar una indicación visual del usuario para mostrar los canales de notificaciones borrados.

• [C-1-7] DEBE renderizar correctamente todos los recursos (imágenes, calcomanías, íconos, etc.) 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 configura a través de setGroupConversation.

• [C-SR-1] SE RECOMIENDAN ENERGENTE para 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 objeto de escucha de notificaciones. El nivel de detalle DEBE ser para que el usuario pueda controlar qué tipos de notificaciones se comparten con este objeto de escucha de notificaciones. Los tipos DEBEN incluir las notificaciones de “conversaciones”, “alertas”, “silenciosas” e “en curso importante”.

• [C-SR-2] Se RECOMIENDEN ENERGMENTE proporcionan una indicación para que los usuarios especifiquen las apps que deben excluirse de notificar a cualquier objeto de escucha de notificaciones específico.

• [C-SR-3] SE RECOMIENDA EXITOSAMENTE para mostrar automáticamente una indicación visual del usuario para bloquear la notificación de una app de terceros determinada por cada canal y nivel de paquete de la app después de que el usuario descarte esa notificación varias veces.

• DEBE admitir notificaciones enriquecidas.

• Se DEBEN presentar algunas notificaciones de prioridad más alta como notificaciones de atención.

• SE RECOMIENDA tener una indicación visual del usuario para posponer las notificaciones.

• PUEDE administrar solo la visibilidad y los horarios de las apps de terceros que notifican a los usuarios sobre eventos notables para mitigar problemas de seguridad, como la distracción del conductor.

Android 11 incorpora compatibilidad con notificaciones de conversación, que son notificaciones que usan MessagingStyle y proporcionan un ID de acceso directo de Personas publicado.

Implementaciones en dispositivos:

• [C-SR-4] SE RECOMIENDA EJECUTARMENTE para agrupar y mostrar conversation notifications antes de las notificaciones que no son de conversación, a excepción de las notificaciones del servicio en primer plano en curso y las notificaciones de importance:high.

Si las implementaciones de dispositivos admiten conversation notifications y la app proporciona los datos necesarios para bubbles, hará lo siguiente:

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

Si las implementaciones de dispositivos admiten notificaciones enriquecidas, sucederá lo siguiente:

• [C-2-1] SE DEBE usar los recursos exactos tal como se proporcionan a través de la clase de API Notification.Style y sus subclases para los elementos de recursos presentados.
• SE DEBE presentar todos y cada uno de los elementos de recursos (p.ej., el ícono, el título y el texto de resumen) definidos en la clase de API 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 de dispositivos admiten notificaciones de atención, sucederá lo siguiente:

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

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

Implementaciones en dispositivos:

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

Si las implementaciones de dispositivos cuentan con la posibilidad de posponer notificaciones por parte del usuario, sucederá lo siguiente:

• [C-1-1] DEBE reflejar correctamente el estado de las notificaciones pospuestas a través de las APIs estándar, como NotificationListenerService.getSnoozedNotifications().
• [C-1-2] DEBE hacer que esta indicación visual del usuario esté disponible para posponer notificaciones de cada app de terceros instalada, a menos que sean de servicios persistentes o en primer plano.

3.8.3.3 No interrumpir (No interrumpir) / Modo de prioridad

Si las implementaciones de dispositivos admiten la función de No interrumpir (también llamada Modo de prioridad), sucederá lo siguiente:

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

3.8.4. API de Assist

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

Si las implementaciones de dispositivos admiten la acción de asistencia, harán lo siguiente:

• [C-2-1] DEBE indicar claramente al usuario final cuando se comparte el contexto de alguna de las siguientes maneras:
  • Cada vez que la app de asistencia accede al contexto, muestra una luz blanca alrededor de los bordes de la pantalla que alcanza 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 app de asistencia preinstalada, proporcionar una indicación visual del usuario a menos de dos navegaciones fuera del menú de configuración de la app de Asistente y entrada de voz predeterminada, y solo compartir el contexto cuando el usuario invoca explícitamente la app de asistencia mediante una palabra clave o una entrada de tecla de navegación de asistencia
• [C-2-2] La interacción designada para iniciar la aplicación de asistencia, tal como se describe en la sección 7.2.3, DEBE iniciar la aplicación de asistencia seleccionada por el usuario; en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que controla el intent ACTION_ASSIST.

3.8.5. Alertas y avisos

Las aplicaciones pueden usar la API de Toast para mostrar al usuario final cadenas no modales cortas que desaparecen después de un período breve, 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 en dispositivos incluyen una salida de pantalla o de video, sucederá lo siguiente:

• [C-1-1] DEBE proporcionar una indicación visual del usuario para bloquear una app de modo que no muestre ventanas de alerta 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 respetar la API de avisos y mostrarlos de las aplicaciones a los usuarios finales de una 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 quieren que coincidan con el diseño del tema Holo, según lo define el SDK de Android.

Si las implementaciones en dispositivos incluyen una salida de pantalla o de video, sucederá 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 alterar ninguno de los atributos del tema de Material ni sus recursos expuestos a las aplicaciones.

• [C-1-3] SE DEBE configurar la familia de fuentes "sans-serif" en Roboto versión 2.x para los idiomas que Roboto admite o proporcionar una opción de usuario para cambiar la fuente utilizada en la familia de fuentes "sans-serif" a Roboto versión 2.x para los idiomas que admite Roboto.

• [C-1-4] DEBE generar paletas de tonos de color dinámicas como se especifica en la documentación de 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 de tonos de color dinámicas con los estilos de temas 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 yMONOCHROMATIC.

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

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

  • SE DEBE derivar 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.

  • SE 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 "Device Default" como un conjunto de estilos definidos que pueden usar los desarrolladores de aplicaciones si desean coincidir con la apariencia del tema del dispositivo según lo define el implementador de dispositivos.

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

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

Si las implementaciones de dispositivos incluyen una barra de estado del sistema, sucederá lo siguiente:

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

3.8.7. Fondos de pantalla animados

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

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

• Las implementaciones en dispositivos capaces de ejecutar fondos de pantalla animados de manera confiable, como se describió anteriormente, DEBEN implementar fondos de pantalla animados.

Si las implementaciones en dispositivos implementan fondos de pantalla animados, sucederá lo siguiente:

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

3.8.8. Cambio de actividad

El código fuente upstream de Android incluye la pantalla de descripció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 mediante una imagen en miniatura del estado gráfico de la aplicación en el momento en que el usuario la abandonó por última vez.

Las implementaciones del dispositivo, 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 del dispositivo, incluida la tecla de navegación de la función de recientes, como se detalla en la sección 7.2.3, modifican la interfaz, sucede lo siguiente:

• [C-1-1] DEBE admitir al menos un máximo de 7 actividades mostradas.
• SE RECOMIENDA mostrar, al menos, el título de 4 actividades a la vez.

• SE DEBE mostrar el color de resaltado, el ícono, el título de la pantalla en recientes.
• SE DEBE mostrar una indicación visual de cierre ("x"), pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas.
• SE DEBE implementar una combinación de teclas para cambiar fácilmente a la actividad anterior.
• SE DEBE activar la acción de cambio rápido entre las dos apps usadas más recientemente cuando se presione dos veces la tecla de función Recientes.
• SE DEBE activar el modo multiventana de pantalla dividida, si es compatible, cuando se mantiene presionada la tecla de funciones recientes.
• PUEDE mostrar los recientes afiliados como un grupo que se mueve de forma conjunta.
• [C-SR-1] SE RECOMIENDA ENcarecidamente usar la interfaz de usuario upstream de Android (o una interfaz similar basada en miniaturas) para la pantalla de descripción general.

3.8.9. Administración de entradas

Android incluye compatibilidad con la Administración de entradas y editores de métodos de entrada de terceros.

Si las implementaciones en dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, sucederá lo siguiente:

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

3.8.10. Control multimedia de la pantalla de bloqueo

La API de cliente de control remoto dejó de estar disponible en Android 5.0 y se reemplazó por la Plantilla de notificación multimedia, que permite que las aplicaciones multimedia 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 obtener información sobre el intent de configuración para configurar 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

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

3.8.13. Unicode y fuentes

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

Si las implementaciones en dispositivos incluyen una salida de pantalla o de video, sucederá lo siguiente:

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

Si las implementaciones en dispositivos incluyen un IME, sucede lo siguiente:

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

Android admite la renderización de fuentes birmanas. Birmania tiene varias fuentes que no son compatibles con Unicode, comúnmente conocidas como "Zawgyi", para renderizar idiomas birmanos.

Si las implementaciones en dispositivos incluyen compatibilidad con birmano, sucederá lo siguiente:

• [C-2-1] DEBE renderizar el texto con una fuente compatible con Unicode de forma predeterminada; la fuente que no es compatible con Unicode NO DEBE configurarse 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 que no sea compatible con Unicode si en el dispositivo se admite una que no lo sea. La fuente que no es compatible con Unicode NO DEBE quitar ni reemplazar la fuente Unicode.
• [C-2-3] DEBE renderizar el texto con una fuente que no sea compatible con Unicode SOLO SI se especifica un código de idioma con código de secuencia de comandos 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 una fuente que no cumpla con Unicode para Birmania. Los desarrolladores de apps y los autores de páginas web pueden especificar my-Qaag como el código de idioma designado como lo harían para cualquier otro idioma.

3.8.14. Multiventana

Si las implementaciones de dispositivos tienen la capacidad de mostrar varias actividades al mismo tiempo, harán lo siguiente:

• [C-1-1] DEBE implementar estos modos multiventana de acuerdo con los comportamientos de la aplicación y las APIs que se describen en la documentación de compatibilidad del modo multiventana del SDK de Android y cumplir con los siguientes requisitos:
• [C-1-2] DEBE respetar el android:resizeableActivity establecido por una app en el archivo AndroidManifest.xml, como se describe en este SDK.
• [C-1-3] NO DEBE ofrecer el modo de pantalla dividida ni de forma libre si la altura de la pantalla es inferior a 440 dp y el ancho es menor que 440 dp.
• [C-1-4] NO DEBE cambiar el tamaño de una actividad a un tamaño inferior a 220 dp en los modos multiventana que no sean Pantalla en pantalla.
• Las implementaciones en dispositivos con tamaño de pantalla xlarge DEBEN admitir el modo de forma libre.

Si las implementaciones de dispositivos admiten modos multiventana y el modo de pantalla dividida, sucederán lo siguiente:

• [C-2-2] SE DEBE recortar la actividad anclada de una multiventana de pantalla dividida, pero SE DEBE mostrar parte de su contenido si la app Launcher 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 de anular estos valores mientras se muestra parte del contenido de la actividad acoplada.

Si las implementaciones de dispositivos admiten los modos multiventana y el modo multiventana:

• [C-3-1] DEBE iniciar actividades en el modo multiventana de pantalla en pantalla cuando la app: * Se orienta al nivel de API 26 o versiones posteriores y declara android:supportsPictureInPicture. * Se orienta al nivel de API 25 o versiones anteriores, y declara android:resizeableActivity y android:supportsPictureInPicture.
• [C-3-2] DEBE exponer las acciones en su SystemUI según lo que especifique la actividad de PIP actual a través de la API de setActions().
• [C-3-3] DEBE admitir relaciones de aspecto superiores o iguales a 1:2.39, e inferiores o iguales a 2.39:1, según se especifica en la actividad de 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 del usuario para bloquear una app para que no se muestre en modo de PIP. La implementación de AOSP cumple con este requisito por tener 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 Configuration.uiMode configurado 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 configurado como UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.

3.8.15. Recorte de pantalla

Android admite un 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 podría 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, sucederá lo siguiente:

• [C-1-5] NO DEBE tener cortes si la relación de aspecto del dispositivo es 1.0 (1:1).
• [C-1-2] NO DEBE tener más de un corte por borde.
• [C-1-3] DEBE respetar 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] SE 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 las APIs de ControlsProviderService y Control para permitir que aplicaciones de terceros publiquen controles de dispositivos para agilizar el estado y las acciones de los usuarios.

Consulta la sección 2_2_3 para conocer los requisitos específicos de cada dispositivo.

3.8.17. Portapapeles

Implementaciones en dispositivos:

• [C-0-1] NO DEBE enviar datos del portapapeles a ningún componente, actividad, servicio ni 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), excepto para los servicios mencionados en 9.8.6 Captura de contenido y Búsqueda de aplicaciones.

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

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

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

3.9 Administración del dispositivo

Android incluye funciones que permiten a las aplicaciones conscientes de la seguridad realizar funciones de administración de dispositivos a nivel del sistema, como la aplicación de políticas de contraseñas o la limpieza remota, a través de la API de administración de dispositivos Android.

Si las implementaciones de dispositivos implementan la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android, harán lo siguiente:

• [C-1-1] DEBE declarar android.software.device_admin.
• [C-1-2] DEBE admitir el aprovisionamiento del propietario del dispositivo, como se describe en las secciones 3.9.1 y 3.9.1.1.

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

Si las implementaciones de dispositivos declaran android.software.device_admin, hará lo siguiente:

• [C-1-1] DEBE admitir la inscripción de un cliente de política de dispositivo (DPC) como una app del propietario del dispositivo, como se describe a continuación:
  • Cuando la implementación del dispositivo no tiene configurados usuarios ni datos del usuario, hace lo siguiente:
    • [C-1-5] DEBE inscribir la aplicación de DPC como la aplicación del propietario del dispositivo o habilitar la aplicación para elegir si convertirse en propietario del dispositivo o propietario del perfil si el dispositivo declara compatibilidad con las comunicaciones 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, de modo que la app para el DPC pueda elegir si desea convertirse en propietario del dispositivo o propietario del perfil, según los valores de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a menos que se 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 del propietario del dispositivo si este se establece durante el aprovisionamiento, sin importar el método de aprovisionamiento que se use. El usuario no debe poder continuar en el asistente de configuración hasta que finalice la app del propietario del dispositivo.
  • Cuando la implementación de dispositivos tiene usuarios o datos del usuario, hace lo siguiente:
    • [C-1-7] Ya no se DEBE inscribir ninguna aplicación de DPC como la app del propietario del dispositivo.

• El [C-1-2] DEBE mostrar un aviso de divulgación adecuado (como como se hace referencia en el AOSP) y obtener el consentimiento afirmativo del usuario final antes de que se establezca una app como Propietario del dispositivo, a menos que el dispositivo esté configurado de manera programática para el modo de demo para punto de venta antes de la interacción en pantalla con el usuario final. Si las implementaciones de dispositivos declaran android.software.device_admin, pero también incluyen una solución de administración de dispositivos de su propiedad y proporcionan un mecanismo para promover una aplicación configurada en su solución como un "Propietario del dispositivo equivalente" al "Propietario del dispositivo", como lo reconocen las APIs estándar de DevicePolicyManager de Android, harán lo siguiente:

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

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

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

3.9.1.2 Aprovisionamiento de perfiles administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, hará lo siguiente:

• [C-1-1] DEBE implementar las APIs que permiten que una aplicación del controlador de política de dispositivo (DPC) se convierta en la propietaria de un nuevo perfil administrado.

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

• [C-1-3] DEBE proporcionar las siguientes condiciones del usuario dentro de la Configuración para indicarle al usuario cuando el controlador de política de dispositivo (DPC) inhabilitó una función del sistema en particular:

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

• [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 inicia 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 de DPC pueda elegir si convertirse en propietario del dispositivo o del perfil, excepto cuando el intent android.app.action.PROVISION_MANAGED_PROFILE activa el aprovisionamiento.

• [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, sin importar el método de aprovisionamiento que se use, excepto cuando el aprovisionamiento se activa por 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 del propietario del perfil.

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

3.9.2 Asistencia para perfiles administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, hará 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 que se cree un solo perfil administrado.
• [C-1-3] SE DEBE usar una insignia de ícono (similar a la insignia de trabajo ascendente de AOSP) para representar las aplicaciones y los widgets administrados, y otros elementos de la IU con insignia, como Recientes y Notificaciones.
• [C-1-4] DEBE mostrar un ícono de notificación (similar a la insignia de trabajo upstream de AOSP) para indicar que el usuario está dentro de una aplicación de perfil administrado.
• [C-1-5] DEBE mostrar un aviso que indique que el usuario está en el perfil administrado si se activa el dispositivo (ACTION_USER_PRESENT) y la aplicación en primer plano está dentro del perfil administrado.
• [C-1-6] Cuando existe un perfil administrado, DEBE mostrar una indicación visual en el "Selector de intents" para permitir que el usuario reenvíe el intent desde el perfil administrado al usuario principal, o viceversa, si el controlador de Device Policy lo habilita.
• [C-1-7] Cuando existe un perfil administrado, DEBE exponer las siguientes condiciones del usuario, tanto para el usuario principal como para el perfil administrado:
  • Contabilización independiente de la batería, la ubicación, los datos móviles y el uso del almacenamiento del usuario principal y el perfil administrado
  • Administración independiente de aplicaciones de VPN instaladas dentro del usuario principal o perfil administrado
  • Administración independiente de aplicaciones instaladas dentro del usuario principal o el perfil administrado
  • Administración independiente de cuentas dentro del usuario principal o el perfil administrado
• [C-1-8] DEBE asegurarse de que el marcador preinstalado, los contactos y las aplicaciones de mensajería puedan buscar y buscar la información del emisor desde el perfil administrado (si existe) junto con los del perfil principal, si el controlador de políticas del dispositivo lo permite.
• [C-1-9] DEBE asegurarse de que cumpla con todos los requisitos de seguridad aplicables para un dispositivo que tenga habilitados varios usuarios (consulta la sección 9.5), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.

Si las implementaciones de dispositivos declaran android.software.managed_users y android.software.secure_lock_screen, hará lo siguiente:

• [C-2-1] DEBE admitir la capacidad de especificar una pantalla de bloqueo separada que cumpla con los siguientes requisitos para otorgar acceso a las apps que se ejecutan solo en un perfil administrado.
  • Las implementaciones de dispositivos DEBEN respetar el intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD y mostrar una interfaz a fin de configurar una credencial de pantalla de bloqueo separada para el perfil administrado.
  • Las credenciales de pantalla de bloqueo del perfil administrado DEBEN usar los mismos mecanismos de administración y almacenamiento de credenciales que el perfil superior, tal como se documenta en el sitio del Proyecto de código abierto de Android.
  • Las políticas de contraseñas de 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 muestra getParentProfileInstance.
• Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la IU en la llamada, las notificaciones en curso y de llamadas perdidas, los contactos y las apps de mensajería, SE DEBEN tener la misma insignia que se utiliza para indicar las aplicaciones de perfil administrado.

3.9.3 Asistencia para usuarios administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, hará lo siguiente:

• [C-1-1] DEBE proporcionar una indicación visual para salir del usuario actual y volver al usuario principal en una sesión de varios usuarios cuando isLogoutEnabled muestre true. Se DEBE acceder a la opción del usuario desde la pantalla de bloqueo sin desbloquear el dispositivo.

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

• [C-SR-1] SE RECOMIENDA RECOMENDADAMENTE que muestren las mismas divulgaciones de consentimiento del propietario del dispositivo del AOSP que se mostraron en el flujo que inició android.app.action.PROVISION_MANAGED_DEVICE, antes de permitir que se agreguen cuentas en el nuevo usuario secundario, para que los usuarios comprendan que el dispositivo está administrado.

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

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

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

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

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

Si se define un nombre de paquete para config_devicePolicyManagement como se describió anteriormente:

• [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 de la función de administración de políticas de dispositivos antes de aprovisionar por medio de la configuración de config_devicePolicyManagementUpdater.

Si se define un nombre de paquete para config_devicePolicyManagementUpdater como se describió anteriormente:

• [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.10. Accesibilidad

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

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, sucederá 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 del usuario para controlar los servicios de accesibilidad que declaran el AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Ten en cuenta que, en el caso de las implementaciones en dispositivos con una barra de navegación del sistema, DEBEN permitir que el usuario tenga la opción de un botón en la barra de navegación del sistema para controlar estos servicios.

Si las implementaciones de dispositivos incluyen servicios de accesibilidad preinstalados, sucederá lo siguiente:

• [C-2-1] SE DEBE implementar estos servicios de accesibilidad preinstalados como apps con conocimiento de inicio directo cuando el almacenamiento de datos está encriptado con encriptación basada en archivos (FBE).
• Se recomienda proporcionar un mecanismo en el flujo de configuración listo para usar a fin de que los usuarios habiliten los servicios de accesibilidad relevantes, así como opciones para ajustar el tamaño de la fuente, el tamaño de la pantalla y los gestos de ampliación.

3.11. Text-to-Speech

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

Si las implementaciones de dispositivos informan la función android.hardware.audio.output, hacen 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, sucederá lo siguiente:

• [C-2-1] DEBE proporcionar la indicación visual del usuario que le permita seleccionar un motor de TTS para usar a nivel del sistema.

3.12. Marco de trabajo de entrada de TV

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

Si las implementaciones en dispositivos son compatibles con el TIF, tienen las siguientes características:

• [C-1-1] SE DEBE declarar la función android.software.live_tv de la plataforma.
• [C-1-2] DEBE admitir todas las APIs del TIF de modo que una aplicación que use estas APIs y el servicio de entradas basadas en el TIF de terceros puedan instalarse y usarse en el dispositivo.

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, harán lo siguiente:

• [C-1-1] DEBE permitir que el usuario agregue o quite los mosaicos proporcionados 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 de apps de terceros que agregó el usuario junto con los mosaicos de configuración rápida proporcionados por el sistema.

3.14. IU multimedia

Si las implementaciones de dispositivos incluyen aplicaciones que no se activan por voz (las Apps) que interactúan con aplicaciones de terceros a través de MediaBrowser o MediaSession, las Apps hacen lo siguiente:

• [C-1-2] DEBE mostrar claramente los íconos obtenidos a través de getIconBitmap() o getIconUri() y los títulos obtenidos con getTitle(), como se describe en MediaDescription. Los títulos pueden acortarse 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 siempre 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 una 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] SE DEBE considerar presionar dos veces 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 cumplir con los siguientes requisitos:

• [C-1-1] A las apps instantáneas solo DEBEN tener permisos con android:protectionLevel establecido en "instant".
• [C-1-2] Las Apps instantáneas NO DEBEN interactuar con las apps instaladas a través de intents implícitos, a menos que se cumpla una de las siguientes condiciones:
  • El filtro de patrón de intents del componente está expuesto y tiene CATEGORY_BROWSABLE
  • La acción es una de las siguientes: ACTION_SEND, ACTION_SENDTO, 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 manera 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 los detalles de las Apps instantáneas en el dispositivo, a menos que se conecten de forma explícita a la aplicación instalada.

• Las implementaciones del dispositivo DEBEN proporcionar las siguientes condiciones del usuario para interactuar con las Apps instantáneas. AOSP cumple con los requisitos con la IU del sistema, la configuración y el Selector predeterminados. Implementaciones en dispositivos:

  • [C-1-5] DEBE proporcionar una indicación visual de usuario para ver y borrar Apps instantáneas localmente almacenadas en caché 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 para el usuario DEBE incluir que las Apps instantáneas no requieren instalación y proporcionar una indicación visual que lo dirija a la pantalla de información de la aplicación en Configuración. En el caso de las apps instantáneas iniciadas a través de intents web, como se define mediante el uso de un intent con una acción establecida en Intent.ACTION_VIEW y con un esquema de "http" o "https", una opción adicional de usuario DEBE permitir que el usuario no inicie la app instantánea ni inicie el vínculo asociado con el navegador web configurado si hay un navegador disponible en el dispositivo.
  • [C-1-7] DEBE permitir el acceso a las Apps instantáneas en ejecución desde la función Recientes si esta función está disponible en el dispositivo.

• [C-1-8] DEBE precargar una o más aplicaciones o componentes del servicio con un controlador de intents para los intents enumerados en el SDK aquí y hacer que los intents sean visibles para Apps instantáneas.

3.16. Sincronización de dispositivos complementarios

Android admite la vinculación de dispositivos complementarios para administrar de manera más eficaz la asociación con estos dispositivos 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, sucederá lo siguiente:

• [C-1-1] DEBE declarar la marca de función FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] DEBE asegurarse de que las APIs del paquete android.companion se hayan implementado por completo.
• [C-1-3] DEBE proporcionar las condiciones del usuario para que este seleccione o confirme que un dispositivo complementario está presente y en funcionamiento.

3.17. Aplicaciones pesadas

Si las implementaciones de dispositivos declaran la función FEATURE_CANT_SAVE_STATE, sucede lo siguiente:

• [C-1-1] DEBE tener solo una app instalada que especifique cantSaveState que se ejecuta en el sistema a la vez. Si el usuario abandona esa app sin salir de ella explícitamente (por ejemplo, presiona el botón de inicio mientras deja una actividad activa en el sistema, en lugar de presionar el botón Atrás sin actividades activas restantes en el sistema), las implementaciones del dispositivo DEBEN priorizar esa app en la RAM, como lo hacen con otras tareas que se espera que permanezcan en ejecución, como los servicios en primer plano. Mientras esta app se encuentra en segundo plano, el sistema puede aplicarle funciones de administración de energía, como limitar el acceso a la CPU y a la red.
• [C-1-2] DEBE proporcionar una indicación visual de IU para elegir la app que no participará en el mecanismo de guardado/restablecimiento de estado normal 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 priorización de la programación.

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

• [C-1-1] DEBE ignorar el atributo cantSaveState establecido por las apps y NO DEBE cambiar el comportamiento de la app según 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 generalmente se sincronizan con un servicio web, pero también PUEDEN residir solo de forma local en el dispositivo. Los contactos que solo se almacenan en el dispositivo se conocen como contactos locales.

Los RawContacts están "asociados con" o "almacenados 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 contactos sin procesar que solo se almacenan en el dispositivo y no se asocian con una cuenta en AccountManager, que se crean con valores null para las columnas ACCOUNT_NAME y ACCOUNT_TYPE.

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

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA ENcarecidamente no crear cuentas locales personalizadas.

Si las implementaciones de dispositivos usan una cuenta local personalizada:

• [C-1-1] El ACCOUNT_NAME de la cuenta local personalizada DEBE devolverse a más tardar el ContactsContract.RawContacts.getLocalAccountName.
• [C-1-2] El ACCOUNT_TYPE de la cuenta local personalizada DEBE devolverse a más tardar el ContactsContract.RawContacts.getLocalAccountType.
• [C-1-3] Los contactos sin procesar que insertan aplicaciones de terceros con la cuenta local predeterminada (es decir, mediante la configuración de valores nulos para ACCOUNT_NAME y ACCOUNT_TYPE) DEBEN insertarse en la cuenta local personalizada.
• [C-1-4] Los contactos sin procesar insertados en la cuenta local personalizada no DEBEN quitarse cuando se agregan o quitan cuentas.
• [C-1-5] Las operaciones de eliminación realizadas en la cuenta local personalizada DEBEN borrar de forma inmediata 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 estableció en falso o no se especificó.

4. Compatibilidad con paquetes de aplicaciones

Implementaciones en dispositivos:

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

  • Dado que el requisito anterior puede ser desafiante, se RECOMIENDA que las implementaciones en dispositivos usen el sistema de administración de paquetes de la implementación de referencia de AOSP.

• [C-0-2] DEBE admitir la verificación de archivos ".apk" con 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 JAR.

• [C-0-3] NO DEBE extender los formatos de código de bytes .apk, manifiesto de Android, código de bytes Dalvik ni RenderScript de manera que eviten que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.

• [C-0-4] NO DEBE permitir que las apps que no sean el "instalador de registro" actual del paquete desinstalen la app de manera 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 android:targetSdkVersion establecido en 24 o menos.
  • DEBE tener el permiso del usuario para instalar apps de fuentes desconocidas.

• SE DEBE proporcionar una indicación visual de usuario para otorgar o revocar el permiso para instalar apps de fuentes desconocidas por cada aplicación, pero PUEDE optar por implementar esto como una no-op y mostrar RESULT_CANCELED para startActivityForResult() si la implementación del dispositivo no desea permitir que los usuarios tengan esta opción. Sin embargo, incluso en esos casos, DEBEN indicar 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 al usuario a través de la API PackageManager.setHarmfulAppWarning del sistema antes de iniciar una actividad en una aplicación que la misma API PackageManager.setHarmfulAppWarning del sistema marcó como potencialmente dañina.

• SE DEBE proporcionar una indicación visual al usuario para que desinstale o inicie una aplicación en el diálogo de advertencia.

• [C-0-8] SE DEBE implementar la compatibilidad con el sistema de archivos incrementales, 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 en dispositivos:

• [C-0-1] DEBE admitir los formatos multimedia, los codificadores, los decodificadores, los tipos de archivo y los formatos de contenedor definidos en la sección 5.1 para cada códec declarado por MediaCodecList.
• [C-0-2] DEBE declarar e informar la compatibilidad de los codificadores y decodificadores disponibles para aplicaciones de terceros a través de MediaCodecList.
• [C-0-3] DEBE poder decodificarse correctamente y poner a disposición de apps de terceros todos los formatos que pueda codificar. Esto incluye todos los flujos de bits que generan sus codificadores y los perfiles informados en su CamcorderProfile.

Implementaciones en dispositivos:

• DEBERÍAN lograr una latencia de códec mínima; en otras palabras, deben
  • NO SE DEBE consumir ni almacenar búferes de entrada ni devolver búferes de entrada solo una vez procesados.
  • NO SE DEBEN retener los búferes decodificados durante más tiempo del que se especifica en el estándar (p.ej., SPS).
  • NO DEBERÍAS retener los búferes codificados más tiempo que el requerido por la estructura del GOP.

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

Ten en cuenta que ni Google ni Open Handset Alliance declaran que estos códecs no tienen patentes de terceros. Se recomienda a quienes deseen utilizar este código fuente en productos de hardware o software que las implementaciones de este código, incluso en el software de código abierto o el software compartido, requieran licencias de patentes de los titulares de patentes pertinentes.

5.1. Códecs de contenido multimedia

5.1.1 Codificación de audio

Puedes obtener más detalles en la sección 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 permitir que estén disponibles para apps de terceros:

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

Todos los codificadores de audio DEBEN admitir lo siguiente:

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

5.1.2. Decodificación de audio

Puedes obtener más detalles en la sección 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 MPEG-4 AAC (AAC LC)
• [C-1-2] Perfil MPEG-4 HE AAC (AAC+)
• [C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ mejorado)
• [C-1-4] AAC ELD (AAC mejorado de bajo retraso)
• [C-1-11] xHE-AAC (perfil HE AAC extendido de ISO/IEC 23003-3, que incluye el perfil de Baseline de la USAC y el perfil de control de rango dinámico ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, incluidos los formatos de audio de alta resolución de hasta 24 bits, una tasa de muestreo de 192 kHz y 8 canales Ten en cuenta que este requisito es solo para la decodificación, y que el dispositivo puede reducir el muestreo y reducir la mezcla durante la fase de reproducción.
• [C-1-10] Opus

Si las implementaciones del dispositivo 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 mezclar (p.ej., una transmisión 5.0 AAC se debe decodificar en cinco canales de PCM, y una transmisión 5.1 AAC debe decodificarse en seis canales de PCM).
• [C-2-2] Los metadatos de rango dinámico DEBEN ser los que se definen en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3 y las claves del 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 nivel 21 y son: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL y KEY_AAC_ENCODED_TARGET_LEVEL.
• [C-SR-1] SE RECOMIENDA ENERCMENTE que todos los decodificadores de audio de AAC cumplan con los requisitos de C-2-1 y C-2-2 mencionados anteriormente.

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

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

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

• PUEDE admitir el control de volumen y 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 ISO/IEC 23003-4 e ISO/IEC 14496-3 están presentes en un flujo de bits decodificado, sucede lo siguiente:

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

Todos los decodificadores de audio DEBEN admitir la salida:

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

Si las implementaciones del dispositivo 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, DEBE ser compatible lo siguiente:

• La aplicación DEBE poder configurar el [C-7-1] usando la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se mezcla en estéreo (cuando se usa un valor de 2) o si se emite con el número nativo de canales (cuando se usa un valor igual o mayor a ese número). Por ejemplo, un valor de 6 o más configuraría un decodificador para que emita 6 canales cuando se ingrese 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, con las constantes android.media.AudioFormat (ejemplo: CHANNEL_OUT_5POINT1).

Si las implementaciones de dispositivos admiten decodificadores de audio distintos del decodificador de audio AAC predeterminado y pueden generar audio multicanal (es decir, más de 2 canales) cuando se les alimenta contenido multicanal comprimido, haz lo siguiente:

• [C-SR-2] SE RECOMIENDA EL DEcodificador que la aplicación pueda configurar mediante la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se mezcla en estéreo (cuando se usa un valor de 2) o si se emite mediante la cantidad nativa de canales (cuando se usa un valor igual o mayor que ese número). Por ejemplo, un valor de 6 o más configuraría un decodificador para que emita 6 canales cuando se ingrese contenido 5.1.
• [C-SR-3] Cuando se realiza la decodificación, se RECOMIENDA EL DEcodificador para anunciar la máscara de canal que se utiliza en el formato de salida con la clave KEY_CHANNEL_MASK, mediante 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 archivos/formatos de contenedor que se admitirán
Perfil MPEG-4 AAC (AAC LC)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 8 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC sin formato ADTS (.aac, ADIF no es compatible) MPEG-TS (.ts, no permite 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 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Perfil (AAC+ mejorado)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC mejorado de bajo retraso)	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 7.35 a 48 kHz.	MPEG-4 (.mp4, .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 de muestra a 16 kHz, como se define en AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (.3gp)
FLAC	Tanto para el codificador como el decodificador, se DEBEN admitir, al menos, los modos Mono y estéreo. DEBEN admitir tasas de muestreo de hasta 192 kHz; DE 16 bits y 24 bits, se DEBE admitir las resoluciones de 16 bits y 24 bits. El manejo 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	Tipos 0 y 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		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 número de punto flotante de 16 bits. El extractor WAVE debe admitir PCM lineal de 16 bits, 24 bits y 32 bits, y un número de punto flotante de 32 bits (las tasas llegan hasta el límite del hardware). Las tasas de muestreo DEBEN ser compatibles entre 8 kHz y 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, 12,400, 26000 y 26000.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) Webm (.webm)

5.1.4. Codificación de imágenes

Obtén más detalles en la sección 5.1.6. Detalles de los códecs de imagen.

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

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

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, sucederá lo siguiente:

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

5.1.5 Decodificación de imágenes

Obtén más detalles en la sección 5.1.6. Detalles de los códecs de imagen.

Las implementaciones del dispositivo 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 lo siguiente: * [C-1-1] DEBE admitir la decodificación de imágenes HEIF (HEIC).

Decodificadores de imágenes que admiten un formato de profundidad de bits alta (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 ARGB_8888 de android.graphics.Bitmap.

5.1.6. Detalles de los códecs de imagen

Formato/códec	Detalles	Tipos de archivos/formatos de contenedor admitidos
JPEG	Básica + progresiva	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Voraz		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Imagen, colección de imágenes, secuencia de imágenes	HEIF (.heif), HEIC (.heic)
AVIF (perfil de Baseline)	Imagen, colección de imágenes, secuencia de imágenes Perfil de Baseline	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 8:8:8 de YUV420 (COLOR_FormatYUV420Flexible) hasta CodecCapabilities.

• [C-SR-1] SE RECOMIENDA ENRENDER A fin de admitir el formato de color RGB888 para el Modo de superficie de entrada.

• [C-1-3] DEBE admitir al menos uno de los formatos de color YUV420 planos o semiplanar con una relación de aspecto de 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). Se RECOMIENDA ENERGAR QUE sea compatible con ambos.

5.1.7 Códecs de video

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

Si las implementaciones en dispositivos incluyen un decodificador o codificador de video:

• [C-1-1] Los códecs de video DEBEN admitir tamaños de búfer de bytes de salida y entrada que se adapten a los fotogramas comprimidos y descomprimidos más grandes posibles según lo que dicta el estándar y la configuración, pero no de manera general.

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

• [C-1-3] Los codificadores y decodificadores de video DEBEN admitir, al menos, uno de los formatos de color YUV420 planos o semiplanar 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). SE RECOMIENDA ENRENDER que sean compatibles con ambos.

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

• [C-1-5] Los decodificadores de video que admiten un formato de profundidad de bits alta (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 mediante 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 perfiles HDR a través de Display.HdrCapabilities, harán lo siguiente:

• [C-2-1] DEBE ser compatible con el análisis y la administración de metadatos estáticos de HDR.

Si las implementaciones de dispositivos anuncian la compatibilidad con actualizaciones internas a través de FEATURE_IntraRefresh en la clase MediaCodecInfo.CodecCapabilities, harán lo siguiente:

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

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

• [C-4-1] DEBE utilizar de forma predeterminada el formato de color optimizado para la pantalla de hardware si se configuró con la salida de Surface.
• [C-4-2] DEBE utilizar de forma predeterminada un formato de color YUV420 8:8:8 optimizado para la lectura de CPU si está configurado para no usar resultados de Surface.

5.1.8. Lista de códecs de video

Formato/códec	Detalles	Tipos de archivos/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 se puede buscar) Matroska (.mkv, solo decodificación)
H.265 HEVC	Consulta la sección 5.3 para obtener más información.	MPEG-4 (.mp4) Matroska (.mkv, solo decodificación)
MPEG-2	Perfil principal	MPEG2-TS (.ts, no se puede buscar) 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 información.	WebM (.webm) Matroska (.mkv)
AV1	Consulta las secciones 5.2 y 5.3 para obtener más detalles.	MPEG-4 (.mp4) Matroska (.mkv, solo para decodificación)

5.1.9 Seguridad de códecs multimedia

Las implementaciones del dispositivo DEBEN garantizar el cumplimiento de las funciones de seguridad de códecs multimedia, como se describe a continuación.

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

Si las implementaciones de dispositivos admiten archivos multimedia, sucederá lo siguiente:

• [C-1-1] DEBE admitir códecs multimedia, ya sea a través de las APIs de OMX o Codec 2.0 (o de ambas), como en el Proyecto de código abierto de Android, y no inhabilitar ni eludir las protecciones de seguridad. Específicamente, esto no significa que todos los códecs DEBEN usar la API de OMX o Codec 2.0, solo que la compatibilidad con al menos una de estas APIs DEBE estar disponible y que la compatibilidad con las APIs disponibles DEBE incluir las protecciones de seguridad presentes.
• [C-SR-1] SE RECOMIENDA ENERCMENTE incluir compatibilidad con la API de códec 2.0.

Si las implementaciones de dispositivos no son compatibles con la API de Codec 2.0, sucederá 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 medio (codificador o decodificador) compatible con el dispositivo.
• [C-2-2] Códecs cuyos nombres comienzan con "OMX.google". DEBE basarse en el código fuente de su Proyecto de código abierto de Android.
• [C-SR-2] SE RECOMIENDA ENcarecidamente que los códecs de software OMX se ejecuten en un proceso de códec que no tenga acceso a controladores de hardware que no sean mappers de memoria.

Si las implementaciones de dispositivos admiten la API de Codec 2.0, sucederá lo siguiente:

• [C-3-1] DEBE incluir el códec de software 2.0 correspondiente del Proyecto de código abierto de Android (si está disponible) para cada formato y tipo de medios (codificador o decodificador) compatible con el dispositivo.
• [C-3-2] DEBE alojar los códecs de software 2.0 en el proceso de códecs de software, como se proporciona en el Proyecto de código abierto de Android, para que sea posible otorgar acceso más limitado a los códecs de software.
• [C-3-3] Códecs cuyos nombres comienzan con "c2.android". DEBE basarse en el código fuente de su 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 multimedia, sucederá lo siguiente:

• [C-1-1] DEBE mostrar los valores correctos de la caracterización de códecs multimedia a través de la API de MediaCodecInfo.

En particular:

• [C-1-2] Códecs cuyos nombres comienzan con "OMX". DEBE usar las APIs de OMX y tener nombres que cumplan con los lineamientos de nombres de OMX IL.
• [C-1-3] Códecs cuyos nombres comienzan con "c2". SE DEBE usar la API de Codec 2.0 y tener nombres que cumplan con las pautas de denominación de Codec 2.0 para Android.
• [C-1-4] Códecs cuyos nombres comienzan con "OMX.google." o "c2.android". NO DEBE estar caracterizada como proveedor o con aceleración de hardware.
• [C-1-5] Los códecs que se ejecutan en un proceso de códecs (proveedor o sistema) y que tienen acceso a controladores de hardware distintos de los asignadores o mapeadores de memoria NO DEBEN caracterizarse como exclusivos 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 basan en el código fuente de ese proyecto DEBEN caracterizarse como proveedores.
• [C-1-7] Los códecs que usan aceleración de hardware DEBEN caracterizarse como acelerados por hardware.
• [C-1-8] Los nombres de códecs NO DEBEN ser engañosos. Por ejemplo, los códecs llamados "decodificadores" DEBEN admitir la decodificación, y aquellos con el nombre "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:

• [C-2-1] Todos los códecs de video DEBEN publicar datos de velocidad de fotogramas alcanzables para los siguientes tamaños si son compatibles con el códec:

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p	UHD
Resolución de video	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificador MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (otro)	704 × 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (otro, AV1)	1,408 x 1,152 px (H263) 1280 x 720 px (otro, AV1)	1,920 x 1,080 px (que no sea MPEG4, AV1)	3840 × 2160 px (HEVC, VP9, AV1)

• [C-2-2] Los códecs de video que se caracterizan como acelerados por hardware DEBEN publicar información de puntos de rendimiento. Cada uno DEBE en cada lista todos los puntos de rendimiento estándar admitidos (enumerados 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 de la lista.

5.2 Codificación de videos

Si las implementaciones en dispositivos incluyen una pantalla de pantalla incorporada con una longitud diagonal de al menos 2.5 pulgadas o incluyen un puerto de salida de video o declaran la compatibilidad de una cámara a través de la marca de función android.hardware.camera.any, hacen 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 aplicaciones de terceros.
• SE RECOMIENDA admitir codificadores de video VP8 y H.264, y debe estar disponible para aplicaciones de terceros.

Si las implementaciones de dispositivos admiten cualquiera de los codificadores de video H.264, VP8, VP9 o HEVC y hacen que estén disponibles para aplicaciones de terceros, deben hacer lo siguiente:

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

Si las implementaciones de dispositivos admiten el codificador de video MPEG-4 SP y permiten que esté disponible para apps de terceros, sucederá lo siguiente:

• DEBE admitir tasas de bits configurables de forma dinámica para el codificador compatible.

Si las implementaciones de dispositivos proporcionan codificadores de imagen o video acelerados por hardware y admiten una o más cámaras de hardware conectadas o conectables que se exponen a través de las APIs de android.camera:

• [C-4-1] Todos los codificadores de imagen y video acelerados por hardware DEBEN admitir la codificación de fotogramas de las cámaras de hardware.
• SE RECOMIENDA admitir fotogramas de codificación de las cámaras de hardware a través de todos los codificadores de imagen o video.

Si las implementaciones de dispositivos proporcionan codificación HDR, sucederán lo siguiente:

• [C-SR-1] SE RECOMIENDA ENERGENTE para proporcionar un complemento para que la API de transcodificación sin interrupciones convierta de formato HDR a SDR.

5.2.1 H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y permiten que estén disponibles para apps de terceros, sucederá lo siguiente:

• [C-1-1] DEBE admitir la resolución QCIF (176 x 144) con el perfil de Baseline nivel 45. La resolución SQCIF es opcional.
• SE RECOMIENDA admitir tasas de bits configurables de forma dinámica para el codificador compatible.

5.2.2. H.264

Si las implementaciones de dispositivos admiten el códec H.264, sucederá lo siguiente:

• [C-1-1] DEBE admitir el perfil de Baseline de nivel 3. Sin embargo, la compatibilidad con ASO (ordenamiento de Slices arbitrario), FMO (orden de macrobloqueo flexible) y RS (Slices redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no usen ASO, FMO ni RS para el perfil de Baseline.
• [C-1-2] DEBE admitir los perfiles de codificación de video SD (definición estándar) que se indican en la siguiente tabla.
• SE DEBE admitir el perfil principal de nivel 4.
• SE RECOMIENDA admitir los perfiles de codificación de video HD (alta definición) como se indica en la siguiente tabla.

Si las implementaciones de dispositivos informan la compatibilidad con la codificación H.264 para videos de resolución 720p o 1080p a través de las APIs de contenido multimedia, sucede lo siguiente:

• [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p
Resolución de video	320 × 240 px	720 × 480 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	20 fps	30 fps	30 fps	30 fps
Tasa de bits del video	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3 VP8

Si las implementaciones de dispositivos admiten el códec VP8, harán lo siguiente:

• [C-1-1] DEBE admitir los perfiles de codificación de video SD.
• SE RECOMIENDA admitir los siguientes perfiles de codificación de video HD (alta definición).
• [C-1-2] DEBE admitir la escritura de archivos Matroska WebM.
• SE DEBE proporcionar un códec de hardware VP8 que cumpla con los requisitos de codificación de hardware RTC del proyecto WebM para garantizar una calidad aceptable de los servicios de transmisión de video por Internet y videoconferencia web.

Si las implementaciones de dispositivos informan la compatibilidad con la codificación VP8 para videos de resolución 720p o 1080p a través de las APIs multimedia, sucede lo siguiente:

• [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p
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, harán lo siguiente:

• [C-1-2] DEBE admitir el perfil 0 de nivel 3.
• [C-1-1] DEBE admitir la escritura de archivos Matroska WebM.
• [C-1-3] DEBE generar datos de CodecPrivate.
• SE RECOMIENDA admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
• Se RECOMIENDA [C-SR-1] para admitir los perfiles de decodificación HD, como se indica en la siguiente tabla, si hay un codificador de hardware.

	SD	HD: 720p	HD: 1080 p	UHD
Resolución de video	720 × 480 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
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 contenido multimedia, haz 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, sucederá lo siguiente:

• [C-1-1] DEBE admitir el perfil principal de nivel 3 con una resolución de hasta 512 x 512.
• SE RECOMIENDA admitir los perfiles de codificación HD como se indica en la siguiente tabla.
• Se recomienda [C-SR-1] para admitir 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: 1080 p	UHD
Resolución de video	720 × 480 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3 Decodificación de video

Si las implementaciones de dispositivos admiten códecs VP8, VP9, H.264 o H.265, entonces:

• [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 estándar de Android dentro de la misma transmisión para todos los códecs VP8, VP9, H.264 y H.265 en tiempo real y hasta la resolución máxima admitida por cada códec en el dispositivo.

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2, sucederá lo siguiente:

• [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, sucederá lo siguiente:

• [C-1-1] DEBE ser compatible con el perfil de Baseline nivel 30 (resoluciones CIF, QCIF y SQCIF a 30fps 384 Kbps) y nivel 45 (resoluciones QCIF y SQCIF a 30 fps 128 kbps).

5.3.3. MPEG-4

Si se implementan en dispositivos con decodificadores MPEG-4, sucederá lo siguiente:

• [C-1-1] DEBE admitir un perfil simple de nivel 3.

5.3.4. H.264

Si las implementaciones de dispositivos admiten decodificadores H.264, sucederá lo siguiente:

• [C-1-1] DEBE admitir el perfil principal nivel 3.1 y el perfil de Baseline. La compatibilidad con ASO (ordenamiento de Slices arbitrario), FMO (orden de macrobloqueo flexible) y RS (Slices redundantes) es OPCIONAL.
• [C-1-2] DEBE ser capaz de decodificar videos con los perfiles SD (definición estándar) que se enumeran en la siguiente tabla y codificados con el perfil de Baseline y el perfil principal nivel 3.1 (incluido 720p30).
• SE DEBE poder decodificar videos con los perfiles HD (alta definición) como se indica en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución de video, las implementaciones en dispositivos hacen 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 HD 1080p que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p
Resolución de video	320 × 240 px	720 × 480 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	60 fps	30 FPS (60 FPS Televisión)
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, sucederá lo siguiente:

• [C-1-1] DEBE admitir el nivel principal de perfil principal nivel 3 y los perfiles de decodificación de video SD, como se indica en la siguiente tabla.
• SE RECOMIENDA admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
• [C-1-2] DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla si hay un decodificador de hardware.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del video, entonces:

• [C-2-1] Las implementaciones en dispositivos DEBEN admitir al menos una decodificación H.265 o VP9 de perfiles 720, 1080 y UHD.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p	UHD
Resolución de video	352 × 288 px	720 × 480 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30/60 FPS (60 FPS Televisión con decodificación por hardware H.265)	60 fps
Tasa de bits del video	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones en dispositivos afirman admitir un perfil HDR a través de las APIs de contenido multimedia, haz lo siguiente:

• [C-3-1] Las implementaciones del dispositivo DEBEN aceptar los metadatos de HDR requeridos de la aplicación, así como admitir la extracción y la salida de los metadatos HDR necesarios del flujo de bits o del contenedor.
• [C-3-2] Las implementaciones del dispositivo 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, harán lo siguiente:

• [C-1-1] DEBE admitir los perfiles de decodificación SD en la siguiente tabla.
• SE DEBE usar un códec de hardware VP8 que cumpla con los requisitos.
• SE RECOMIENDA admitir los perfiles de decodificación 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 en dispositivos DEBEN admitir perfiles de 720p en la siguiente tabla.
• [C-2-2] Las implementaciones en dispositivos DEBEN admitir perfiles de 1080p en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p
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 Televisión)	30 (60 FPS Televisión)
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, harán lo siguiente:

• [C-1-1] DEBE admitir los perfiles de decodificación de video SD como se indica en la siguiente tabla.
• SE RECOMIENDA admitir los perfiles de decodificación HD como se indica en la siguiente tabla.

Si las implementaciones de dispositivos admiten el códec VP9 y un decodificador de hardware:

• [C-2-1] DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del video, entonces:

• [C-3-1] Las implementaciones en dispositivos DEBEN admitir al menos una decodificación VP9 o H.265 de los perfiles 720, 1080 y UHD.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p	UHD
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 FPS (60 FPS 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 en dispositivos afirman admitir VP9Profile2 o VP9Profile3 a través de las APIs de contenido multimedia "CodecProfileLevel":

• La compatibilidad con el formato de 12 bits es OPCIONAL.

Si las implementaciones en dispositivos afirman admitir un perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) a través de las APIs de contenido multimedia, haz lo siguiente:

• [C-4-1] Las implementaciones en dispositivos DEBEN aceptar los metadatos de HDR requeridos (KEY_HDR_STATIC_INFO para todos los perfiles HDR, así como 'KEY_HDR10_PLUS_INFO' para los perfiles HDR10Plus) de la aplicación. También DEBEN admitir la extracción y la salida de los metadatos HDR necesarios del flujo de bits o del contenedor.
• [C-4-2] Las implementaciones del dispositivo 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, sucede lo siguiente:

• [C-1-1] DEBE incluir un extractor compatible con Dolby Vision.
• [C-1-2] DEBE mostrar correctamente el contenido de Dolby Vision en la pantalla del dispositivo o en un puerto de salida de video estándar (p.ej., HDMI).
• [C-1-3] DEBE establecer el ID de pista de las capas base retrocompatibles (si están presentes) para que sea el mismo que el ID de pista de la capa combinada de Dolby Vision.

5.3.9. AV1

5.4. Grabación de audio

Si bien algunos de los requisitos descritos en esta sección se enumeran como DEBEN desde Android 4.3, se planea cambiar la definición de compatibilidad para versiones futuras a DEBE. Se RECOMIENDA EJECUTAR que los dispositivos Android existentes y nuevos cumplan con los requisitos que se indican como DEBEN. De lo contrario, no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

5.4.1 Captura de audio sin procesar e información del micrófono

Si las implementaciones de dispositivos declaran android.hardware.microphone, hará lo siguiente:

• [C-1-1] DEBE permitir la captura de contenido de audio sin procesar para cualquier transmisión 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, 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.

• SE RECOMIENDA permitir la captura de contenido de audio sin procesar con las siguientes características:

  • Formato: PCM lineal, 16 bits 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: tantos canales como la cantidad de micrófonos en el dispositivo

• [C-1-2] DEBE capturar con tasas de muestreo superiores sin sobremuestreo.

• [C-1-3] DEBE incluir un filtro de suavizado de contorno adecuado cuando las tasas de muestreo proporcionadas anteriormente se capturan con reducción de muestreo.

• SE RECOMIENDA 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, 48,000 Hz
  • Canales: estéreo

• [C-1-4] DEBE respetar 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 la grabación de audio activa con MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Si las implementaciones de dispositivos permiten la captura con calidad de radio AM y DVD de contenido de audio sin procesar, harán lo siguiente:

• [C-2-1] DEBE capturar sin sobremuestreo en cualquier proporción superior a 16000:22050 o 44100:48000.

• [C-2-2] DEBE incluir un filtro de suavizado de contorno adecuado para cualquier aumento o reducción de muestreo.

5.4.2. Capturar para el reconocimiento de voz

Si las implementaciones de dispositivos declaran android.hardware.microphone, hará lo siguiente:

• [C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION con una de las tasas de muestreo, 44,100 y 48,000.
• [C-1-2] DEBE inhabilitar de forma predeterminada cualquier procesamiento de audio con 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 mostrar características aproximadamente de amplitud frente a frecuencia en el rango de frecuencia media: específicamente de ±3 dB de 100 Hz a 4,000 Hz para cada micrófono utilizado para grabar la fuente de audio de reconocimiento de voz.

• Se recomienda [C-SR-1] para que muestre niveles de amplitud en el rango de baja frecuencia: específicamente de ±20 dB, de 30 Hz a 100 Hz, en comparación con el rango de frecuencia media de cada micrófono utilizado para grabar la fuente de audio de reconocimiento de voz.

• Se RECOMIENDA EL [C-SR-2] para mostrar niveles de amplitud en el rango de alta frecuencia: específicamente de ±30 dB, de 4,000 Hz a 22 KHz, en comparación con el rango de frecuencia media de cada micrófono utilizado para grabar la fuente de audio de reconocimiento de voz.

• SE DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz se reproduzca a un nivel de presión de sonido (SPL) de 90 dB (medido a una distancia de 30 cm de junto al micrófono) que produzca una respuesta ideal de 2,500 RMS en un rango de precisión de 1,770 bits/3,5 B para el micrófono de precisión de ±5 o 2 B para la fuente de reconocimiento de voz flotante de 1,770 y 35 B para cada fuente.

• SE DEBE grabar la transmisión de audio de reconocimiento de voz para que el nivel de amplitud de PCM realice un seguimiento lineal de los cambios de SPL de entrada en un rango de al menos 30 dB, de -18 dB a +12 dB y 90 dB de SPL en el micrófono.

• SE DEBE grabar la transmisión de audio mediante 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 android.hardware.microphone y las tecnologías de supresión (reducción) de ruido se ajustan para el reconocimiento de voz, suceden lo siguiente:

• [C-2-1] DEBE permitir que este efecto de audio se pueda controlar con la API de android.media.audiofx.NoiseSuppressor.
• [C-2-2] DEBE identificar de manera ú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 redireccionamiento de la reproducción

La clase android.media.MediaRecorder.AudioSource incluye la fuente de audio REMOTE_SUBMIX.

Si las implementaciones de dispositivos declaran tanto android.hardware.audio.output como android.hardware.microphone, harán lo siguiente:

• [C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX de modo que, cuando una aplicación use la API de android.media.AudioRecord para grabar desde esta fuente de audio, capture una combinación de todas las transmisiones de audio, excepto las siguientes:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Cancelador de eco acústico

Si las implementaciones de dispositivos declaran android.hardware.microphone, hará lo siguiente:

• SE DEBE implementar una tecnología de cancelador de eco acústico (AEC) ajustada para la comunicación por voz y aplicada a la ruta de captura cuando se realiza una captura con AudioSource.VOICE_COMMUNICATION.

Si las implementaciones en dispositivos proporcionan un cancelador de eco acústico que se inserta en la ruta de acceso de la captura de audio cuando se selecciona AudioSource.VOICE_COMMUNICATION, sucede lo siguiente:

• Los [C-SR-1] tienen la SECCIÓN DE RECOMENDACIÓN StrongLY_RECOMMENDED para declarar esto a través del método de la API AcousticEchoCanceler AcousticEchoCanceler.isAvailable().
• [C-SR-2] son StrongLY_RECOMMENDED para permitir que este efecto de audio se pueda controlar con la API de AcousticEchoCanceler.
• [C-SR-3] están FUERTELY_RECOMMENDED para identificar de manera única cada implementación de tecnología AEC 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:

• [C-1-1] DEBE permitir el acceso simultáneo al micrófono a través de un servicio de accesibilidad que captura con AudioSource.VOICE_RECOGNITION y al menos una captura de aplicación con cualquier AudioSource.
• [C-1-2] DEBE permitir el acceso simultáneo al micrófono por parte de una aplicación preinstalada que tenga una función de Asistente y al menos una aplicación que capture con cualquier AudioSource, excepto AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
• [C-1-3] DEBE silenciar la captura de audio para cualquier otra aplicación, excepto para un servicio de accesibilidad, mientras una aplicación realiza una captura con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Sin embargo, cuando una app realiza una 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 al mismo tiempo y ninguna de ellas tiene una IU en la parte superior, la que comenzó a capturar la más reciente recibe audio.

5.5 Reproducción de audio

Android incluye 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, hará 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):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100 y 48000 en los parámetros de configuración de los canales mencionados anteriormente
    • 96,000 en mono y estéreo

5.5.2. Efectos de audio

Android proporciona una API de efectos de audio para implementaciones en dispositivos.

Si las implementaciones de dispositivos declaran la función android.hardware.audio.output, hará lo siguiente:

• [C-1-1] DEBE admitir las implementaciones EFFECT_TYPE_EQUALIZER y EFFECT_TYPE_LOUDNESS_ENHANCER que se pueden controlar 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 que se puede controlar a través de la subclase de AudioEffect DynamicsProcessing.

• SE DEBE admitir las implementaciones EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER que se pueden controlar a través de las subclases de AudioEffect BassBoost, EnvironmentalReverb, PresetReverb y Virtualizer.
• [C-SR-1] SE RECOMIENDAN IMPORTANTE para admitir efectos en el punto flotante y multicanal.

5.5.3. Volumen de audio saliente

Implementaciones en dispositivos de Automotive:

• SE DEBE permitir ajustar el volumen del audio por separado para cada transmisión de audio con el tipo de contenido o uso, como se define en AudioAttributes y el uso del audio del vehículo, como se define públicamente en android.car.CarAudioManager.

5.5.4. Descarga de audio

Si las implementaciones de dispositivos admiten la reproducción de descarga de audio, sucederá lo siguiente:

• [C-SR-1] SE RECOMIENDA RECOMENDADAMENTE para cortar el contenido de audio sin interrupciones reproducido entre dos clips con el mismo formato cuando lo especifique la API sin espacios de AudioTrack y el contenedor de contenido multimedia para MediaPlayer.

5.6. Latencia de audio

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

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

• latencia de salida. El intervalo entre el momento en que una aplicación escribe una trama de datos codificados en PCM y el momento en que el sonido correspondiente se presenta al entorno en un transductor integrado en el dispositivo o la señal sale del dispositivo a través de un puerto y se puede observar externamente.
• latencia de salida en frío. El tiempo entre el inicio de una transmisión de salida y el tiempo de presentación del primer fotograma según las marcas de tiempo, cuando el sistema de salida de audio estuvo inactivo y apagado antes de la solicitud.
• latencia de salida continua. Es la latencia de salida para los fotogramas posteriores, después de que el dispositivo reproduce audio.
• latencia de entrada. El intervalo entre el momento en que el entorno presenta un sonido al dispositivo a través de un transductor o una señal integrados en el dispositivo, y cuando una aplicación lee la trama correspondiente de datos codificados en PCM.
• entrada perdida. La parte inicial de una señal de entrada que no se puede usar o no está disponible.
• latencia de entrada en frío. El tiempo transcurrido entre el inicio de la transmisión y la recepción del primer fotograma válido, cuando el sistema de entrada de audio estuvo inactivo y se apagó antes de la solicitud.

• latencia de entrada continua. Es la latencia de entrada para los fotogramas posteriores, mientras el dispositivo está capturando audio.

• latencia de ida y vuelta continua. Es la suma de la latencia de entrada continua más la latencia de salida continua más un período de búfer. El período de búfer permite que la app procese la señal y el tiempo para que la app mitigue la diferencia de fase entre las transmisiones de entrada y salida.

• API de cola de búfer PCM de OpenSL ES. Conjunto de APIs de OpenSL ES relacionadas con PCM dentro del NDK de Android.

• API de audio nativo de AAudio. Es el conjunto de las APIs de AAudio dentro del NDK de Android.

• Marca de tiempo: Un par que se compone de una posición relativa de un marco dentro de una transmisión y el tiempo estimado cuando esa trama ingresa o sale de la canalización de procesamiento de audio en el extremo asociado. Consulta también AudioTimestamp.

• falla. Una interrupción temporal o un valor de muestra incorrecto en la señal de audio, por lo general, causada por un desbordamiento del búfer para la salida, el exceso de búfer para la entrada o cualquier otra fuente de ruido digital o analógico.

• desviación absoluta media. Es el promedio del valor absoluto de las desviaciones de la media para un conjunto de valores.

• latencia de toque a tono. El tiempo que transcurre desde que se presiona la pantalla hasta que se escucha en la bocina un tono generado como resultado de ese toque.

Si las implementaciones de dispositivos declaran android.hardware.audio.output, DEBEN cumplir o superar los siguientes requisitos:

• [C-1-1] La marca de tiempo de salida que muestran AudioTrack.getTimestamp y AAudioStream_getTimestamp es precisa en +/- 2 ms.

• [C-1-2] Latencia en frío de salida de 500 milisegundos o menos.

• [C-1-3] Abrir una transmisión de salida con AAudioStreamBuilder_openStream() DEBE tardar menos de 1,000 milisegundos.

Si las implementaciones de dispositivos declaran android.hardware.audio.output, SE RECOMIENDA EJECUTAR que cumplan o superen los siguientes requisitos:

• [C-SR-1] Latencia de salida en frío de 100 milisegundos o menos en la ruta de datos de la bocina.
• [C-SR-2] La latencia de la función de tocar para tono es de 80 milisegundos o menos.

Si las implementaciones de dispositivos cumplen con los requisitos anteriores, después de cualquier calibración inicial cuando se usa la API de audio nativa de AAudio, para obtener latencia de salida continua y latencia de salida en frío en al menos un dispositivo de salida de audio compatible, sucederá lo siguiente:

• [C-SR-5] SE RECOMIENDA ENRENDER informar de audio de baja latencia declarando la marca de función android.hardware.audio.low_latency.
• [C-SR-6] SE RECOMIENDA ENRENDER para cumplir con los requisitos de audio de baja latencia a través de la API de AAudio.
• [C-SR-7] SE RECOMIENDA ENRENDER para garantizar que, en las transmisiones que muestran AAUDIO_PERFORMANCE_MODE_LOW_LATENCY de AAudioStream_getPerformanceMode(), el valor que muestra AAudioStream_getFramesPerBurst() sea menor o igual que el que muestra android.media.AudioManager.getProperty(String) para la clave de propiedad AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Si las implementaciones de dispositivos no cumplen con los requisitos para audio de baja latencia a través de la API de audio nativo de AAudio, sucederá lo siguiente:

• [C-2-1] NO DEBE informar compatibilidad con audio de baja latencia.

Si las implementaciones de dispositivos incluyen android.hardware.microphone, DEBEN cumplir con los siguientes requisitos de audio de entrada:

• [C-3-1] Limita el error en las marcas de tiempo de entrada, como lo muestra AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 2 ms. "Error" aquí hace referencia a la desviación del valor correcto.
• [C-3-2] Latencia en frío de entrada de 500 milisegundos o menos.
• [C-3-3] Abrir una transmisión de entrada con AAudioStreamBuilder_openStream() DEBE tardar menos de 1,000 milisegundos.

Si las implementaciones de dispositivos incluyen android.hardware.microphone, SE RECOMIENDA ENERGMENTE que cumplan con estos requisitos de audio de entrada:

• [C-SR-8] Latencia de entrada en frío de 100 milisegundos o menos en la ruta de acceso a los datos del micrófono.

• [C-SR-11] Limita el error en las marcas de tiempo de entrada, como lo muestra AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

Si las implementaciones de dispositivos declaran android.hardware.audio.output y android.hardware.microphone, hará lo siguiente:

• [C-SR-12] SE RECOMIENDA QUE tengan una latencia media continua continua de 50 milisegundos o menos durante 5 mediciones, con una desviación absoluta media inferior a 10 ms en al menos una ruta admitida.

5.7. Protocolos de red

Las implementaciones en dispositivos DEBEN admitir los protocolos de red multimedia para la reproducción de audio y video, como se especifica en la documentación del SDK de Android.

Para cada códec y formato de contenedor que se requiere para admitir la implementación de un dispositivo, la implementación del dispositivo:

• [C-1-1] DEBE admitir ese códec o contenedor en HTTP y HTTPS.

• [C-1-2] DEBE admitir los formatos de segmentos multimedia correspondientes, como se muestra en la tabla de formatos de segmentos multimedia a continuación sobre el protocolo de borrador de transmisión en vivo HTTP, versión 7.

• [C-1-3] DEBE admitir los formatos de carga útil de RTSP correspondientes, como se muestra en la tabla de RTSP a continuación. Para ver las excepciones, consulta las notas al pie de la tabla de la sección 5.1.

Formatos de segmentos de medios

Formatos de segmentos	Referencias	Compatibilidad con códecs requeridos
MPEG-2 Transport Stream	ISO 13818	Códecs de video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sección 5.1.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 AAC y sus variantes.
AAC con enmarcado ADTS y etiquetas ID3	ISO 13818‐7	Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
WebVTT	WebVTT

RTSP (RTP, SDP)

Nombre del perfil	Referencias	Compatibilidad con códecs requeridos
H264 AVC	RFC 6184	Consulta la sección 5.1.8 para obtener información acerca de H264 AVC.
MP4A-LATM	RFC 6416	Consulta la sección 5.1.3 para obtener detalles sobre 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
MPEG-4-genérico	RFC 3640	Consulta la sección 5.1.3 para obtener detalles sobre AAC y sus variantes
MP2T	RFC 2250	Consulta MPEG-2 Transport Stream debajo de HTTP Live Streaming para obtener más detalles.

5.8. Contenido multimedia seguro

Si las implementaciones de dispositivos admiten salida de video segura y son capaces de admitir plataformas seguras, sucederá lo siguiente:

• [C-1-1] DEBE declarar compatibilidad con Display.FLAG_SECURE.

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y admiten el protocolo de pantalla inalámbrica, harán lo siguiente:

• [C-2-1] SE DEBE asegurar el vínculo 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 admiten pantallas externas con cable, harán lo siguiente:

• [C-3-1] DEBE ser compatible con HDCP 1.2 o superior para todas las pantallas externas conectadas a través de un puerto con cable accesible para el usuario.

5.9 Interfaz digital para instrumentos musicales (MIDI)

Si las implementaciones de dispositivos informan compatibilidad con la función android.software.midi a través de la clase android.content.pm.PackageManager, sucede lo siguiente:

• [C-1-1] DEBE admitir MIDI en todos los transportes de hardware compatibles con MIDI para los que proporcionan conectividad genérica que no es MIDI, en los que estos transportes son:

  • Modo de host USB, sección 7.7
  • Funcionamiento central de MIDI por Bluetooth de bajo consumo (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)

• SE RECOMIENDA admitir el modo periférico MIDI mediante USB (sección 7.7)

5.10. Audio profesional

Si las implementaciones de dispositivos informan compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager, sucede lo siguiente:

• [C-1-1] SE DEBE informar la compatibilidad con la función android.hardware.audio.low_latency.
• [C-1-2] DEBE tener la latencia de audio de ida y vuelta continua, como se define en la sección 5.6 Latencia de audio de 25 milisegundos o menos en al menos una ruta compatible.
• [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 y 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.

• [C-1-8] DEBE tener una latencia promedio de Tono para presionar de 80 milisegundos o menos en al menos 5 mediciones en la ruta de acceso de datos de la bocina al micrófono.

• [C-SR-1] SE RECOMIENDAN ENERGENTE para cumplir con las latencias definidas en la sección 5.6 Latencia de audio, de 20 milisegundos o menos, más de 5 mediciones con una desviación absoluta media inferior a 5 milisegundos en la ruta de acceso de bocina a micrófono.

• [C-SR-2] SE RECOMIENDA ENERGENTE para cumplir con los requisitos del audio Pro para latencia de audio de ida y vuelta continua, latencia de entrada en frío, latencia de salida en frío y requisitos de audio USB mediante la API de audio nativo de AAudio a través de la ruta de acceso de MMAP.

• Los [C-SR-3] SE RECOMIENDEN ENERGÍAMENTE para proporcionar un nivel coherente de rendimiento de la CPU mientras el audio está activo y la carga de la CPU varía. Esto se debe probar con la app para Android SynthMark. SynthMark usa un sintetizador de software que se ejecuta en un framework de audio simulado que mide el rendimiento del sistema. Consulta la documentación de SynthMark para obtener una explicación de las comparativas. La app de SynthMark debe ejecutarse con la opción "Prueba automatizada" y lograr los siguientes resultados:

  • voicemark.90 >= 32 voces
  • latenciamark.fixed.little <= 15 ms
  • latemark.dynamic.little <= 50 ms

• SE DEBE minimizar la imprecisión y la desviación del reloj de audio en relación con la hora estándar.

• SE RECOMIENDA minimizar el desvío del reloj de audio en relación con el CLOCK_MONOTONIC de la CPU cuando ambos están activos.

• SE DEBE minimizar la latencia de audio en los transductores integrados en el dispositivo.

• SE DEBE minimizar la latencia de audio mediante audio digital USB.

• SE RECOMIENDA documentar las mediciones de latencia de audio en todas las rutas de acceso.

• SE DEBE minimizar el jitter en los tiempos de entrada de devolución de llamada de finalización del búfer de audio, ya que esto afecta el porcentaje utilizable del ancho de banda total de la CPU por parte de la devolución de llamada.

• SE DEBE proporcionar cero fallas de audio en condiciones de uso normal con la latencia informada.

• SE DEBE proporcionar una diferencia de latencia entre canales de cero.

• DEBES minimizar la latencia media de MIDI en todos los transportes.

• SE RECOMIENDA minimizar la variabilidad de la latencia MIDI bajo carga (jitter) en todos los transportes.

• DEBERÍAS proporcionar marcas de tiempo MIDI precisas en todos los transportes.

• SE DEBE minimizar el ruido de la señal de audio en los transductores del dispositivo, incluido el período inmediatamente posterior al inicio en frío.

• SE DEBE proporcionar una diferencia de reloj de audio cero entre los lados de entrada y salida de los extremos correspondientes, cuando ambos están activos. Entre los ejemplos de extremos correspondientes, se incluyen la bocina y el micrófono integrados en el dispositivo, o la entrada y salida del conector de audio.

• SE RECOMIENDA administrar las devoluciones de llamada de finalización del búfer de audio para los extremos de entrada y salida de los extremos correspondientes en el mismo subproceso cuando ambos estén activos. Luego, se debe ingresar la devolución de llamada de salida inmediatamente después de la devolución de la devolución de llamada de entrada. Por otro lado, si no es posible manejar las devoluciones de llamada en el mismo subproceso, ingresa la devolución de llamada de salida poco después de ingresar la devolución de llamada de entrada para permitir que la aplicación tenga una sincronización coherente de los lados de entrada y salida.

• Se recomienda minimizar la diferencia de fase entre el almacenamiento en búfer de audio de HAL para los lados de entrada y salida de los puntos finales correspondientes.

• SE DEBE minimizar la latencia táctil.

• SE DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).

Si las implementaciones de dispositivos cumplen con todos los requisitos anteriores, sucederá lo siguiente:

• [C-SR-4] RECOMIENDA QUE informes la compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager.

Si las implementaciones de los dispositivos incluyen un conector de audio de 4 conductores de 3.5 mm, sucede lo siguiente:

• [C-2-1] DEBE tener una latencia media de audio de ida y vuelta continua promedio, como se define en la sección 5.6 Latencia de audio, de 20 milisegundos o menos, más de 5 mediciones con una desviación absoluta media inferior a 5 milisegundos en la ruta del conector de audio usando un llave de bucle invertido de audio.

• [C-SR-5] SE RECOMIENDA ENERCMENTE cumplir con la sección Especificaciones de dispositivo móvil (conector) de la Especificación de auriculares de audio con cable (v1.1).

Si las implementaciones de dispositivos omiten un conector de audio de 3.5 mm de 4 conductores e incluyen puertos USB que admiten el modo de host USB, sucederán lo siguiente:

• [C-3-1] SE DEBE implementar la clase de audio USB.
• [C-3-2] DEBE tener una latencia de audio de ida y vuelta continua media de 25 milisegundos o menos, más de 5 mediciones con una desviación absoluta media inferior a 5 milisegundos en el puerto del modo host USB mediante la clase de audio USB. (se puede medir con un adaptador USB de 3.5 mm y una llave de bucle invertido de audio, o con una interfaz de audio USB con cables de conexión que conectan las entradas a las salidas).
• Los [C-SR-6] se RECOMIENDEN ENCENDERMENTE para admitir una E/S simultánea de hasta 8 canales en cada dirección, una tasa de muestreo de 96 kHz y una profundidad de 24 bits o 32 bits cuando se usan con periféricos de audio USB que también admiten estos requisitos.
• [C-SR-7] SE RECOMIENDA ENERCMENTE cumplir con este grupo de requisitos mediante la API de audio nativo de AAudio a través de la ruta de acceso MMAP.

Si las implementaciones de dispositivos incluyen un puerto HDMI, sucederá lo siguiente:

• SE DEBE admitir la salida en estéreo y en ocho canales a una profundidad de 20 bits o 24 bits y a 192 kHz sin pérdida de profundidad de bits ni remuestreo, en al menos una configuración.

5.11. Captura para contenido sin procesar

Android admite 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 con el ajuste predeterminado de grabación SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si las implementaciones de dispositivos intentan admitir fuentes de audio sin procesar y hacer que estén disponibles para apps de terceros, suceden lo siguiente:

• [C-1-1] SE DEBE informar la compatibilidad a través de la propiedad PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED de android.media.AudioManager.

• [C-1-2] DEBE mostrar características aproximadamente planas de amplitud frente a frecuencia en el rango de frecuencia media: específicamente ±10 dB de 100 Hz a 7,000 Hz para cada micrófono utilizado para grabar la fuente de audio sin procesar.

• [C-1-3] DEBE mostrar niveles de amplitud en el rango de frecuencia baja: específicamente de ±20 dB, de 5 Hz a 100 Hz, en comparación con el rango de frecuencia media de cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

• [C-1-4] DEBE mostrar niveles de amplitud en el rango de frecuencia alta: específicamente de ±30 dB, de 7,000 Hz a 22 KHz, en comparación con el rango de frecuencia media de cada uno de los micrófonos utilizados 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 que se reproduzca a un nivel de presión de sonido (SPL) de 94 dB produzca una respuesta con una RRM de 520 para muestras de 16 bits (o de -36 dB para las muestras de precisión doble o de punto flotante) para cada fuente y cada micrófono no procesado que se use para grabar.

• El [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 usan para grabar la fuente de audio no procesada. mientras que la SNR se mide como la diferencia entre 94 dB de SPL y el SPL equivalente de ruido propio, ponderado A.

• [C-1-7] DEBE tener una distorsión armónica total (THD) inferior al 1% para 1 kHZ a un nivel de entrada SPL de 90 dB en cada micrófono utilizado para grabar la fuente de audio no procesada.

• [C-1-8] No DEBE tener otro procesamiento de señal (p.ej., control automático de ganancia, filtro de paso alto o cancelación de eco) en la ruta que no sea un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:

  • [C-1-9] Si hay procesamiento de señal presente en la arquitectura por algún motivo, se DEBE inhabilitar y generar de manera efectiva un retraso cero o una latencia adicional en la ruta de acceso de la señal.
  • [C-1-10] Si bien el multiplicador de nivel puede estar en la ruta, NO DEBE introducir demora ni latencia en la ruta de acceso de la señal.

Todas las mediciones del SPL se realizan directamente junto al micrófono que se está probando. Para varias configuraciones de micrófono, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone, pero no admiten fuentes de audio sin procesar, sucederá lo siguiente:

• [C-2-1] DEBE mostrar null para el método de la API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), a fin de indicar correctamente la falta de compatibilidad.
• Aún se RECOMIENDA [C-SR-1] para cumplir con la misma cantidad de requisitos de la ruta de acceso de la señal para la fuente de registro no procesada.

5.12. Video HDR

Android 13 admite las tecnologías HDR como se describe en un documento próximo.

Formato de píxeles

Si un decodificador de video anuncia la compatibilidad con COLOR_FormatYUVP010, entonces:

• [C-1-1] DEBE admitir el formato P010 para la lectura de CPU (ImageReader, MediaImage, ByteBuffer). En Android 13, P010 se relaja para permitir el segmento arbitrario para los planos Y y UV.

• [C-1-2] La GPU DEBE poder muestrear el búfer de salida P010 (cuando se lo asigna con el uso de GPU_SAMPLING). Esto permite la composición de GPU y la asignación de tonos personalizados por apps.

Si un decodificador de video indica la compatibilidad con COLOR_Format32bitABGR2101010, sucede lo siguiente:

• [C-2-1] DEBE admitir el formato RGBA_1010102 para la superficie de salida y ser legible por la CPU (salida ByteBuffer).

Si un codificador de video indica que es compatible con COLOR_FormatYUVP010, sucede lo siguiente:

• [C-3-1] DEBE admitir el formato P010 para la entrada de superficie de entrada y capacidad de escritura de CPU (ImageWriter, MediaImage, ByteBuffer).

Si un codificador de video indica que es compatible con COLOR_Format32bitABGR2101010, sucede lo siguiente:

• [C-4-1] DEBE admitir el formato RGBA_1010102 para la superficie de entrada y las entradas que admiten escritura en la CPU (ImageWriter, ByteBuffer). Nota: Los codificadores NO requieren la conversión entre varias curvas de transferencia.

Requisitos de la captura HDR

Para todos los codificadores de video compatibles con perfiles HDR, las implementaciones en dispositivos deben cumplir con lo siguiente:

• [C-5-1] NO DEBE suponer que los metadatos de HDR son precisos. Por ejemplo, el fotograma codificado puede tener píxeles que superan el nivel de luminancia máximo, o el histograma puede no ser representativo del fotograma.

• SE RECOMIENDA agregar metadatos dinámicos de HDR a fin de generar metadatos estáticos de HDR adecuados para transmisiones codificadas, y deben obtenerlos al final de cada sesión de codificación.

Si las implementaciones de dispositivos admiten la captura HDR con las APIs de CamcorderProfile, sucederá lo siguiente:

• [C-6-1] también DEBE admitir la captura HDR 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 compatible.

• [C-6-3] DEBE admitir (como mínimo) la captura HLG.

• [C-6-4] DEBE admitir la escritura de los metadatos HDR (si corresponde a la tecnología HDR) en el archivo de video capturado. Para AV1, HEVC y DolbyVision, esto significa incluir los metadatos en el flujo de bits codificado.

• [C-6-5] DEBE admitir P010 y COLOR_FormatYUVP010.

• [C-6-6] DEBE admitir la asignación de tonos de HDR a SDR en el decodificador acelerado por hardware predeterminado para el perfil capturado. En otras palabras, si un dispositivo puede capturar HDR10+ HEVC, el decodificador HEVC predeterminado DEBE poder decodificar la transmisión capturada en SDR.

Requisitos para la edición HDR

Si las implementaciones de dispositivos incluyen codificadores de video compatibles con la edición HDR, ocurrirá lo siguiente:

• SE DEBE usar una latencia mínima para generar los metadatos de HDR cuando no están presentes y de manejar correctamente 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 real y el histograma del fotograma).

Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, esos códecs:

• [C-7-1] DEBE admitir al menos un perfil HDR.

• [C-7-2] DEBE admitir FEATURE_HdrEditing para todos los perfiles HDR anunciados por ese códec. En otras palabras, DEBEN admitir la generación de metadatos HDR cuando no están presentes para todos los perfiles HDR compatibles que usan metadatos HDR.

• [C-7-3] DEBE admitir los siguientes formatos de entrada de codificador de video que preservan por completo la señal decodificada HDR:

  • RGBA_1010102 (ya en la curva de transferencia de destino) 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 hace lo siguiente:

• [C-7-4] DEBE anunciar compatibilidad con la extensión de OpenGL EXT_YUV_target.

6. Compatibilidad de las Herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con las Herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.

• Android Debug Bridge (adb)

  • [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y los comandos de shell proporcionados en AOSP, que pueden usar los desarrolladores de apps, incluido dumpsys cmd stats
  • [C-0-11] DEBE admitir el comando de shell cmd testharness. La actualización de implementaciones de dispositivos desde una versión anterior de Android sin un bloque de datos persistente PUEDE estar exenta de C-0-11.
  • [C-0-3] NO DEBE alterar el formato ni el contenido de los eventos del sistema del dispositivo (batterystats , discstats, huella digital, graphicsstats, netstats, notification, procstats) registrados con el comando dumpsys.
  • [C-0-10] DEBE registrar, sin omisiones, y hacer que los siguientes eventos sean accesibles y estén disponibles para el comando de shell cmd stats y la clase de API del sistema StatsManager.
    • ActivityForegroundStateChanged
    • Anomalía detectada
    • Informado por rutas de navegación de aplicaciones
    • Falla de la app
    • Inicio de la aplicación
    • Nivel de batería cambiado
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • Cambio de estado de carga
    • ModificaciónDeEstadoDeModoIddeDispositivos.
    • ForegroundServiceStateChanged
    • Modificación del estado del objeto GPSScan
    • Cambio de estado del trabajo
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • Cambio de estado de pantalla
    • Estado de sincronización cambiado
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • Modificación del estado de bloqueo de activación
    • Se produjo la alarma de despertador
    • Modificación del estado de bloqueo de Wi-Fi
    • Wi-FiMulticastLockStateChanged
    • Wi-FiScanStateChanged
  • [C-0-4] DEBE tener el daemon de adb del dispositivo 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 admite adb seguro. adb seguro 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:

  Si las implementaciones de dispositivos sin un puerto USB admiten el modo periférico, sucederá 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 usando 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, harán lo siguiente:

  • [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 e incluyen al menos una cámara, sucederá lo siguiente:

  • [C-5-1] DEBE hacer que el método AdbManager#isAdbWifiQrSupported() devuelva true.

• Servicio Dalvik Debug Monitor (ddms)

  • [C-0-7] DEBE admitir todas las funciones de DDMS, tal como se documenta en el SDK de Android. Dado que ddms usa adb, su compatibilidad DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario activa Android Debug Bridge, como se indicó anteriormente.

• SysTrace

  • [C-0-9] DEBE admitir la herramienta systrace tal como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activarlo.

• Perfetto

  • [C-SR-1] SE RECOMIENDA MUY BIEN exponer un objeto binario /system/bin/perfetto al usuario de shell que cmdline cumple con la documentación de perfetto.
  • [C-SR-2] Se recomienda encarecidamente que el objeto 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 EL FUERTE 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 ENERGMENTE proporcionar, a través del objeto binario perfetto, al menos las fuentes de datos descritas en la documentación de perfetto.

• Optimizador de memoria baja

  • [C-0-12] SE DEBE escribir un Atom LMK_KILL_OCCURRED_FIELD_NUMBER en el registro estadístico cuando el optimizador de poca memoria finaliza una app.

• Modo de agente de prueba Si las implementaciones del dispositivo admiten el comando de shell cmd testharness y ejecutan cmd testharness enable, sucederán lo siguiente:

  • [C-2-1] DEBE devolver true para ActivityManager.isRunningInUserTestHarness().
  • [C-2-2] SE 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 en dispositivos:

  • [C-0-13] SE DEBE implementar el comando de shell dumpsys gpu --gpuwork para mostrar los datos agregados de trabajo de la GPU que muestra el punto de seguimiento del kernel power/gpu_work_period, o no mostrar datos si el punto de seguimiento no es compatible. La implementación del AOSP es frameworks/native/services/gpuservice/gpuwork/.

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o versiones posteriores a través de las marcas de función android.hardware.vulkan.version, sucederán lo siguiente:

• [C-1-1] DEBE proporcionar una indicación visual 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 GPU están habilitadas, enumerar las capas de las bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte de la plataforma o el paquete de la aplicación) que se encuentran en el directorio base de las aplicaciones depurables para admitir los métodos de API vkEnumerateInstanceLayerProperties() y vkCreateInstance().

6.2. Opciones para desarrolladores

Android incluye asistencia para que los desarrolladores configuren la configuración relacionada con el desarrollo de aplicaciones.

Las implementaciones en dispositivos DEBEN proporcionar una experiencia coherente para las Opciones para desarrolladores:

• [C-0-1] DEBE respetar el intent android.settings.APPLICATION_DEVELOPMENT_CONFIGURACIÓN para mostrar la configuración relacionada con el desarrollo de la aplicación. La implementación ascendente de Android oculta el menú Opciones para desarrolladores de forma predeterminada y permite a los usuarios iniciar estas opciones después de presionar siete (7) veces en el elemento de menú Configuración > Acerca del dispositivo > Número de compilación.
• [C-0-2] DEBE ocultar las Opciones para desarrolladores de forma predeterminada.
• [C-0-3] DEBE proporcionar un mecanismo claro que no brinde un tratamiento preferencial a una app de terceros, en lugar de otra, para habilitar las Opciones para desarrolladores. DEBEN proporcionar un documento o sitio web visible público en el que se describa cómo habilitar las Opciones para desarrolladores. Se DEBE poder vincular este documento o sitio web desde los documentos del SDK de Android.
• SE RECOMIENDA tener una notificación visual continua para el usuario cuando las Opciones para desarrolladores están habilitadas y la seguridad del usuario es de interés.
• PUEDE limitar temporalmente el acceso al menú Opciones para desarrolladores, con la opción de ocultar o inhabilitar visualmente el menú, para evitar distracciones en situaciones en las que preocupa la seguridad del usuario.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware en particular que tiene una API correspondiente para desarrolladores externos:

• [C-0-1] La implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android.

Si una API del SDK interactúa con un componente de hardware que se indica como opcional y la implementación del dispositivo no tiene ese componente, haz lo siguiente:

• [C-0-2] Se DEBEN presentar las definiciones completas de las clases (como están documentadas por el SDK) para las APIs del componente.
• [C-0-3] Los comportamientos de la API DEBEN implementarse como no-ops de una forma razonable.
• Los métodos de la API [C-0-4] DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
• Los métodos de API [C-0-5] DEBEN mostrar 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 generar excepciones que no están documentadas en la documentación del SDK.
• [C-0-7] Las implementaciones de dispositivos DEBEN informar de manera coherente información precisa sobre la configuración del 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 sean teléfonos, estas APIs deben implementarse como no-ops razonables.

7.1. Pantalla y gráficos

Android incluye instalaciones que ajustan automáticamente los recursos de la aplicación y los diseños de la IU de manera adecuada para el dispositivo a fin de garantizar que las aplicaciones de terceros se ejecuten bien en una variedad de configuraciones de hardware. diversas pantallas y configuraciones de hardware. Una pantalla compatible con Android es aquella que implementa todos los comportamientos y las APIs que se describen en Android Developers: Descripción general de la compatibilidad de pantalla, esta sección (7.1) y sus subsecciones, así como cualquier comportamiento adicional específico por tipo de dispositivo documentado en la sección 2 de este CDD. En las pantallas compatibles con Android, donde se pueden ejecutar todas las aplicaciones de terceros compatibles con Android, las implementaciones en dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

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

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

7.1.1 Configuración de pantalla

7.1.1.1. Tamaño y forma de la pantalla

El framework de la IU de Android admite varios 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 en 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 en dispositivos DEBEN informar las dimensiones de pantalla correctas de píxeles independientes de la densidad (dp) lógica como se muestra a continuación:

  • Los dispositivos con Configuration.uiMode configurado como cualquier valor distinto de UI_MODE_TYPE_WATCH y que informan un tamaño de small para Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
  • Los dispositivos que informan un tamaño de normal para Configuration.screenLayout DEBEN tener al menos 480 dp x 320 dp.
  • Los dispositivos que informan un tamaño de large para Configuration.screenLayout DEBEN tener al menos 640 dp x 480 dp.
  • Los dispositivos que informan un tamaño de xlarge para Configuration.screenLayout DEBEN tener al menos 960 dp x 720 dp.

• [C-0-2] DEBE respetar correctamente la compatibilidad indicada en las aplicaciones con los tamaños de pantalla a través del atributo <supports-screens> en el 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 realizar la configuración de tamaño UI_MODE_TYPE_NORMAL e incluyen pantallas físicas compatibles con Android con esquinas redondeadas para renderizar estas pantallas, sucederán lo siguiente:

• [C-1-1] DEBE asegurarse de que se cumpla al menos uno de los siguientes requisitos para cada pantalla:

  • El radio de las esquinas redondeadas es menor o igual que 38 dp.
  • Cuando se ancla un 15un cuadro de 18 dp por 1518 dp en cada esquina de la pantalla lógica, se puede ver al menos un píxel de cada cuadro en la pantalla.

• SE DEBE incluir la indicación visual del usuario para cambiar al modo de visualización con las esquinas rectangulares.

Para obtener detalles sobre la implementación correcta de las APIs de sidecar o de extensión, consulta la documentación pública de Window Manager Jetpack.

7.1.1.3. Densidad de la pantalla

El framework de la IU de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientarse a los recursos de la aplicación.

Implementaciones en dispositivos:

• [C-0-1] De forma predeterminada, las implementaciones en dispositivos DEBEN informar solo una de las densidades del framework de Android que se indican en DisplayMetrics a través de la API de DENSITY_DEVICE_STABLE, y este valor debe ser un valor estático para cada pantalla física. NO DEBE cambiar en ningún momento. Sin embargo, Sin embargo el dispositivo PUEDE informar una densidad arbitraria DisplayMetrics.density según los cambios en la configuración de pantalla que realice el usuario (por ejemplo, el tamaño de pantalla) establecidos después del inicio inicial.

Si las implementaciones en dispositivos proporcionan hay una posibilidad de cambiar el tamaño de la pantalla del dispositivo , estas deben:

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

7.1.2. Métricas de Display

Si las implementaciones de dispositivos incluyen pantallas o salidas de video compatibles con Android en esas pantallas, sucede lo siguiente:

• [C-1-1] DEBE informar los valores correctos para todas las métricas de pantalla compatibles con Android definidas en la API de android.util.DisplayMetrics.

Si las implementaciones en dispositivos no incluyen una pantalla incorporada o una salida de video, harán lo siguiente:

• [C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android, según se define en la API de android.util.DisplayMetrics para el view.Display predeterminado emulado.

7.1.3 Orientación de pantalla

Implementaciones en dispositivos:

• [C-0-1] DEBE informar qué orientaciones de pantalla admiten (android.hardware.screen.portrait o android.hardware.screen.landscape) y DEBE informar, al menos, una orientación compatible. Por ejemplo, un dispositivo con una pantalla horizontal con orientación fija, como una televisión o una laptop, solo DEBE informar android.hardware.screen.landscape.
• [C-0-2] SE DEBE informar el valor correcto para la orientación actual del dispositivo, siempre que se realice una consulta a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() o alguna otra API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla, sucederá lo siguiente:

• [C-1-1] DEBE admitir la orientación dinámica de las aplicaciones a la orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación respecto de una orientación de pantalla específica.
• [C-1-2] NO DEBE cambiar la densidad o el tamaño de pantalla informados cuando se cambia la orientación.
• PUEDES seleccionar la orientación vertical u horizontal como opción predeterminada.

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

7.1.4.1 OpenGL ES

Implementaciones en dispositivos:

• [C-0-1] DEBE identificar correctamente las versiones de OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) a través de las APIs administradas (por ejemplo, a través del método GLES10.getString()) y las APIs nativas.
• [C-0-2] DEBE incluir compatibilidad con todas las APIs administradas y APIs nativas correspondientes para cada versión de OpenGL ES que identificó como compatible.

Si las implementaciones en dispositivos incluyen una salida de pantalla o de video, sucederá lo siguiente:

• [C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, tal como se detalla en la documentación del SDK de Android.
• [C-SR-1] SE RECOMIENDA ENcarecidamente que sean compatibles con OpenGL ES 3.1.
• SE DEBE admitir OpenGL ES 3.2.

Las pruebas dEQP de OpenGL ES se dividen en varias listas de prueba, 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-main-YYYY-MM-DD.txt. Si un dispositivo admite OpenGL ES en un nivel autoinformado, significa que puede pasar las pruebas de dEQP en todas las listas de prueba de este nivel y de versiones anteriores.

Si las implementaciones de dispositivos admiten alguna de las versiones de OpenGL ES, sucederá lo siguiente:

• [C-2-1] SE DEBE informar a través de las APIs nativas y las APIs administradas de OpenGL ES sobre cualquier otra extensión de OpenGL ES que hayan implementado. Por el contrario, NO DEBE informar las cadenas de extensión que no admiten.
• [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] SE DEBE informar la versión máxima de las pruebas dEQP de OpenGL ES compatibles con la marca de función android.software.opengles.deqp.level.
• [C-2-4] DEBE al menos admitir la versión 132383489 (del 1 de marzo de 2020), como se informa en la marca de función android.software.opengles.deqp.level.
• [C-2-5] DEBE superar todas las pruebas de dEQP de OpenGL ES en las listas de prueba 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 compatible de OpenGL ES.
• [C-SR-2] SE RECOMIENDA COMPLETAMENTE ser compatible con las extensiones EGL_KHR_partial_update y OES_EGL_image_external.

• SE RECOMIENDA 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.

• SE RECOMIENDA 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, suceden lo siguiente:

• [C-3-1] DEBE exportar los símbolos de función correspondientes a estas versiones, además de los símbolos de función OpenGL ES 2.0 en la biblioteca libGLESv2.so.
• [C-SR-3] Se RECOMIENDA ENERGMENTE para admitir la extensión OES_EGL_image_external_essl3.

Si las implementaciones de dispositivos admiten OpenGL ES 3.2, sucederán lo siguiente:

• [C-4-1] DEBE admitir el paquete de extensiones de Android para OpenGL ES en su totalidad.

Si las implementaciones de dispositivos admiten el Android Extension Pack de OpenGL ES en su totalidad, sucederá lo siguiente:

• [C-5-1] SE DEBE identificar la compatibilidad a través de la marca de función android.hardware.opengles.aep.

Si las implementaciones de dispositivos exponen la compatibilidad con la extensión EGL_KHR_mutable_render_buffer, harán lo siguiente:

• [C-6-1] también DEBE admitir la extensión EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android admite Vulkan, una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento.

Si las implementaciones de dispositivos admiten OpenGL ES 3.1, sucederán 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 en dispositivos incluyen una salida de pantalla o de video, sucederá lo siguiente:

• [C-SR-2] SE RECOMIENDA ENcarecidamente incluir compatibilidad con Vulkan 1.3.

Las pruebas de dEQP de Vulkan se dividen en varias listas de prueba, 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-main-YYYY-MM-DD.txt. Si un dispositivo admite Vulkan en un nivel autoinformado, significa que puede pasar las pruebas de dEQP en todas las listas de prueba de este nivel y de versiones anteriores.

Si las implementaciones en dispositivos incluyen compatibilidad con Vulkan 1.0 o versiones posteriores, sucede lo siguiente:

• [C-1-1] SE DEBE informar el valor de número entero correcto con las marcas de función android.hardware.vulkan.level y android.hardware.vulkan.version.
• [C-1-2] SE DEBE enumerar, al menos, un VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] SE DEBE implementar por completo las APIs de Vulkan 1.0 Vulkan 1.1 para cada VkPhysicalDevice enumerado.
• [C-1-4] SE DEBE enumerar las capas que se encuentran 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 aplicación ni proporcionar otras formas de hacer un seguimiento 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 en true .
• [C-1-6] DEBE informar todas las cadenas de extensión que sí admiten a través de las APIs nativas de Vulkan. Por el contrario , NO DEBE informar cadenas de extensión que no admiten correctamente.
• [C-1-7] DEBE admitir las extensiones VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain y VK_KHR_incremental_present.
• [C-1-8] SE DEBE informar la versión máxima de las pruebas de dEQP de Vulkan compatibles con la marca de función android.software.vulkan.deqp.level.
• [C-1-9] DEBE al menos admitir 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 superar todas las pruebas de dEQP de Vulkan en las listas de prueba 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 mencionar 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 ENERGENTE para admitir las extensiones VK_KHR_driver_properties y VK_GOOGLE_display_timing.

• [C-1-12] NO DEBE mencionar la compatibilidad con la extensión VK_KHR_performance_query.

• [C-SR-4] SE RECOMIENDEN ENERGMENTE para cumplir con los requisitos especificados en el perfil de Android Baseline 2022.

Si las implementaciones en dispositivos no incluyen compatibilidad con Vulkan 1.0, sucederá lo siguiente:

• [C-2-1] NO DEBE declarar ninguna de las marcas de función 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 función de Vulkan que se describen aquí , sucede lo siguiente:

• [C-3-1] DEBE exponer compatibilidad con los tipos de controlador y semáforo externo SYNC_FD, además de la extensión VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Las implementaciones en dispositivos DEBEN admitir Android RenderScript, como se detalla en la documentación del SDK de Android.

7.1.4.4 Aceleración de gráficos 2D

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

Implementaciones en dispositivos:

• [C-0-1] SE 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 mostrar un comportamiento coherente con la documentación del SDK de Android sobre aceleración de hardware.

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas de OpenGL ES con aceleración de hardware como objetivos de renderización en una jerarquía de IU.

Implementaciones en dispositivos:

• [C-0-3] DEBE admitir la API de TextureView y DEBE exhibir un comportamiento coherente con la implementación ascendente de Android.

7.1.4.5 Pantallas de amplia gama

Si las implementaciones de dispositivos afirman ser compatibles con pantallas de amplia gama a través de Configuration.isScreenWideColorGamut() , sucede lo siguiente:

• [C-1-1] DEBE tener una pantalla con calibración de color.
• [C-1-2] DEBE tener una pantalla cuyo gamut cubra toda la gama de colores sRGB en el espacio xyY de CIE 1931.
• [C-1-3] DEBE tener una pantalla cuyo gamut tenga un área de al menos el 90% de DCI-P3 en el espacio xyY de CIE 1931.
• [C-1-4] SE DEBE admitir OpenGL ES 3.1 o 3.2, y se debe informar 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 RECOMIENDA ENERGENTE para admitir GL_EXT_sRGB.

Por el contrario, si las implementaciones de dispositivos no admiten pantallas de amplia gama, sucederá lo siguiente:

• [C-2-1] SE DEBE cubrir el 100% o más de sRGB en el espacio xyY de CIE 1931, aunque el gamut de colores de la pantalla no está definido.

7.1.5 Modo de compatibilidad de 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 aplicaciones heredadas no desarrolladas para versiones anteriores de Android que son anteriores a la independencia del tamaño de la 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 en este documento.

Todas las pantallas compatibles con Android de una implementación de dispositivo:

• [C-0-1] DEBE ser capaz de renderizar gráficos de colores de 16 bits.
• SE RECOMIENDA admitir pantallas que admitan gráficos de color de 24 bits.
• [C-0-2] DEBE ser capaz de renderizar animaciones.
• [C-0-3] DEBE tener una relación de aspecto de píxeles (PAR) de entre 0.9 y 1.15. Es decir, la relación de aspecto de los píxeles DEBE ser cercana al cuadrado (1.0) con una tolerancia del 10% al 15%.

7.1.7 Pantallas secundarias

Android admite pantallas secundarias compatibles con Android para habilitar las capacidades de uso compartido de contenido multimedia y APIs de desarrolladores para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa, ya sea a través de una conexión de pantalla con cable, inalámbrica o una adicional incorporada, sucederá lo siguiente:

• [C-1-1] SE 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 en dispositivos:

• [C-0-1] DEBE incluir un mecanismo de entrada, como una pantalla táctil o navegación no táctil, para navegar entre los elementos de la IU.

7.2.1. Teclado

Si las implementaciones de dispositivos incluyen compatibilidad con aplicaciones de terceros del Editor de método de entrada (IME), sucederá lo siguiente:

• [C-1-1] DEBE declarar la marca de función android.software.input_methods.
• [C-1-2] DEBE implementar completamente Input Management Framework
• [C-1-3] DEBE tener un teclado en pantalla preinstalado.

Implementaciones en 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.tecla (QWERTY o teclas de 12 teclas).
• SE RECOMIENDA incluir implementaciones adicionales de teclado en pantalla.
• PUEDE incluir un teclado de hardware.

7.2.2. Navegación no táctil

Android incluye compatibilidad con pad direccional, bola de seguimiento y rueda como mecanismos de navegación no táctil.

Implementaciones en dispositivos:

• [C-0-1] DEBE informar el valor correcto para android.content.res.Configuration.navigation.

Si las implementaciones de dispositivos no tienen navegaciones no táctiles, sucede lo siguiente:

• [C-1-1] DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición de texto, compatible con motores de administración de entradas. La implementación ascendente de código abierto de Android incluye un mecanismo de selección adecuado para dispositivos que carecen de entradas de navegación no táctiles.

7.2.3. Teclas de navegación

Las funciones Inicio, Recientes y Atrás, que se suelen proporcionar mediante la 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, son implementaciones en dispositivos:

• [C-0-1] DEBE proporcionar una indicación visual de usuario para iniciar aplicaciones instaladas que tienen una actividad con el <intent-filter> establecido con ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para implementaciones de dispositivos de televisión. La función Inicio DEBE ser el mecanismo de esta indicación del usuario.
• SE DEBE proporcionar botones para las funciones Recientes y Atrás.

Si se proporcionan las funciones Inicio, Recientes o Atrás, significan lo siguiente:

• [C-1-1] DEBE ser accesible con una sola acción (p.ej., tocar, hacer doble clic o gesto) cuando se puede acceder a cualquiera de ellas.
• [C-1-2] DEBE proporcionar una indicación clara de qué acción activaría cada función. Tener un ícono visible impreso en el botón, mostrar un ícono de software en la parte de la barra de navegación de la pantalla o guiar al usuario a través de un flujo de demostración guiado paso a paso durante la experiencia de configuración lista para usar son ejemplos de esta indicación.

Implementaciones en dispositivos:

• Se RECOMIENDA [C-SR-1] no proporcionar el mecanismo de entrada para la función de menú, ya que dejó de estar disponible y se reemplazó por la barra de acciones desde Android 4.0.

• [C-SR-2] SON RECOMENDADAS EN VEZ para 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., ir a la página principal, volver, etc.) si el deslizamiento no se libera más allá de un umbral determinado.

Si las implementaciones de dispositivos proporcionan la función Menú, sucederá lo siguiente:

• [C-2-1] SE DEBE mostrar el botón de menú ampliado de acciones cada vez 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 ampliación de acciones que se muestra seleccionando el botón de menú ampliado en la barra de acciones, pero PUEDE renderizarla en una posición modificada de la pantalla cuando se muestra seleccionando la función Menú.

Si las implementaciones de dispositivos no proporcionan la función Menú, para la retrocompatibilidad, deben hacer lo siguiente: * [C-3-1] DEBEN hacer que la función Menú esté disponible para las aplicaciones cuando targetSdkVersion sea inferior a 10, ya sea mediante un botón físico, una tecla de software o gestos. Se debe poder acceder a esta función de menú, a menos que esté oculta junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función Assist, hacen lo siguiente:

• [C-4-1] DEBE hacer que la función Assist sea accesible con una sola acción (p.ej., presionar, hacer doble clic o gesto) cuando otras teclas de navegación están disponibles.
• [C-SR-3] SE RECOMIENDA ENcarecidamente mantener presionada la función INICIO debido a esta interacción designada.

Si las implementaciones de dispositivos usan una parte distinta de la pantalla para mostrar las teclas de navegación, harán lo siguiente:

• [C-5-1] Las teclas de navegación DEBEN usar una parte distinta de la pantalla, no están disponibles para las aplicaciones, y NO DEBEN oscurecer ni interferir de ninguna otra manera la parte de la pantalla disponible para las aplicaciones.
• [C-5-2] DEBE poner una parte de la pantalla a disposición de las aplicaciones que cumplan con los requisitos definidos en la sección 7.1.1.
• [C-5-3] DEBE respetar las marcas establecidas por la app a través del método de la API View.setSystemUiVisibility(), de modo que esta parte distinta de la pantalla (también conocida como barra de navegación) esté oculta 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:

• [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 DEBEN ser interceptados para la función de navegación, siempre que el rectángulo de exclusión esté permitido dentro del límite de exclusión máximo especificado en la documentación de View#setSystemGestureExclusionRects().
• [C-6-3] DEBE enviar un evento MotionEvent.ACTION_CANCEL a la app en primer plano una vez que comiencen a interceptarse los toques para un gesto del sistema, si la app en primer plano ya envió un evento MotionEvent.ACTION_DOWN.
• [C-6-4] DEBE proporcionar una indicación visual del usuario para cambiar a una navegación en pantalla basada en botones (por ejemplo, en Configuración).
• SE DEBE proporcionar la función de inicio deslizando el dedo hacia arriba desde el borde inferior de la orientación actual de la pantalla.
• SE DEBE proporcionar la función Recientes al deslizar hacia arriba y mantener presionado antes de soltar, desde la misma área que el gesto de la pantalla principal.
• Los gestos que comienzan en WindowInsets#getMandatorySystemGestureInsets() NO DEBEN verse afectados por los rectángulos de exclusión proporcionados por la aplicación en primer plano a través de View#setSystemGestureExclusionRects().

Si se proporciona una función de navegación desde cualquier parte de los bordes izquierdo y derecho de la orientación actual de la pantalla, ocurrirá lo siguiente:

• [C-7-1] La función de navegación DEBE estar 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 deslizables personalizados 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, si arrastras hacia adentro, se invocarán los paneles mencionados anteriormente y, por lo tanto, no se hará Atrás. Un usuario PUEDE configurar un panel del sistema de modo que quede debajo del 1/3 de la parte superior del borde 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 los objetos View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPEAOSP, que se implementa en el SDK de las marcas de borde, deslizando el dedo desde el borde.
• [C-7-4] Cuando la app en primer plano tiene los objetos View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowsInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPEms.

Si se proporciona la función de navegación hacia atrás y el usuario cancela el gesto de retroceso, entonces:

• [C-8-1] Se DEBE llamar a OnBackInvokedCallback.onBackCancelled().
• [C-8-2] NO SE DEBE llamar a OnBackInvokedCallback.onBackInvoked().
• [C-8-3] NO 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 sugiere que el usuario regresa, como se indica en AOSP.

Si las implementaciones del dispositivo proporcionan compatibilidad con la API del sistema setNavBarMode para permitir que cualquier app del sistema con el permiso android.permission.STATUS_BAR configure el modo de barra de navegación, sucederá lo siguiente:

• [C-9-1] DEBE admitir íconos aptos para niños o navegación basada en botones, como se proporciona en el código del AOSP.

7.2.4. Entrada de pantalla táctil

Android admite una variedad de sistemas de entrada de puntero, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basados en pantallas táctiles se asocian con una pantalla de modo que el usuario tenga la impresión de manipular elementos directamente en la pantalla. Como el usuario está tocando directamente la pantalla, el sistema no requiere ninguna indicación adicional para indicar los objetos que se manipulan.

Implementaciones en dispositivos:

• SE RECOMIENDA tener algún tipo de sistema de entrada de puntero (ya sea similar al de un mouse o táctil).
• SE RECOMIENDA admitir punteros con seguimiento independiente en su totalidad.

Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor) en una pantalla principal compatible con Android, sucederá lo siguiente:

• [C-1-1] SE DEBE informar TOUCHSCREEN_FINGER para el campo de la API Configuration.touchscreen.
• [C-1-2] SE DEBE informar las marcas de función android.hardware.touchscreen y android.hardware.faketouch.

Si las implementaciones de dispositivos incluyen una pantalla táctil que puede rastrear más de un toque en una pantalla principal compatible con Android, sucederá lo siguiente:

• [C-2-1] DEBE informar las marcas de función correspondientes android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondientes 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 bola de seguimiento (es decir, que no toque directamente la pantalla) para la entrada en una pantalla principal compatible con Android y cumplen con los requisitos táctiles falsos de la sección 7.2.5, sucede lo siguiente:

• [C-3-1] NO DEBE informar ninguna marca de función que comience con android.hardware.touchscreen.
• [C-3-2] DEBE informar solo android.hardware.faketouch.
• [C-3-3] SE DEBE informar TOUCHSCREEN_NOTOUCH para el campo de API Configuration.touchscreen.

7.2.5. Entrada táctil falsa

La interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un subconjunto de capacidades de pantalla táctil. Por ejemplo, un mouse o un control remoto que controla un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o enfoque y, luego, haga clic. Varios dispositivos de entrada, como el mouse, el panel táctil, el mouse basado en el giroscopio, el puntero giroscópico, el joystick y el panel táctil multitáctil, pueden admitir interacciones táctiles falsas. Android incluye la función constante android.hardware.faketouch, que corresponde a un dispositivo de entrada no táctil de alta fidelidad (basado en el puntero), como un mouse o un panel táctil que puede emular de forma adecuada una entrada táctil (incluida la compatibilidad básica con gestos), e indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil.

Si las implementaciones del dispositivo no incluyen una pantalla táctil, pero sí otro sistema de entrada de puntero que quieren que esté disponible, sucede lo siguiente:

• SE DEBE declarar la compatibilidad con la marca de función android.hardware.faketouch.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch, sucede lo siguiente:

• [C-1-1] DEBE informar las posiciones X e Y absolutas de la pantalla de la ubicación del puntero y mostrar un puntero visual en la pantalla.
• [C-1-2] DEBE informar un evento táctil con el código de acción que especifica el cambio de estado que se produce cuando el puntero hacia abajo o hacia arriba en la pantalla.
• [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios emular el toque en un objeto en pantalla.
• [C-1-4] DEBE admitir puntero hacia abajo, puntero hacia arriba, puntero hacia abajo y, luego, puntero hacia arriba en el mismo lugar de un objeto en la pantalla dentro de un umbral de tiempo, lo que permite a los usuarios emular presionar dos veces en un objeto en pantalla.
• [C-1-5] DEBE admitir el puntero hacia abajo en un punto arbitrario de la pantalla; el puntero se mueve a cualquier otro punto arbitrario en la pantalla, seguido de un puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
• [C-1-6] DEBE admitir el puntero hacia abajo y, luego, permitir a los usuarios mover rápidamente el objeto a una posición diferente en la pantalla y, luego, apuntar hacia arriba en la pantalla, lo que permite a los usuarios desplazar un objeto en la pantalla.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct, hacen lo siguiente:

• [C-2-1] DEBE declarar 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, hacen lo siguiente:

• [C-3-1] DEBE declarar compatibilidad con android.hardware.faketouch.
• [C-3-2] DEBE admitir un seguimiento distinto de 5 (seguimiento de una mano de dedos) o más entradas del puntero de forma completamente independiente.

7.2.6. Compatibilidad con controles de juegos

7.2.6.1. Asignaciones de botones

Implementaciones en dispositivos:

• [C-1-1] DEBE ser capaz de asignar eventos HID a las constantes InputEvent correspondientes, como se indica en las siguientes tablas. La implementación ascendente de Android cumple con 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 enumerados en las siguientes tablas, sucederá lo siguiente:

• [C-2-1] SE DEBE declarar la marca de función android.hardware.gamepad.

Botón	Uso de HID2	Botón de Android
R1	0x09 0x0001.	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x090x0004.	KEYCODE_BUTTON_X (99)
A1	0x090x0005.	KEYCODE_BUTTON_Y (100)
Pad direccional arriba1 Pad direccional abajo1	0x01 0x00393	AXIS_HAT_Y4
Pad direccional izquierdo1 Pad direccional derecho1	0x01 0x00393	AXIS_HAT_X4
Botón del hombro izquierdo1	0x090x0007.	KEYCODE_BUTTON_L1 (102)
Botón del hombro derecho1	0x09 0x0008.	KEYCODE_BUTTON_R1 (103)
Clic con la palanca izquierda1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic derecho1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Atrás1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores deben declararse en una AC de control de juegos (0x01 0x0005).

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

4 MotionEvent

Controles analógicos1	Uso de HID	Botón de Android
Activador izquierdo	0x02 0x00C5	AXIS_LTRIGGER
Activador derecho	0x02 0x00C4	AXIS_RTRIGGER
Joystick izquierdo	0x01 0x0030 0x01 0x0031	AXIS_X 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 los dispositivos.

7.3 Sensores

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, la implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android y en la documentación de código abierto de Android sobre sensors.

Implementaciones en 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 mostrar una lista precisa de los sensores compatibles mediante SensorManager.getSensorList() y métodos similares.
• [C-0-3] DEBE comportarse de manera razonable para todas las demás APIs de sensores (por ejemplo, mostrar true o false según corresponda cuando las aplicaciones intentan registrar objetos de escucha, no llamando a objetos de escucha de sensores cuando los sensores correspondientes no están presentes, etc.).

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, hacen lo siguiente:

• [C-1-1] DEBE informar todas las mediciones de los sensores con los valores relevantes del Sistema Internacional de Unidades (métricas) para cada tipo de sensor, como se define en la documentación del SDK de Android.
• [C-1-2] DEBE informar los datos del sensor con una latencia máxima de 100 milisegundos + 2 × sample_time para la transmisión de un sensor con una latencia solicitada máxima de 0 ms cuando el procesador de la aplicación está activo. Esta demora no incluye ninguna demora en el filtrado.
• [C-1-3] DEBE informar la primera muestra del sensor dentro de los 400 milisegundos + 2 * sample_time del sensor que se está activando. La exactitud aceptable de esta muestra es 0.
• [C-1-4] Para que cualquier API indicada en la documentación del SDK de Android sea un sensor continuo, las implementaciones del dispositivo DEBEN proporcionar continuamente muestras de datos periódicas que DEBEN tener un Jitter inferior al 3%, en el que el Jitter se define como la desviación estándar de la diferencia de los valores de marca de tiempo informados entre eventos consecutivos.
• [C-1-5] DEBE asegurarse de que la transmisión de eventos del sensor NO DEBE evitar que la CPU del dispositivo entre en un estado de suspensión o se active de un estado de suspensión.
• [C-1-6] DEBE informar el tiempo del evento en nanosegundos, como se define en la documentación del SDK de Android, que representa la hora en que ocurrió el evento y se sincronizó con el reloj SystemClock.elapsedRealtimeNano().
• [C-SR-1] SE RECOMIENDA QUE tengan un error de sincronización de marca de tiempo inferior a 100 milisegundos y SE DEBE tener un error de sincronización de marca de tiempo inferior a 1 milisegundo.
• Cuando se activan varios sensores, el consumo de energía NO DEBE superar la suma del consumo de energía informado del sensor individual.

La lista anterior no es exhaustiva. Se debe considerar que el comportamiento documentado del SDK de Android y las Documentación de código abierto de Android sobre sensors sean confiables.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, hacen lo siguiente:

• [C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores e informar el valor a través del método Sensor.getResolution() de la API.

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 en dispositivos:

• SE DEBE implementar estos tipos de sensores cuando incluyen los sensores físicos necesarios, como se describe en tipos de sensores.

Si las implementaciones de dispositivos incluyen un sensor compuesto, sucederá lo siguiente:

• [C-2-1] SE DEBE implementar el sensor como se describe en la documentación de código abierto de Android sobre sensores compuestos.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos y el sensor solo informa un valor, las implementaciones del dispositivo hacen lo siguiente:

• [C-3-1] DEBE establecer la resolución del sensor en 1 y, luego, informar el valor a través del método Sensor.getResolution() de la API.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor está expuesto a desarrolladores externos, se debe hacer lo siguiente:

• [C-4-1] NO DEBE incluir ningún parámetro de calibración fijo determinado de fábrica en los datos proporcionados.

Si las implementaciones de dispositivos incluyen una combinación de un acelerómetro de 3 ejes, un sensor de giroscopio de 3 ejes o un sensor magnetómetro, son las siguientes:

• [C-SR-2] SE RECOMIENDA ENRENDIDAMENTE para garantizar que el acelerómetro, el giroscopio y el magnetómetro tengan una posición relativa fija, de modo que, si el dispositivo es transformador (p.ej., plegable), los ejes de los sensores permanezcan alineados y coherentes con el sistema de coordenadas del sensor en todos los estados posibles de transformación del dispositivo.

7.3.1. Acelerómetro

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones en dispositivos incluyen un acelerómetro, ocurrirá lo siguiente:

• [C-1-1] DEBE ser capaz de 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 ser capaz de medir desde una caída libre hasta cuatro veces la gravedad(4g) o más en cualquier eje.
• [C-1-5] DEBE tener una resolución de al menos 12 bits.
• [C-1-6] DEBE tener una desviación estándar no superior a 0.05 m/s^, en la que la desviación estándar debe calcularse por eje en las muestras recopiladas durante un período de al menos 3 segundos a la tasa de muestreo más rápida.
• SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.
• DEBE tener una resolución de al menos 16 bits.
• SE DEBE calibrar mientras está en uso si las características cambian durante el ciclo de vida y se compensan, y se conservan los parámetros de compensación entre los reinicios del dispositivo.
• SE DEBE compensar la temperatura.

Si las implementaciones en dispositivos incluyen un acelerómetro de 3 ejes, sucederá lo siguiente:

• [C-2-1] SE DEBE implementar e informar el sensor TYPE_ACCELEROMETER.
• [C-SR-4] SE RECOMIENDA COMPLETAMENTE implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION.
• [C-SR-5] SE RECOMIENDA COMPLETAMENTE implementar y, luego, informar el sensor TYPE_ACCELEROMETER_UNCALIBRATED. SE RECOMIENDA QUE los dispositivos Android cumplan con este requisito para que puedan actualizarse a la versión futura de la plataforma, en la que esto podría ser OBLIGATORIO.
• Se recomienda implementar los sensores compuestos de 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, sucederá lo siguiente:

• [C-3-1] SE DEBE implementar e informar el sensor de TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] SON StrongLY_RECOMMENDED para implementar e informar el sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones en dispositivos incluyen un acelerómetro de 3 ejes y se implementan cualquiera de los sensores compuestos de TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR y TYPE_STEP_COUNTER:

• [C-4-1] La suma de su consumo de energía DEBE ser siempre inferior a 4 mW.
• Cuando el dispositivo esté en condiciones dinámicas o estáticas, SE DEBE ser inferior a 2 mW y 0.5 mW cada uno.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor de giroscopio de 3 ejes, harán lo siguiente:

• [C-5-1] DEBE implementar los sensores compuestos de TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
• [C-SR-7] SE RECOMIENDA COMPLETAMENTE 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 magnetómetro, harán lo siguiente:

• [C-6-1] SE DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

7.3.2. Magnetómetro

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un magnetómetro de 3 ejes (brújula).

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, sucederá lo siguiente:

• [C-1-1] SE DEBE implementar el sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] SE DEBE poder informar eventos con una frecuencia de al menos 10 Hz. Y DEBES informar eventos de hasta 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 ser capaz de medir entre -900 μT y +900 μT en cada eje antes de saturar.
• [C-1-5] DEBE tener un valor de desplazamiento de hierro resistente inferior a 700 μT y DEBERÍA tener un valor inferior a 200 μT. Para ello, coloca el magnetómetro lejos de los campos magnéticos dinámicos (inducidos por la corriente) y estáticos (inducidos por imán).
• [C-1-6] DEBE tener una resolución igual o mayor que 0.6 μT.
• [C-1-7] DEBE admitir la calibración en línea y la compensación del sesgo del hierro resistente, y conservar los parámetros de compensación entre los reinicios del dispositivo.
• [C-1-8] SE DEBE aplicar la compensación de hierro blando: la calibración se puede realizar mientras se usa 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 tasa de muestreo más rápida, no superior a 1.5 μT; SE DEBE tener una desviación estándar no superior a 0.5 μT.
• [C-1-10] SE DEBE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un sensor acelerómetro y un sensor de giroscopio de 3 ejes, sucederá lo siguiente:

• [C-2-1] SE DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes o un acelerómetro, harán lo siguiente:

• PUEDES 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 TYPE_GEOMAGNETIC_ROTATION_VECTOR, sucederá lo siguiente:

• [C-3-1] DEBE consumir menos de 10 mW.
• SE DEBE consumir menos de 3 mW cuando el sensor está registrado para el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un receptor GPS/GNSS.

Si las implementaciones en dispositivos incluyen un receptor de GPS/GNSS e informan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, sucederá lo siguiente:

• [C-1-1] DEBE admitir salidas de ubicación a una tasa de al menos 1 Hz cuando se solicita a través de LocationManager#requestLocationUpdate.
• [C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, insignificantes de ruta múltiple, HDOP < 2) en un plazo de 10 segundos (tiempo rápido para la primera corrección), cuando se conecta a una conexión a Internet con una velocidad de datos de 0.5 Mbps o superior. Por lo general, este requisito se cumple con alguna forma de técnica de GPS/GNSS asistido o previsto para minimizar el tiempo de bloqueo del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y las efeméris y reloj satelitales).
  • [C-1-6] Después de realizar el cálculo de la ubicación, las implementaciones del dispositivo DEBEN determinar su ubicación a 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 realiza sin una conexión de datos o después de un reinicio.

• En condiciones a cielo abierto después de determinar la ubicación, mientras estás detenido o en movimiento a menos de 1 metro por segundo al cuadrado de aceleración:

  • [C-1-3] DEBE poder determinar la ubicación dentro de los 20 metros y la velocidad dentro de los 0.5 metros por segundo, al menos el 95% del tiempo.
  • [C-1-4] DEBE realizar un seguimiento y, también, informar simultáneamente mediante GnssStatus.Callback al menos 8 satélites de una constelación.
  • DEBERÍAS poder realizar un seguimiento simultáneo de al menos 24 satélites de varias constelaciones (p.ej., GPS +, al menos, uno de los objetos Glonass, Beidou o Galileo).

• [C-SR-2] SE RECOMIENDA ENERGMENTE para seguir proporcionando salidas normales de ubicación GPS/GNSS a través de las APIs del proveedor de ubicación de GNSS durante una llamada telefónica de emergencia.

• [C-SR-3] SE RECOMIENDA ENcarecidamente informar las mediciones de GNSS de todas las constelaciones a las que se les realiza un seguimiento (como se informa en los mensajes de GnssStatus), a excepción de SBAS.

• [C-SR-4] SE RECOMIENDA ENERCMENTE informar el AGC y la frecuencia de la medición de GNSS.

• [C-SR-5] SE RECOMIENDA ENERCMENTE que informen todas las estimaciones de precisión (incluidas el rumbo, la velocidad y la vertical) como parte de cada ubicación GPS/GNSS.

• [C-SR-6] SE RECOMIENDA ENRENDER que informen las mediciones de GNSS en cuanto se encuentran, incluso si aún no se informa una ubicación calculada a partir del GPS/GNSS.

• [C-SR-7] SE RECOMIENDA ENRENDER que informen pseudorrangos y pseudorrangos GNSS que, en condiciones a cielo abierto después de determinar la ubicación, mientras están detenidos o en movimiento con menos de 0.2 metros por segundo de aceleración, son suficientes para calcular la posición dentro de los 20 metros y la velocidad dentro de los 0.2 metros por segundo, al menos, el 95% del tiempo.

7.3.4. Giroscopio

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un sensor de giroscopio.

Si las implementaciones de dispositivos incluyen un giroscopio, sucederá lo siguiente:

• [C-1-1] DEBE ser capaz de 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] SE DEBE compensar la temperatura.
• [C-1-6] SE DEBE calibrar y compensar mientras se usa, y conservar los parámetros de compensación entre los reinicios del dispositivo.
• [C-1-7] DEBE tener una varianza no superior a 1e-7 rad^2 / s^2 por Hz (varianza por Hz o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero DEBE estar limitada por este valor. En otras palabras, si mides la varianza del giroscopio a una tasa de muestreo de 1 Hz, no DEBE ser superior a 1e-7 rad^2/s^2.
• [C-SR-2] SE RECOMIENDA QUE el error de calibración sea inferior a 0.01 rad/s cuando el dispositivo está quieto a temperatura ambiente.
• [C-SR-3] SE RECOMIENDA ENcarecidamente que tengan una resolución de 16 bits o más.
• SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, sucederá lo siguiente:

• [C-2-1] SE DEBE implementar el sensor TYPE_GYROSCOPE.
• [C-SR-4] Se recomienda que implementes el sensor TYPE_GYROSCOPE_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un giroscopio con menos de 3 ejes, sucederá lo siguiente:

• [C-3-1] SE DEBE implementar e informar el sensor de TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] SON StrongLY_RECOMMENDED para implementar e informar el sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, un sensor acelerómetro y un sensor magnetómetro, harán lo siguiente:

• [C-4-1] SE 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, sucederá lo siguiente:

• [C-5-1] DEBE implementar los sensores compuestos de TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
• [C-SR-6] SE RECOMIENDA COMPLETAMENTE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barómetro

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA ENcarecidamente incluir un barómetro (sensor de presión de aire ambiental).

Si las implementaciones en dispositivos incluyen un barómetro, hacen lo siguiente:

• [C-1-1] SE DEBE implementar e informar el sensor de TYPE_PRESSURE.
• [C-1-2] DEBE ser capaz de transmitir eventos a 5 Hz o más.
• [C-1-3] SE DEBE compensar la temperatura.
• [C-SR-2] SE RECOMIENDA ENRENDADAMENTE poder informar las mediciones de presión en el rango de 300 hPa a 1,100 hPa.
• SE DEBE tener una precisión absoluta de 1 hPa.
• SE DEBE tener una precisión relativa de 0.12 hPa sobre el rango de 20 hPa (equivalente a una exactitud de ~1 m por sobre el cambio de ~200 m a nivel del mar).

7.3.6. Termómetro

Si las implementaciones de dispositivos incluyen un termómetro de ambiente (sensor de temperatura), sucederá lo siguiente:

• [C-1-1] DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para el sensor de temperatura ambiente, y este DEBE medir la temperatura ambiente (de la habitación o de 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 distinta de la temperatura ambiente, como la de la CPU, harán 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 supervisar la temperatura cutánea, sucederá lo siguiente:

• [C-SR-1] SE RECOMIENDEN ENERGENTE para ser compatibles con la API de PowerManager.getThermalHeadroom.

7.3.7. Fotómetro

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

7.3.8. sensor de proximidad

• Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad.

Si las implementaciones de dispositivos incluyen un sensor de proximidad y solo informan una lectura binaria "cerca" o "lejana", sucede 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 cercanos a la pantalla, ya que el objetivo principal de este tipo de sensor es detectar un teléfono en uso por el usuario. 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 lectura cercana y 5 centímetros como lectura lejana.
• [C-1-4] DEBE informar un rango y resolución máximos de 5.

7.3.9. Sensores de alta fidelidad

Si las implementaciones de dispositivos incluyen un conjunto de sensores de mayor calidad, como se define en esta sección y los ponen a disposición de apps de terceros, sucederá lo siguiente:

• [C-1-1] SE DEBE identificar la función 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, hará lo siguiente:

• [C-2-1] DEBE tener un sensor TYPE_ACCELEROMETER con las siguientes características:

  • SE DEBE tener un rango de medición de al menos -8 g a +8 g, y se RECOMIENDA ESTABLECER un rango de medición de al menos -16 g y +16 g.
  • DEBE tener una resolución de medición de al menos 2048 LSB/g.
  • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 400 Hz o superior; SE DEBE admitir SensorDirectChannel RATE_VERY_FAST.
  • DEBE tener un ruido de medición que no supere los 400 μg/√ Hz.
  • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 3,000 eventos de sensor.
  • DEBE tener un consumo de energía por lotes que no sea inferior a 3 mW.
  • [C-SR-1] SE RECOMIENDA ENcarecidamente tener un ancho de banda de medición de 3 dB de, al menos, el 80% de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
  • SE DEBE hacer una caminata aleatoria de aceleración menor a 30 μg √Hz a temperatura ambiente.
  • SE RECOMIENDA tener un cambio de sesgo en comparación con la temperatura de ≤ +/- 1 mg/°C.
  • SE RECOMIENDA tener una no linealidad de la línea más adecuada de ≤ 0.5% y un cambio de sensibilidad en comparación con la temperatura de ≤ 0.03%/C°.
  • SE RECOMIENDA 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 con las siguientes características:

  • DEBE tener un rango de medición de al menos -1,000 y +1,000 dps.
  • DEBE tener una resolución de medición de al menos 16 LSB/dps.
  • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 400 Hz o superior; SE DEBE admitir SensorDirectChannel RATE_VERY_FAST.
  • DEBE tener un ruido de medición que no supere los 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.
  • SE DEBE hacer una caminata aleatoria de frecuencia inferior a 0.001 °/s √Hz probada a temperatura ambiente.
  • SE RECOMIENDA tener un cambio de sesgo respecto a la temperatura de ≤ +/- 0.05 °/ s / °C.
  • SE RECOMIENDA cambiar la sensibilidad frente a la temperatura de ≤ 0.02% / °C.
  • SE DEBE tener una no linealidad de la línea más adecuada de ≤ 0.2%.
  • SE DEBE tener una densidad de ruido igual o superior a ≤ 0.007 °/s/√ Hz.
  • Cuando el dispositivo está quieto, se DEBE tener un error de calibración inferior a 0.002 rad/s en un rango de temperatura de entre 10 °C y 40 °C.
  • DEBE tener una g-sensibilidad inferior a 0.1 °/s/g.
  • SE RECOMIENDA tener una sensibilidad entre ejes inferior al 4.0 % y una variación de 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 con las siguientes características:

  • 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 inferior.
  • DEBE tener una frecuencia de medición máxima de 50 Hz o superior.
  • DEBE tener un ruido de medición que no supere los 0.5 uT.

• [C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GEOMAGNETIC_FIELD y, además:

  • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 600 eventos de sensor.
  • [C-SR-3] SE RECOMIENDA ENcarecidamente tener un espectro de ruido blanco de 1 Hz a, al menos, 10 Hz cuando la frecuencia de informe sea de 50 Hz o superior.

• [C-2-7] DEBE tener un sensor TYPE_PRESSURE con las siguientes características:

  • DEBE tener un rango de medición de al menos 300 y 1,100 hPa.
  • DEBE tener una resolución de medición de al menos 80 LSB/hPa.
  • DEBE tener una frecuencia de medición mínima de 1 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 10 Hz o superior.
  • DEBE tener un ruido de medición que no supere los 2 Pa/√Hz.
  • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 300 eventos de sensor.
  • DEBE tener un consumo de energía por lotes que no sea inferior a 2 mW.

• [C-2-8] DEBE tener un sensor TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] DEBE tener un sensor TYPE_SIGNIFICANT_MOTION con las siguientes características:

  • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.

• [C-2-10] DEBE tener un sensor TYPE_STEP_DETECTOR con las siguientes características:

  • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 100 eventos de sensor.
  • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
  • DEBE tener un consumo de energía por lotes que no sea inferior a 4 mW.

• [C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER con las siguientes características:

  • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.

• [C-2-12] DEBE tener un sensor TILT_DETECTOR con las siguientes características:

  • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.

• [C-2-13] La marca de tiempo del evento del mismo evento físico informado por el acelerómetro, el giroscopio y el magnetómetro DEBE estar dentro de los 2.5 milisegundos de distancia entre sí. La marca de tiempo del mismo evento físico que informan el acelerómetro y el giroscopio DEBE tener 0.25 milisegundos de diferencia entre sí.

• [C-2-14] DEBE tener marcas de tiempo de eventos del sensor del giroscopio en la misma base de tiempo que el subsistema de la cámara y dentro de 1 milisegundos desde el error.

• [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 anteriores para la aplicación.

• El [C-2-16] NO DEBE tener un consumo de energía superior a 0.5 mW cuando el dispositivo está estático ni a 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 TYPE_PROXIMITY, pero, si está presente, DEBE tener una capacidad de búfer mínima de 100 eventos de 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 del sensor: el sensor, cualquier circuito de soporte, cualquier sistema de procesamiento de sensor dedicado, etcétera.

Si las implementaciones de dispositivos incluyen compatibilidad directa con el sensor, sucederá lo siguiente:

• [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 de sensores para todos los sensores que declaran compatibilidad con el canal directo de sensores.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• SE RECOMIENDA admitir informes 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 más información 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 en dispositivos incluyen una pantalla de bloqueo segura, sucederá lo siguiente:

• SE RECOMIENDA incluir un sensor biométrico

Los sensores biométricos se pueden clasificar como Clase 3 (antes Sólida), Clase 2 (anteriormente Débil) o Clase 1 (anteriormente Conveniencia) según sus tasas de aceptación de impostores y falsificación, y en la seguridad de la canalización biométrica. Esta clasificación determina las capacidades que el sensor biométrico tiene para interactuar con la plataforma y con aplicaciones de terceros. Los sensores deben cumplir con los requisitos adicionales que se detallan a continuación si desean que se clasifiquen como Clase 1, Clase 2 o Clase 3. Los datos biométricos de clase 2 y clase 3 obtienen las funciones adicionales que se detallan a continuación.

Si las implementaciones de dispositivos hacen que un sensor biométrico esté disponible para aplicaciones de terceros a través de android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt y android.provider.Settings.ACTION_BIOMETRIC_ENROLL, hacen lo siguiente:

• [C-4-1] DEBE cumplir con los requisitos de los datos biométricos de Clase 3 o Clase 2, como se define en este documento.
• [C-4-2] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase Authenticators y cualquier combinación de estos. Por el contrario, NO DEBE respetar ni reconocer las constantes de números enteros pasadas a los métodos canAuthenticate(int) y setAllowedAuthenticators(int) que no sean las documentadas como constantes públicas en Autenticadores y cualquier combinación de ellos.
• [C-4-3] DEBE implementar la acción ACTION_BIOMETRIC_ENROLL en dispositivos con 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.

Si las implementaciones de dispositivos admiten datos biométricos pasivos, sucederá lo siguiente:

• [C-5-1] De forma predeterminada, DEBE requerir un paso de confirmación adicional (p.ej., presionar un botón).
• [C-SR-1] SE RECOMIENDA ENcarecidamente tener una configuración que permita a los usuarios anular la preferencia de aplicación y siempre requerir el paso de confirmación complementario.
• [C-SR-2] SE RECOMIENDA ENcarecidamente proteger la acción de confirmación de modo que la vulneración del sistema operativo o el kernel no pueda falsificarla. Por ejemplo, esto significa que la acción de confirmación basada en un botón físico se enruta a través de un PIN de entrada y salida de uso general (GPIO) de solo entrada de un Elemento seguro (SE) que no se puede impulsar por ningún otro medio que no sea presionar un botón físico.
• [C-5-2] Además, DEBE implementar un flujo de autenticación implícito (sin paso de confirmación) que corresponda a setConfirmationRequired(boolean), que las aplicaciones se pueden configurar para usar en flujos de acceso.

Si las implementaciones de dispositivos tienen varios sensores biométricos:

• [C-SR-3] SE RECOMIENDA ENRENDER que se requiera solo un método biométrico por autenticación (p.ej., si el dispositivo cuenta con sensores faciales y de huella dactilar disponibles, se debe enviar onAuthenticationSucceeded después de que se confirme cualquiera de ellos).

Para que las implementaciones de dispositivos permitan el acceso de aplicaciones de terceros a las claves del almacén de claves, deben hacer lo siguiente:

• [C-6-1] DEBE cumplir con los requisitos de la Clase 3 según se define en la siguiente sección.
• [C-6-2] DEBE presentar solo los datos biométricos de Clase 3 cuando la autenticación requiere BIOMETRIC_STRONG o cuando la autenticación se invoca con un CryptoObject.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 1 (anteriormente Conveniencia), hacen lo siguiente:

• [C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0.002%.
• [C-1-2] SE 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 falsificación y impostor son superiores al 7%, según las mediciones de los Protocolos de prueba biométrica de Android.
• [C-1-9] SE DEBE solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón, contraseña) después de no más de veinte pruebas falsas y un tiempo de retirada de no menos de noventa segundos para la verificación biométrica, en la que una prueba falsa es aquella que tiene una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un método biométrico inscrito.
• [C-SR-4] SE RECOMIENDA ENERCMENTE reducir la cantidad total de pruebas falsas de verificación biométrica especificada en [C-1-9] si las tasas de aceptación de falsificación de identidad y impostores son superiores al 7% según los Protocolos de prueba biométrica de Android.
• [C-1-3] DEBEN limitar los intentos de verificación biométrica en los casos en los que una prueba falsa es aquella que tiene una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un método biométrico inscrito.
• [C-SR-5] SE RECOMIENDA ENERGENTEMENTE que se limite la frecuencia de intentos durante al menos 30 segundos después de cinco pruebas falsas de verificación biométrica para la cantidad máxima de pruebas falsas por [C-1-9], en la que una prueba falsa es una con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un método biométrico inscrito.
• [C-SR-6] SE RECOMIENDA ENcarecidamente tener toda la lógica de límite de frecuencia en TEE.

• [C-1-10] DEBE inhabilitar los datos biométricos una vez que se active 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 falsificación e impostor que no sea superior al 30%, con (1) una tasa de aceptación de falsificación e impostor para especies de instrumento de ataque de presentación (PAI) de nivel A no superior al 30%, y (2) una tasa de aceptación de falsificación e impostor de especies de prueba de PAI de nivel B no superior al 40%, ya que las métricas biométricas de Android Test Protocol no superan el 40%.

• [C-1-4] DEBE evitar agregar datos biométricos nuevos sin primero establecer una cadena de confianza. Para ello, se debe pedirle al usuario que confirme la credencial de dispositivo existente o que agregue una nueva (PIN, patrón o contraseña) protegida por el TEE. La implementación del Proyecto de código abierto de Android proporciona el mecanismo del framework para hacerlo.

• [C-1-5] SE DEBE quitar por completo todos los datos biométricos identificables de un usuario cuando se quita su cuenta (incluso mediante el restablecimiento de la configuración de fábrica).

• [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] SE DEBE solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón, contraseña) una vez cada 24 horas o menos. Nota: La actualización de dispositivos lanzados con Android 9 o versiones anteriores DEBERÁ solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 72 horas o menos.

• [C-1-8] SE DEBE desafiar al usuario a obtener la autenticación principal recomendada (p. ej., PIN, patrón, contraseña) o datos biométricos de clase 3 (FUERTE) después de una de las siguientes acciones:

  • un tiempo de espera de inactividad de 4 horas O
  • 3 intentos fallidos de autenticación biométrica.
  • El tiempo de espera de inactividad y el recuento de autenticaciones con errores se restablecen luego de que se confirman correctamente las credenciales del dispositivo. Nota: Las actualizaciones de dispositivos lanzados en Android 9 o versiones anteriores PUEDEN estar exentas de C-1-8.

• Se recomienda que los [C-SR-7] usen la lógica en el framework que proporciona el Proyecto de código abierto de Android para aplicar las restricciones especificadas en [C-1-7] y [C-1-8] para dispositivos nuevos.

• [C-SR-8] SE RECOMIENDA ENcarecidamente tener una tasa de rechazo falso inferior al 10%, según la medición del 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.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 2 (anteriormente Débil), sucede 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 falsificación e impostor que no sea superior al 20%, con (1) una tasa de aceptación de falsificación e impostor para especies de instrumento de ataque de presentación (PAI) de nivel A no superior al 20%, y (2) una tasa de aceptación de falsificación e impostor de especies de PAI de nivel B que no sean superiores al 30% de las métricas de prueba de biodiversidad de Android Test.

• [C-2-3] SE DEBE realizar la coincidencia biométrica en un entorno de ejecución aislado fuera del espacio de usuario o kernel de Android, como el entorno de ejecución confiable (TEE), o en un chip con un canal seguro al 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 manera criptográfica de modo que no se puedan adquirir, leer o modificar 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 del 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] Para datos biométricos basados en cámaras, mientras se realiza la autenticación o inscripción basadas en ellos:
  • DEBE operar la cámara en un modo que evite que los marcos de la cámara se lean o modifiquen fuera del entorno de ejecución aislado, o en 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 soluciones RGB de una sola cámara, los marcos de la cámara PUEDEN leerse fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para la inscripción, pero Aun así NO DEBEN ser alterables.
• [C-2-6] NO DEBE habilitar aplicaciones de terceros para distinguir entre inscripciones biométricas individuales.
• [C-2-7] NO DEBE permitir el acceso sin encriptar a datos biométricos identificables o a cualquier dato derivado de ellos (como incorporaciones) al procesador de aplicaciones fuera del contexto del TEE o la máquina virtual protegida controlada por un hipervisor que cumpla con los requisitos de la sección 9.17. Las actualizaciones de dispositivos lanzados en Android 9 o versiones anteriores no están exentas de C-2-7.

• [C-2-8] DEBE tener una canalización de procesamiento segura de modo que el compromiso del sistema operativo o el kernel no pueda permitir que se inserten datos directamente para autenticarse de forma falsa como usuario. Nota: Si las implementaciones de dispositivos ya se lanzaron en Android 9 o versiones anteriores y no pueden cumplir con el requisito C-2-8 a través de una actualización de software del sistema, PUEDEN estar exentas del requisito.

• [C-SR-10] SE RECOMIENDA ENRENDER que incluyan la detección de actividad física para todas las modalidades biométricas y la detección de atención para los biométricos faciales.

• [C-2-9] DEBE hacer que el sensor biométrico esté disponible para aplicaciones de terceros.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 3 (anteriormente Strong), hacen lo siguiente:

• [C-3-1] DEBE cumplir con todos los requisitos de la Clase 2 anteriores, excepto para [C-1-7] y [C-1-8].
• [C-3-2] DEBE tener una implementación de un almacén de claves guardadas en hardware.
• [C-3-3] DEBE tener una tasa de aceptación de falsificación e impostor que no sea superior al 7%, con (1) una tasa de aceptación de falsificación e impostor para especies de instrumento de ataque de presentación (PAI) de nivel A que no sea superior al 7%, y (2) una tasa de aceptación de falsificación e impostor de especies de PAI de nivel B que no sea superior al 20%, según la medición de los Protocolos biométricos de prueba Android.
• [C-3-4] DEBE desafiar al usuario a la autenticación principal recomendada (p.ej., PIN, patrón, 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 compatibles con el dispositivo si alguno de ellos se vuelve a inscribir.
• [C-3-6] Se debe habilitar las claves de almacén de claves respaldadas con datos biométricos para aplicaciones de terceros.

Si las implementaciones de dispositivos contienen un sensor de huellas dactilares ubicado debajo de la pantalla (UDFPS), hacen lo siguiente:

• Los [C-SR-11] SE RECOMIENDEN ENERGMENTE para evitar que el área táctil de UDFPS interfiera en la navegación con 3 botones( que algunos usuarios pueden requerir para fines de accesibilidad).

7.3.11. Sensor de postura

Implementaciones en dispositivos:

• PUEDE admitir el sensor de poses con 6 grados de libertad.

Si las implementaciones de dispositivos admiten el sensor de poses con 6 grados de libertad, harán lo siguiente:

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

7.3.12. Sensor de ángulo de bisagra

Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra, sucederá lo siguiente:

• [C-1-1] DEBE implementar y, luego, informar TYPE_HINGLE_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] SE DEBE mostrar 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, harán lo siguiente:

7.4. Conectividad de datos

7.4.1 Telefonía

El término "Telefonía", tal como utilizan las APIs de Android, y este documento hace referencia específicamente al hardware relacionado con realizar llamadas de voz y enviar mensajes SMS , o establecer datos móviles mediante una red móvil (p.ej., GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo compatible con "Telefonía" puede optar por ofrecer algunos o todos los servicios de llamadas, mensajería y datos, según corresponda para el producto.

a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no cambiarse de paquetes,se usan para que Android se considere independiente de cualquier conectividad de datos que se pueda implementar usando la misma red. En otras palabras,la funcionalidad y las APIs de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si usan una red móvil para la conectividad de datos.

• Android PUEDE usarse en dispositivos que no incluyen hardware de telefonía. Es decir, Android es compatible con dispositivos que no son teléfonos.

Si las implementaciones de dispositivos incluyen telefonía GSM o CDMA, sucederá lo siguiente:

• [C-1-1] SE DEBE declarar la marca de función android.hardware.telephony y otras marcas de función secundaria según la tecnología.
• [C-1-2] DEBE implementar compatibilidad total con la API para esa tecnología.
• SE RECOMIENDA permitir todos los tipos de servicios de telefonía celular disponibles (2G, 3G, 4G, 5G, etc.) durante las llamadas de emergencia (independientemente de los tipos de red configurados por SetAllowedNetworkTypeBitmap()).

Si las implementaciones de dispositivos no incluyen hardware de telefonía:

• [C-2-1] DEBE implementar las APIs completas como no-ops.

Si las implementaciones de dispositivos admiten eUICC o eSIMs/SIM incorporadas, e incluyen un mecanismo de su propiedad para que la funcionalidad de eSIM esté disponible para los desarrolladores externos, deben hacer lo siguiente:

• [C-3-1] SE DEBE declarar la marca de función android.hardware.telephony.euicc.

Si las implementaciones de dispositivos no establecen la propiedad del sistema ro.telephony.iwlan\_operation\_mode como "legacy", sucederá 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 único registro del subsistema multimedia de IP (IMS) para las funciones del servicio de telefonía multimedia (MMTEL) y del servicio de comunicación enriquecida (RCS), y se espera que cumplan con los requisitos de los proveedores de telefonía celular en relación con el uso de un solo registro de IMS para todo el tráfico de señalización de IMS:

• [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 MMTEL y la API de User Capability Exchange de 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 Gboard, las indicaciones dedicadas del portador con la HAL de IRadio 1.6 y el aprovisionamiento a través del servidor de configuración automático (ACS) o algún otro mecanismo de aprovisionamiento propio con la API de configuración de IMS.

Si las implementaciones de dispositivos informan la función android.hardware.telephony, haz lo siguiente:

• [C-6-1] SmsManager#sendTextMessage y SmsManager#sendMultipartTextMessage DEBEN dar como resultado las llamadas correspondientes a CarrierMessagingService para proporcionar la funcionalidad de mensajería de texto. SmsManager#sendMultimediaMessage y SmsManager#downloadMultimediaMessage DEBEN generar las 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ía y recibe mensajes SMS y MMS. La implementación de referencia del AOSP en paquetes/apps/Mensajes cumple con este requisito.
• [C-6-3] La aplicación que responde a Intent#ACTION_DIAL DEBE admitir la entrada de códigos de marcador arbitrarios con 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 la transcripción visual del buzón de voz a los usuarios si admite transcripciones visuales de buzón de voz.
• [C-6-5] DEBE representar todos los SubscriptionInfo con los UUID de grupo equivalentes como una sola suscripción en todas las condiciones visibles para el usuario que muestran y controlan la información de la tarjeta SIM. Algunos ejemplos de estas posibilidades 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 SubscriptionInfo con un UUID de grupo y un bit oportunista no nulos en ninguna opción visible para el usuario que permita la configuración o el control de la configuración de la tarjeta SIM.

Si las implementaciones de dispositivos informan la función android.hardware.telephony y proporcionan una barra de estado del sistema, sucede lo siguiente:

• [C-7-1] DEBE seleccionar una suscripción activa representativa para un UUID de grupo determinado que se le mostrará al usuario en cualquier opción que proporcione información del estado de la SIM. Algunos ejemplos de estas posibilidades incluyen el ícono de la señal móvil de la barra de estado o la tarjeta de configuración rápida.
• [C-SR-1] SE RECOMIENDA ENcarecidamente que la suscripción del representante se elija como la suscripción de datos activa, a menos que el dispositivo esté en una llamada de voz, durante la cual se RECOMIENDA QUE la suscripción del representante sea la suscripción de voz activa.

Si las implementaciones de dispositivos informan la función android.hardware.telephony, haz lo siguiente:

• [C-6-7] DEBE ser capaz de abrir y utilizar simultáneamente la cantidad máxima de canales lógicos (20 en total) para cada UICC según TSSI TS 102 221.
• [C-6-8] NO DEBE aplicar ninguno de los siguientes comportamientos a las apps de operadores activas (como lo designa TelephonyManager#getCarrierServicePackageName) de forma automática o sin la confirmación explícita del usuario:
  • Revocar o limitar el acceso a la red
  • Revocar permisos
  • Restringir la ejecución de apps en primer o segundo plano más allá de las funciones de administración de batería existentes incluidas en el AOSP
  • Cómo inhabilitar o desinstalar la app

Si las implementaciones de dispositivos informan que la función android.hardware.telephony y todas las suscripciones no oportunistas activas que comparten un UUID de grupo se inhabilitan, se quitan físicamente del dispositivo o se marcan como oportunistas, el dispositivo hace lo siguiente:

• [C-8-1] DEBE inhabilitar automáticamente todas las suscripciones oportunistas restantes que estén activas en el mismo grupo.

Si las implementaciones de dispositivos incluyen telefonía GSM, pero no telefonía CDMA, sucederá lo siguiente:

• [C-9-1] NO DEBE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] DEBE arrojar una IllegalArgumentException cuando se intente configurar cualquier tipo de red 3GPP2 con máscaras de bits de tipo de red preferidas o permitidas.
• [C-9-3] DEBE mostrar una cadena vacía de TelephonyManager#getMeid.

Si las implementaciones de dispositivos admiten eUICC con varios puertos y perfiles, tendrán las siguientes características:

• [C-10-1] SE DEBE declarar la marca de función android.hardware.telephony.euicc.mep.

7.4.1.1. Compatibilidad con bloqueo de números

Si las implementaciones de dispositivos informan la función android.hardware.telephony.calling, sucederá lo siguiente:

• [C-1-1] DEBE incluir asistencia para el bloqueo de números.
• [C-1-2] SE 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 provenientes de un número de teléfono en "BlockedNumberProvider" sin ninguna interacción con las apps. La única excepción ocurre cuando se quita temporalmente el bloqueo de números, como se describe en la documentación del SDK.

• [C-1-4] DEBE escribir en el proveedor de registro de llamadas de la plataforma para una llamada bloqueada y DEBE filtrar las llamadas con BLOCKED_TYPE fuera de la vista predeterminada del registro de llamadas en la app de teléfono preinstalada.

• [C-1-5] NO DEBE escribirle al 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 muestra el método TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] NO DEBE permitir que los usuarios secundarios vean o editen los números bloqueados en el dispositivo, ya que la plataforma 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 estar oculta para los usuarios secundarios, y la lista de entidades bloqueadas DEBE respetarse.

• SE RECOMIENDA migrar los números bloqueados al proveedor cuando un dispositivo se actualice a Android 7.0.

• SE DEBE proporcionar una indicación visual de usuario para mostrar las llamadas bloqueadas en la app de marcador preinstalada.

7.4.1.2. API de Telecom

Si las implementaciones de dispositivos informan android.hardware.telephony.calling, sucederá lo siguiente:

• [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 la indicación visual del usuario para aceptar o rechazar la llamada entrante cuando el usuario está en una llamada en curso realizada por una app de terceros que no admite la función de espera especificada en CAPABILITY_SUPPORT_HOLD.
• [C-1-3] DEBE tener una aplicación que implemente InCallService.

• [C-SR-1] SE RECOMIENDA MUY BIEN notificar al usuario que contestar una llamada entrante la finalizará.

  La implementación del AOSP cumple con estos requisitos mediante una notificación de atención que le indica al usuario que responder una llamada entrante hará que la otra llamada se descarte.

• [C-SR-2] SE RECOMIENDA COMPLEMENTAR LA precarga de la app de marcador predeterminada que muestra una entrada de 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 en true.

• [C-SR-3] SE RECOMIENDA EXITOSAMENTE para 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 detecte una pulsación breve de un evento de tecla durante una llamada en curso.
  • Llama a Connection.onAnswer() cuando se detecte una pulsación breve de un evento de tecla durante una llamada entrante.
  • Llama a Connection.onReject() cuando se detecte la acción de mantener presionado un evento de tecla durante una llamada entrante.
  • Activa o desactiva el estado de silencio de CallAudioState.

7.4.1.3 Descarga Keepalive de NAT-T celular

Implementaciones en dispositivos:

• SE DEBE incluir compatibilidad con la descarga de keepalive de la red móvil.

Si las implementaciones de dispositivos incluyen compatibilidad con la descarga keepalive de redes móviles y exponen la funcionalidad a apps de terceros, deben hacer lo siguiente:

• [C-1-1] DEBE ser compatible con la API de SocketKeepAlive.
• [C-1-2] DEBE admitir al menos una ranura keepalive simultánea a través de datos móviles.
• [C-1-3] DEBE admitir la mayor cantidad de ranuras keepalive simultáneas que admita la HAL de radio móvil.
• [C-SR-1] SE RECOMIENDA ENERGENTE para admitir al menos tres ranuras de keepalive móviles por instancia de radio.

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de keepalive de redes móviles, harán lo siguiente:

• [C-2-1] DEBE mostrar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones en dispositivos:

• SE DEBE incluir compatibilidad con uno o más formularios de 802.11.

Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 y exponen la funcionalidad a una aplicación de terceros, sucederá lo siguiente:

• [C-1-1] DEBE implementar la API de Android correspondiente.
• [C-1-2] SE DEBE informar la marca de función de hardware android.hardware.wifi.
• [C-1-3] DEBE implementar la API de multicast como se describe en la documentación del SDK.
• [C-1-4] DEBE admitir DNS multicast (mDNS) y NO filtrar paquetes mDNS (224.0.0.251 o ff02::fb) en cualquier momento de operación, incluso cuando la pantalla no está activa, a menos que sea necesario descartar o filtrar estos paquetes para mantenerse dentro de los rangos de consumo de energía que exigen los requisitos regulatorios del mercado. Para implementaciones en dispositivos de Android Television, incluso en estados de energía en espera
• [C-1-5] NO DEBE tratar la llamada de método a la API WifiManager.enableNetwork() como una indicación suficiente para cambiar el Network actualmente activo que se usa de forma predeterminada para el tráfico de la aplicación y que se muestra en los métodos de la API de ConnectivityManager, como getActiveNetwork y registerDefaultNetworkCallback. En otras palabras, PUEDEN inhabilitar solo 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 ENRENDER 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 cambien a cualquier otra red disponible (p.ej., datos móviles) que lo haga.
• [C-1-7] DEBE aleatorizar la dirección MAC de origen y el número de secuencia de los marcos de solicitud de sondeo, una vez al comienzo de cada análisis, mientras el STA está desconectado.
• [C-1-8] SE DEBE usar una dirección MAC coherente (NO SE DEBE aleatorizar la dirección MAC a mitad del análisis).
• [C-1-9] DEBE iterar el número de secuencia de la solicitud de sondeo como de costumbre (de forma secuencial) entre las solicitudes de sondeo de 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 RECOMIENDEN ENERGMENTE para aleatorizar la dirección MAC de origen que se usa para toda la comunicación de STA a un punto de acceso (AP) mientras se asocia y se asocia.
  • El dispositivo DEBE usar una dirección MAC aleatoria diferente para cada SSID (FQDN para Passpoint) con el que se comunica.
  • El dispositivo DEBE brindar al usuario la opción de controlar la aleatorización por SSID (FQDN para Passpoint) con opciones no aleatorias y aleatorias, y DEBE establecer el modo predeterminado para que las nuevas configuraciones de Wi-Fi sean aleatorias.
• [C-SR-2] SE RECOMIENDA ENcarecidamente usar un BSSID aleatorio para cualquier AP que se cree.
  • La dirección MAC DEBE aleatorizarse y conservarse por SSID que usa el AP.
  • EL DISPOSITIVO PUEDE ofrecer al usuario la opción de inhabilitar esta función. Si se proporciona tal opción, 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 como se define en el estándar IEEE 802.11, sucederá lo siguiente:

• SE DEBE desactivar el modo de ahorro de energía de Wi-Fi cada vez que una app adquiere un bloqueo 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 se encuentra en el modo de bloqueo de baja latencia de Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) DEBE ser menor que la latencia que se encuentra en el modo de bloqueo de alto rendimiento de Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] SE RECOMIENDEN ENERGÍAMENTE para minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere y se aplica un bloqueo de latencia baja (WIFI_MODE_FULL_LOW_LATENCY).

Si las implementaciones de dispositivos admiten Wi-Fi y usan Wi-Fi para la búsqueda de ubicación, sucederá lo siguiente:

• [C-2-1] DEBE proporcionar una indicación visual del usuario para habilitar o inhabilitar el valor leído a través del método WifiManager.isScanAlwaysAvailable de la API.

7.4.2.1. Wi-Fi directo

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con Wi-Fi directo (Wi-Fi entre pares).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi directo, sucederá lo siguiente:

• [C-1-1] SE 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 directo en simultáneo.
• [C-SR-1] SE RECOMIENDA aleatorizar la dirección MAC de origen de todas las conexiones de Wi-Fi directo recién formadas.

7.4.2.2. Configuración del vínculo directo en túnel Wi-Fi

Implementaciones en dispositivos:

• SE RECOMIENDA incluir compatibilidad con la Configuración de vínculos directos de túneles Wi-Fi (TDLS), como se describe en la Documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad con TDLS y el TDLS está habilitado por la API de WiFiManager, sucederá lo siguiente:

• [C-1-1] DEBE declarar la compatibilidad con TDLS a través de WifiManager.isTdlsSupported.
• DEBE usar TDLS solo cuando sea posible Y beneficioso.
• SE DEBE tener una heurística y NO usar TDLS cuando su rendimiento podría ser peor que el de pasar por el punto de acceso Wi-Fi.

7.4.2.3 Reconocimiento de Wi-Fi

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con Wi-Fi Aware.

Si las implementaciones de dispositivos incluyen compatibilidad con el reconocimiento de Wi-Fi y exponen la funcionalidad a apps de terceros, hará lo siguiente:

• [C-1-1] SE 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 reconocimiento de Wi-Fi al mismo tiempo.
• [C-1-4] SE DEBE aleatorizar la dirección de la interfaz de administración de reconocimiento de Wi-Fi a intervalos de no más de 30 minutos y siempre que se habilite esa función, a menos que una operación de reconocimiento de rango esté en curso o que una ruta de datos de reconocimiento esté activa (no se espera la aleatorización mientras la ruta de datos esté activa).

Si las implementaciones de dispositivos incluyen compatibilidad con el reconocimiento de Wi-Fi y la ubicación de Wi-Fi como se describe en la Sección 7.4.2.5 y exponen estas funciones a apps de terceros, sucederá lo siguiente:

• [C-2-1] DEBEN implementar las APIs de descubrimiento basadas en la ubicación: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm y onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint para Wi-Fi

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

• [C-1-1] DEBE incluir compatibilidad con Wi-Fi Passpoint.
• [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 ser compatible con el estándar IEEE 802.11u, relacionado específicamente con el descubrimiento y la selección de redes, como el servicio de publicidad genérica (GAS) y el protocolo de consulta de red de acceso (ANQP).
• [C-1-4] SE DEBE declarar la marca de función android.hardware.wifi.passpoint.
• [C-1-5] DEBE seguir la implementación de AOSP para descubrir, hacer coincidir y asociar a redes de Passpoint.
• [C-1-6] DEBE admitir, al menos, el siguiente subconjunto de protocolos de aprovisionamiento de dispositivos, como se define en Wi-Fi Alliance Passpoint R2: autenticación EAP-TTLS y SOAP-XML.
• [C-1-7] DEBE procesar el certificado del servidor AAA como se describe en la especificación de Hotspot 2.0 R3.
• [C-1-8] DEBE admitir el control de aprovisionamiento por parte del usuario a través del selector de Wi-Fi.
• [C-1-9] DEBE mantener la persistencia de la configuración de Passpoint en los reinicios.
• [C-SR-1] SE RECOMIENDA COMPLETAMENTE la función de aceptación de Términos y Condiciones.
• [C-SR-2] SE RECOMIENDA ENERCMENTE que respalden la función de información del lugar.

Si se proporciona un interruptor global de Passpoint que inhabilita el interruptor de control de usuario, las implementaciones hacen lo siguiente:

• [C-3-1] SE 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 en dispositivos:

• SE DEBE incluir compatibilidad con la Ubicación Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con la ubicación de Wi-Fi y exponen la funcionalidad a apps de terceros, harán lo siguiente:

• [C-1-1] SE 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 aumento de actividad de RTT que se ejecuta mientras la interfaz Wi-Fi en la que se ejecuta el RTT no está asociada con un punto de acceso.
• [C-1-4] DEBE tener una precisión de 2 metros con un ancho de banda de 80 MHz en el percentil 68 (como se calcula con la función de distribución acumulativa).
• [C-SR-1] SE RECOMIENDA ENRENDER que se informe con precisión dentro de los 1.5 metros con un ancho de banda de 80 MHz en el percentil 68 (como se calcula con la función de distribución acumulativa).

7.4.2.6. Descarga de Wi-Fi Keepalive

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con la descarga de keepalive de Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con la descarga de keepalive de Wi-Fi y exponen la funcionalidad a apps de terceros, harán lo siguiente:

• [C-1-1] DEBE admitir la API de SocketKeepAlive.
• [C-1-2] DEBE admitir al menos tres ranuras de keepalive simultáneas a través de Wi-Fi

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de keepalive de Wi-Fi, sucederá lo siguiente:

• [C-2-1] DEBE devolver ERROR_UNSUPPORTED.

7.4.2.7. Easy Connect para Wi-Fi (protocolo de aprovisionamiento de dispositivos)

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con Easy Connect (DPP) de Wi-Fi.

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

• [C-1-1] DEBE hacer que el método WifiManager#isEasyConnectSupported() devuelva true.

7.4.2.8. Validación del certificado del servidor Wi-Fi para empresas

Si el certificado del servidor Wi-Fi no está validado o el nombre de dominio del servidor Wi-Fi no está configurado, las implementaciones del dispositivo:

• [C-SR-1] SE RECOMIENDA QUE no le proporcionen al usuario la opción de agregar manualmente 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 de WPA/WPA2/WPA3-Enterprise, sucederá lo siguiente:

• [C-4-1] DEBE brindarle al usuario la opción de usar TOFU.

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth, sucederá 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, harán lo siguiente:

• SE RECOMIENDA admitir al menos 5 dispositivos conectados en total.

Si las implementaciones de dispositivos declaran la función android.hardware.vr.high_performance, hará lo siguiente:

• [C-1-1] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE.

Android admite Bluetooth y Bluetooth de bajo consumo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo, sucederá lo siguiente:

• [C-2-1] DEBE declarar las funciones relevantes de la plataforma (android.hardware.bluetooth y android.hardware.bluetooth_le, respectivamente) e implementar las APIs de la plataforma.
• SE DEBE implementar perfiles de Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP, etc., según corresponda para el dispositivo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo (BLE), sucederá lo siguiente:

• [C-3-1] SE 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 en android.bluetooth.
• [C-3-3] DEBE informar el valor correcto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar si se implementó la lógica de filtrado para las clases de API ScanFilter.
• [C-3-4] SE DEBE informar el valor correcto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo.

• [C-3-5] SE DEBE implementar un tiempo de espera de dirección privada resolvable (RPA) de no más de 15 minutos y rotar la dirección en el tiempo de espera para proteger la privacidad del usuario cuando el dispositivo usa BLE de forma activa para el escaneo o la publicidad. Para evitar ataques de tiempo, los intervalos de tiempo de espera también DEBEN aleatorizarse entre 5 y 15 minutos.

• SE DEBE admitir la transferencia de la lógica de filtrado al chipset Bluetooth cuando se implementa la API de ScanFilter.

• SE DEBE admitir la transferencia del escaneo por lotes al chipset Bluetooth.

• SE DEBE admitir anuncios múltiples con al menos 4 espacios.

Si las implementaciones de dispositivos admiten Bluetooth LE y usan Bluetooth LE para la búsqueda de la ubicación, sucederá lo siguiente:

• [C-4-1] DEBE proporcionar una indicación visual del usuario para habilitar o inhabilitar el valor leído a través de BluetoothAdapter.isBleScanAlwaysAvailable() de la API del sistema.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth LE y el perfil de audífonos, como se describe en Compatibilidad con audio de audífonos a través de Bluetooth de bajo consumo, sucederá lo siguiente:

• [C-5-1] SE DEBE mostrar true para BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID).

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo, sucederá lo siguiente:

• [C-6-1] DEBE restringir el acceso a cualquier metadato de Bluetooth (como los resultados de análisis) que podría usarse para obtener la ubicación del dispositivo, a menos que la app solicitante pase correctamente una verificación de permisos android.permission.ACCESS_FINE_LOCATION en función de su estado actual de primer plano/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 obtienen la ubicación de Bluetooth, sucederá lo siguiente:

• [C-6-2] DEBE establecer la puerta de acceso a Bluetooth detrás del android.permission.ACCESS_FINE_LOCATION.

Si las implementaciones de dispositivos muestran true para la API de BluetoothAdapter.isLeAudioSupported(), sucederá lo siguiente:

• [C-7-1] DEBE ser compatible con el cliente de unidifusión.
• [C-7-2] DEBE admitir 2M PHY.
• [C-7-3] DEBE ser compatible con la publicidad de LE Extended.
• [C-7-4] DEBE admitir al menos 2 conexiones CIS en una CIG.
• [C-7-5] DEBE habilitar el cliente de unidifusión de BAP, el coordinador del conjunto de CSIP, el servidor MCP, el controlador de VCP y el servidor CCP de forma simultánea.
• [C-SR-1] SE RECOMIENDAN IMPORTANTE para habilitar el cliente de unidifusión de HAP.

Si las implementaciones de dispositivos muestran true para la API de BluetoothAdapter.isLeAudioBroadcastSourceSupported(), sucederá lo siguiente:

• [C-8-1] DEBE admitir al menos 2 vínculos BIS en una 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 LE.

Si las implementaciones de dispositivos muestran true para la API de BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), sucederá lo siguiente:

• [C-9-1] DEBE admitir PAST (transferencia de sincronización de publicidad periódica).
• [C-9-2] DEBE admitir la publicidad periódica LE.

Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE, hará lo siguiente:

• [C-10-1] DEBE tener mediciones de RSSI dentro de +/-9dB para el 95% de las mediciones a 1 m de distancia de un dispositivo de referencia que transmite a ADVERTISE_TX_POWER_HIGH en la línea del entorno visual.

• [C-10-2] DEBE incluir correcciones de Rx/Tx para reducir las desviaciones por canal, de manera que las mediciones en cada uno de los 3 canales, en cada una de las antenas (si se usan múltiples) estén dentro de +/-3dB entre sí para el 95% de las mediciones.

• [C-SR-2] SE RECOMIENDA ENERCMENTE para medir y compensar el desplazamiento de Rx para garantizar que el RSSI de BLE medio sea de -60 dBm +/-10 dB a 1 m de distancia de un dispositivo de referencia que transmite a ADVERTISE_TX_POWER_HIGH, donde los dispositivos están orientados de modo que estén en "planos paralelos" con pantallas orientadas a la misma dirección.

• [C-SR-3] SE RECOMIENDA ENERGARSE para medir y compensar el desplazamiento de Tx para garantizar que el RSSI de BLE medio sea de -60 dBm +/-10 dB cuando se realiza un escaneo desde un dispositivo de referencia ubicado a 1 m de distancia y se transmite a ADVERTISE_TX_POWER_HIGH, donde los dispositivos están orientados de modo que estén en "planos paralelos" con pantallas orientadas a la misma dirección.

  Se movieron los requisitos [C-10-3] y [C-10-4] a 2.2.1. Hardware.

Te recomendamos que sigas los pasos para configurar la medición que se especifican en los Requisitos de calibración de presencias.

7.4.4. Comunicaciones de campo cercano

Implementaciones en dispositivos:

• SE RECOMIENDA incluir un transceptor y el hardware relacionado para las comunicaciones 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 si 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 que esté disponible para apps de terceros, sucederá lo siguiente:

• [C-1-1] SE DEBE informar el atributo android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature().
• DEBE ser capaz de leer y escribir mensajes NDEF mediante los siguientes estándares NFC, como se muestra a continuación:
• [C-1-2] DEBE ser capaz de actuar como lector/escritor de NFC Forum (según se define en la especificación técnica NFCForum-TS-DigitalProtocol-1.0 del foro de NFC) mediante los siguientes estándares de NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de etiquetas del foro de NFC 1, 2, 3, 4, 5 (definidas por NFC Forum)

• [C-SR-1] SE RECOMIENDA ENERCMENTE ser capaz de leer y escribir mensajes NDEF, así como datos sin procesar, a través de los siguientes estándares NFC. Ten en cuenta que, si bien los estándares de NFC se indican como MUY RECOMENDADOS, se planea que la definición de compatibilidad para una versión futura cambie a DEBE. Estos estándares son opcionales en esta versión, pero serán obligatorios en versiones futuras. Se recomienda que los dispositivos existentes y nuevos que ejecutan esta versión de Android cumplan ahora con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.

• [C-1-13] SE DEBE sondear todas las tecnologías compatibles en el modo de descubrimiento de NFC.

• SE DEBE estar en el modo de descubrimiento de NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.

• SE RECOMIENDA 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 del foro de JIS, ISO y NFC citadas anteriormente.

Android admite el modo de emulación de tarjeta de host NFC (HCE).

Si las implementaciones de dispositivos incluyen un chipset del controlador NFC capaz de HCE (para NfcA o NfcB) y que admiten el enrutamiento de ID de aplicación (AID), deben hacer lo siguiente:

• [C-2-1] DEBE informar la constante de función android.hardware.nfc.hce.
• [C-2-2] DEBE ser compatible con las APIs de NFC HCE como se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen un chipset del controlador NFC capaz de HCE para NfcF y, además, implementan la función para aplicaciones de terceros, deben hacer 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 tarjeta NfcF como se define 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, NDEF en MIFARE Classic) en la función de lector/escritor, hacen lo siguiente:

• [C-4-1] SE DEBE implementar las APIs de Android correspondientes según se documenta en el SDK de Android.
• [C-4-2] SE DEBE informar el elemento com.nxp.mifare desde el método android.content.pm.PackageManager.hasSystemFeature(). Ten en cuenta que esta no es una función estándar de Android y, por lo tanto, no aparece como una constante en la clase android.content.pm.PackageManager.

7.4.5. Protocolos de red y APIs

7.4.5.1. Capacidad de red mínima

Implementaciones en dispositivos:

• [C-0-1] DEBE incluir compatibilidad con una o más formas de red de datos. Específicamente, las implementaciones en dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos capaz de 200 Kbit/s o más. Algunos ejemplos de tecnologías que cumplen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet y número PAN de Bluetooth.
• También se 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 red físico (como Ethernet) es la conexión de datos principal.
• PUEDE implementar más de una forma de conectividad de datos.

7.4.5.2. IPv6

Implementaciones en dispositivos:

• [C-0-2] DEBE incluir una pila de red IPv6 y admitir la comunicación IPv6 a través de las APIs administradas, como java.net.Socket y java.net.URLConnection, además de las APIs nativas, como los sockets AF_INET6.
• [C-0-3] SE DEBE habilitar IPv6 de forma predeterminada.
  • DEBES asegurarte de que la comunicación IPv6 sea tan confiable como IPv4, por ejemplo:
    • [C-0-4] DEBE mantener la conectividad IPv6 en modo Descanso.
    • [C-0-5] El límite de frecuencia NO DEBE provocar que el dispositivo pierda conectividad IPv6 en ninguna red compatible con IPv6 que use ciclos 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 conecta a una red IPv6, sin que la traducción de direcciones o puertos se lleve a cabo localmente en el dispositivo. Tanto las APIs administradas, como Socket#getLocalAddress o Socket#getLocalPort, y las APIs de NDK, como getsockname() o IPV6_PKTINFO, DEBEN mostrar 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, sucederá lo siguiente:

• [C-1-1] DEBE admitir operaciones de pila doble y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos son compatibles con Ethernet, deberán hacer lo siguiente:

• [C-2-1] DEBE admitir la operación de pila doble y solo IPv6 en Ethernet.

Si las implementaciones de dispositivos admiten datos móviles, harán lo siguiente:

• [C-3-1] DEBE admitir la operación de IPv6 (solo IPv6 y posiblemente de pila doble) en la red móvil.

Si las implementaciones de dispositivos admiten más de un tipo de red (p.ej., Wi-Fi y datos móviles), hacen lo siguiente:

• [C-4-1] DEBE cumplir de forma simultánea 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 hace referencia a una red que requiere acceso para obtener acceso a Internet.

Si las implementaciones en dispositivos proporcionan una implementación completa de android.webkit.Webview API, harán 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 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 del portal cautivo cuando el dispositivo está conectado a cualquier tipo de red, incluida la red móvil o móvil, Wi-Fi, Ethernet o Bluetooth.
• [C-1-3] DEBE admitir el acceso a portales cautivos con DNS de texto simple cuando el dispositivo está configurado para usar el modo estricto de DNS privado.
• [C-1-4] SE 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 manera explícita con el portal cautivo.
• [C-1-5] DEBE asegurarse de que, mientras el usuario accede a un portal cautivo, la red predeterminada que usan las aplicaciones (como se muestra en ConnectivityManager.getActiveNetwork y ConnectivityManager.registerDefaultNetworkCallback, y que usan las APIs de red 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 en dispositivos:

• [C-0-1] DEBE tener activada la sincronización automática de la instancia principal de forma predeterminada para que el método getMasterSyncAutomatically() muestre el valor “true”.

7.4.7. Ahorro de datos

Si las implementaciones en dispositivos incluyen una conexión de uso medido, son las siguientes:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE proporcionar el modo de Ahorro de datos.

Si las implementaciones de dispositivos proporcionan el modo de Ahorro de datos, sucederá lo siguiente:

• [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, sucederá lo siguiente:

• [C-2-1] SE DEBE mostrar el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
• [C-2-2] NO DEBE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Elementos seguros

Si las implementaciones de dispositivos admiten elementos seguros que admiten Open Mobile API y los ponen a disposición de apps de terceros, sucederá lo siguiente:

• [C-1-1] SE 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 las marcas de función correctas 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, sucederá lo siguiente:

• [C-1-1] DEBE implementar la API de Android correspondiente en android.uwb.
• [C-1-2] SE DEBE informar el parámetro de función de hardware android.hardware.uwb.
• [C-1-3] DEBE admitir todos los perfiles de UWB relevantes definidos en la implementación de Android.
• [C-1-4] DEBE proporcionar una indicación visual del usuario que le permita activar o desactivar el estado de activación o desactivación de la radio UWB.
• [C-1-5] DEBE exigir que las apps que usan la radio UWB mantengan el permiso UWB_RANGING (en el grupo de permisos NEARBY_DEVICE).
• [C-SR-1] SE RECOMIENDA ENERCMENTE aprobar las pruebas de cumplimiento y certificación relevantes definidas por las organizaciones estándar, incluidas FIRA, CCC y CSA.
• El [C-1-6] DEBE asegurarse de que las mediciones de distancia estén a una distancia de +/-15 cm para el 95% de las mediciones en la línea de visión del entorno a 1 m de distancia en una cámara no reflectante.
• [C-1-7] DEBE asegurarse de que la mediana de las mediciones de distancia a 1 m del dispositivo de referencia se encuentre dentro de [0.75 m, 1.25 m], donde la distancia de la verdad fundamental se mide desde el borde superior del DUT. Mantenerlo boca arriba e inclinado 45 grados.
• [C-SR-2] SE RECOMIENDA ENERGENTE que sigan los pasos para configurar la medición especificados en Requisitos de calibración de presencias.

7.5 Cámaras

Si las implementaciones en dispositivos incluyen al menos una cámara, sucederá lo siguiente:

• [C-1-1] DEBE declarar la marca de función android.hardware.camera.any.
• [C-1-2] DEBE ser posible para que una aplicación asigne de manera simultánea 3 mapas de bits RGBA_8888 igual al tamaño de las imágenes producidas por el sensor de la cámara de mayor resolución en el dispositivo, mientras la cámara está abierta para la vista previa básica y la captura.
• [C-1-3] DEBE asegurarse de 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, es responsable de quitar la ubicación del usuario en los metadatos de la imagen antes de enviarla a la aplicación receptora cuando la aplicación receptora no tenga ACCESS_FINE_LOCATION.

Si las implementaciones de dispositivos admiten la capacidad de salida HDR de 10 bits, sucederá lo siguiente:

• [C-2-1] DEBE admitir al menos el perfil HLG HDR para cada dispositivo de cámara compatible con salida de 10 bits.
• [C-2-2] DEBE admitir una salida de 10 bits para la cámara posterior principal o la cámara frontal principal.
• [C-SR-1] SE RECOMIENDA ENERGENTE para admitir una salida de 10 bits para ambas cámaras principales.
• [C-2-3] DEBE admitir los mismos perfiles HDR para todas las subcámaras físicas compatibles con BACKWARD_COMPATIBLE de una cámara lógica y la propia cámara lógica.

Para dispositivos de cámara lógica que admiten HDR de 10 bits que implementan la API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, deben hacer lo siguiente:

• [C-3-1] DEBE admitir el cambio entre todas las cámaras físicas retrocompatibles a través del control CONTROL_ZOOM_RATIO de la cámara lógica.

7.5.1 Cámara posterior

Implementaciones en dispositivos:

• SE RECOMIENDA incluir una cámara posterior.

Si las implementaciones en dispositivos incluyen al menos una cámara posterior, sucederá lo siguiente:

• [C-1-1] SE 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.
• SE DEBE tener un enfoque automático de hardware o uno de software implementado en el controlador de la cámara (transparente para el software de aplicación).
• PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
• PUEDE incluir un destello.

Si la cámara incluye flash:

• [C-2-1] La lámpara de flash NO DEBE encenderse mientras se registra 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 del sistema integrada del dispositivo, sino solo a las aplicaciones de terceros que usan Camera.PreviewCallback.

7.5.2. Cámara frontal

Implementaciones en dispositivos:

• PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, sucederá lo siguiente:

• [C-1-1] SE 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 x 480 píxeles).
• El [C-1-3] NO DEBE usar una cámara frontal como predeterminada para la API de Camera y NO DEBE configurar la API para que considere una cámara frontal como la cámara posterior 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 se rote la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation(). Por el contrario, la vista previa DEBE duplicarse en el eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicita explícitamente que se rote la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NO DEBE duplicar la imagen estática capturada final ni las transmisiones de video de video que se devuelven a las devoluciones de llamada de la aplicación o que se envían al almacenamiento de contenido multimedia.
• [C-1-6] DEBE duplicar la imagen que muestra la vista previa de la misma manera que el flujo de imágenes de vista previa de la cámara.
• PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras posteriores, según se describe en la sección 7.5.1.

Si el usuario puede rotar las implementaciones del dispositivo (por ejemplo, de forma automática mediante un acelerómetro o de forma manual mediante una entrada del usuario), haz lo siguiente:

• [C-2-1] La vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación actual del dispositivo.

7.5.3 Cámara externa

Implementaciones en dispositivos:

• PUEDE incluir compatibilidad con una cámara externa que no siempre esté conectada.

Si las implementaciones de dispositivos incluyen compatibilidad con una cámara externa, sucederá lo siguiente:

• [C-1-1] SE DEBE declarar las marcas de función de la plataforma android.hardware.camera.external y android.hardware camera.any.
• [C-1-2] DEBE ser compatible con la clase de video USB (UVC 1.0 o superior) si la cámara externa se conecta a través del puerto de host USB.
• [C-1-3] DEBE pasar las pruebas del CTS de la cámara con un dispositivo de cámara externo físico conectado. Los detalles de las pruebas del CTS de la cámara están disponibles en source.android.com.
• SE RECOMIENDA admitir compresiones de video como MJPEG para habilitar la transferencia de transmisiones de alta calidad sin codificación (es decir, transmisiones de imágenes sin procesar o comprimidas de forma independiente).
• 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:

• [C-2-1] La implementación del dispositivo DEBE poder acceder a una transmisión MJPEG o sin codificación simultánea (QVGA o superior resolución).

7.5.4. Comportamiento de la API de Camera

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

El paquete de API más antiguo, android.hardware.Camera, está marcado como obsoleto en Android 5.0, pero debería estar disponible para que lo usen las apps. Las implementaciones en dispositivos Android DEBEN garantizar la compatibilidad continua de la API, como se describe en esta sección y en el SDK de Android.

Todas las funciones comunes entre la clase android.hardware.Camera obsoleta y el paquete android.hardware.camera2 más nuevo DEBEN tener rendimiento y calidad equivalentes en ambas APIs. Por ejemplo, con una configuración equivalente, 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 semántica de las dos APIs tengan la misma velocidad o calidad, pero SE DEBEN coincidir lo más estrechamente posible.

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

• [C-0-1] SE 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 el formato de codificación NV21 cuando una aplicación registra una instancia de android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() y el formato de vista previa es YCbCr_420_SP, los datos en el byte[] que se pasa a onPreviewFrame(). Es decir, NV21 DEBE ser el predeterminado.
• [C-0-3] DEBE admitir el formato YV12 (como lo indica la constante android.graphics.ImageFormat.YV12) para las vistas previas de las cámaras frontal y posterior de android.hardware.Camera. (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxeles nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
• [C-0-4] DEBE admitir los formatos android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como resultados a través de la API de android.media.ImageReader para dispositivos android.hardware.camera2 que anuncian la capacidad de REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities.
• [C-0-5] DE todas formas DEBE implementar la API de Camera completa que se incluye en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático de hardware o alguna otra función. Por ejemplo, las cámaras sin enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no sea relevante para una cámara sin enfoque automático). Ten en cuenta que esto se aplica a las cámaras frontales. Por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API deben “simular” de todos modos, como se describe.
• [C-0-6] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en las clases android.hardware.Camera.Parameters y android.hardware.camera2.CaptureRequest. Por el contrario, las implementaciones del dispositivo NO DEBEN respetar ni reconocer las constantes de cadena pasadas al método android.hardware.Camera.setParameters() que no sean las documentadas como constantes en android.hardware.Camera.Parameters. Es decir, las implementaciones en dispositivos DEBEN admitir todos los parámetros estándar de la cámara si el hardware lo permite, y NO DEBEN admitir tipos de parámetros personalizados de la cámara. 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 adecuado de compatibilidad con la propiedad android.info.supportedHardwareLevel, como se describe en el SDK de Android, además de informar las marcas de funciones del framework adecuadas.
• El [C-0-8] también DEBE declarar sus capacidades individuales de 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 conectados la admite.
• [C-0-9] DEBE transmitir el intent Camera.ACTION_NEW_PICTURE cada vez que la cámara toma una foto nueva y la entrada de la imagen se agrega a la tienda de contenido multimedia.
• [C-0-10] DEBE transmitir el intent Camera.ACTION_NEW_VIDEO cada vez que la cámara graba un video nuevo y la entrada de la imagen se agrega a la tienda de contenido multimedia.
• [C-0-11] SE DEBE poder acceder a todas las cámaras mediante la API obsoleta de android.hardware.Camera y también a través de la API de android.hardware.camera2.
• El [C-0-12] DEBE asegurarse de que la apariencia facial NO se haya alterado, lo que incluye, sin limitaciones, alterar la geometría facial, el tono de piel facial o su 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 cerca de cerca y orientadas en la misma dirección, se recomienda que sea compatible con un dispositivo de cámara lógico que indique la capacidad CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, que contenga todas las cámaras RGB orientadas a esa dirección como dispositivos secundarios físicos.

Si las implementaciones de dispositivos proporcionan una API de cámara de propiedad a apps de terceros, sucederá lo siguiente:

• [C-1-1] DEBE implementar una API de cámara de este tipo con la API de android.hardware.camera2.
• PUEDE proporcionar etiquetas o extensiones del proveedor a la API de android.hardware.camera2.

7.5.5 Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o posterior, estas cámaras son las siguientes:

• [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 mantiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo; es decir, se aplica tanto a los dispositivos principales con modo horizontal como a los principales verticales.

Los dispositivos que cumplan con todos los criterios que se indican a continuación estarán exentos del requisito anterior:

• El dispositivo implementa pantallas de geometría variable, como pantallas plegables o bisagras.
• Cuando cambia el estado de plegado o bisagra del dispositivo, este cambia entre orientaciones vertical-primaria y horizontal-principal (o viceversa).

7.6 Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Implementaciones en 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 en dispositivos:

• [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, también conocido como "almacenamiento externo compartido", "almacenamiento compartido de la aplicación" o por la ruta de Linux "/sdcard" en la que está activado.
• [C-0-2] DEBE configurarse con el almacenamiento compartido activado de forma predeterminada, en otras palabras, "listo para usar", sin importar si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (p.ej., ranura de tarjeta digital segura).
• [C-0-3] SE DEBE activar el almacenamiento compartido de la aplicación directamente en la ruta de acceso de Linux sdcard o incluir un vínculo simbólico de Linux desde sdcard hasta el punto de activación real.
• [C-0-4] DEBE habilitar el almacenamiento específico de forma predeterminada para todas las apps que se orienten al nivel de API 29 o superior, excepto en el siguiente caso:
  • Cuando la app solicita android:requestLegacyExternalStorage="true" en su manifiesto.
• [C-0-5] SE DEBE ocultar los metadatos de ubicación, como las etiquetas Exif de GPS, que se almacenan en archivos multimedia cuando se accede a esos archivos 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 usando cualquiera de las siguientes opciones:

• Almacenamiento extraíble accesible para el usuario, como una ranura de tarjeta Secure Digital (SD).
• Una parte del almacenamiento interno (no extraíble) como se implementa en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones de dispositivos usan almacenamiento extraíble para cumplir con los requisitos anteriores, sucederá lo siguiente:

• [C-1-1] DEBE implementar un aviso o una interfaz de usuario emergente que advierta al usuario cuando no se insertó un medio de almacenamiento en la ranura.
• [C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (p.ej., una tarjeta SD) o aparecer en la caja y otro material disponible en el momento de la compra que indica que el medio de almacenamiento se debe comprar por separado.

Si las implementaciones de dispositivos usan una parte del almacenamiento no extraíble para cumplir con los requisitos anteriores, sucederá lo siguiente:

• SE DEBE usar la implementación de 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 compatible con el modo de periférico USB, sucederá lo siguiente:

• [C-3-1] DEBE proporcionar un mecanismo para acceder a los datos en el almacenamiento compartido de la aplicación desde una computadora host.
• SE RECOMIENDA exponer el contenido de ambas rutas de almacenamiento de forma transparente a través del servicio de escáner de contenido multimedia de Android y android.provider.MediaStore.
• PUEDE usar el almacenamiento masivo de USB, pero SE DEBE usar el Protocolo de transferencia de medios para cumplir con este requisito.

Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y admiten el Protocolo de transferencia multimedia, harán lo siguiente:

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

7.6.3. Almacenamiento adoptable

Si se espera que el dispositivo sea móvil, a diferencia de la televisión, las implementaciones en dispositivos son las siguientes:

• [C-SR-1] RECOMIENDA implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlos 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 compartimento de la batería o alguna otra cubierta protectora, las implementaciones del dispositivo:

• [C-SR-2] RECOMIENDA implementar el almacenamiento adoptable.

7.7 USB

Si las implementaciones de dispositivos tienen un puerto USB, tienen las siguientes características:

• SE DEBE admitir el modo de periférico USB y el modo de host USB.
• DEBERÍA admitir la inhabilitación de la señalización de datos por USB.

7.7.1 Modo periférico USB

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo periférico:

• [C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
• [C-1-2] SE DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo estándar USB a través de android.os.Build.SERIAL.
• [C-1-3] DEBE detectar cargadores de 1.5 A y 3.0 A según el estándar de resistencia tipo C, y DEBE detectar cambios en el anuncio si son compatibles con USB tipo C.
• [C-SR-1] El puerto DEBE usar el factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENRENDER A los dispositivos Android existentes y nuevos que cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
• [C-SR-2] El puerto se DEBE ubicar en la parte inferior del dispositivo (según la orientación natural) o habilitar la rotación de la pantalla del software para todas las apps (incluida la pantalla principal), de modo que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. Se RECOMIENDA EJECUTARMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
• [C-SR-3] SE DEBE implementar la compatibilidad para generar una corriente de 1.5 A durante el pitido en HS y el tráfico, como se especifica en la especificación de la carga de batería USB, revisión 1.2. Se RECOMIENDA ENRENDER A los dispositivos Android existentes y nuevos que cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
• [C-SR-4] SE RECOMIENDA ENRENDER no admitir métodos de carga patentados que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o alteren los roles de receptor y fuente, como tales, pueden provocar problemas de interoperabilidad con los cargadores o dispositivos compatibles con los métodos estándar de USB Power Delivery. Si bien esto se denomina "EMERGENTE RECOMENDACIÓN", en futuras versiones de Android es posible que REQUISITOS que todos los dispositivos tipo C sean compatibles con la interoperabilidad completa con cargadores tipo C estándar.
• [C-SR-5] SE RECOMIENDA ENRENDER para admitir Power Delivery para el intercambio de funciones de datos y energía cuando admiten el modo de host USB y USB tipo C.
• SE RECOMIENDA admitir Power Delivery para la carga de alto voltaje y compatibilidad con modos alternativos, como visualización de salida.
• SE DEBE implementar la API y la especificación de Android Open Accessory (AOA) como se indica en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen un puerto USB e implementan la especificación AOA, sucederá lo siguiente:

• [C-2-1] DEBE declarar compatibilidad con la función de hardware android.hardware.usb.accessory.
• [C-2-2] La clase de almacenamiento masivo USB DEBE incluir la cadena "android" al final de la cadena de descripción iInterface de la interfaz del almacenamiento masivo USB.
• NO SE DEBE implementar el audio AOAv2 documentado en la documentación de Android Open Accessory Protocol 2.0. El audio AOAv2 dejó de estar disponible a partir de la versión de Android 8.0 (nivel de API 26).

7.7.2. Modo de host USB

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host, sucederá lo siguiente:

• [C-1-1] DEBE implementar la API del host de USB de Android como se documenta en el SDK de Android y DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.host.
• [C-1-2] SE DEBE implementar la compatibilidad para conectar periféricos USB estándar; en otras palabras, DEBE implementar una de las siguientes opciones:
  • Tener un puerto tipo C integrado en el dispositivo o enviar cables que adapten un puerto patentado del dispositivo a un puerto USB tipo C (dispositivo USB tipo C) estándar.
  • Tener un dispositivo tipo A integrado o enviarlo con cables que adapten un puerto exclusivo del dispositivo a un puerto USB tipo A estándar
  • Tener un puerto micro-AB en el dispositivo que SE DEBE enviar con un cable que se adapte a un puerto estándar tipo A.
• [C-1-3] NO DEBE enviarse con un adaptador que convierta de puertos USB tipo A o micro AB a un puerto tipo C (receptáculo).
• [C-SR-1] SE RECOMIENDA COMPLETAMENTE implementar la clase de audio USB, como se indica en la documentación del SDK de Android.
• SE DEBE admitir la carga del dispositivo periférico USB conectado mientras se está en modo host; anunciar una corriente de origen de al menos 1.5 A, como se especifica en la sección Parámetros de terminación de la Revisión 1.2 de la especificación del cable USB tipo C y conector para conectores USB tipo C, o el uso del rango de corriente de salida del puerto de carga descendente(CDP) según lo especificado en las especificaciones de carga de batería USB 2 del cable USB tipo C, revisión 1.
• SE DEBE implementar y admitir estándares USB tipo C.

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host y la clase de audio USB, harán lo siguiente:

• [C-2-1] DEBE admitir la clase USB HID.
• [C-2-2] DEBE admitir la detección y asignación de los siguientes campos de datos HID especificados en las tablas de uso de HID USB y la Solicitud de uso de comandos por voz a las constantes KeyEvent como se muestra a continuación:
  • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
  • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
  • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host y el framework de acceso al almacenamiento (SAF), sucederá lo siguiente:

• [C-3-1] DEBE reconocer todos los dispositivos MTP (protocolo de transferencia multimedia) conectados de forma remota y permitir el acceso a su contenido a través de los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT. .

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host y un USB tipo C, sucederá lo siguiente:

• [C-4-1] DEBE implementar la funcionalidad del puerto de función doble según se define en la especificación de USB tipo C (sección 4.5.1.3.3). Para puertos de función doble, en dispositivos que incluyen un conector de audio de 3.5 mm, la detección del receptor USB (modo de host) PUEDE estar desactivada de forma predeterminada, pero DEBE ser posible para el usuario habilitarla.
• [C-SR-2] SE RECOMIENDA ENRENDER que sea compatible con DisplayPort, SE DEBE admitir las velocidades de datos de SuperSpeed de USB, y SE RECOMIENDA ES IMPORTANTE para admitir Power Delivery para el intercambio de datos y funciones.
• [C-SR-3] SE RECOMIENDA ENRENDER QUE NO sea compatible con el modo de accesorio del adaptador de audio, como se describe en el Apéndice A de la Revisión 1.2 de la Especificación sobre cables y conectores USB tipo C.
• SE DEBE implementar el modelo Try.* que sea más adecuado para el factor de forma del dispositivo. Por ejemplo, un dispositivo de mano DEBE implementar el modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

Si las implementaciones en dispositivos incluyen un micrófono, sucederá 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 de la sección 5.4.
• [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6.
• [C-SR-1] SE RECOMIENDA ENERGENTE para admitir la grabación casi ultrasónica, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos omiten un micrófono, sucederán lo siguiente:

• [C-2-1] NO DEBE informar la constante de función android.hardware.microphone.
• [C-2-2] SE 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 del dispositivo incluyen un altavoz o un puerto de salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 3.5 mm de 4 conductores o un puerto de modo host USB que usa una clase de audio USB, sucederá 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 de la sección 5.5.
• [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6.
• [C-SR-1] SE RECOMIENDA ENRENDER para admitir la reproducción casi ultrasónica, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos no incluyen un puerto de salida de audio o bocina, sucederá lo siguiente:

• [C-2-1] NO DEBE informar la función android.hardware.audio.output.
• [C-2-2] SE DEBE implementar, al menos, las API relacionadas con la Salida de audio como no-ops.

A 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 la radio, como Bluetooth, Wi-Fi o la red móvil, no califica como incluir un "puerto de salida".

7.8.2.1. Puertos de audio analógicos

Para que sea compatible con auriculares y otros accesorios de audio que utilizan 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 hacer lo siguiente:

• [C-SR-1] SE RECOMIENDA ENcarecidamente incluir al menos uno de los puertos de audio para que sea un conector de audio de 3.5 mm de 4 conductores.

Si las implementaciones de dispositivos tienen un conector de audio de 4 conductores de 3.5 mm, sucede lo siguiente:

• [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con un micrófono.
• [C-1-2] DEBE admitir conectores de audio TRRS con el orden de pines CTIA.
• [C-1-3] DEBE admitir la detección y la asignación a los códigos de teclas para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
  • 70 ohm o menos: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DEBE activar ACTION_HEADSET_PLUG cuando se inserta un enchufe, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
• El [C-1-5] DEBE ser capaz de conducir al menos 150 mV ± 10% del voltaje de salida en una impedancia de la bocina de 32 ohm.
• [C-1-6] DEBE tener una compensación de voltaje del micrófono entre 1.8 V y 2.9 V.
• [C-1-7] DEBE detectar y asignar el código de clave para el siguiente rango de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] SE RECOMIENDA ENcarecidamente que admitan enchufes de audio con el orden de pines de OMTP.
• [C-SR-3] SE RECOMIENDA ENERGENTE para admitir la grabación de audio de auriculares estéreo con un micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm de 4 conductores y admiten un micrófono, y transmiten el android.intent.action.HEADSET_PLUG con el micrófono de valor adicional establecido en 1, suceden lo siguiente:

• [C-2-1] DEBE admitir la detección del micrófono en el accesorio de audio enchufado.

7.8.2.2. Puertos de audio digitales

Consulta la sección 2.2.1 para conocer los requisitos específicos de los dispositivos.

7.8.3. Casi ultrasónica

El audio casi ultrasónico está en la banda de entre 18.5 kHz y 20 kHz.

Implementaciones en dispositivos:

• SE DEBE informar correctamente la compatibilidad de la función de audio casi ultrasónico mediante la API de AudioManager.getProperty de la siguiente manera:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es "verdadero", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED DEBEN cumplir los siguientes requisitos:

• [C-1-1] La potencia de respuesta promedio del micrófono en la banda de 18.5 kHz a 20 kHz DEBE ser no superior a 15 dB por debajo de la respuesta a 2 kHz.
• [C-1-2] La relación señal-ruido no ponderada del micrófono superior a 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS no DEBE ser inferior a 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es "true", haz lo siguiente:

• [C-2-1] La respuesta media de la bocina en 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 en dispositivos:

• SE DEBE proporcionar una ruta de acceso de la señal de audio sin fallas para las transmisiones de entrada y salida en dispositivos de mano, según se define en función de cero fallas medidas durante una prueba de un minuto por ruta de acceso. Realiza la prueba con OboeTester “Automated Glitch Test”.

La prueba requiere una llave de bucle invertido de audio, que se usa directamente en un conector de 3.5 mm 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 acceso de AAudio, por lo que las siguientes combinaciones SE DEBEN probar para detectar fallas usando AAudio:

Modo rendimiento	Uso compartido	Tasa de muestreo de salida	En Chans	Oportunidades de salida
BAJO_LATENCIA	EXCLUSIVO	SIN ESPECIFICAR	1	2
BAJO_LATENCIA	EXCLUSIVO	SIN ESPECIFICAR	2	1
BAJO_LATENCIA	COMPARTIDO	SIN ESPECIFICAR	1	2
BAJO_LATENCIA	COMPARTIDO	SIN ESPECIFICAR	2	1
NINGUNA	COMPARTIDO	48000	1	2
NINGUNA	COMPARTIDO	48000	2	1
NINGUNA	COMPARTIDO	44100	1	2
NINGUNA	COMPARTIDO	44100	2	1
NINGUNA	COMPARTIDO	16000	1	2
NINGUNA	COMPARTIDO	16000	2	1

Una transmisión confiable DEBE cumplir con los siguientes criterios de relación señal/ruido (SNR) y distorsión total armónica (THD) para el seno de 2,000 Hz.

Transductor	THD	SNR
bocina principal integrada, medida con un micrófono de referencia externo	< 3%	50 dB o superior
micrófono principal integrado, medido con una bocina de referencia externa	< 3%	50 dB o superior
conectores analógicos de 3.5 mm integrados, probados con un adaptador de bucle invertido	< 1%	60 dB o superior
Adaptadores USB incluidos con el teléfono, probados con un adaptador de bucle invertido.	< 1%	60 dB o superior

7.9 Realidad virtual

Android incluye API e instalaciones para crear aplicaciones de "realidad virtual" (RV), lo que incluye experiencias de RV móvil de alta calidad. Las implementaciones en 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 RV, una función que controla la renderización estereoscópica de notificaciones e inhabilita los componentes monoculares de la IU del sistema mientras una aplicación de RV está enfocada en el usuario.

7.9.2. Modo de realidad virtual: Alto rendimiento

Si las implementaciones de dispositivos admiten el modo RV, sucederá lo siguiente:

• [C-1-1] DEBE tener al menos 2 núcleos físicos.
• [C-1-2] SE DEBE declarar la función android.hardware.vr.high_performance.
• [C-1-3] DEBE admitir el modo de rendimiento sostenido.
• [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
• [C-1-5] DEBE admitir android.hardware.vulkan.level 0.
• SE DEBE admitir android.hardware.vulkan.level 1 o versiones posteriores.
• [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 que se deben exponer las extensiones EGL en la lista.
• [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 COMPLEMENTE 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 sean compatibles con Vulkan 1.1.
• [C-SR-3] SE RECOMIENDA COMPLEMENTE 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 ENRENDER exponer al menos una familia de colas de Vulkan en la que flags contiene VK_QUEUE_GRAPHICS_BIT y VK_QUEUE_COMPUTE_BIT, y queueCount es al menos 2.
• [C-1-7] La GPU y la pantalla DEBEN poder sincronizar el acceso al búfer frontal compartido, de modo que se muestre la renderización ocular alternativa del contenido de RV a 60 FPS con dos contextos de renderización sin artefactos de seccionamiento visibles.
• [C-1-9] DEBE implementar 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] SE DEBE implementar la compatibilidad para AHardwareBuffer con cualquier combinación de las marcas de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para al menos los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM y AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] SE RECOMIENDEN ENERGMENTE para admitir la asignación de AHardwareBuffer con más de una capa, además de las marcas y los 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-10 Mbps o 2 instancias de 1920 FPS x 20 Mbps a 1080 Mbps).
• [C-1-12] DEBE ser compatible con HEVC y VP9. DEBE ser capaz de decodificar al menos 1920 × 1080 a 30 fps comprimidos a un promedio de 10 Mbps y DEBERÍA ser capaz de decodificar 3,840 × 2,160 a 30 FPS a 10 Mbps a 10 Mbps a 10 Mbps (equivalente a 8 FPS a 10 Mbps a 19 Mbps).
• [C-1-13] DEBE admitir la API de HardwarePropertiesManager.getDeviceTemperatures y mostrar valores precisos para la temperatura cutánea.
• [C-1-14] DEBE tener una pantalla incorporada 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 actualizar al menos 60 Hz en modo RV.
• [C-1-17] La pantalla DEBE admitir un modo de baja persistencia con una persistencia menor o igual a 5 milisegundos. La persistencia se define como la cantidad de tiempo durante el cual un píxel emite luz.
• [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE (sección 7.4.3).
• [C-1-19] DEBE admitir e informar 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 ENERGENTE para admitir 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 EXITOSAMENTE para admitir la función android.hardware.sensor.hifi_sensors.
• [C-1-22] DEBE tener movimiento de extremo a extremo para una latencia de fotón que no sea superior a 28 milisegundos.
• [C-SR-9] SE RECOMIENDA ENRENDER que tengan movimiento de extremo a extremo a una latencia de fotón no 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 del primer fotograma después de una transición del negro al blanco y el brillo de los píxeles blancos en estado estable, de al menos 85%.
• [C-SR-10] SE RECOMIENDA ENcarecidamente que tengan una proporción del primer fotograma de al menos un 90%.
• PUEDE proporcionar un núcleo exclusivo para la aplicación en primer plano y PUEDE admitir la API de Process.getExclusiveCores para mostrar los números de los núcleos de la CPU que son exclusivos de la aplicación principal en primer plano.

Si se admite el núcleo exclusivo, entonces el núcleo:

• [C-2-1] No DEBE permitir que se ejecuten otros procesos del espacio del usuario en él (excepto los controladores de dispositivos que usa la aplicación), pero PUEDE permitir que se ejecuten algunos procesos de kernel según sea necesario.

7.10. Tecnología háptica

7.11. Clase de rendimiento del contenido multimedia

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 de 0 indica que el dispositivo no es de una clase de rendimiento de contenido multimedia.

Si las implementaciones de dispositivos muestran un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucederá lo siguiente:

• [C-1-1] DEBE mostrar 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 de mano en las versiones T, S o R.

Consulta la sección 2.2.7 para conocer los requisitos específicos del dispositivo.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y energía son fundamentales para la experiencia del usuario y afectan las suposiciones de referencia que los desarrolladores tendrían cuando desarrollen una app.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si hay ciertos requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta coherentes para apps y juegos. Las implementaciones de dispositivos, según el tipo, 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 a la E/S de archivos

Proporcionar un modelo de referencia común para un rendimiento coherente de acceso a los archivos en el almacenamiento de datos privados de la aplicación (partición /data) permite a los desarrolladores de apps establecer una expectativa adecuada que ayudaría en el diseño de su software. Las implementaciones de dispositivos, según el tipo, PUEDEN tener ciertos requisitos que se describen en la sección 2 para las siguientes operaciones de lectura y escritura:

• Rendimiento de la 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 la 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 mediante la lectura de 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 en dispositivos incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en el AOSP (p.ej., intervalo de App Standby o Descanso) o extienden las funciones para aplicar restricciones más fuertes que el intervalo de App Standby RESTRINGIDO, sucede lo siguiente:

• [C-1-1] NO DEBE desviarse de la implementación de AOSP para la activación, el mantenimiento, los algoritmos de activación y el uso de la configuración global del sistema o el uso de DeviceConfig en los modos de ahorro de energía de App Standby y Descanso.
• [C-1-2] NO DEBE desviarse de la implementación de AOSP para usar la configuración global o DeviceConfig para administrar la limitación de los trabajos, la alarma y la red de las apps en cada intervalo de App Standby.
• [C-1-3] NO DEBE desviarse de la implementación de AOSP para la cantidad de buckets de App Standby que se usan para App Standby.
• [C-1-4] DEBE implementar los buckets de App Standby y el modo Descanso como se describe en Administración de energía.
• [C-1-5] SE DEBE mostrar true para PowerManager.isPowerSaveMode() cuando el dispositivo está en modo de ahorro de energía.
• El [C-1-6] DEBE proporcionar al usuario la posibilidad de mostrar todas las apps exentas de los modos de ahorro de energía App Standby y Descanso o cualquier optimización de la batería, y DEBE implementar el intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para pedirle al usuario que permita que una app ignore las optimizaciones de la batería.
• [C-SR-1] SE RECOMIENDEN ENERGÍAMENTE para proporcionar al usuario la indicación visual de habilitar o inhabilitar la función de ahorro de batería.
• Los [C-SR-2] se RECOMIENDEN ENERGÍAMENTE para proporcionar al usuario la posibilidad de mostrar todas las apps 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 batería que se incluyen en AOSP y esa extensión aplica restricciones más estrictas que el intervalo de App Standby poco frecuente, consulta la sección 3.5.1.

Además de los modos de ahorro de energía, las implementaciones en dispositivos Android PUEDEN implementar cualquiera o todos los 4 estados de energía suspendida, tal como se define en la Interfaz avanzada de configuración y energía (ACPI).

Si las implementaciones del dispositivo implementan los estados de energía de S4 según lo definido por la ACPI, hacen lo siguiente:

• [C-1-1] DEBE ingresar a este estado solo después de que el usuario haya realizado una acción explícita para colocar el dispositivo en estado inactivo (p.ej., cerrar una tapa que sea 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 los estados de energía de S3 según lo definido por la ACPI, hacen lo siguiente:

• [C-2-1] DEBE cumplir con C-1-1 anterior o DEBE entrar en estado S3 solo cuando las aplicaciones de terceros no necesitan los recursos del sistema (p.ej., la pantalla, la CPU).

  Por el contrario, DEBE salir del estado de S3 cuando las aplicaciones de terceros necesitan los recursos del sistema, como se describe en este SDK.

  Por ejemplo, si bien las aplicaciones de terceros solicitan mantener la pantalla encendida durante FLAG_KEEP_SCREEN_ON o la CPU en ejecución a través de PARTIAL_WAKE_LOCK, el dispositivo NO DEBE entrar en el 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 estado inactivo. Por el contrario, cuando se activa una tarea que implementan apps de terceros con JobScheduler o se entrega Firebase Cloud Messaging a apps de terceros, el dispositivo DEBE salir del estado S3, a menos que el usuario lo haya puesto en estado inactivo. Estos no son ejemplos exhaustivos, y el AOSP implementa amplios indicadores de activación que activan una activación a partir de este estado.

8.4. Contabilidad del consumo de energía

Una contabilización y un informe más precisos del consumo de energía le proporcionan al desarrollador de apps los incentivos y las herramientas para optimizar el patrón de uso de energía de la aplicación.

Implementaciones en dispositivos:

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

8.5. Rendimiento coherente

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

Implementaciones en dispositivos:

• [C-0-1] SE DEBE informar con precisión la compatibilidad del Modo de rendimiento sostenido a través del método de la API PowerManager.isSustainedPerformanceModeSupported().

• SE DEBE admitir el Modo de rendimiento sostenido.

Si las implementaciones de dispositivos informan compatibilidad con el Modo de rendimiento sostenido, deben hacer lo siguiente:

• [C-1-1] DEBE proporcionar un nivel coherente de rendimiento a la aplicación en primer plano durante al menos 30 minutos, cuando la app lo solicite.
• [C-1-2] DEBE respetar la API de Window.setSustainedPerformanceMode() y otras APIs relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, sucederán lo siguiente:

• SE DEBE proporcionar al menos un núcleo exclusivo que se pueda reservar la aplicación principal en primer plano.

Si las implementaciones de dispositivos permiten reservar un núcleo exclusivo para la aplicación en primer plano, sucederá lo siguiente:

• [C-2-1] SE DEBE informar a través del método de la API Process.getExclusiveCores() los números de ID de los núcleos exclusivos que la aplicación superior en primer plano puede reservar.
• [C-2-2] No DEBE permitir ningún proceso de espacio del usuario, excepto los controladores de dispositivo que usa la aplicación para ejecutarse en núcleos exclusivos, pero PUEDE permitir que algunos procesos de kernel se ejecuten según sea necesario.

Si las implementaciones en dispositivos no admiten un núcleo exclusivo, sucederá lo siguiente:

• [C-3-1] DEBE mostrar una lista vacía a través del método de la API Process.getExclusiveCores().

9. Compatibilidad del modelo de seguridad

Implementaciones en dispositivos:

• [C-0-1] SE DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android según se define en el documento de referencia de Seguridad y permisos de las APIs de la documentación para desarrolladores de Android.

• [C-0-2] DEBE admitir la instalación de aplicaciones autofirmadas sin la necesidad de permisos o certificados adicionales de terceros o autoridades.

Si las implementaciones de dispositivos declaran la función android.hardware.security.model.compatible, sucederá lo siguiente:

• [C-1-1] DEBE admitir los requisitos que se enumeran en las siguientes subsecciones.

9.1 Permisos

Implementaciones en dispositivos:

• [C-0-1] DEBE admitir el modelo de permisos de Android y el Modelo de roles de Android, como se define en la documentación para desarrolladores de Android. Específicamente, DEBEN aplicar cada permiso y rol definidos como se describe en la documentación del SDK; no se pueden omitir, modificar ni ignorar permisos ni funciones.

• PUEDES agregar permisos adicionales, siempre que las nuevas strings de ID del permiso no estén en el espacio de nombres android.\*.

• [C-0-2] Los permisos con un protectionLevel de PROTECTION_FLAG_PRIVILEGED solo deben otorgarse a las apps preinstaladas en las rutas de acceso con privilegios de la imagen del sistema (así como los archivos APEX) y estar dentro del subconjunto de permisos explícitamente permitidos para cada app. La implementación de AOSP cumple con este requisito, ya que lee y respeta los permisos incluidos en la lista de entidades permitidas de cada app desde la ruta de acceso privilegiada de la ruta de acceso etc/permissions/, así como el uso de estos.system/priv-app

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 las solicitan durante el tiempo de ejecución.

Implementaciones en dispositivos:

• [C-0-3] DEBE mostrar una interfaz dedicada para que el usuario decida si otorga los permisos de tiempo de ejecución solicitados y también proporcionar una interfaz para que el usuario administre los permisos de tiempo de ejecución.

• [C-0-5] NO DEBE otorgar ningún permiso de tiempo de ejecución a las aplicaciones, a menos que ocurra lo siguiente:

  • 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 mediante la política de otorgamiento de permisos predeterminada o para conservar una función de la plataforma.

• [C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo a las apps del sistema que registran un agente de recuperación correctamente protegido. Un agente de recuperación protegido correctamente 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 una protección equivalente o más fuerte que la descrita en el Servicio de Google Cloud Key Vault para evitar ataques de fuerza bruta en el factor de conocimiento de la pantalla de bloqueo.

Implementaciones en 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 actividad física a través de la API estándar de Android o un mecanismo de propiedad. Estos datos incluyen, entre otros, los siguientes:

  • Es la ubicación del dispositivo (p.ej., la latitud y la longitud) como se describe en la sección 9.8.8.
  • Es la información que se puede usar para determinar o estimar la ubicación del dispositivo (p.ej., SSID, BSSID, ID de celular o la ubicación de la red a la que está conectado el dispositivo).
  • Indica la actividad física del usuario o la clasificación de la actividad física.

Más concretamente, las implementaciones en dispositivos:

• [C-0-8] SE DEBE obtener el consentimiento del usuario para permitir que una aplicación 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 tiene los permisos suficientes, como se describe en el SDK. Por ejemplo, TelephonyManager#getServiceState requiere android.permission.ACCESS_FINE_LOCATION).

Las únicas excepciones a las propiedades de permiso de ubicación de Android anteriores son para las apps que no acceden a la ubicación para obtener o identificar la ubicación del usuario. Específicamente:

• Cuando las apps tienen el permiso RADIO_SCAN_WITHOUT_LOCATION
• Para la configuración del dispositivo, en los que las apps del sistema tienen el permiso NETWORK_SETTINGS o NETWORK_SETUP_WIZARD.

Los permisos se pueden marcar como una restricción que altera su comportamiento.

• [C-0-10] Los permisos marcados con la marca hardRestricted NO DEBEN otorgarse a una app, a menos que ocurra lo siguiente:

  • Hay un archivo APK de la app en la partición del sistema.
  • El usuario asigna una función que está asociada con los permisos hardRestricted a una app.
  • El instalador otorga el hardRestricted a una app.
  • A una app se le otorga la hardRestricted en una versión anterior de Android.

• [C-0-11] Las apps que tienen un permiso softRestricted DEBEN tener acceso limitado y NO DEBEN obtener acceso completo hasta que se incluya 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 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] SE DEBE usar las APIs de AppOpsManager para registrar y realizar un seguimiento de cada uno de los accesos programáticos de datos protegidos por permisos peligrosos de actividades y servicios de Android.

• [C-0-14] Solo DEBE 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 funcionalidades de superconjunto de roles definidos por la plataforma.

Si los dispositivos informan android.software.managed_users, hará lo siguiente:

• [C-1-1] NO DEBE tener los siguientes permisos otorgados de manera silenciosa por el administrador:
  • Ubicación (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Cámara (CÁMARA)
  • Micrófono (RECORD_AUDIO)
  • Sensor corporal (BODY_SENSORS)
  • Actividad física (ACTIVITY_RECOGNITION)

Si las implementaciones de dispositivos proporcionan una indicación visual al usuario para elegir qué apps pueden superponerse a otras con una actividad que controle el intent ACTION_MANAGE_OVERLAY_PERMISSION, sucederá lo siguiente:

• [C-2-1] DEBE asegurarse de 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 iniciadora o cualquier información que proporcione.

Si las implementaciones de dispositivos informan android.software.device_admin, harán lo siguiente:

• [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 del dispositivo.

Si las implementaciones del dispositivo preinstalan cualquier paquete que contenga cualquiera de los roles de System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence o System Visual Intelligence, los paquetes:

• [C-4-1] DEBE cumplir con todos los requisitos descritos para las implementaciones en dispositivos en las secciones "9.8.6 Captura de contenido", "9.8.6 Datos ambientales y a nivel del SO, e implementaciones de la API de Sandboxed 9.8.15".

9.2 UID y aislamiento de procesos

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con el modelo de zona de pruebas de aplicaciones para Android, en el que cada aplicación se ejecuta como un UID único de estilo Unix y en un proceso independiente.
• [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 en dispositivos:

• [C-0-1] DEBE admitir el modelo de permisos de acceso a los archivos de Android como se define en la referencia de seguridad y permisos.

Entornos de ejecución alternativos

Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de permisos y la seguridad de Android, incluso si incluyen entornos de ejecución que ejecutan aplicaciones que usan algún otro software o tecnología que no sea el formato ejecutable Dalvik o el código nativo. En otras palabras:

• [C-0-1] Los entornos de ejecución alternativos DEBEN ser aplicaciones para Android y cumplir con el modelo de seguridad estándar de Android, como se describe en otro lugar de la sección 9.

• [C-0-2] A los entornos de ejecución alternativos NO DEBEN tener acceso a recursos protegidos por permisos no solicitados en el archivo AndroidManifest.xml del entorno 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 permisos de Android restringidos a aplicaciones del sistema.

• [C-0-4] Los entornos 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 aplicación instalada en el dispositivo, excepto a través de los mecanismos estándar de Android de ID de usuario compartido y certificado de firma.

• [C-0-5] Los entornos de ejecución alternativos NO DEBEN iniciar, otorgar ni recibir acceso a las zonas de pruebas correspondientes a otras aplicaciones para Android.

• [C-0-6] Los entornos de ejecución alternativos NO DEBEN iniciarse con, otorgar ni otorgar a otras aplicaciones ningún privilegio del superusuario (raíz) ni de ningún otro ID de usuario.

• [C-0-7] Cuando los archivos .apk de entornos de ejecución alternativos se incluyen en la imagen del sistema de las implementaciones de dispositivos, se DEBEN firmar con una clave distinta de la que se usa para firmar otras aplicaciones incluidas con las implementaciones del dispositivo.

• [C-0-8] Cuando se instalan aplicaciones, los tiempos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que utiliza la aplicación.

• [C-0-9] Cuando una aplicación necesita usar un recurso de dispositivo para el que hay un permiso de Android correspondiente (como Cámara, GPS, etc.), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.

• [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 propio tiempo de ejecución cuando se instala cualquier aplicación que usa ese tiempo de ejecución.

• Los entornos de ejecución alternativos DEBEN instalar las apps a través de PackageManager en zonas de pruebas de Android independientes (ID de usuario de Linux, etcétera).

• Los entornos de ejecución alternativos PUEDEN proporcionar una única zona de pruebas de Android compartida por todas las aplicaciones que usan el entorno de ejecución alternativo.

9.5 Compatibilidad multiusuario

Android admite varios usuarios y admite el aislamiento completo de usuarios y clonar perfiles de usuario con aislamiento parcial(es decir, un perfil de usuario adicional único de tipo android.os.usertype.profile.CLONE).

• PUEDEN POSIBLES implementaciones en dispositivos, pero NO DEBEN habilitar la función multiusuario si usan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones en dispositivos admiten compatibilidad para varios usuarios, sucederá lo siguiente:

• [C-1-2] DEBE, para cada usuario, implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, como se define en el documento de referencia de Seguridad y permisos en las APIs.
• [C-1-3] DEBE tener directorios de almacenamiento de aplicación compartido separados y aislados (también conocido como /sdcard) para cada instancia de usuario.
• [C-1-4] SE DEBE asegurarse de que las aplicaciones que pertenecen a un usuario determinado y que se ejecutan en su nombre no puedan enumerar, leer ni escribir en los archivos que son propiedad de cualquier otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
• [C-1-5] SE DEBE encriptar el contenido de la tarjeta SD cuando el modo multiusuario está habilitado con una clave almacenada solo en medios no extraíbles al 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 el contenido multimedia no sea legible para una PC host, las implementaciones en el dispositivo deberán cambiar a MTP o un sistema similar para proporcionarles a las PC host acceso a los datos del usuario actual.

Si las implementaciones de dispositivos incluyen compatibilidad con varios usuarios, todos los usuarios, excepto los creados específicamente para ejecutar instancias dobles de la misma app, deben hacer lo siguiente:

• [C-2-1] DEBE tener directorios de almacenamiento de aplicación compartido separados y aislados (también conocido como /sdcard) para cada instancia de usuario.
• [C-2-2] DEBE asegurarse de que las aplicaciones que son propiedad de un usuario determinado y que se ejecutan en su nombre no puedan enumerar, leer ni escribir en los archivos que son propiedad de 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 único perfil de usuario adicional de tipo android.os.usertype.profile.CLONE para el usuario principal (y solo para el usuario principal) con el fin de ejecutar instancias dobles 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 distintas de una sola app en un dispositivo con doble tarjeta SIM.

Si las implementaciones de dispositivos crean el perfil de usuario adicional que se mencionó antes, hará lo siguiente:

• [C-3-1] solo DEBE proporcionar acceso al almacenamiento o a los datos a los que ya puede acceder el perfil de usuario principal o que son directamente propiedad de este perfil de usuario adicional.
• [C-3-2] NO DEBE tener esto como un perfil de trabajo.
• [C-3-3] DEBE tener directorios de datos de app privados aislados de la cuenta de usuario principal.
• [C-3-4] NO DEBE permitir que se cree el perfil de usuario adicional si hay un propietario del dispositivo aprovisionado (consulta la sección 3.9.1) ni permitir que se aprovisione un propietario del dispositivo sin quitar primero el perfil de usuario adicional.

9.6 Advertencia de SMS premium

Android admite las advertencias a los usuarios sobre cualquier mensaje SMS premium saliente. Los SMS premium son mensajes de texto que se envían a un servicio registrado con un operador que puede generar un cargo para el usuario.

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

• [C-1-1] DEBE advertir a los usuarios antes de enviar un mensaje SMS a los números identificados por las expresiones regulares definidas en el archivo /data/misc/sms/codes.xml del dispositivo. El Proyecto de código abierto de Android ascendente proporciona una implementación que cumple con este requisito.

9.7 Funciones de seguridad

Las implementaciones del dispositivo DEBEN garantizar el cumplimiento de las funciones de seguridad tanto en el kernel como en la plataforma, como se describe a continuación.

La zona de pruebas de Android incluye funciones que utilizan el sistema de control de acceso obligatorio (MAC) Security-Enhanced Linux (SELinux), la zona de pruebas seccomp y otras funciones de seguridad en el kernel de Linux. Implementaciones en dispositivos:

• [C-0-1] SE DEBE mantener la compatibilidad con las aplicaciones existentes, incluso cuando SELinux o cualquier otra función de seguridad se implementen por debajo del framework de Android.
• [C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta y bloquea correctamente una infracción de seguridad por la función de seguridad implementada debajo del framework de Android, pero PUEDE tener una interfaz de usuario visible cuando se produce una violación de seguridad desbloqueada, lo que genera un exploit exitoso.
• [C-0-3] NO DEBE permitir que el usuario o el desarrollador de la app puedan configurar SELinux o cualquier otra función de seguridad implementada 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 robe la compatibilidad.
• [C-0-5] SE DEBE dividir el framework de medios en varios procesos para que sea posible otorgar acceso de manera más específica 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 zona de pruebas de aplicaciones de kernel que permita filtrar llamadas al sistema con una política configurable de programas multiprocesamiento. El Proyecto de código abierto de Android ascendente cumple con este requisito habilitando seccomp-BPF con sincronización de grupo de subprocesos (TSYNC) como se describe en la sección de configuración de kernel de source.android.com.

La integridad del kernel y las funciones de autoprotección son esenciales para la seguridad de Android. Implementaciones en dispositivos:

• [C-0-7] DEBE implementar mecanismos de protección contra el desbordamiento del búfer de la pila del kernel. Algunos ejemplos de estos mecanismos son CC_STACKPROTECTOR_REGULAR y CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] DEBEN implementar protecciones de memoria de kernel estrictas en las que el código ejecutable es de solo lectura, los datos de solo lectura no son ejecutables ni que se pueden escribir, y los datos que admiten escritura no son ejecutables (p.ej., CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] SE DEBE implementar la verificación de límites de tamaño de objeto estático y dinámico de las copias entre el espacio del usuario y el espacio del kernel (p.ej., CONFIG_HARDENED_USERCOPY) en dispositivos que originalmente se enviaban con un nivel de API 28 o superior.
• [C-0-10] NO DEBE ejecutar la memoria del espacio del usuario cuando se ejecuta en el modo de 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 envían originalmente con nivel de API 28 o posterior.
• [C-0-11] NO DEBE leer ni escribir la memoria del espacio del usuario en el kernel fuera de las APIs de acceso de copia de usuario normales (p.ej., el número PAN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se enviaron originalmente con nivel de API 28 o superior.
• [C-0-12] SE DEBE implementar el aislamiento de la tabla de la página de kernel si el hardware es vulnerable a CVE-2017-5754 en todos los dispositivos que se enviaron originalmente con 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 enviaron originalmente con nivel de API 28 o superior (p.ej., CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] SE RECOMIENDEN ENERGENTEmente para habilitar la inicialización de pila en el kernel y evitar el uso de variables locales sin inicializar (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Además, las implementaciones en dispositivos NO DEBEN suponer el valor que usa el compilador para inicializar las configuraciones locales.

• [C-SR-2] SE RECOMIENDAN ENcarecidamente para 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-3] SE RECOMIENDA aleatorizar el diseño del código del kernel y la memoria, y evitar exposiciones que comprometan la aleatorización (p.ej., CONFIG_RANDOMIZE_BASE con entropía de bootloader mediante /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

• [C-SR-4] SE RECOMIENDEN ENERGENTEMENTE para habilitar la integridad del flujo de control (CFI) en el kernel para brindar protección adicional contra ataques de reutilización de código (p.ej., CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK).

• [C-SR-5] SE RECOMIENDA ENERGENTE no inhabilitar la integridad de flujo de control (CFI), la pila de llamadas paralelas (SCS) o la limpieza de desbordamiento de números enteros (IntSan) en los componentes que la tienen habilitada.

• [C-SR-6] SE RECOMIENDA ENERCMENTE habilitar CFI, IntSan y SCS para cualquier componente adicional del espacio del usuario sensible a la seguridad, como se explica en IntSan y CFI.

• [C-SR-7] SE RECOMIENDA COMPLEMENTE habilitar la inicialización de pila en el kernel para evitar el uso de variables locales sin inicializar (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Además, las implementaciones en dispositivos NO DEBEN suponer el valor que usa el compilador para inicializar las configuraciones locales.

• [C-SR-8] SE RECOMIENDEN ENERGENTEmente para habilitar la inicialización de montón en el kernel y evitar el uso de asignaciones de 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 es capaz de admitir SELinux, sucederá lo siguiente:

• [C-1-1] DEBE implementar SELinux.
• [C-1-2] DEBE configurar SELinux en el modo de aplicación global.
• [C-1-3] SE DEBE configurar todos los dominios en modo de aplicación forzosa. No se permiten dominios en modo permisivo, incluidos los dominios específicos de un dispositivo o proveedor.
• [C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas de Neverallow presentes dentro de la carpeta del sistema o de la política proporcionada en el Proyecto de código abierto de Android (AOSP) ascendente, y la política DEBE compilar con todas las reglas de Neverallow presentes, tanto para dominios SELinux del AOSP como para dominios específicos del dispositivo o proveedor.
• [C-1-5] DEBE ejecutar aplicaciones de terceros orientadas al 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.
• SE DEBE conservar la política predeterminada de SELinux que se proporciona en la carpeta del sistema o la política del proyecto del Proyecto de código abierto de Android ascendente y solo agregarla a esta política para su propia configuración específica del dispositivo.

Si las implementaciones de dispositivos usan un kernel distinto de Linux o Linux sin SELinux, hacen lo siguiente:

• [C-2-1] SE DEBE usar un sistema de control de acceso obligatorio que sea equivalente a SELinux.

Si las implementaciones en dispositivos usan dispositivos de E/S compatibles con DMA, sucederá lo siguiente:

• [C-SR-9] SE RECOMIENDA ENERGMENTE aislar cada dispositivo de E/S capaz de DMA mediante un IOMMU (p.ej., el SMMU de ARM).

Android contiene varias funciones de defensa en profundidad que son esenciales para la seguridad del dispositivo. Además, Android se enfoca en reducir las clases clave de errores comunes que contribuyen a las fallas de calidad y seguridad.

Para reducir los errores de memoria, las implementaciones en dispositivos hacen lo siguiente:

• Los [C-SR-10] SE RECOMIENDAN ENERGAR 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 PROBAR 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 TrustZone de Arm, sucederá lo siguiente:

• [C-SR-13] SE RECOMIENDA ENcarecidamente usar un protocolo estándar para el uso compartido de memoria entre Android y el TEE, como el framework de firmware de Arm para Armv8-A (FF-A).
• [C-SR-14] SE RECOMIENDAN ENRENDER restringiendo las aplicaciones de confianza para que solo accedan a la memoria que se ha compartido explícitamente con ellas a través del protocolo anterior. Si el dispositivo es compatible con el nivel de excepción de Arm S-EL2, el administrador de particiones seguro debería aplicar esto. De lo contrario, el SO de TEE debe aplicarla.

9.8 Privacidad

9.8.1 Historial de uso

Android almacena el historial de selecciones del usuario y administra este historial a través de UsageStatsManager.

Implementaciones en dispositivos:

• [C-0-1] DEBE mantener un período razonable de retención de dicho historial del usuario.
• [C-SR-1] SE RECOMIENDA EXITOSAMENTE para mantener el período de retención de 14 días según la configuración predeterminada en la implementación de AOSP.

Android almacena los eventos del sistema utilizando los identificadores StatsLog y administra el historial mediante StatsManager y la API del sistema IncidentManager.

Implementaciones en 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 DEBEN usar los identificadores de eventos del sistema para registrar ningún otro evento que no se describa en los documentos del SDK de StatsLog. Si se registran eventos del sistema adicionales, PUEDEN usar un identificador atómico diferente en el rango entre 100,000 y 200,000.

9.8.2. Grabando

Implementaciones en 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, informe de errores) fuera del dispositivo sin el consentimiento del usuario o borrar notificaciones continuas.
• [C-0-2] SE DEBE mostrar una advertencia del usuario y obtener su consentimiento explícito para permitir que se capture cualquier información sensible que se muestra en la pantalla del usuarioque incluya exactamente el mismo mensaje que el AOSP siempre que cada y cada vez que una sesión para capturar la pantalla se habilite a la transmisión o grabación de pantalla es 1MediaProjection.createVirtualDisplay() o las APIs de propiedad iniciadas.MediaProjection.createVirtualDisplay()1/VirtualDeviceManager.createVirtualDisplay() NO DEBE ofrecerles a los usuarios la posibilidad de inhabilitar la visualización futura del consentimiento del usuario.
• [C-0-3] DEBE tener una notificación continua para el usuario mientras la transmisión de pantalla o la grabación de pantalla están habilitadas. Para cumplir con este requisito, el AOSP muestra un ícono de notificación continuo en la barra de estado.

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 reproducida en el dispositivo de forma distinta a la ContentCaptureService de la API del sistema o a otros medios de propiedad descritos en la Sección 9.8.6 Datos ambientales y a nivel del SO, sucederán lo siguiente:

• [C-1-1] DEBE tener una notificación continua para el usuario siempre que esta funcionalidad esté habilitada y que se esté capturando o grabando de forma activa.

Si las implementaciones de dispositivos incluyen un componente habilitado listo para usar que es capaz de grabar audio ambiental o grabar el audio reproducido en el dispositivo para inferir información útil sobre el contexto del usuario, sucederá lo siguiente:

• El [C-2-1] NO DEBE almacenar en el almacenamiento persistente integrado en el dispositivo ni transmitir desde el dispositivo el audio sin procesar grabado ni ningún formato que se pueda volver a convertir al audio original o a un facsímil, excepto con el consentimiento explícito del usuario.

Un "indicador de micrófono" hace referencia a una vista en la pantalla que está constantemente visible para el usuario y no se puede ocultar, que los usuarios entienden como un micrófono en uso(a través de texto, color, ícono o alguna combinación únicos).

Un "indicador de cámara" hace referencia a una vista en la pantalla que está constantemente visible para el usuario y no se puede ocultar, que los usuarios entienden como una cámara en uso (a través de texto, color, ícono o alguna combinación únicos).

Después de que se muestra el primer segundo, un indicador puede cambiar visualmente, por ejemplo, achicarse y no es necesario que se muestre como se presentó y comprendió originalmente.

El indicador del micrófono se puede combinar con un indicador de cámara que se muestra de forma activa, siempre que el texto, los íconos o los colores le indiquen al usuario que comenzó el uso del micrófono.

El indicador de la cámara se puede combinar con un indicador de micrófono que se muestra de forma activa, siempre que el texto, los íconos o los colores le indiquen al usuario que comenzó a usar la cámara.

Si las implementaciones de dispositivos declaran android.hardware.microphone, hará lo siguiente:

• [C-SR-1] SE RECOMIENDA ENERCMENTE mostrar el indicador del micrófono cuando una app accede a datos de audio desde él, pero no cuando solo acceden HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o apps que tengan los roles mencionados en la sección 9.1 Permisos con el identificador de CDD [C-3-X]. .
• [C-SR-2] SE RECOMIENDA MUY BIEN mostrar la lista de apps recientes y activas que usan el micrófono como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensaje de atribución asociado a ellas.
• [C-SR-3] SE RECOMIENDA ENERGENTEmente no ocultar el indicador del micrófono para las apps del sistema que tengan interfaces de usuario visibles o interacción directa con el usuario.

Si las implementaciones de dispositivos declaran android.hardware.camera.any, hará lo siguiente:

• [C-SR-4] SE RECOMIENDA ENERCMENTE mostrar el indicador de la cámara cuando una app accede a datos de la cámara en vivo, pero no cuando solo acceden a la cámara las apps que tienen las funciones mencionadas en la sección 9.1 Permisos con el identificador de CDD [C-3-X].
• [C-SR-5] SE RECOMIENDA ENcarecidamente mostrar apps recientes y activas que usen la cámara como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensaje de atribución asociado a ellas.
• [C-SR-6] SE RECOMIENDA EJECUTAR no ocultar el indicador de la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

9.8.3 Conectividad

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo de periférico USB, sucederá lo siguiente:

• [C-1-1] DEBE presentar una interfaz de usuario para solicitar 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 en dispositivos:

• [C-0-1] SE DEBE preinstalar los mismos certificados raíz para el almacén de la autoridad certificadora (CA) de confianza del sistema que se proporcionan en el Proyecto de código abierto de Android ascendente.
• [C-0-2] SE DEBE enviar con un almacén de AC raíz de usuario vacío.
• [C-0-3] DEBE mostrar una advertencia al usuario en la que se indique que se puede supervisar el tráfico de red, cuando se agrega una AC raíz del usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones de los dispositivos:

• [C-1-1] DEBE mostrar una advertencia al usuario en la que se indique lo siguiente:
  • Es posible que ese tráfico de red esté supervisado.
  • 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 inmediato desde el primer uso, 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, precargar un servicio de VPN con android.permission.CONTROL_VPN otorgado), hacen lo siguiente:

• [C-2-1] SE DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de política de dispositivo habilite la VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage(), en cuyo caso el usuario no necesita dar un consentimiento por separado, pero solo DEBE recibir una notificación.

Si las implementaciones de dispositivos implementan una indicación visual de usuario para activar la función “VPN siempre activada” de una app de VPN de terceros, sucederá lo siguiente:

• [C-3-1] DEBE inhabilitar esta opción de usuario para las apps que no admiten el servicio de VPN siempre activada en el archivo AndroidManifest.xml configurando el atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON en false.

9.8.5 Identificadores de dispositivos

Implementaciones en dispositivos:

• [C-0-1] DEBE evitar el acceso al número de serie del dispositivo y, cuando corresponda, al IMEI/MEID, al número de serie de SIM y a la identidad internacional de suscriptor móvil (IMSI) desde una app, a menos que cumpla 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.
  • Tenga privilegios de operador, tal como se define en los Privilegios de proveedor de UICC.
  • es un propietario de dispositivo o perfil al que se le otorgó el permiso READ_PHONE_STATE.
  • (Solo para el número de serie de SIM o ICCID) tiene el requisito de reglamentaciones locales que indica que la app debe detectar cambios en la identidad del suscriptor.

9.8.6 Captura de contenido y búsqueda de aplicacionesDatos ambientales y a nivel del SO

Android, a través de las APIs del sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query y otros medios patentados, admite un mecanismo para que las implementaciones de dispositivos capturen las siguientes interacciones de datos de aplicación entre las aplicaciones y el usuario datos sensibles:

• Texto y gráficos renderizados en pantalla, incluidas, sin limitaciones, las notificaciones y los datos de asistencia, a través de la API de AssistStructure
• Datos multimedia, como audio o video, que el dispositivo graba o reproduce
• Eventos de entrada (p. ej., tecla, mouse, gesto, voz, video y accesibilidad)

• Cualquier texto o cualquier otro dato enviado a través de TextClassifier API al Sistema TextClassifier, es decir, al servicio del sistema para comprender el significado del texto, así como generar las próximas acciones previstas basadas en el texto.
• Datos indexados por la implementación de AppSearch de la plataforma, incluidos, sin limitaciones, texto, gráficos, datos multimedia y otros datos similares.

Si las implementaciones de dispositivos capturan alguno de los datos anteriores, sucederá lo siguiente:

• [C-1-1] SE DEBE encriptar todos esos datos cuando estén almacenados en el dispositivo. Esta encriptación PUEDE llevarse a cabo mediante la encriptación basada en archivos de Android o cualquiera de los cifrados que figuran en la API 26 o una versión posterior, descritos en el SDK de Cypher.
• [C-1-2] NO DEBE crear una copia de seguridad de datos sin procesar ni encriptados usando métodos de copia de seguridad de Android ni ningún otro método de copia de seguridad.
• [C-1-3] solo DEBE enviar todos esos datos y el registro fuera del dispositivo mediante un mecanismo de preservación de la privacidad, excepto con el consentimiento explícito del usuario cada vez que se comparten los datos. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis agregado y evitan la coincidencia de eventos registrados o resultados derivados con usuarios individuales" para evitar que los datos por usuario sean introspecbles (p.ej., que se implementen con una tecnología de privacidad diferencial, como RAPPOR).
• [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 asocian los datos.
• [C-1-5] NO DEBE compartir esos datos con otros componentes del SO que no cumplan con los requisitos descritos en la sección actual (9.8.6 Captura de contenido Datos ambientales y a nivel del SO), excepto con el consentimiento explícito del usuario cada vez que se comparten. A menos que esa funcionalidad se compile como una API del SDK de Android (AmbientContext, HotwordDetectionService).
• [C-1-6] DEBE proporcionar al usuario la opción para borrar los datos que la implementación o los medios de propiedad de ContentCaptureService recopilan si cuando los datos se almacenan de cualquier forma en el dispositivo. Si el usuario elige borrar los datos, DEBE quitar todos los datos históricos recopilados.
• [C-1-7] DEBE proporcionar una indicación para que el usuario inhabilite los datos recopilados a través de AppSearch o medios de propiedad para que no se muestren en la plataforma de Android, p.ej., en el Selector.
• [C-SR-1] SE RECOMIENDA ENERGMENTE NO solicitar el permiso de INTERNET.
• [C-SR-2] SE RECOMIENDA ENERGMENTE acceder a Internet solo a través de APIs estructuradas respaldadas por implementaciones de código abierto disponibles de forma pública.

Si las implementaciones de dispositivos incluyen un servicio que implementa ContentCaptureService o AppSearchManager.index de la API del sistema, o cualquier servicio de propiedad que capture los datos como se describió anteriormente, sucederá lo siguiente:

• [C-2-1] NO DEBE permitir que los usuarios reemplacen los servicios con una aplicación o servicio instalable, y solo DEBE permitir que los servicios preinstalados capturen esos datos.
• [C-2-2] NO DEBE permitir que ninguna app que no sea el mecanismo de servicios preinstalado pueda capturar esos datos.
• [C-2-3] DEBE proporcionar al usuario la posibilidad de inhabilitar los servicios.
• [C-2-4] NO DEBE omitir la indicación visual del usuario para administrar los permisos de Android que poseen los servicios y seguir el modelo de permisos de Android, como se describe en la Sección 9.1. Permiso.

• [C-SR-3] SE RECOMIENDEN ENERGENTEmente para mantener los servicios separados de otros componentes del sistema(p.ej., no vincular el servicio ni compartir los ID de procesos), excepto por lo siguiente:

  • Telefonía, Contactos, IU del sistema y Contenido multimedia

9.8.7 Acceso al portapapeles

Implementaciones en dispositivos:

• [C-0-1] NO DEBE mostrar 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 sea la app que actualmente está enfocada.

• [C-0-2] DEBE borrar los datos del portapapeles como máximo 60 minutos después de su última posición en un portapapeles o de haberlos leído desde este.

9.8.8. Ubicación

La ubicación incluye información en la clase Location de Android( como latitud, longitud y altitud), así como los identificadores que se pueden convertir a ubicación. La ubicación puede ser tan precisa como el DGPS (sistema de posicionamiento global diferencial) o tan aproximada como las ubicaciones a nivel de país (como la ubicación del código de país, MCC, código de país móvil).

La siguiente es una lista de 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 completa, pero debe usarse como ejemplo sobre de qué puede derivarse la ubicación directa o indirectamente:

• GPS/GNSS/DGPS/PPP
  • Solución de posicionamiento global, sistema satelital de navegación global o solución de posicionamiento global diferencial
  • También se incluyen las mediciones GNSS sin procesar y el estado de GNSS.
    • La ubicación precisa puede derivar de las mediciones GNSS sin procesar
• Tecnologías inalámbricas con identificadores únicos, como los 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 la torre de telefonía celular (3G, 4G, 5G, incluidas todas las futuras tecnologías de módems móviles que tengan identificadores únicos)

Como punto de referencia principal, consulta las APIs de Android que requieren permisos ACCESS_FINE_Location o ACCESS_COARSE_Location.

Implementaciones en dispositivos:

• [C-0-1] NO DEBE activar/desactivar la configuración de ubicación del dispositivo ni la configuración de búsqueda de Wi-Fi/Bluetooth sin el consentimiento explícito del usuario ni su iniciación.
• [C-0-2] DEBE proporcionar al usuario la opción de acceder a 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 Wi-Fi/Bluetooth para determinar la ubicación.
• [C-0-3] DEBE asegurarse de 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 911 o enviar un mensaje de texto al 911). Sin embargo, en el caso de la industria automotriz, un vehículo PUEDE iniciar una sesión de emergencia sin interacción activa del usuario en caso de que se detecte un accidente o accidente (p.ej., para cumplir con los requisitos de llamadas electrónicas).
• [C-0-4] DEBE preservar la capacidad de la API de Emergency Location Bypass para omitir la configuración de ubicación del dispositivo sin cambiar la configuración.
• [C-0-5] DEBE programar una notificación que le recuerde al usuario después de que una app en segundo plano acceda a su ubicación con el permiso [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instaladas

Las apps para Android que se orientan al nivel de API 30 o versiones posteriores no pueden ver detalles sobre otras apps instaladas de forma predeterminada (consulta Visibilidad de paquetes en la documentación del SDK de Android).

Implementaciones en dispositivos:

• [C-0-1] NO DEBE exponer a ninguna app que se oriente al nivel de API 30 o superior con detalles sobre ninguna otra app instalada, a menos que la app ya pueda ver los detalles de la otra app instalada a través de las APIs administradas. Esto incluye, entre otros, los detalles que exponen las APIs personalizadas que agrega el implementador del dispositivo o a los que se puede 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 del directorio específico y específico de la app dentro del almacenamiento externo. Las únicas excepciones son las siguientes:
  • Es la autoridad del proveedor de almacenamiento externo (p.ej., apps como DocumentsUI).
  • Proveedor de descargas que usa la autoridad del proveedor de "descargas" para descargar archivos al almacenamiento de la app.
  • Apps que usan el Protocolo de transferencia de medios (MTP) firmadas por la plataforma que usan el permiso con privilegios ACCESS_MTP para habilitar la transferencia de archivos a otro dispositivo
  • Las apps que instalan otras apps y tienen el permiso INSTALL_PACKAGES pueden acceder solo a directorios "obb" con el fin de administrar 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, hará 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] SE DEBE obtener el consentimiento del usuario cada vez que se usa BUGREPORT_MODE_TELEPHONY para generar un informe, y NO DEBE solicitar 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:
  • Volcado de TelephonyDebugService
  • Volcado de TelephonyRegistry
  • Volcado de WifiService
  • Volcado de ConnectivityService
  • Un volcado de la instancia de CarrierService del paquete que realiza la llamada (si está vinculada)
  • Búfer de registro de radio
  • Volcado de SubscriptionManagerService
• [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.
  • Cualquier tipo de registros de tráfico de aplicaciones instalados por el usuario o perfiles detallados de aplicaciones o paquetes instalados por el usuario (los UID están bien, pero los nombres de paquetes no lo son).
• PUEDE incluir información adicional que no esté asociada con ninguna identidad del usuario. (p.ej., registros del proveedor).

Si las implementaciones de dispositivos incluyen información adicional (p.ej., registros del proveedor) en informes de errores y esa información tiene un impacto en la privacidad, la seguridad, la batería, el almacenamiento y la memoria, sucederá lo siguiente:

• [C-SR-1] SE RECOMIENDA ENcarecidamente que tengan inhabilitada la configuración de desarrollador de forma predeterminada. Para cumplir con esto, la implementación de referencia del AOSP proporciona la opción Enable verbose vendor logging en la configuración para desarrolladores, de modo que se incluyan 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 contribuyan con BLOB de datos al sistema para que se compartan con un conjunto seleccionado de apps.

Si las implementaciones de dispositivos admiten BLOB de datos compartidos, como se describe en la documentación del SDK, sucederá lo siguiente:

• [C-1-1] NO DEBEN compartir BLOB de datos que pertenezcan a apps más allá de lo que ellos pretenden permitir (es decir, el alcance del acceso predeterminado y los otros modos de acceso que se pueden especificar mediante BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() o BlobStoreManager.session#allowPublicAccess(). La implementación de referencias de 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, en el caso de una grabación de audio, y deleguen el reconocimiento de música a una app con privilegios que implemente la API de MusicRecognitionService.

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema MusicRecognitionManager o cualquier servicio de propiedad que transmita datos de audio como se describió anteriormente, sucederá lo siguiente:

• [C-1-1] SE DEBE exigir que el llamador de MusicRecognitionManager tenga el permiso MANAGE_MUSIC_RECOGNITION.
• [C-1-2] SE DEBE exigir 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 con una aplicación o servicio que el usuario pueda instalar.
• [C-1-4] SE DEBE asegurarse de que, cuando MusicRecognitionManagerService acceda al registro de audio y lo reenvíe a la aplicación que implementa MusicRecognitionService, se realice un seguimiento del acceso al audio mediante invocaciones de AppOpsManager.noteOp / startOp.

Si las implementaciones del dispositivo de MusicRecognitionManagerService o MusicRecognitionService almacenan los datos de audio capturados, sucederá lo siguiente:

• [C-2-1] NO DEBE almacenar audio sin procesar ni huellas digitales de audio en el disco ni en la memoria por más de 14 días.
• [C-2-2] NO DEBE compartir dichos datos más allá del MusicRecognitionService, excepto con el consentimiento explícito del usuario cada vez que se comparten.

9.8.13 SensorPrivacyManager

Si las implementaciones de dispositivos proporcionan al usuario una indicación visual de software para desactivar la entrada de la cámara o del micrófono para la implementación del dispositivo, sucederá lo siguiente:

• [C-1-1] DEBE mostrar con exactitud "true" para el método de API supportsSensorToggle() relevante.
• [C-1-2] DEBE, cuando una app intenta acceder a un micrófono o una cámara bloqueados, se debe presentar al usuario una indicación visual no descartable que indique claramente que el sensor está bloqueado y requiere la opción de continuar bloqueando o desbloqueando según la implementación del AOSP que cumple con este requisito.
• [C-1-3] Solo DEBE pasar datos de la cámara y de audio en blanco (o falsos) a las apps y no informar un código de error debido a que el usuario no enciende la cámara ni el micrófono según la opción presentada por [C-1-2] anterior.

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 en 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 la Definición de compatibilidad de Android correspondiente al nivel de API en el que se lanzó el dispositivo.

9.9.1 Inicio directo

Implementaciones en dispositivos:

• [C-0-1] DEBE implementar las API de 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 DEBEN transmitirse para indicar a las aplicaciones con reconocimiento de inicio directo que las ubicaciones de almacenamiento encriptado por dispositivo (DE) y encriptación de credenciales (CE) están disponibles para el usuario.

9.9.2. Requisitos de encriptación

Implementaciones en 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 del dispositivo no extraíble.
• [C-0-2] SE DEBE habilitar la encriptación de almacenamiento de datos de forma predeterminada en el momento en que el usuario completa la experiencia de configuración lista para usar.

• [C-0-3] DEBE cumplir con el requisito de encriptación de almacenamiento de datos anterior con la implementación de uno de los dos métodos de encriptación siguientes:

  • 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 bloqueo 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, suceden lo siguiente:

• [C-1-1] DEBE iniciarse sin solicitar credenciales al usuario y permitir que las apps que reconocen el inicio directo accedan al almacenamiento encriptado por dispositivo (DE) después de que se emite el mensaje ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] Solo DEBE permitir el acceso al almacenamiento de credenciales encriptadas (CE) después de que el usuario haya desbloqueado el dispositivo proporcionando sus credenciales (p. ej., contraseña, PIN, patrón o huella dactilar) y se haya transmitido el mensaje ACTION_USER_UNLOCKED.
• [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 custodia registrada o un currículum durante la implementación del 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 encriptación basada en archivos con encriptación de metadatos, sucederá lo siguiente:

• [C-1-5] DEBE encriptar el contenido del archivo 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 algoritmo de cifrado de 256 bits, operada en modo XTS; la longitud total 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 el tamaño, la propiedad, los modos y los atributos extendidos (xattrs) de los archivos.
• [C-1-6] SE DEBE encriptar los nombres de los 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 de ARMv8 en dispositivos basados en ARM o AES-NI en dispositivos basados en x86), se DEBEN usar las opciones basadas en AES anteriores para el nombre del archivo, el contenido del archivo y la encriptación de metadatos del sistema de archivos, no Adiantum.
• [C-1-13] DEBE usar una función de derivación de clave criptográficamente segura y no reversible (p.ej., HKDF-SHA512) para derivar cualquier subclave necesaria (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 seguridad de seguridad de al menos 256 bits y se comporta como una familia de funciones pseudoaleatoria en sus entradas.
• [C-1-14] NO DEBE usar las mismas claves o subclaves de encriptación basada en archivos (FBE) para diferentes fines 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 asegurarse de que todos los bloques no borrados del contenido del archivo encriptado en el almacenamiento persistente se hayan encriptado con combinaciones de clave de encriptación y vector de inicialización (IV) que dependan del archivo y del desplazamiento dentro de este. Además, todas esas combinaciones DEBEN ser distintas, excepto cuando la encriptación se realiza con hardware de encriptación intercalada que solo admite una longitud IV de 32 bits.
• [C-1-16] DEBE asegurarse de que todos los nombres de archivo encriptados no eliminados del almacenamiento persistente en directorios distintos se hayan encriptado con distintas combinaciones de clave de encriptación y vector de inicialización (IV).

• [C-1-17] DEBE asegurarse de que todos los bloques de metadatos del sistema de archivos encriptados en el almacenamiento persistente se hayan encriptado con distintas combinaciones de clave de encriptación y vector de inicialización (IV).

• Claves que protegen las áreas de almacenamiento CE y DE, y los metadatos del sistema de archivos:

  • [C-1-7] DEBE vincularse criptográficamente a un almacén de claves guardado en 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 CE DEBEN estar vinculadas a las credenciales de la pantalla de bloqueo de un usuario.
  • [C-1-9] Las claves CE DEBEN estar vinculadas a una contraseña predeterminada cuando el usuario no especificó credenciales de pantalla de bloqueo.
  • [C-1-10] DEBE ser única y diferente, es decir, ninguna clave CE o DE de usuario coincide con ninguna otra de las claves CE o DE.
  • [C-1-11] SE 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í.

• SE DEBE permitir que las apps esenciales preinstaladas (p.ej., Alarma, Teléfono, Messenger) reconozcan el inicio directo.

El proyecto ascendente de código abierto de Android proporciona una implementación preferida de encriptación basada en archivos, basada en la función de encriptación "fscrypt" del kernel de Linux, y 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 bloqueo por usuario

Si las implementaciones de dispositivos usan encriptación a nivel de bloque por usuario, sucederá lo siguiente:

• [C-1-1] SE DEBE habilitar la asistencia 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 la encriptación de 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.

• Estas son las claves que protegen los dispositivos encriptados por usuario a nivel de bloque:

  • [C-1-5] DEBE vincularse de forma criptográfica a un almacén de claves guardado en 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 vincularse con 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 en el reinicio

La reanudación en el reinicio permite desbloquear el almacenamiento de CE de todas las apps, incluidas aquellas que aún no admiten el inicio directo, después de un reinicio que se inicia de manera inalámbrica. Esta función permite que los usuarios reciban notificaciones de apps instaladas después del reinicio.

Una implementación de la función Reanudación en el reinicio debe continuar garantizando que, cuando un dispositivo caiga en manos de un atacante, sea muy difícil para ese atacante recuperar los datos encriptados CE del usuario, incluso si el dispositivo está encendido, el almacenamiento CE está desbloqueado y el usuario desbloquea el dispositivo después de recibir una actualización inalámbrica. Para la resistencia ante ataques de usuarios con información privilegiada, también suponemos que el atacante obtiene acceso a la transmisión de claves de firma criptográficas.

Más precisamente:

• [C-0-1] El almacenamiento CE NO DEBE ser legible incluso para el atacante que tiene físicamente el dispositivo y, luego, tiene las siguientes capacidades y limitaciones:

  • Se puede usar la clave de firma de cualquier proveedor o empresa para firmar mensajes arbitrarios.
  • Puede hacer que el dispositivo reciba una actualización inalámbrica.
  • Puede modificar el funcionamiento de cualquier hardware (AP, flash, etc.), excepto los que se detallan a continuación, pero dicha modificación implica un retraso de al menos una hora y un reinicio de energía que destruye el contenido de la RAM.
  • No se puede modificar el funcionamiento del hardware resistente a alteraciones (p. ej., Titan M).
  • No se puede leer la RAM del dispositivo activo.
  • No se puede obtener la credencial del usuario (PIN, patrón o contraseña) o 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 que el estado de la integridad del dispositivo sea transparente. Implementaciones en dispositivos:

• [C-0-1] DEBE informar correctamente a través del método PersistentDataBlockManager.getFlashLockState() de la API del sistema si el estado de su bootloader permite la instalación de la imagen del sistema.

• [C-0-2] DEBE admitir el inicio verificado para la integridad del dispositivo.

Si las implementaciones en dispositivos ya se lanzaron sin compatibilidad con 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, PUEDEN estar exentas del requisito.

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si las implementaciones en dispositivos admiten la función, sucederá lo siguiente:

• [C-1-1] SE DEBE declarar la marca de función de la plataforma android.software.verified_boot.
• [C-1-2] SE DEBE verificar cada secuencia de inicio.
• [C-1-3] DEBE iniciar la verificación desde una clave de hardware inmutable que es la raíz de confianza y avanzar 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] SE 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 dé su consentimiento para intentar iniciar de todos modos. En ese caso, los datos de cualquier bloque de almacenamiento no verificado no DEBEN usarse.
• [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-SR-1] Si hay varios chips discretos en el dispositivo (p.ej., radio o procesador de imágenes especializado), se RECOMIENDA EL proceso de inicio de cada uno de ellos para verificar cada etapa durante el inicio.
• [C-1-8] SE DEBE usar el almacenamiento de manipulación evidente, es decir, para almacenar si el bootloader está desbloqueado. El almacenamiento a prueba de manipulaciones significa que el bootloader puede detectar si se manipuló el almacenamiento desde Android.
• [C-1-9] SE DEBE solicitar al usuario, mientras usa el dispositivo, y requerir una confirmación física antes de permitir una transición del modo bloqueado de bootloader al modo desbloqueado de bootloader.
• [C-1-10] DEBE implementar la protección contra reversión para las particiones que usa Android (p.ej., inicio, particiones del sistema) y usar el almacenamiento a prueba de manipulación para almacenar los metadatos usados con el fin de determinar la versión mínima permitida del SO.
• [C-1-11] SE DEBE borrar de forma segura todos los datos del usuario durante el desbloqueo y el bloqueo del bootloader, de acuerdo con '9.12. Data Deletion' (incluidas la partición de datos del usuario y cualquier espacio NVRAM).
• [C-SR-2] SE RECOMIENDAN COMPLETAMENTE verificar todos los archivos APK de la app con privilegios con una cadena de confianza basada en particiones protegidas por el inicio verificado.
• [C-SR-3] SE RECOMIENDA ENERCMENTE verificar cualquier artefacto ejecutable cargado por una app con privilegios desde fuera de su archivo APK (como código cargado de forma dinámica o código compilado) antes de ejecutarlos, o SE RECOMIENDA ESTAR ALTO no hacerlo.
• SE DEBE implementar la protección contra reversión para cualquier componente con firmware persistente (p.ej., módem, cámara), y DEBERÍA usar el almacenamiento a prueba de manipulación para almacenar los metadatos usados a fin de determinar la versión mínima permitida.

Si las implementaciones de dispositivos ya se lanzaron sin compatibilidad con C-1-8 a C-1-11 en una versión anterior de Android y no pueden agregar compatibilidad con estos requisitos con una actualización de software del sistema, PUEDEN estar exentas de los requisitos.

El Proyecto de código abierto de Android ascendente 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.

Implementaciones en dispositivos

Si las implementaciones en dispositivos tienen la capacidad de verificar el contenido del archivo por página, entonces:

• [C-0-3 C-2-1] admiten la verificación criptográfica del contenido del archivo con una clave de confianza sin leer todo el archivo.

• [C-0-4 C-2-2] NO DEBE permitir que las solicitudes de lectura en un archivo protegido tengan éxito cuando el contenido de lectura no se verifica con una clave de confianza no se verifica según [C-2-1] anterior.

Si las implementaciones de dispositivos ya se iniciaron 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, PUEDEN estar exentas del requisito. El proyecto upstream de código abierto de Android proporciona una implementación preferida de esta función, según la función fs-verity del kernel de Linux.

Implementaciones en dispositivos:

• [C-SR-4] SE RECOMIENDA ENERGMENTE que sea compatible con la API de Confirmación de protección de Android.

Si las implementaciones de dispositivos admiten la API de Confirmación de protección de Android, ocurrirá lo siguiente:

• [C-3-1] SE DEBE informar true para la API de ConfirmationPrompt.isSupported().

• [C-3-2] SE DEBE asegurarse de que el código que se ejecuta en el SO Android, incluido su kernel, malicioso o de otro modo, no pueda generar una respuesta positiva sin interacción del usuario.

• [C-3-3] SE DEBE asegurarse de que el usuario haya podido revisar y aprobar el mensaje solicitado, aun en el caso de que el SO Android, incluido su kernel, se vea comprometido.

9.11. Claves y credenciales

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

• [C-0-1] DEBE permitir que se importen o generen al menos 8,192 claves.
• [C-0-2] La autenticación de la pantalla de bloqueo DEBE implementar un intervalo de tiempo entre intentos fallidos. Si n es 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 30*2^floor((n-30)/10)) como mínimo o 24 horas, lo que sea menor.
• No se DEBE limitar la cantidad de claves que se pueden generar.

Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, hace lo siguiente:

• [C-1-1] SE DEBE crear 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 RSA, AES, ECDSA, ECDH (si se admite IKeyMintDevice), 3DES y HMAC y algoritmos criptográficos de MD5, SHA1 y SHA-2 de la familia de funciones de hash MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles del sistema Android Keystore en un área que esté aislada de manera segura del código que se ejecuta en el kernel y versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos mediante los cuales el kernel o el código del espacio del usuario podrían acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) ascendente cumple con este requisito mediante 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 un 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 realiza con éxito, permitir el uso de las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android ascendente proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para cumplir con este requisito.
• [C-1-4] DEBE admitir la certificación de claves cuando la clave de firma de la certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad de dispositivos lo suficientemente grande para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la misma clave de certificación, a menos que se produzcan al menos 100,000 unidades de un SKU determinado. Si se producen más de 100,000 unidades de un SKU, PUEDE usar una clave diferente por cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se inició en una versión anterior de Android, ese dispositivo estará 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 requiera un almacén de claves respaldado por un entorno de ejecución aislado.

• [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 automotores, que bloquean la pantalla cuando la consola central está apagada o se cambia el usuario, NO PUEDEN tener la configuración de tiempo de espera de suspensión.
• [C-1-6] DEBE ser compatible con IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice versión 1 o IKeyMintDevice versión 2.
• [C-SR-1] se RECOMIENDA ENRENDER para ser compatible con la versión 1 de IKeyMintDevice.

9.11.1 Proteger la pantalla de bloqueo, la autenticación y los dispositivos virtuales

La implementación del AOSP sigue un modelo de autenticación por niveles en el que una autenticación principal basada en la fábrica del conocimiento puede respaldarse con un método biométrico secundario sólido o modalidad terciaria más débil.

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA ENERGMENTE establecer solo uno de los siguientes 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 denominan los métodos de autenticación principales recomendados en este documento.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación principales recomendados y usan un método de autenticación nuevo como una forma segura de bloquear la pantalla, el método de autenticación nuevo hará lo siguiente:

• [C-2-1] DEBE ser el método de autenticación del usuario como se describe en Solicitud de autenticación del usuario para el uso de la clave.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo si se basan en un secreto conocido y usan un método de autenticación nuevo que se considere una forma segura de bloquear la pantalla, ocurrirá lo siguiente:

• [C-3-1] La entropía de la longitud más corta permitida de entradas DEBE ser superior a 10 bits.
• [C-3-2] La entropía máxima de todas las entradas posibles DEBE ser mayor que 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 o contraseña) implementados y proporcionados en el AOSP.
• [C-3-4] El nuevo método de autenticación DEBE inhabilitarse cuando la aplicación del controlador de política de dispositivo (DPC) establece la política de requisitos de contraseña con DevicePolicyManager.setRequiredPasswordComplexity() con una constante de complejidad más restrictiva que PASSWORD_COMPLEXITY_NONE o a través del método DevicePolicyManager.setAKPassword() con una constante más restrictiva que la METRIC_PASSWORDIO_PASSWORD.
• [C-3-5] Los nuevos métodos de autenticación DEBEN recurrir a los métodos de autenticación principales recomendados (es decir, PIN, patrón, contraseña) una vez cada 72 horas o menos O informarle claramente al usuario que no se creará 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 tratarse como una forma segura de bloquear la pantalla, el nuevo método hará lo siguiente:

• [C-4-1] DEBE cumplir con todos los requisitos descritos en la sección 7.3.10 para la Clase 1 (anteriormente, Conveniencia).
• [C-4-2] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados que se basan en un secreto conocido.
• [C-4-3] SE DEBE inhabilitar y solo permitir la autenticación principal recomendada para desbloquear la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya configurado la política de funciones de bloqueo de teclado llamando al método DevicePolicyManager.setKeyguardDisabledFeatures(), con cualquiera de las marcas biométricas asociadas (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 Strong), como se describe en la sección 7.3.10, ocurre 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 mediante DevicePolicyManager.setRequiredPasswordComplexity() con un bucket de complejidad más restrictivo que PASSWORD_COMPLEXITY_LOW o usando el método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Se DEBE cuestionar al usuario para obtener la autenticación principal recomendada (p. ej., PIN, patrón, 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 método de autenticación nuevo se basa en un token físico o en la ubicación, sucede lo siguiente:

• [C-6-1] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados, el cual se basa en un secreto conocido y cumple con los requisitos para que se los considere como una pantalla de bloqueo segura.
• [C-6-2] El nuevo método DEBE inhabilitarse y permitir que solo uno de los métodos de autenticación principales recomendados desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política con alguna de las siguientes opciones:
  • El método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • Es 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 cuestionar al usuario por uno de los métodos de autenticación principales recomendados (p.ej., 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 seguir las restricciones que se enumeran 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 del sistema de TrustAgentService, hacen 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 aplaza o los agentes de confianza pueden desbloquearlo. Por ejemplo, para cumplir con este requisito, AOSP muestra una descripción de texto para la "Configuración de bloqueo automático" y el "Botón de encendido que se bloquea instantáneamente" en el menú de configuración, además de un ícono distinguible en la pantalla de bloqueo.
• [C-7-2] DEBE respetar e implementar por completo todas las APIs de agente 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., portátil), pero PUEDE implementar por completo la función en implementaciones de dispositivos que se suelen compartir (p.ej., Android Television o Automotive).
• [C-7-4] DEBE encriptar todos los tokens almacenados que agregó TrustAgentService.addEscrowToken().
• [C-7-5] NO DEBE almacenar la clave de encriptación ni el token de depósito 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 Automotive, 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 custodia 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-8] Se DEBE cuestionar al usuario por uno de los métodos de autenticación principales recomendados (p. ej., PIN, patrón, contraseña) al menos una vez cada 72 horas o menos, a menos que la seguridad del usuario (p. ej., la distracción del conductor) sea una preocupación.
• [C-7-9] Se DEBE cuestionar al usuario por uno de los métodos de autenticación principales recomendados (p. ej., PIN, patrón o contraseña) como se describe en [C-1-7] y [C-1-8] en la sección 7.3.10, a menos que la seguridad del usuario (p. ej., la distracción del conductor) sea de interés.
• [C-7-10] NO DEBE tratarse como una pantalla de bloqueo segura y DEBE seguir las restricciones que se mencionan en C-8 a continuación.
• [C-7-11] NO DEBE permitir que TrustAgents acceda a los dispositivos personales principales (p. ej., de mano) para desbloquear el dispositivo y solo puede usarlos para mantener un dispositivo ya desbloqueado en ese estado 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 de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo que no es segura, como se describió anteriormente, y usan un método de autenticación nuevo para desbloquear el bloqueo de teclado:

• [C-8-1] El nuevo método DEBE inhabilitarse cuando la aplicación del controlador de política de dispositivo (DPC) establece la política de calidad de la contraseña con el método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_NONE o con una DevicePolicyManager.setRequiredPasswordComplexity() con una complejidad constante más restrictiva que "PASSWORD_COMPLEXITY_NONE".
• [C-8-2] NO DEBEN restablecer los temporizadores de vencimiento de contraseña establecidos por DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NO DEBEN exponer una API para que la usen apps de terceros a fin de determinar el estado de bloqueo.

Si las implementaciones en dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y no admiten eventos de entrada asociados, como a través de VirtualDeviceManager, sucede lo siguiente:

• El [C-9-1] DEBE bloquear estas pantallas virtuales secundarias cuando la pantalla predeterminada del dispositivo está bloqueada y desbloquearlas cuando la pantalla predeterminada del dispositivo está desbloqueada.

Si las implementaciones en dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y admiten eventos de entrada asociados, como a través de VirtualDeviceManager, harán lo siguiente:

• [C-10-1] DEBE admitir estados de bloqueo separados por dispositivo virtual.
• [C-10-2] SE DEBE desconectar todos los dispositivos virtuales tras el tiempo de espera de inactividad.
• [C-10-3] DEBE tener un tiempo de espera de inactividad.
• [C-10-4] DEBE bloquear todas las pantallas cuando el usuario inicia un bloqueo, incluso a través de la opción de bloqueo del usuario 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 independientes por usuario.
• [C-10-6] SE DEBE inhabilitar la creación de eventos de entrada asociados a través de VirtualDeviceManager cuando lo indique DevicePolicyManager.setNearbyAppStreamingPolicy.
• [C-10-7] DEBE usar un portapapeles independiente solo para cada dispositivo virtual (o inhabilitar el portapapeles para los dispositivos virtuales).
• [C-10-11] DEBE inhabilitar la IU de autenticación en los dispositivos virtuales, incluida la entrada del factor de conocimiento y el mensaje biométrico.
• [C-10-12] DEBE restringir los intents iniciados desde un dispositivo virtual para que se muestren solo en el mismo dispositivo virtual.
• [C-10-13] No DEBES usar un estado de bloqueo virtual del dispositivo como autorización de autenticación de usuarios con el sistema Android Keystore. Consulta KeyGenParameterSpec.Builder.setUserAuthentication*.

Cuando las implementaciones de dispositivos permiten que el usuario transfiera el factor de conocimiento de autenticación principal de un dispositivo de origen a uno de destino, por ejemplo, para la configuración inicial del dispositivo de destino, sucede lo siguiente:

• [C-11-1] SE DEBE encriptar el factor de conocimiento con garantías de protección similares a las descritas en el informe de seguridad del servicio de Key Vault de Google Cloud cuando se transfiera el factor de conocimiento del dispositivo de origen al de destino, de modo que el factor de conocimiento no se pueda desencriptar de forma remota ni se use para desbloquear cualquiera de ellos de forma remota.
• [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 no tenga ningún factor de conocimiento de autenticación principal configurado, pedirle al usuario que confirme un factor de conocimiento transferido en el dispositivo de destino antes de configurarlo como el factor de conocimiento de autenticación principal para el dispositivo de destino y antes de poner a disposición los datos transferidos desde un dispositivo de origen.

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

• [C-12-1] solo DEBE llamar a grantTrust() con la marca cuando se conecta a un dispositivo físico próximo con una pantalla de bloqueo propia y cuando el usuario ha autenticado su identidad en esa pantalla de bloqueo. Los dispositivos cercanos pueden usar mecanismos de detección de transporte o en la muñeca después de que un usuario se desbloquea por única vez para satisfacer el requisito de autenticación del usuario.
• [C-12-2] DEBE poner la implementación del dispositivo en el estado TrustState.TRUSTABLE cuando la pantalla está apagada (por ejemplo, cuando se presiona un botón o se agota el tiempo de espera de visualización) y el TrustAgent no revoca la confianza. AOSP cumple con este requisito.
• [C-12-3] Solo se DEBE mover el dispositivo del estado TrustState.TRUSTABLE al estado TrustState.TRUSTED si el TrustAgent aún otorga confianza según los requisitos de C-12-1.
• [C-12-4] DEBE llamar a TrustManagerService.revokeTrust() después de un máximo de 24 horas desde la concesión de confianza, un período de inactividad de 8 horas o cuando se pierde la conexión subyacente con el dispositivo físico próximo.

Si las implementaciones en dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y admiten eventos de entrada asociados, como a través de VirtualDeviceManager, y las pantallas no están marcadas con VIRTUAL_DISPLAY_FLAG_SECURE, sucede lo siguiente:

• [C-13-8] DEBE bloquear las actividades con el atributo android:canDisplayOnRemoteDevices o los metadatos android.activity.can_display_on_remote_devices configurados como falsos para que no se inicien en el dispositivo virtual.
• [C-13-9] DEBE bloquear las actividades que no habilitan explícitamente la transmisión y que indican que muestran contenido sensible, por ejemplo, a través de SurfaceView#setSecure, FLAG_SECURE o SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS para que no se inicien en el dispositivo virtual.
• [C-13-10] SE DEBE inhabilitar la instalación de apps iniciadas desde dispositivos virtuales.

Si las implementaciones del dispositivo admiten estados de energía separados de la pantalla a través de DeviceStateManager Y admiten estados de bloqueo de la pantalla separados a través de KeyguardDisplayManager, sucederá lo siguiente:

• [C-SR-2] SE RECOMIENDA ENERCMENTE utilizar una credencial que cumpla con los requisitos definidos en la sección 9.11.1 o un sistema biométrico que cumpla con al menos 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 ENERGENTE para limitar el desbloqueo de la pantalla por separado a través de un tiempo de espera de pantalla definido.
• [C-SR-4] SE RECOMIENDEN ENERGÍAMENTE para 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 dedicado se llama "StrongBox". Los requisitos de C-1-3 a C-1-11 que se incluyen a continuación definen los requisitos que debe cumplir un dispositivo para calificar como StrongBox.

Implementaciones en dispositivos que tienen un procesador seguro dedicado:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE ser compatible con StrongBox. Es probable que StrongBox se convierta en un requisito en una versión futura.

Si las implementaciones de dispositivos admiten StrongBox, hacen lo siguiente:

• [C-1-1] DEBE declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DEBE proporcionar hardware seguro y dedicado que se use para respaldar el almacén de claves y la autenticación de usuario segura. 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] SE DEBE asegurarse de 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 de AP.

• [C-1-6] DEBE tener un verdadero generador de números aleatorios que produzca resultados impredecibles y distribuidos de manera uniforme.

• El [C-1-7] DEBE tener resistencia a la manipulación, incluida la resistencia contra la penetración física y las fallas.

• El [C-1-8] DEBE tener resistencia de canal lateral, incluida la resistencia contra filtraciones de información a través de canales laterales de energía, sincronización, radiación electromagnética y radiación térmica.

• [C-1-9] DEBE tener un almacenamiento seguro que garantice la confidencialidad, integridad, autenticidad, coherencia y actualidad del contenido. El almacenamiento NO se DEBE poder leer ni modificar, excepto según lo permitan las APIs de StrongBox.

• Para validar el cumplimiento de [C-1-3] a [C-1-9], las implementaciones en dispositivos hacen lo siguiente:

  • [C-1-10] DEBE incluir el hardware certificado según el Perfil de protección de IC seguro BSI-CC-PP-0084-2014 o evaluado por un laboratorio de pruebas acreditado a nivel nacional que incorpore una evaluación de vulnerabilidad de alto potencial de ataque de acuerdo con la Aplicación de criterios comunes del potencial de ataque de las tarjetas inteligentes.
  • [C-1-11] DEBE incluir el firmware que evalúa un laboratorio de pruebas acreditado a nivel nacional que incorpora la evaluación de vulnerabilidades potenciales de alto ataque de acuerdo con la Aplicación de criterios comunes del potencial de ataque a las tarjetas inteligentes.
  • [C-SR-2] SE RECOMIENDA ENERCMENTE incluir el hardware evaluado mediante un objetivo de seguridad, un nivel de garantía de evaluación (EAL) 5, aumentado por AVA_VAN.5. Es probable que la certificación EAL 5 se convierta en un requisito en una versión futura.
  • Los [C-SR-3] SE RECOMIENDEN ENERGÍAMENTE para proporcionar resistencia ante ataques de usuarios con información privilegiada (IAR), lo que significa que un usuario con acceso a las claves de firma de firmware no puede producir firmware que haga que StrongBox filtre secretos, omita los requisitos de seguridad funcionales o habilite, de otro modo, el acceso a datos sensibles del usuario. La forma recomendada de implementar IAR es permitir las actualizaciones de firmware solo cuando la contraseña de usuario principal se proporciona a través de la HAL de IAuthSecret.

9.11.3 Credencial de identidad

El Sistema de credenciales de identidad se define y logra implementando todas las APIs del paquete android.security.identity.*. Estas APIs permiten a los desarrolladores de apps almacenar y recuperar documentos de identidad de usuarios. Implementaciones en dispositivos:

• [C-SR-1] se RECOMIENDA ENERGENTE para implementar el Sistema de credenciales de identidad.

Si las implementaciones de dispositivos implementan Identity Credential System, ocurrirá lo siguiente:

• [C-1-1] DEBE mostrar un valor no nulo para el método IdentityCredentialStore#getInstance().

• [C-1-2] SE 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 aislada de forma segura del código que se ejecuta en el kernel y en los posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos mediante los cuales el kernel o el código del espacio del usuario podrían 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 clave privada nunca DEBEN 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 (por ejemplo, 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 tiene un comportamiento incorrecto o se ve comprometido.

El Proyecto de código abierto de Android ascendente proporciona una implementación de referencia de una aplicación de confianza (libeic) que se puede usar para implementar el Sistema de credenciales de identidad.

9.12. Eliminación de Datos

Todas las implementaciones en dispositivos:

• [C-0-1] DEBE proporcionarles a los usuarios un mecanismo para restablecer la configuración de fábrica.
• [C-0-2] SE DEBE borrar todos los datos del sistema de archivos userdata cuando se realiza un “restablecimiento de la configuración de fábrica”.
• [C-0-3] SE DEBE borrar los datos de una manera que cumpla con los estándares relevantes de la industria, como NIST SP800-88, cuando se realiza un “restablecimiento de la configuración de fábrica”.
• [C-0-4] DEBE activar el proceso de "restablecimiento de la configuración de fábrica" anterior cuando la app del controlador de política de dispositivo del usuario principal llama a la API de DevicePolicyManager.wipeData().
• PUEDE proporcionar una opción de limpieza de datos rápida que lleve a cabo solo una eliminación lógica de datos.

9.13 Modo de inicio seguro

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

Las implementaciones en dispositivos son las siguientes:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE implementar el modo de inicio seguro.

Si las implementaciones de dispositivos implementan el modo de inicio seguro, harán lo siguiente:

• [C-1-1] DEBE brindarle al usuario la opción de ingresar al modo de inicio seguro de una manera que no se pueda interrumpir desde las apps de terceros instaladas en el dispositivo, excepto cuando la app de terceros es un controlador de política de dispositivo y estableció la marca UserManager.DISALLOW_SAFE_BOOT como verdadera.

• [C-1-2] DEBE brindar al usuario la posibilidad de desinstalar cualquier app de terceros en el modo seguro.

• SE DEBE ofrecerles al usuario la opción de ingresar al modo de inicio seguro desde el menú de inicio mediante un flujo de trabajo diferente al de un inicio normal.

9.14. Aislamiento de sistemas para vehículos

Se espera que los dispositivos Android Automotive intercambien datos con subsistemas críticos del vehículo usando la HAL del vehículo para enviar y recibir mensajes a través de redes del vehículo, como CAN bus.

El intercambio de datos se puede proteger implementando funciones de seguridad 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 en 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 una copia de seguridad de los planes de suscripción ni subirlos de forma remota.
• [C-0-3] solo DEBE permitir anulaciones, como SubscriptionManager.setSubscriptionOverrideCongested(), de la app del operador de telefonía celular que actualmente proporciona planes de suscripción válidos.

9.16. Migración de datos de aplicaciones

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 copia a lo que configura el desarrollador de la aplicación en el manifiesto a través del atributo android:fullBackupContent, sucede lo siguiente:

• [C-1-1] NO DEBE iniciar transferencias de datos de aplicaciones desde dispositivos en los que el usuario no estableció una autenticación principal, como se describe en 9.11.1 Autenticación y pantalla de bloqueo seguras.
• [C-1-2] DEBE confirmar de forma segura la autenticación principal en el dispositivo de origen y confirmar con la intención del usuario de copiar los datos en el dispositivo de origen antes de que se transfieran los datos.
• [C-1-3] SE DEBE usar la certificación de llave de seguridad para garantizar que tanto el dispositivo de origen como el 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 DEBE 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 se migraron datos al dispositivo de origen en el menú de configuración mediante una migración de datos de un dispositivo a otro. Los usuarios NO DEBEN poder quitar esta indicación.

9.17. Android Virtualization Framework

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework (android.system.virtualmachine.*), el host de Android hará lo siguiente:

• [C-1-1] DEBE admitir todas las APIs definidas por el paquete android.system.virtualmachine.
• [C-1-2] NO DEBE modificar el modelo de permisos y SELinux de Android para la administración de máquinas virtuales protegidas (pVM).

• [C-1-4] Solo DEBE permitir apps con privilegios y código firmado por la plataforma.NO DEBE permitir código que no sea de confianza (p. ej., apps de terceros) para crear y ejecutar una máquina virtual protegidapVM. Nota: Esto podría cambiar en versiones futuras de Android.

Si el dispositivo implementa la compatibilidad con las APIs de Android Virtualization Framework (android.system.virtualmachine.*), entonces cualquier instancia de pVM de máquina virtual protegida :

• [C-2-1] DEBE ser capaz de ejecutar todos los sistemas operativos disponibles en el APEX de virtualización en una máquina virtual protegida pVM .
• [C-2-2] NO DEBE permitir que una máquina virtual protegida pVM ejecute un sistema operativo que no esté firmado por el implementador de dispositivos ni por el proveedor del SO.
• [C-2-3] NO DEBE permitir que una máquina virtual protegida pVM ejecute datos como código (p.ej., SELinux nuncaallow execmem).

• [C-2-5] DEBE implementar mecanismos de defensa en profundidad de máquina virtual protegida pVM (p.ej., SELinux para pVM) incluso para sistemas operativos que no sean microdroid.
• [C-2-6] DEBE asegurarse de que la pVM falla el firmware se niega al inicio si no puede verificar las imágenes iniciales que la VM no puede ejecutar. La verificación DEBE realizarse dentro de la VM.
• [C-2-7] DEBE asegurarse de que la pVM falla el firmware se niega al inicio si se ve comprometida la integridad de instance.img.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework (android.system.virtualmachine.*), el hipervisor hace lo siguiente:

• [C-3-1] DEBE asegurarse de que las páginas de memoria que son propiedad exclusiva de una VM (ya sea una pVM o una VM host) sean accesibles solo para la máquina virtual o el hipervisor, no para otras máquinas virtuales, ya sean protegidas o no protegidas. NO DEBE permitir que una pVM tenga acceso a una página que pertenezca a otra entidad (es decir, otra pVM o hipervisor), a menos que el propietario de la página lo comparta de forma explícita. Esto incluye la VM del host. Esto se aplica a los accesos de CPU y DMA.
• [C-3-2] DEBE limpiar una página después de que la usa una pVM y antes de que regrese al host (p.ej., se destruye la pVM).
• [C-3-3SR-1] SE RECOMIENDA RECOMENDADAMENTE para garantizar SE DEBES garantizar que el firmware de la pVM se cargue y se ejecute antes de que se cargue cualquier código en una pVM.
• [C-3-4] SE DEBE asegurarse de que cada VM derive un secreto por VM que{la cadena de certificados de inicio (BCC) y el identificador de dispositivo compuesto (CDI) proporcionados a una instancia de pVM solo puedan derivarse a través de esa instancia de VM en particular y que los cambios se realicen al restablecimiento de la configuración de fábrica y de manera inalámbrica.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework, haz lo siguiente en todas las áreas:

• [C-4-1] NO DEBE proporcionar funcionalidad a una pVM que permita omitir el modelo de seguridad de Android.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework, sucede lo siguiente:

• [C-5-1] DEBE ser capaz de admitir la compilación aislada , pero puede inhabilitar la función de compilación aislada en el envío del dispositivo de una actualización del tiempo de ejecución de ART.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework, haz lo siguiente para Key Management:

• [C-SR-26-2] SE RECOMIENDA ENERGMENTE usar DICE como el mecanismo de derivación de secretos por VM. DEBE hacer DICE de forma correcta, es decir, proporcionar los valores correctos.

10. Pruebas de compatibilidad de software

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

10.1 Conjunto de pruebas de compatibilidad (CTS)

Implementaciones en 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 de envío final del dispositivo.

• [C-0-2] SE DEBE garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier reimplementación de partes del código fuente de referencia.

El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, el CTS puede contener errores. Se controlarán las versiones del CTS independientemente de esta definición de compatibilidad, y es posible que se publiquen varias revisiones del CTS para Android 14.

Implementaciones en dispositivos:

• [C-0-3] DEBE pasar la última versión disponible del CTS en el momento en que se completa el software del dispositivo.

• SE 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 está incluido en el Conjunto de pruebas de compatibilidad y está diseñado para que lo ejecute un operador humano a fin de probar funciones que un sistema automatizado no pueda probar, como el funcionamiento correcto de la cámara y los sensores.

Implementaciones en dispositivos:

• [C-0-1] DEBE ejecutar correctamente todos los casos aplicables en el verificador del CTS.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluidos algunos que son opcionales.

Implementaciones en dispositivos:

• [C-0-2] DEBE superar todas las pruebas de hardware que posean. Por ejemplo, si un dispositivo posee un acelerómetro, DEBE ejecutar correctamente el caso de prueba del acelerómetro en el verificador del CTS.

PUEDEN omitirse o omitirse los casos de prueba de las funciones indicadas como opcionales en este documento de definición de compatibilidad.

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

11. Software actualizable

• [C-0-1] Las implementaciones del dispositivo DEBEN incluir un mecanismo para reemplazar todo el software del sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, PUEDE ser necesario reiniciar el dispositivo. Se puede usar cualquier método, siempre que pueda reemplazar todo el software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques cumplirá con este requisito:

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

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

• [C-0-3] Se DEBE firmar toda la actualización, 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 EJECUTIVO al mecanismo de firma para generar un hash de la actualización con SHA-256 y validar el hash con la clave pública mediante ECDSA NIST P-256.

Si las implementaciones de dispositivos incluyen compatibilidad con una conexión de datos no medida, como el perfil 802.11 o el perfil de red de área personal (PAN) Bluetooth, deben hacer lo siguiente:

• [C-1-1] DEBE admitir descargas OTA con actualización sin conexión a través del reinicio.

Las implementaciones en dispositivos DEBEN verificar que la imagen del sistema sea binaria idéntica al resultado esperado después de una actualización inalámbrica. La implementación inalámbrica basada en bloques del Proyecto de código abierto de Android ascendente, agregado a partir de Android 5.1, cumple con este requisito.

Además, las implementaciones en dispositivos DEBEN admitir las actualizaciones del sistema A/B. AOSP implementa esta función mediante la HAL de control de inicio.

Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro del ciclo de vida razonable del producto, que se determina junto con el equipo de compatibilidad de Android para afectar la compatibilidad de aplicaciones de terceros, haz lo siguiente:

• [C-2-1] El implementador de dispositivos DEBE corregir el error mediante 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 del 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] SE DEBE implementar el comportamiento que se describe en la clase SystemUpdatePolicy.

12. Registro de cambios del documento

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

• Registro de cambios del documento

13. Comunícate con nosotros

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