Registro de cambios del Documento de definición de compatibilidad de Android

Android 14

26 de junio de 2024

2. Tipos de dispositivo

  • 2.2.1. Hardware:

    Ver revisión

    • [7.6.1/H-1-1] Solo DEBE admitir una única ABI (ya sea solo para 64 bits o solo para 32 bits).

    Ver revisión

    Comenzar con los nuevos requisitos

    Si las implementaciones de dispositivos de mano incluyen compatibilidad con Vulkan, sucederá lo siguiente:

  • 2.4.1. Hardware:

    Ver revisión

    Comenzar con los nuevos requisitos

    Si las implementaciones en dispositivos de reloj incluyen compatibilidad con Vulkan, ocurrirá lo siguiente:

  • 2.5.1. Hardware:

    Ver revisión

    Comenzar con los nuevos requisitos

    Si las implementaciones en dispositivos de Automotive incluyen compatibilidad con Vulkan, sucederá lo siguiente:

3. Software

  • 3.2.2. Parámetros de compilación:

    Para el parámetro ODM_SKU:

    Ver revisión

    El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular ^([0-9A-Za-z.,_-]+)$.

5. Compatibilidad con contenido multimedia

  • 5.1.3. Detalles de los códecs de audio:

    Se agregaron detalles para el códec o formato Vorbis:

    Ver revisión

    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, 24,000 y 24,000.

7. Compatibilidad de hardware

  • 7.1.4.2 Vulkan:

    Ver revisión

  • 7.7.1. Modo periférico USB:

    Eliminación de lo siguiente:

    Ver revisión

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

9. Compatibilidad del modelo de seguridad

  • 9.7. Función de seguridad:

    Se volvió a numerar [C-SR-1] a [C-SR-7] para quitar el contenido duplicado y se quitó [C-SR-8]:

    Ver revisión

    • [C-SR-1] SE RECOMIENDA ENRENDIDAMENTE 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-2] 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-3] SE RECOMIENDEN ENERGENTEMENTE para habilitar la integridad del flujo de control (CFI) en el kernel y así proporcionar protección adicional contra ataques de reutilización de código (p.ej., CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK).

    • [C-SR-4] SE RECOMIENDA 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-5] 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-6] SE RECOMIENDEN ENERGENTEmente para 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-7] SE RECOMIENDEN ENERGMENTE para habilitar la inicialización del montón en el kernel para evitar el uso de asignaciones de montón no inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) y NO DEBEN suponer el valor que usa el kernel para inicializar esas asignaciones.

  • 9.11. Claves y credenciales:

    Ver revisión

    • [C-1-6] DEBE admitir una de las siguientes opciones:
      • IKeymasterDevice 3.0,
      • IKeymasterDevice 4.0,
      • IKeymasterDevice 4.1,
      • IKeyMintDevice versión 1 o
      • IKeyMintDevice versión 2.

  • 9.11.1. Proteger la pantalla de bloqueo, la autenticación y los dispositivos virtuales:

    Ver revisión

    • [C-8-3] NO DEBEN exponer una API para que la usen aplicaciones de terceros para cambiar el estado de bloqueo.

    Ver revisión

    • [C-12-4] DEBE llamar a TrustManagerService.revokeTrust().
      • Después de un máximo de 24 horas desde que se otorga la confianza
      • Después de un período de inactividad de 8 horas
      • Si las implementaciones no usan un rango exacto y seguro a nivel criptográfico, como se define en [C-12-5], cuando se pierde la conexión subyacente con el dispositivo físico cercano.
    • [C-12-5] Las implementaciones que dependen de un rango seguro y preciso para cumplir con los requisitos de [C-12-4] DEBEN usar una de las siguientes soluciones:

8 de abril de 2024

2. Tipos de dispositivo

  • 2.2.1. Hardware:

    Ver revisión

    Comenzar con los nuevos requisitos

    Si las implementaciones de dispositivos de mano declaran FEATURE_BLUETOOTH_LE, hacen lo siguiente:

    • [7.4.3/H-1-3] DEBE medir y compensar el desplazamiento de recepción para garantizar que la mediana de RSSI de BLE sea de -50 dBm +/-15 dB a 1 m de distancia de un dispositivo de referencia que transmite a ADVERTISE_TX_POWER_HIGH.
    • [7.4.3/H-1-4] SE DEBE medir y compensar el desplazamiento de Tx para garantizar que la mediana de RSSI de BLE sea de -50 dBm +/-15 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.

  • 2.2.5. Modelo de seguridad:

    Ver revisión

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

    Ver revisión

    Cambia [9.8/H-1-13] a:

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

    Ver revisión

    Se quitaron los requisitos [9.8.2/H-4-3], [9.8.2/H-4-4] y [9.8.2/H-5-3].

  • 2.2.7.2. Cámara:

    Ver revisión

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

    • [7.5/H-1-3] DEBE admitir la propiedad android.info.supportedHardwareLevel como FULL o superior para la cámara principal posterior y LIMITED o mejor para la cámara principal frontal.

  • 2.3.2. Contenido multimedia:

    Ver revisión

    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.

3. Software

5. Compatibilidad con contenido multimedia

  • 5.3.8. Dolby Vision:

    Ver revisión

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

7. Compatibilidad de hardware

  • 7.1.1.1. Tamaño y forma de la pantalla:

    Ver revisión

    Si las implementaciones de dispositivos admiten pantallas compatibles con la configuración de tamaño UI_MODE_TYPE_NORMAL y usan pantallas físicas con esquinas redondeadas para renderizar esas pantallas, sucederá lo siguiente:

    • [C-1-1] DEBE asegurarse de que se cumpla al menos uno de los siguientes requisitos para cada una de esas pantallas:
      • 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.

  • 7.4.3. Bluetooth:

    Ver revisión

    Se restablecieron los siguientes requisitos:

    Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE, hará lo siguiente:

    • [C-SR-2] SE RECOMIENDA ENERCMENTE para medir y compensar el desplazamiento de recepción para garantizar que la mediana de RSSI de BLE sea de -60 dBm +/-10 dB a una distancia de 1 m de un dispositivo de referencia que transmita 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.

    • Los [C-SR-3] SE RECOMIENDEN ENERGENTEMENTE para medir y compensar el desplazamiento de Tx para garantizar que la mediana de RSSI de BLE 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 en la misma dirección.

    Ver revisión

    Se movieron los requisitos [C-10-3] y [C-10-4] a 2.2.1. Hardware.

    • [C-10-3] DEBE medir y compensar el desplazamiento de Rx para garantizar que la mediana de RSSI de BLE sea de -55 dBm +/-10 dB a una distancia de 1 m desde un dispositivo de referencia que transmite a ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] DEBE medir y compensar el desplazamiento de Tx para garantizar que la mediana de RSSI de BLE sea de -55 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.

20 de noviembre de 2023

2. Tipos de dispositivo

  • 2.2.1. Hardware:

    Ver revisión

    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:

  • 2.2.7.2. Cámara:

    Ver revisión

    • [7.5/H-1-13] DEBE admitir la función LOGICAL_MULTI_CAMERA para la cámara posterior principal si hay más de 1 cámara posterior RGB.

  • 2.3.2. Contenido multimedia:

    Ver revisión

    • [5.8/T-0-1] DEBE configurar el modo de salida HDMI en la resolución más alta para el formato SDR o HDR elegido que funcione con una frecuencia de actualización de 50 Hz o 60 Hz para la pantalla externa.

      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.

  • 2.4.5. Modelo de seguridad:

    Ver revisión

    • [9/W-0-1] DEBE declarar android.hardware.security.model.compatible feature.

6. Compatibilidad de las Herramientas y opciones para desarrolladores

  • 6.1. Herramientas para desarrolladores:

    Ver revisión

    • [C-0-12] SE DEBE escribir un Atom LMK_KILL_OCCURRED_FIELD_NUMBER en la

    Ver revisión

    • [C-0-13] DEBE implementar el comando de shell dumpsys gpu --gpuwork para mostrar

9. Compatibilidad del modelo de seguridad

  • 9.7. Funciones de seguridad:

    Ver revisión

    Si las implementaciones de dispositivos usan un kernel de Linux que es capaz de admitir SELinux, sucederá lo siguiente:

    Ver revisión

    Si las implementaciones de dispositivos usan un kernel distinto de Linux o Linux sin SELinux, hacen lo siguiente:

4 de octubre de 2023

2. Tipos de dispositivo

  • 2.2. Requisitos para dispositivos portátiles:

    Ver revisión

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

    • 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

    Comenzar con los nuevos requisitos

    • Tener una interfaz de entrada con pantalla táctil

  • 2.2.1. Hardware:

    Ver revisión

    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. una pantalla que mida al menos 2.2" en el borde corto y 3.4" en el borde largo.

    Si las implementaciones de dispositivos de mano admiten la rotación de pantalla de software, sucederá lo siguiente:

    • [7.1.1.1/H-1-1]* SE DEBE hacer que la pantalla lógica que está disponible para aplicaciones de terceros esté al menos a 2 pulgadas en los bordes cortos y 2.7 pulgadas en los bordes largos. Los dispositivos que se enviaron con el nivel de API 29 o versiones anteriores PUEDEN estar exentos de este requisito.

    Si las implementaciones de dispositivos de mano no admiten la rotación de pantalla de software, sucederá lo siguiente:

    • [7.1.1.1/H-2-1]* SE DEBE hacer que la pantalla lógica que está disponible para aplicaciones de terceros tenga al menos 2.7 pulgadas en los bordes cortos. Los dispositivos que se enviaron con el nivel de API 29 o versiones anteriores PUEDEN estar exentos de este requisito.

    Comenzar con los nuevos requisitos

    • [7.1.1.1/H-0-3]* SE DEBE asignar cada pantalla UI_MODE_NORMAL disponible para aplicaciones de terceros a un área de pantalla física sin obstrucciones que tenga al menos 2.2 pulgadas en el borde corto y 3.4 pulgadas en el borde largo.

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

    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 continua de ida y vuelta de 300 milisegundos o menos de 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 a los datos de la bocina al micrófono.

    Si las implementaciones en dispositivos de mano incluyen al menos un accionador táctil, sucederá lo siguiente:

    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 ubicar el accionador cerca de la ubicación donde las manos suelen sostenerlo o tocarlo.

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

  • 2.2.2. Contenido multimedia:

    Ver revisión

    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-3] AV1

    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-6] AV1

  • 2.2.3. Software:

    Ver revisión

    Si las implementaciones en dispositivos, incluida la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, modifican la interfaz, sucede lo siguiente:

    • [3.8.3/H-1-1] SE DEBE implementar el comportamiento de fijación de pantalla y proporcionarle al usuario un menú de configuración para activar o desactivar la función.

    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-6] Las implementaciones del dispositivo DEBEN renderizar con precisión la opción del usuario de la siguiente manera:
      • Si el dispositivo configuró config_supportsMultiWindow=true y la app declara los metadatos META_DATA_PANEL_ACTIVITY en la declaración ControlsProviderService, incluido el ComponentName de una actividad válida (según lo define la API), la app DEBE incorporar dicha actividad en esta prestación del usuario.
      • Si la app no declara metadatos META_DATA_PANEL_ACTIVITY, DEBE renderizar los campos especificados según lo que proporciona la API de ControlsProviderService, así como cualquier campo especificado que proporcionen las APIs de Control.
    • [3.8.16/H-1-7] Si la app declara los metadatos META_DATA_PANEL_ACTIVITY, DEBE pasar el valor de la configuración definida en [3.8.16/H-1-5] mediante EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS cuando se inicia la actividad incorporada.

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

  • 2.2.4. Rendimiento y potencia:

    Ver revisión

    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.

    • [8.5/H-0-2]DEBE proporcionar una indicación visual del usuario para detener una app que ejecuta un servicio en primer plano o una tarea iniciada por el usuario.

  • 2.2.5. Modelo de seguridad:

    Ver revisión

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

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

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

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

    Si las implementaciones de dispositivos de mano establecen UserManager.isHeadlessSystemUserMode en true,

    • [9.5/H-4-1] NO DEBE incluir compatibilidad con eUICC ni eSIM con función de llamadas.
    • [9.5/H-4-2] NO DEBE declarar compatibilidad con android.hardware.telephony.

    Si las implementaciones de dispositivos de mano admiten la API del sistema HotwordDetectionService o un 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-6] NO DEBE permitir que se transmitan más de 100 bytes de datos (excepto las transmisiones de audio) desde el servicio de detección de palabras clave en cada resultado exitoso de palabra clave.

    • [9.8/H-1-15] DEBE asegurarse de que las transmisiones de audio proporcionadas en los resultados de palabras clave correctas se transmitan unidireccionalmente desde el servicio de detección de palabras clave al servicio de interacción de voz.

    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-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 admiten la API del sistema VisualQueryDetectionService o algún otro mecanismo para la detección de consultas sin indicación de acceso al micrófono o a la cámara, sucederá lo siguiente:

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

  • 2.2.7.1. Contenido multimedia:

    Ver revisión

    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:

    Comenzar con los nuevos requisitos

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

    • [5.1/H-1-1] DEBE anunciar la cantidad máxima de sesiones de decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códecs a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] DEBE admitir 6 sesiones de decodificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs que se ejecuten simultáneamente con 3 sesiones a una resolución de 1080p a 30 FPS y 3 sesiones a una resolución de 4K a 30 fps, a menos que AV a 30 FPS Los códecs de AV1 solo se requieren para admitir una resolución de 1080p, pero de todos modos son necesarios para admitir 6 instancias a 1080p30 fps.
    • [5.1/H-1-3] DEBE anunciar la cantidad máxima de sesiones de codificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códecs a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] DEBE admitir 6 sesiones de codificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs que se ejecuten al mismo tiempo con 4 sesiones a una resolución de 1080p a 30 FPS y 2 sesiones a una resolución de 4K a 30 fps, a menos que se ejecute AV1. Los códecs de AV1 solo se requieren para admitir una resolución de 1080p, pero de todos modos son necesarios para admitir 6 instancias a 1080p30 fps.
    • [5.1/H-1-5] DEBE anunciar la cantidad máxima de sesiones de codificador de video por hardware y decodificador que se pueden ejecutar simultáneamente en cualquier combinación de códecs a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] DEBE admitir 6 instancias de decodificador de video de hardware de 8 bits (SDR) y sesiones de codificador de video de hardware (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs que se ejecuten simultáneamente con 3 sesiones a 4K a 30 FPS (a menos que sea AV1), de las cuales 8 sesiones de resolución son de codificador, como máximo, y 30 sesiones son de codificador. Los códecs de AV1 solo se requieren para admitir una resolución de 1080p, pero de todos modos son necesarios para admitir 6 instancias a 1080p30 fps.
    • [5.1/H-1-19] DEBE admitir 3 instancias de decodificador de video de hardware de 10 bits (HDR) y sesiones de codificador de video de hardware (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs que se ejecuten simultáneamente a una resolución de 4K a 30 FPS (a menos que AV1) de las cuales, como máximo, 1 sea una sesión de codificador de superficie GL20 a través del codificador GL20 y una sesión de entrada RGB1. El codificador no genera metadatos de HDR si se codifica desde la superficie de GL. Las sesiones de códecs de AV1 solo deben admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
    • [5.1/H-1-7] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de codificación de video de 1080p o menor para todos los codificadores de video de hardware cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación solo de video de 1080p a 720p que usa códecs de video por hardware junto con la inicialización de grabación de audio y video en 1080p. Para el códec de Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
    • [5.1/H-1-8] DEBE tener una latencia de inicialización de códec de 30 ms o menos para una sesión de codificación de audio de 128 Kbps o menor tasa de bits para todos los codificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación solo de video de 1080p a 720p que usa códecs de video por hardware junto con la inicialización de grabación de audio y video en 1080p.
    • [5.1/H-1-9] DEBE admitir 2 instancias de sesiones de decodificador de video de hardware seguro (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs que se ejecuten simultáneamente a una resolución de 4K a 30 FPS (a menos que AV1) para contenido HDR de 8 bits (SDR) y 10 bits. Las sesiones de códecs de AV1 solo deben admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
    • [5.1/H-1-10] DEBE admitir 3 instancias de sesiones de decodificador de video de hardware no seguro junto con 1 instancia de sesión de decodificador de video de hardware seguro (4 instancias en total) (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecuten en simultáneo con 3 sesiones a 4K de resolución a 30 fps y 30 fps seguros, en los que la mayoría de las sesiones de AV-20 fps de resolución n 30 pueden ser de 10 FPS seguras a resolución 4K y 30 fps a 30 fps de resolución segura, y una sesión AV1 a 30 fps, que una Las sesiones de códecs de AV1 solo deben admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
    • [5.1/H-1-11] DEBE admitir un decodificador seguro para cada decodificador AVC, HEVC, VP9 o AV1 de hardware en el dispositivo.
    • [5.1/H-1-12] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de decodificación de video de 1080p o menor para todos los decodificadores de video de hardware cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación solo de video de 1080p a 720p que usa códecs de video de hardware junto con la inicialización de reproducción de audio y video en 1080p. Para el códec de Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
    • [5.1/H-1-13] DEBE tener una latencia de inicialización de códec de 30 ms o menos para una sesión de decodificación de audio de 128 Kbps o una tasa de bits inferior para todos los decodificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación solo de video de 1080p a 720p que usa códecs de video por hardware junto con la inicialización de reproducción de audio y video en 1080p.
    • [5.1/H-1-14] DEBE ser compatible con el decodificador de hardware de AV1 Main 10, Nivel 4.1 y grano de película.
    • [5.1/H-1-15] DEBE tener al menos 1 decodificador de video por hardware compatible con 4K60.
    • [5.1/H-1-16] DEBE tener al menos 1 codificador de video de hardware compatible con 4K60.
    • [5.3/H-1-1] NO DEBE reducir más de 1 fotograma en 10 segundos (es decir, menos de 0.167 por ciento de caída de fotogramas) para una sesión de video 4K a 60 FPS bajo carga.
    • [5.3/H-1-2] NO DEBE reducir más de 1 fotograma en 10 segundos durante un cambio de resolución de video en una sesión de video de 60 FPS bajo carga para una sesión en 4K.
    • [5.6/H-1-1] DEBE tener una latencia de toque a tono de 80 milisegundos o menos con la prueba de toque a tono del verificador del CTS.
    • [5.6/H-1-2] DEBE tener una latencia de audio de ida y vuelta de 80 milisegundos o menos en al menos una ruta de acceso de datos admitida.
    • [5.6/H-1-3] DEBE admitir audio de más de 24 bits para salida estéreo de más de 3.5 mm de audio con conectores de audio de 3.5 mm, si están presentes, y a través de audio USB, si se admite en toda la ruta de datos, para baja latencia y configuraciones de transmisión. Para la configuración de baja latencia, la app debe usar AAudio en el modo de devolución de llamada de baja latencia. Para la configuración de transmisión, la app debe usar AudioTrack de Java. En las configuraciones de latencia baja y de transmisión, el receptor de salida de HAL debe aceptar AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT como su formato de salida objetivo.
    • [5.6/H-1-4] DEBE admitir dispositivos de audio USB de más de 4 canales (esto lo utilizan los controladores de DJ para obtener una vista previa de las canciones).
    • [5.6/H-1-5] DEBE admitir dispositivos MIDI compatibles con la clase y declarar la marca de función MIDI.
    • [5.6/H-1-9] DEBE admitir una combinación de al menos 12 canales. lo que implica la capacidad de abrir un audioTrack con una máscara de canal 7.1.4 y de espacializar de manera correcta o mezclar todos los canales en estéreo.
    • [5.6/H-SR] SE RECOMIENDA EJECUTAR que admitan la combinación de 24 canales con, al menos, compatibilidad con las máscaras de canal 9.1.6 y 22.2.
    • [5.7/H-1-2] DEBE admitir MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con las siguientes capacidades de desencriptación de contenido.
    Tamaño mínimo de la muestra 4 MiB
    Cantidad mínima de submuestras: H264 o HEVC 32
    Cantidad mínima de submuestras: VP9 9
    Cantidad mínima de submuestras: AV1 288
    Tamaño mínimo del búfer de la submuestra 1 MiB
    Tamaño mínimo de búfer criptográfico genérico 500 KiB
    Cantidad mínima de sesiones simultáneas 30
    Cantidad mínima de claves por sesión 20
    Cantidad total mínima de claves (todas las sesiones) 80
    Cantidad total mínima de claves de DRM (todas las sesiones) 6
    Tamaño del mensaje 16 KiB
    Fotogramas desencriptados por segundo 60 FPS
    • [5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes de hardware compatible con el perfil de Baseline de AVIF.
    • [5.1/H-1-18] DEBE ser compatible con el codificador AV1 que puede codificar una resolución de hasta 480p a 30 FPS y 1 Mbps.
    • [5.12/H-1-1] DEBE [5.12/H-SR] Son muy recomendados para admitir la función Feature_HdrEditing para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
    • [5.12/H-1-2] DEBE admitir el formato de color RGBA_1010102 para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
    • [5.12/H-1-3] DEBE anunciar la compatibilidad con la extensión EXT_YUV_target para tomar muestras de texturas YUV en 8 y 10 bits.
    • [7.1.4/H-1-1] DEBE tener al menos 6 superposiciones de hardware en el Compositor de hardware (HWC) de la unidad de procesamiento de datos (DPU), y al menos 2 de ellas deben poder mostrar contenido de video de 10 bits.

    Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e incluyen compatibilidad con un codificador AVC o HEVC de hardware, sucederá lo siguiente:

    • [5.2/H-2-1] DEBE cumplir con el objetivo de calidad mínimo definido por las curvas de distorsión de frecuencia del codificador de video para los códecs AVC y HEVC de hardware, como se define en la documentación futura.

  • 2.2.7.2. Cámara:

    Ver revisión

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

    • [7.5/H-1-1] DEBE tener una cámara posterior principal con una resolución de al menos 12 megapíxeles que admita la captura de video a 4K a 30 FPS. La cámara posterior principal es la posterior con el ID de cámara más bajo.
    • [7.5/H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 6 megapíxeles y admitir la captura de video a 1080p a 30 FPS. La cámara frontal principal es la que tiene el ID de cámara más bajo.
    • [7.5/H-1-3] DEBE admitir la propiedad android.info.supportedHardwareLevel como FULL o mejor para ambas cámaras principales.
    • [7.5/H-1-4] DEBE admitir CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para ambas cámaras principales.
    • [7.5/H-1-5] DEBE tener una latencia de captura JPEG de la cámara2 inferior a 1,000 900 ms para una resolución de 1080p según la medición de la PerformanceTest de la cámara del CTS en condiciones de iluminación del ITS (3,000 K) para ambas cámaras principales.
    • [7.5/H-1-6] DEBE tener una latencia de inicio de camera2 (abre la cámara para el primer fotograma de vista previa) inferior a 500 ms, según la medición de la PerformanceTest de la cámara del CTS en condiciones de iluminación del ITS (3,000 K) para ambas cámaras principales.
    • [7.5/H-1-8] DEBE admitir CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW y android.graphics.ImageFormat.RAW_SENSOR para la cámara posterior principal.
    • [7.5/H-1-9] DEBE tener una cámara posterior principal que admita 720p o 1080p a 240 FPS.
    • [7.5/H-1-10] DEBE tener un mínimo de ZOOM_RATIO < 1.0 para las cámaras principales si hay una cámara RGB ultra gran angular orientada en la misma dirección.
    • [7.5/H-1-11] DEBE implementar la transmisión frontal simultánea en las cámaras principales.
    • [7.5/H-1-12] DEBE admitir CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para la cámara frontal principal y la cámara posterior principal.
    • [7.5/H-1-13] DEBE admitir la función LOGICAL_MULTI_CAMERA para las cámaras principales si hay más de 1 cámara RGB orientada en la misma dirección.
    • [7.5/H-1-14] DEBE admitir la capacidad STREAM_USE_CASE para la cámara frontal principal y la cámara posterior principal.
    • [7.5/H-1-15] DEBE admitir extensiones de Bokeh y de Modo nocturno a través de extensiones de CameraX y Camera2 para las cámaras principales.
    • [7.5/H-1-16] DEBE admitir la capacidad DYNAMIC_RANGE_TEN_BIT para las cámaras principales.
    • [7.5/H-1-17] DEBE admitir CONTROL_SCENE_MODE_FACE_PRIORITY y la detección de rostro (STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL) para las cámaras principales.

  • 2.2.7.3. Hardware:

    Ver revisión

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

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

  • 2.2.7.4. Rendimiento:

    Ver revisión

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

    • [8.2/H-1-1] SE DEBE garantizar un rendimiento de escritura secuencial de al menos 150 MB/s.
    • [8.2/H-1-2] SE DEBE garantizar un rendimiento de escritura aleatorio de al menos 10 MB/s.
    • [8.2/H-1-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 250 MB/s.
    • [8.2/H-1-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 100 MB/s.
    • [8.2/H-1-5] DEBE garantizar un rendimiento de lectura y escritura secuenciales paralelos con el doble de rendimiento de lectura y 1 vez de escritura de al menos 50 MB/s.

  • 2.3.2. Contenido multimedia:

    Ver revisión

    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-3] AV1

    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:

  • 2.4.5. Modelo de seguridad:

    Ver revisión

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

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

  • 2.5.1. Hardware:

    Ver revisión

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

    • [7.4.10/A-0-1] DEBE declarar la compatibilidad con FEATURE_BROADCAST_RADIO.

    Una cámara de vista exterior es una cámara que genera imágenes fuera de la implementación del dispositivo, como la cámara de retroceso.

    Implementaciones en dispositivos de Automotive:

    • SE DEBE incluir una o más cámaras de vista exterior.

    Si las implementaciones en dispositivos de Automotive incluyen una cámara de vista exterior para esa cámara, sucederá lo siguiente:

    • [7.5/A-1-1] NO DEBE tener cámaras de vista exterior accesibles a través de las APIs de Android Camera, a menos que cumplan con los requisitos principales de la cámara.
    • [7.5/A-SR-1] SE RECOMIENDA ESPECÍFICAMENTE no rotar ni duplicar de forma horizontal la vista previa de la cámara.
    • [7.5/A-SR-2] SE RECOMIENDA ENcarecidamente que tengan una resolución de al menos 1.3 megapíxeles.
    • SE DEBE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
    • PUEDE tener implementado un enfoque automático de hardware o de software en el controlador de la cámara.

    Si las implementaciones en dispositivos de automóviles incluyen una o más cámaras de vista exterior y cargan el servicio del sistema de vista exterior (EVS), entonces, para esa cámara, deben hacer lo siguiente:

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

    Implementaciones en dispositivos de Automotive:

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

    Si las implementaciones en dispositivos de automóviles incluyen al menos una cámara y permiten que esté disponible para aplicaciones de terceros, sucede lo siguiente:

    • [7.5/A-3-1] SE DEBE informar la marca de función android.hardware.camera.any.
    • [7.5/A-3-2] No se DEBE declarar la cámara como una cámara del sistema.
    • PUEDE ser compatible con las cámaras externas que se describen en la sección 7.5.3.
    • PUEDE incluir funciones (como enfoque automático, etc.) disponibles para las cámaras posteriores, como se describe en la sección 7.5.1.

    Una cámara trasera significa una cámara orientada al mundo que puede ubicarse en cualquier lugar del vehículo y apuntar hacia el exterior de la cabina del vehículo; es decir, captura escenas en el lado más alejado de la carrocería del vehículo, como la cámara de vista posterior.

    Una cámara frontal hace referencia a una cámara orientada al usuario que puede ubicarse en cualquier lugar del vehículo y orientada dentro de la cabina del vehículo; es decir, imágenes del usuario, como para videoconferencias y aplicaciones similares.

    Implementaciones en dispositivos de Automotive:

    • [7.5/A-SR-1] SE RECOMIENDA ENERCMENTE que incluyan una o más cámaras orientadas al mundo.
    • PUEDE incluir una o más cámaras para el usuario.
    • [7.5/A-SR-2] SE RECOMIENDA ES IMPORTANTE para admitir la transmisión simultánea de varias cámaras.

    Si las implementaciones en dispositivos de Automotive incluyen al menos una cámara orientada al mundo, para esa cámara, deben hacer lo siguiente:

    • [7.5/A-1-1] DEBE orientarse para que la dimensión larga de la cámara se alinee con el plano X-Y de los ejes de los sensores de automóviles de Android.
    • [7.5/A-SR-3] SE RECOMIENDA ENcarecidamente tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
    • [7.5/A-1-2] DEBE tener la cámara frontal principal como la cámara frontal con el ID de cámara más bajo.

    Si las implementaciones en dispositivos de Automotive incluyen al menos una cámara orientada al usuario, para esa cámara, haz lo siguiente:

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

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

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

    Si las implementaciones de dispositivos de Automotive incluyen una cámara a la que no se puede acceder con la API de android.hardware.Camera o android.hardware.camera2, sucede lo siguiente:

    • Se DEBE poder acceder a [7.5/A-4-1] a través del servicio de Extended View System.

    Si las implementaciones en dispositivos de Automotive incluyen una o más cámaras a las que se puede acceder a través del servicio del sistema de Vista extendida, para una cámara de este tipo, harán lo siguiente:

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

    Si las implementaciones en dispositivos de automóviles incluyen una o más cámaras a las que se puede acceder a través del servicio de sistema de vista extendida y la API de android.hardware.Camera o android.hardware.Camera2, entonces, para esa cámara, deben hacer lo siguiente:

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

    Si las implementaciones en dispositivos de Automotive proporcionan una API de cámara de propiedad, sucederá lo siguiente:

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

  • 2.5.3. Software:

    Ver revisión

    Implementaciones en dispositivos de Automotive:

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

  • 2.5.5. Modelo de seguridad:

    Ver revisión

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

    • [9.8.2/A-1-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/A-1-2] No DEBE ocultar el indicador del micrófono para las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
    • [9.8.2/A-1-3] DEBE proporcionar una indicación visual del usuario para activar o desactivar el micrófono en la app de Configuración.

    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-3] DEBE proporcionar una indicación visual del usuario para activar o desactivar la cámara en la app de Configuración.
    • [9.8.2/A-2-4] DEBE mostrar las apps recientes y activas que usan la cámara como se muestra desde PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensaje de atribución asociado a ellas.

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

    • [9.11.1/A-1-1] DEBE desafiar al usuario a uno de los métodos de autenticación principales recomendados (p. ej., PIN, patrón o contraseña) con una frecuencia mayor que una vez cada 336 horas.

3. Software

  • 3.1. Compatibilidad de la API administrada:

    Ver revisión

    Implementaciones en dispositivos:

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

  • 3.2.3.5. Intents de aplicación condicionales:

    Ver revisión

    Si las implementaciones de dispositivos informan android.hardware.nfc.uicc o android.hardware.nfc.ese, harán lo siguiente:

  • 3.3.1. Interfaces binarias de la aplicación:

    Ver revisión

    Implementaciones en dispositivos:

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

  • 3.8.6. Temas:

    Ver revisión

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

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

  • 3.8.8. Cambio de actividad:

    Ver revisión

    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:

  • 3.9.2 Asistencia para perfiles administrados:

    Ver revisión

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

    • [C-1-10] DEBE asegurarse de que los datos de la captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se realice con una ventana topActivity que tenga enfoque (la que el usuario interactuó en último lugar entre todas las actividades) y pertenezca a una app de perfil de trabajo.
    • [C-1-11] NO DEBE capturar ningún otro contenido de pantalla (barra del sistema, notificaciones o contenido de perfil personal), excepto las ventanas/ventanas de la aplicación del perfil de trabajo cuando se guarda una captura de pantalla en el perfil de trabajo (para garantizar que los datos de perfil personal no se guarden en el perfil de trabajo).

  • 3.9.5 Marco de trabajo de resolución de políticas de dispositivos: Sección nueva

    Ver revisión

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

    • [C-1-1] SE DEBE resolver los conflictos de políticas de dispositivos según se documenta en la documentación del AOSP.

5. Compatibilidad con contenido multimedia

  • 5.1.4. Codificación de imágenes:

    Ver revisión

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

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

  • 5.1.5. Decodificación de imágenes:

    Ver revisión

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

    [C-0-7] AVIF (perfil de Baseline)

  • 5.1.6. Detalles de los códecs de imagen:

    Ver revisión

    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)

  • 5.1.8. Lista de códecs de video:

    Ver revisión

    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
    VP9 Consulta la sección 5.3 para obtener más información.
    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.10. Clasificación de códecs de medios:

    Ver revisión

    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)

  • 5.2. Codificación de videos:

    Ver revisión

    Si las implementaciones en dispositivos son compatibles con cualquier codificador de video y permiten que estén disponibles para apps de terceros, deben cumplir con lo siguiente:

    • En dos ventanas variables, NO se DEBE superar el 15% de la tasa de bits entre los intervalos entre el marco (I-frame).
    • NO DEBERÍA ser superior al 100% sobre la tasa de bits en una ventana variable de 1 segundo.

    Si las implementaciones de dispositivos admiten cualquier codificador de video y lo ponen a disposición de apps de terceros y establece la MediaFormat.KEY_BITRATE_MODE de
    en BITRATE_MODE_VBR para que el codificador funcione en el modo de tasa de bits variable, siempre y cuando no afecte el valor mínimo de calidad mínimo, la tasa de bits codificada :

    • [C-5-1] DEBE NO DEBE ser, en una ventana variable, más del 15% sobre la tasa de bits entre intervalos intraframe (I-frame).
    • [C-5-2] DEBE NO DEBE ser superior al 100% sobre la tasa de bits en una ventana variable de 1 segundo.

    Si las implementaciones de dispositivos admiten cualquier codificador de video y lo ponen a disposición de apps de terceros y estableces MediaFormat.KEY_BITRATE_MODE en BITRATE_MODE_CBR para que el codificador funcione en un modo de tasa de bits constante, esto significa la tasa de bits codificada:

    • [C-6-1] SE DEBE [C-SR-2] SE RECOMIENDA ES IMPORTANTE que NO sea más del 15% sobre la tasa de bits objetivo en una ventana variable de 1 segundo.

  • 5.2.1. H.263:

    Ver revisión

    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.5. H.265:

    Ver revisión

    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.

  • 5.2.6. AV1: sección nueva

    Ver revisión

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

    • [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.

    • [C-1-2] SE DEBE publicar los datos de rendimiento, es decir, informar los datos de rendimiento a través de las APIs de getSupportedFrameRatesFor() o getSupportedPerformancePoints() para las resoluciones compatibles en la siguiente tabla.

    • [C-1-3] DEBE aceptar metadatos de HDR y enviarlos al flujo de bits.

    Si el codificador AV1 está acelerado por hardware, hará lo siguiente:

    • [C-2-1] DEBE admitir hasta el perfil de codificación HD1080p incluido en la tabla que aparece a continuación:
    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 5 Mbps 8 Mbps 16 Mbps 50 Mbps

  • 5.3.2. H.263:

    Ver revisión

    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.9. AV1:

    Ver revisión

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

    • [C-1-1] DEBE admitir el perfil 0, incluido el contenido de 10 bits.

    Si las implementaciones de dispositivos admiten el códec AV1 y permiten que esté disponible para aplicaciones de terceros, sucederá lo siguiente:

    • [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.

    Si las implementaciones de dispositivos proporcionan compatibilidad con el códec AV1 con un decodificador acelerado por hardware, sucede lo siguiente:

    • [C-2-1] DEBE poder decodificar al menos perfiles de decodificación de video HD 720p de la tabla a continuación cuando la altura informada por el método Display.getSupportedModes() es igual o superior a 720p.
    • [C-2-2] DEBE poder decodificar al menos perfiles de decodificación de video HD de 1080p de la tabla que aparece a continuación cuando la altura informada por el método Display.getSupportedModes() es igual o superior a 1080p.
    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 5 Mbps 8 Mbps 16 Mbps 50 Mbps

    Si las implementaciones de dispositivos admiten perfiles HDR a través de las APIs de contenido multimedia, sucederá lo siguiente:

    • [C-3-1] DEBE admitir la extracción y la salida de metadatos de HDR del flujo de bits o del contenedor.
    • [C-3-2] DEBE mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).

  • 5.4.2. Captura para reconocimiento de voz:

    Ver revisión

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

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

  • 5.5.2. Efectos de audio:

    Ver revisión

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

    • [C-1-4] DEBE admitir efectos de audio con entrada y salida de punto flotante.
    • [C-1-5] DEBE asegurarse de que los efectos de audio admitan varios canales hasta el recuento de canales del mezclador, también conocido como FCC_LIMIT.

  • 5.6. Latencia de audio:

    Ver revisión

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

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

    • [C-SR-4] Se RECOMIENDA QUE las latencias de ida y vuelta calculadas basadas en las marcas de tiempo de entrada y salida que muestra AAudioStream_getTimestamp estén dentro de los 30 ms de la latencia medida de ida y vuelta para AAUDIO_PERFORMANCE_MODE_NONE y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para bocinas, auriculares inalámbricos y con cable.

7. Compatibilidad de hardware

  • 7.1. Pantalla y gráficos:

    Ver revisión

    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.

    Comenzar con los nuevos requisitos

    Implementaciones en dispositivos:

    • [C-0-1] DEBE, de forma predeterminada, renderizar aplicaciones de terceros solo en pantallas compatibles con Android.

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

    • tamaño diagonal físico. Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
    • 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.1. Tamaño y forma de la pantalla:

    Ver revisión

    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 un cuadro de 15 dp por 15 dp se ancla 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.

    Comenzar con los nuevos requisitos

    Si las implementaciones en dispositivos solo pueden configurar el teclado NO_KEYS y tienen la intención de informar la compatibilidad con la configuración del modo de IU UI_MODE_TYPE_NORMAL, harán lo siguiente:

    • [C-4-1] DEBE tener un tamaño de diseño de al menos 596 dp x 384 dp (sin incluir cortes de pantalla) o superior.

    Si las implementaciones en dispositivos incluyen pantallas plegables o compatibles con Android, o que incluyen una bisagra plegable entre varios paneles de la pantalla y ponen esas pantallas a disposición para renderizar apps de terceros, deben hacer lo siguiente:

    Si las implementaciones de dispositivos incluyen pantallas plegables o compatibles con Android, o que incluyen una bisagra plegable entre varios paneles de la pantalla, y si la bisagra o el pliegue cruzan una ventana de aplicación de pantalla completa, hacen lo siguiente:

    • [C-3-1] DEBE informar la posición, los límites y el estado de la bisagra o el pliegue a través de extensiones o APIs de sidecar a la aplicación.

    Si las implementaciones en dispositivos incluyen una o más áreas de la pantalla plegables compatibles con Android, o bien incluyen una bisagra plegable entre varias áreas del panel de la pantalla compatibles con Android y permiten que esas áreas de visualización estén disponibles para las aplicaciones, sucede lo siguiente:

    • [C-4-1] DEBE implementar la versión correcta del nivel de API de las extensiones de Window Manager como se describe en la próxima documentación.

  • 7.1.1.2. Relación de aspecto de la pantalla: quitada

  • 7.1.1.3. Densidad de la pantalla:

    Ver revisió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 enumeran 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 DEBEN cambiar en ningún momento; sin embargo, puede modificarse la configuración de pantalla.2 El usuario configura la pantalla según los cambios de arranque/arranque.DisplayMetrics.density

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

    Comenzar con los nuevos requisitos

    • SE DEBE definir la densidad estándar del framework de Android que sea numéricamente más cercana a la densidad física de la pantalla o un valor que se asigne a las mismas mediciones del campo visual angular equivalente de un dispositivo de mano.

    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.

  • 7.1.4.2 Vulkan:

    Ver revisión

    Si las implementaciones en dispositivos incluyen compatibilidad con Vulkan 1.0 o versiones posteriores, sucede lo siguiente:

    • [C-1-3] SE DEBE implementar por completo las APIs de Vulkan 1.0 Vulkan 1.1 para cada VkPhysicalDevice enumerado.

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

    • SE DEBE admitir VkPhysicalDeviceProtectedMemoryFeatures y VK_EXT_global_priority.

    • [C-SR-5] SE RECOMIENDA ENERGENTE para admitir VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory y VK_EXT_global_priority.

    • [C-SR-6] SE RECOMIENDA ENcarecidamente usar SkiaVk con HWUI.

    Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.1 y declaran cualquiera de las marcas de función de Vulkan que se describen aquí , sucede lo siguiente:

    • [C-SR-7] SE RECOMIENDA ENERGENTE para hacer que la extensión VK_KHR_external_fence_fd esté disponible para aplicaciones de terceros y permitir que la aplicación exporte la carga útil de valla e importe una carga útil de valla desde descriptores de archivo POSIX como se describe aquí.

  • 7.3.10. Sensores biométricos:

    Ver revisión

    Si las implementaciones de dispositivos tienen varios sensores biométricos:

    • [C-7-1] DEBE, cuando los datos biométricos están bloqueados (es decir, cuando los datos biométricos están inhabilitados hasta que el usuario desbloquea el dispositivo con la autenticación principal) o por tiempo limitado (es decir, los datos biométricos se inhabilitan temporalmente hasta que el usuario espera un intervalo de tiempo) debido a demasiados intentos fallidos, también se deben bloquear todos los demás datos biométricos de una clase biométrica inferior. En el caso del bloqueo por tiempo limitado, el tiempo de retirada para la verificación biométrica DEBE ser el tiempo de retirada máximo de todos los datos biométricos en el bloqueo por tiempo limitado.

    • [C-SR-12] SE RECOMIENDEN ENERGÍAMENTE cuando un sistema biométrico está bloqueado (es decir, cuando se inhabilita hasta que el usuario desbloquea con la autenticación principal) o el bloqueo por tiempo limitado (es decir, el dato biométrico se inhabilita de forma temporal hasta que el usuario espera durante un intervalo de tiempo) debido a demasiados intentos fallidos, a fin de excluir también todos los demás datos biométricos de la misma clase. En el caso del bloqueo por límite de tiempo, se RECOMIENDA QUE el tiempo de retirada para la verificación biométrica sea el tiempo de retirada máximo de todos los datos biométricos en el bloqueo por plazos determinados.

    • [C-7-2] SE DEBE solicitar al usuario la autenticación principal recomendada (p. ej., PIN, patrón, contraseña) para restablecer el contador de bloqueo de datos biométricos que se bloquearán. PUEDE permitirse que los datos biométricos de clase 3 restablezcan el contador de bloqueo de un biométrico bloqueado de la misma clase o una inferior. NO se DEBE permitir el restablecimiento de los datos biométricos de clase 2 o clase 1 para completar una operación de bloqueo de datos biométricos.

    Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 1 (anteriormente Conveniencia), hacen lo siguiente:

    • [C-1-12] DEBE tener una tasa de aceptación de falsificación de identidad y impostor que no supere el 40% por especie de instrumento de ataque de presentación (PAI), según las mediciones de los Protocolos de prueba de datos biométricos de Android.

    • [C-SR-13] SE RECOMIENDA ENcarecidamente tener una tasa de aceptación de falsificación de identidad y impostor que no supere el 30% por especie de instrumento de ataque de presentación (PAI), según las mediciones de los Protocolos de prueba de datos biométricos de Android.

    • [C-SR-14] SE RECOMIENDA ENERCMENTE divulgar la clase biométrica del sensor biométrico y los riesgos correspondientes de habilitarlos.

    • [C-SR-17] SE RECOMIENDA MUY BIEN implementar las interfaces de AIDL nuevas (como IFace.aidl y IFingerprint.aidl).

    Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 2 (anteriormente Débil), sucede lo siguiente:

    • [C-SR-15] SE RECOMIENDA ENcarecidamente tener una tasa de aceptación de falsificación de identidad y impostor que no supere el 20% por especie de instrumento de ataque de presentación (PAI), según las mediciones de los Protocolos de prueba de datos biométricos de Android.

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

    Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 3 (anteriormente Strong), hacen lo siguiente:

    • [C-SR-16] SE RECOMIENDA ENcarecidamente tener una tasa de aceptación de falsificación de identidad y impostor que no supere el 7% por especie de instrumento de ataque de presentación (PAI), según las mediciones de los Protocolos de prueba de datos biométricos de Android.

  • 7.3.13. IEEE 802.1.15.4 (UWB):

    Ver revisión

    Si las implementaciones de dispositivos incluyen compatibilidad con 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, deben hacer lo siguiente:

    • [C-1-2] SE DEBE informar la marca de función de hardware android.hardware.uwb.
    • [C-1-3] DEBE admitir todos los siguientes conjuntos de configuración (combinaciones predefinidas de los parámetros FIRA UCI) definidos en la implementación de AOSP.
      • CONFIG_ID_1: Rango de unidifusión STATIC STS DS-TWR definido por FiRa, modo diferido, intervalo de 240 ms
      • CONFIG_ID_2: Rango de STATIC STS DS-TWR de uno a varios definidos por FiRa, modo diferido, intervalo de 200 ms. Caso de uso típico: un smartphone interactúa con muchos dispositivos inteligentes.
      • CONFIG_ID_3: Igual que CONFIG_ID_1, excepto que no se informan los datos del ángulo de llegada (AoA).
      • CONFIG_ID_4: Igual que CONFIG_ID_1, excepto que el modo de seguridad de P-STS está habilitado.
      • CONFIG_ID_5: Igual que CONFIG_ID_2, excepto que el modo de seguridad de P-STS está habilitado.
      • CONFIG_ID_6: Igual que CONFIG_ID_3, excepto que el modo de seguridad de P-STS está habilitado.
      • CONFIG_ID_7: Igual que CONFIG_ID_2, excepto que el modo de clave de control individual de P-STS está habilitado.
    • [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 tengan el permiso UWB_RANGING (en el grupo de permisos NEARBY_DEVICES).

    Aprobar las pruebas de cumplimiento y certificación relevantes definidas por las organizaciones estándar, incluidas FIRA, CCC y CSA, ayuda a garantizar que el estándar 802.1.15.4 funcione correctamente.

  • 7.4.1. Telefonía:

    Ver revisión

    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 bien 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, para los fines de Android, se consideran independientes 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.

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    Ver revisión

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

  • 7.4.3. Bluetooth:

    Ver revisión

    Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE, sucede lo siguiente:

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

    • [C-10-3] DEBE medir y compensar el desplazamiento de Rx para garantizar que la mediana de RSSI de BLE sea de -55 dBm +/-10 dB a una distancia de 1 m desde un dispositivo de referencia que transmite a ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] DEBE medir y compensar el desplazamiento de Tx para garantizar que la mediana de RSSI de BLE sea de -55 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.

    Si las implementaciones de dispositivos admiten Bluetooth versión 5.0, entonces:

    • [C-SR-4] SE RECOMIENDA ENERCMENTE brindar asistencia para lo siguiente:
    • LE 2M PHY
    • Códec LE PHY
    • Extensión de publicidad de LE
    • Publicidad periódica
    • Al menos 10 conjuntos de anuncios
    • Al menos 8 conexiones simultáneas de LE Cada conexión puede tener cualquiera de los roles de topología de conexión.
    • Privacidad de la capa de vínculos de LE
    • Un tamaño de "lista de resolución" de al menos 8 entradas

  • 7.4.9. UWB:

    Ver revisión

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

  • 7.5.1. Cámara posterior:

    Ver revisión

    Una cámara posterior es una cámara ubicada en el lado del dispositivo opuesto a la pantalla. Es decir, captura escenas en el lado más alejado del dispositivo, como una cámara tradicional.

    Una cámara posterior es una cámara orientada al mundo que muestra escenas en el lado más alejado del dispositivo, al igual que una cámara tradicional. En los dispositivos de mano, es una cámara ubicada en el lado del dispositivo opuesto a la pantalla.

  • 7.5.2. Cámara frontal:

    Ver revisión

    Una cámara frontal es una cámara ubicada en el mismo lado del dispositivo que la pantalla; es decir, una cámara que se suele usar para generar imágenes del usuario, como videoconferencias y aplicaciones similares.

    Una cámara frontal es una cámara orientada al usuario que, por lo general, se usa para generar imágenes, por ejemplo, para videoconferencias y aplicaciones similares. En los dispositivos de mano, es una cámara ubicada en el mismo lado del dispositivo que la pantalla.

  • 7.5.3. Cámara externa:

    Ver revisión

    Una cámara externa es una cámara que puede conectarse o desconectarse físicamente de la implementación del dispositivo en cualquier momento y puede apuntar a cualquier dirección, como cámaras USB.

  • 7.5.4. Comportamiento de la API de Camera:

    Ver revisión

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

  • 7.5.5. Orientación de la cámara:

    Ver revisión

    Los dispositivos que cumplan con todos los criterios que se indican a continuación estarán exentos del requisito anterior:

    • Implementaciones de dispositivos que el usuario no puede rotar, como los dispositivos de automóviles

  • 7.10. Tecnología háptica:

    Ver revisión

    Los dispositivos destinados a usarse o de mano pueden incluir un accionador táctil de uso general, disponible para las aplicaciones con fines como la captación de atención a través de tonos, alarmas, notificaciones y respuestas táctiles generales.

    Si las implementaciones de dispositivos NO incluyen un accionador táctil de uso general de este tipo, ocurrirán lo siguiente:

    • [7.10/C] DEBE mostrar falso para Vibrator.hasVibrator().

    Si las implementaciones de dispositivos SÍ incluyen al menos uno de estos accionadores táctiles de uso general, sucederá lo siguiente:

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

    Consulta la sección 2.2.1 para conocer los requisitos específicos de los dispositivos.

9. Compatibilidad del modelo de seguridad

  • 9.1. Permisos:

    Ver revisión

    Implementaciones en dispositivos:

    • [C-0-4] DEBE tener una sola implementación de ambas interfaces de usuario.

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

    • [C-4-2] NO DEBE tener el permiso android.permission.INTERNET. Esto es más estricto que lo que se RECOMIENDA EN FUNCIÓN DE LA SECCIÓN 9.8.6.
    • [C-4-3] NO DEBE vincularse con otras apps, excepto para las siguientes apps del sistema: Bluetooth, Contactos, Multimedia, Telefonía, IU del Sistema y componentes que proporcionan APIs de Internet. Esto es más estricto que lo que SE RECOMIENDA EN FUNCIÓN DE LA SECCIÓN 9.8.6.

    Si las implementaciones de dispositivos incluyen una aplicación predeterminada para admitir VoiceInteractionService, sucederá lo siguiente:

    • [C-5-1] NO DEBE otorgar ACCESS_FINE_LOCATION como el valor predeterminado para esa aplicación.

  • 9.5. Compatibilidad con multiusuario:

    Ver revisión

    Si las implementaciones de dispositivos crean el perfil de usuario adicional que se mencionó antes, hará lo siguiente:

    • [C-4-5] DEBE distinguir visualmente los íconos de aplicación de doble instancia cuando los íconos se presentan a los usuarios.
    • [C-4-6] DEBE proporcionar una autorización del usuario para borrar todos los datos del perfil de clonación.
    • [C-4-7] DEBE desinstalar todas las apps de clonación, borrar los directorios de datos privados de las apps y su contenido, y borrar los datos del perfil de la clonación, cuando el usuario elija borrar todos los datos del perfil de la clonación.
    • SE DEBE solicitar al usuario que borre todos los datos del perfil de clonación cuando se borre la última app de clonación.
    • [C-4-8] DEBE informarle al usuario que los datos de la app se borrarán cuando se desinstale la aplicación clonada o debe proporcionar una opción a los usuarios para conservar los datos de la app cuando se desinstale del dispositivo.
    • [C-4-9] SE DEBE borrar los directorios de datos privados de apps y su contenido cuando el usuario elige borrar los datos durante la desinstalación.

    • [C-4-14] DEBE tener permisos y administración de almacenamiento independientes para las aplicaciones que se ejecutan en este perfil adicional

    • [C-4-5] Solo DEBE permitir que las aplicaciones del perfil adicional que tienen una actividad de selector accedan a contactos a los que ya puede acceder el perfil de usuario principal.

  • 9.7. Funciones de seguridad:

    Ver revisión

    Una tecnología de seguridad de la memoria es una tecnología que mitiga al menos las siguientes clases de errores con una probabilidad alta (más del 90%) en aplicaciones que usan la opción de manifiesto android:memtagMode:

    • desbordamiento de búfer de montón
    • usar después de la liberación
    • doble libre
    • libre (sin punteros que no son malloc)

    Implementaciones en dispositivos:

    • [C-SR-15] SE RECOMIENDA MUY BIEN para configurar ro.arm64.memtag.bootctl_supported.

    Si las implementaciones de dispositivos establecen la propiedad del sistema ro.arm64.memtag.bootctl_supported como verdadera, sucederá lo siguiente:

    • [C-3-1] DEBE permitir que la propiedad del sistema arm64.memtag.bootctl acepte una lista separada por comas de los siguientes valores, con el efecto deseado aplicado en el próximo reinicio posterior:

      • memtag: Se habilita una tecnología de seguridad de la memoria, tal como se definió anteriormente.
      • memtag-once: Una tecnología de seguridad de la memoria, tal como se definió anteriormente, se habilita de forma transitoria y se inhabilita automáticamente en el siguiente reinicio
      • memtag-off: Se inhabilitó una tecnología de seguridad de la memoria, tal como se definió anteriormente.

    • [C-3-2] DEBE permitir que el usuario de shell configure arm64.memtag.bootctl.

    • [C-3-3] DEBE permitir que cualquier proceso lea arm64.memtag.bootctl.

    • [C-3-4] DEBE establecer arm64.memtag.bootctl en el estado solicitado actualmente al iniciar el dispositivo. También DEBE actualizar la propiedad si la implementación del dispositivo permite modificar el estado sin cambiar la propiedad del sistema.

    • [C-SR-16] SE RECOMIENDA MUY BIEN mostrar una Configuración para desarrolladores que establezca una etiqueta de memoria una vez y reinicie el dispositivo. Con un bootloader compatible, el Proyecto de código abierto de Android cumple con los requisitos anteriores a través del protocolo de bootloader MTE.

    • [C-SR-17] SE RECOMIENDA MUY BIEN mostrar una opción de configuración en el menú de configuración de seguridad que permita al usuario habilitar memtag.

  • 9.8.2. Grabación:

    Ver revisión

    Implementaciones en dispositivos:

    • [C-0-2] SE DEBE mostrar una advertencia del usuario y obtener el consentimiento explícito del usuario para que se capture cualquier información sensible que se muestre en la pantalla del usuarioy que incluya exactamente el mismo mensaje que el AOSP siempre cada y cada vez que una sesión para capturar la pantalla se inicie la transmisión o grabación de pantalla MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() NO DEBE ofrecerles a los usuarios la posibilidad de inhabilitar la visualización futura del consentimiento del usuario.

    • [C-SR-1] SE RECOMIENDA ENERCMENTE mostrar una advertencia para el usuario que sea exactamente el mismo mensaje que se implementó en AOSP, pero SE PUEDE alterar, siempre que el mensaje advierta claramente al usuario que se capturó cualquier información sensible en su pantalla.

    • [C-0-4] NO DEBE proporcionar a los usuarios la posibilidad de inhabilitar futuros mensajes del usuario para capturar la pantalla, a menos que la sesión la inicie una app del sistema a la que el usuario haya permitido associate() con el perfil del dispositivo android.app.role.COMPANION_DEVICE_APP_STREAMING o android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  • 9.8.6. Datos ambientales y a nivel del SO: Se cambió el nombre de esta sección de Captura de contenido y Búsqueda de aplicaciones a Datos ambientales y a nivel del SO.

    Ver revisión

    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:

    • Cualquier pantalla u otros datos que se envíen al sistema a través de AugmentedAutofillService
    • Cualquier pantalla o cualquier otro dato al que se pueda acceder a través de la API de Content Capture
    • Cualquier pantalla u otros datos a los que se pueda acceder a través de la API de FieldClassificationService
    • Todos los datos de la aplicación que se pasan al sistema a través de la API de AppSearchManager y a los que se puede acceder a través de AppSearchGlobalManager.query

    • Cualquier otro evento que una aplicación proporcione al sistema a través de la API de Content Capture o la API de AppSearchManager, una API propia de Android con capacidad similar

    • Datos de audio obtenidos como resultado del uso de SpeechRecognizer#onDeviceSpeechRecognizer() por parte de la implementación del reconocedor de voz
    • Datos de audio obtenidos en segundo plano (de forma continua) a través de AudioRecord, SoundTrigger o alguna otra API de audio y que no generan un indicador visible para el usuario
    • Datos de la cámara obtenidos en segundo plano (de forma continua) a través de CameraManager o las otras APIs de Camera y que no generan un indicador visible para el usuario

    Si las implementaciones de dispositivos capturan alguno de los datos anteriores, sucederá lo siguiente:

    • [C-1-3] solo DEBE enviar todos esos datos y el registro fuera del dispositivo mediante un mecanismo que preserve la privacidad, excepto con el consentimiento explícito del usuario cada vez que se compartan los datos. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o resultados derivados con usuarios individuales" para evitar que los datos por usuario sean introspectivos (p.ej., implementados con una tecnología de privacidad diferencial como RAPPOR).

    • [C-1-5] NO DEBE compartir esos datos con otros componentes del SO que no cumplen 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).

    • El [C-1-6] DEBE proporcionar la indicación visual del usuario para borrar los datos que la implementación o el medio 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-SR-3] SE RECOMIENDA EJECUTARMENTE que se implementen con la API del SDK de Android o con un repositorio de código abierto similar de un OEM, y que se realicen en una implementación en la zona de pruebas (consulta la sección 9.8.15 de implementaciones de la API en zonas de pruebas).

    Android, a través de SpeechRecognizer#onDeviceSpeechRecognizer(), proporciona la capacidad de realizar reconocimiento de voz en el dispositivo sin involucrar la red. Cualquier implementación de SpeechRecognizer integrado en el dispositivo DEBE seguir las políticas que se describen en esta sección.

  • 9.8.10. Informe de errores de conectividad:

    Ver revisión

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

    • [C-1-4] Los informes generados con BUGREPORT_MODE_TELEPHONY DEBEN contener al menos la siguiente información:
      • Volcado de SubscriptionManagerService

  • 9.8.14. Credential Manager: Se quitó.

  • 9.8.15. Implementaciones de API en la zona de pruebas: Nueva sección

    Ver revisión

    A través de un conjunto de APIs delegadas, Android proporciona un mecanismo para procesar datos ambientales y a nivel del SO seguros. Este procesamiento se puede delegar a un APK preinstalado con acceso privilegiado y capacidades de comunicación reducidas, lo que se conoce como implementación de API de Sandboxed.

    Cualquier implementación de la API de Sandboxed:

    • [C-0-1] NO DEBE solicitar el permiso de INTERNET.
    • [C-0-2] Solo DEBE acceder a Internet a través de APIs estructuradas respaldadas por implementaciones de código abierto disponibles públicamente con mecanismos que preservan la privacidad, o de forma indirecta a través de las APIs del SDK de Android. El mecanismo que preserva la privacidad se define como “aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o resultados derivados con usuarios individuales” para evitar que los datos por usuario sean introspecbles (p.ej., implementados con una tecnología de privacidad diferencial como RAPPOR).
    • [C-0-3] DEBE mantener los servicios separados de otros componentes del sistema (p.ej., no vincular el servicio ni compartir los IDs de procesos), excepto por lo siguiente:
      • Telefonía, Contactos, IU del sistema y Contenido multimedia
    • [C-0-4] NO DEBE permitir que los usuarios reemplacen los servicios con una aplicación o servicio que el usuario pueda instalar
    • [C-0-5] Solo DEBE permitir que los servicios preinstalados capturen esos datos. A menos que la función de reemplazo esté integrada en AOSP (p.ej., para apps de Asistente digital).
    • [C-0-6] NO DEBE permitir que ninguna app que no sea el mecanismo de servicios preinstalado pueda capturar esos datos. A menos que esa capacidad de captura se implemente con una API del SDK de Android.
    • [C-0-7] DEBE proporcionar al usuario la posibilidad de inhabilitar los servicios.
    • [C-0-8] NO DEBE omitir la indicación visual del usuario para administrar los permisos de Android que poseen los servicios y seguir el modelo de permisos de Android como se describe en la Sección 9.1. Permiso.

  • 9.8.16. Datos de la cámara y el audio continuos: Nueva sección

    Ver revisión

    Además de los requisitos descritos en 9.8.2 Grabación, 9.8.6 datos a nivel del SO y de ambiente, e implementaciones de la API de zona de pruebas 9.8.15, implementaciones que usan datos de audio obtenidos en segundo plano (continuamente) a través de AudioRecord, SoundTrigger u otras APIs de audio O datos de la cámara obtenidos en segundo plano (continuamente) a través de CameraManager u otras APIs de Cámara:

    • [C-0-1] SE DEBE aplicar un indicador correspondiente (cámara o micrófono según la sección 9.8.2 Grabación), a menos que ocurra lo siguiente:
    • [C-SR-1] SE RECOMIENDA RECOMENDADAMENTE solicitar el consentimiento del usuario para todas las funciones que utilicen esos datos y debe inhabilitarse de forma predeterminada.
    • [C-SR-2] SE RECOMIENDA ENERCMENTE aplicar el mismo tratamiento (es decir, seguir las restricciones descritas en 9.8.2 Grabación, 9.8.6 datos ambientales y a nivel del SO, 9.8.15 implementaciones de la API de Sandboxed y 9.8.16 datos de la cámara y el audio continuos) a los datos de la cámara que provienen de un dispositivo wearable remoto.

    Si los datos de la cámara se proporcionan desde un dispositivo wearable remoto y se accede a ellos de manera no encriptada fuera del SO Android, una implementación en zona de pruebas o una funcionalidad de zona de pruebas compilada por WearableSensingManager, sucederá lo siguiente:

    • [C-1-1] DEBE indicarle al dispositivo wearable remoto que muestre un indicador adicional allí.

    Si los dispositivos permiten interactuar con una aplicación de Asistente digital sin la palabra clave asignada (ya sea cuando manejan consultas genéricas de los usuarios o analizan la presencia del usuario a través de la cámara), ocurrirá lo siguiente:

    • [C-2-1] DEBE asegurarse de que dicha implementación sea proporcionada por un paquete que contiene la función android.app.role.ASSISTANT.
    • [C-2-2] DEBE asegurarse de que dicha implementación use las APIs de Android HotwordDetectionService o VisualQueryDetectionService.

  • 9.8.17. Telemetría: Sección nueva

    Ver revisión

    Android almacena los registros del sistema y de las apps con las APIs de StatsLog. Estos registros se administran a través de las APIs de StatsManager, que las aplicaciones del sistema con privilegios pueden usar.

    StatsManager también proporciona una forma de recopilar datos categorizados como sensibles a la privacidad de dispositivos con un mecanismo de preservación de la privacidad. En particular, la API de StatsManager::query proporciona la capacidad de consultar categorías de métricas restringidas definidas en StatsLog.

    Cualquier consulta de implementación y recopilación de métricas restringidas de StatsManager:

    • [C-0-1] DEBE ser la única aplicación o implementación en el dispositivo y tener el permiso READ_RESTRICTED_STATS.
    • [C-0-2] solo DEBE enviar datos de telemetría y el registro del dispositivo con un mecanismo que preserve la privacidad. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o resultados derivados con usuarios individuales" para evitar que los datos por usuario sean introspecbles (p.ej., implementados con una tecnología de privacidad diferencial como RAPPOR).
    • [C-0-3] NO DEBE asociar esos datos con ninguna identidad de usuario (como Cuenta) en el dispositivo.
    • [C-0-4] NO DEBE compartir esos datos con otros componentes del SO que no cumplen con los requisitos descritos en la sección actual (9.8.17 Telemetría que preserva la privacidad).
    • [C-0-5] DEBE proporcionar una indicación visual del usuario para habilitar o inhabilitar la recopilación, el uso y el uso compartido de la telemetría que preserva la privacidad.
    • [C-0-6] DEBE proporcionar la indicación visual del usuario para borrar los datos que recopila la implementación si los datos se almacenan de cualquier forma en el dispositivo. Si el usuario decidió borrar los datos, DEBE quitar todos los datos almacenados actualmente en el dispositivo.
    • [C-0-7] DEBE divulgar la implementación del protocolo subyacente que preserva la privacidad en un repositorio de código abierto.
    • [C-0-8 ]DEBE aplicar de manera forzosa las políticas de salida de datos en esta sección para limitar la recopilación de datos en categorías de métricas restringidas definidas en StatsLog.

  • 9.10. Integridad del dispositivo:

    Ver revisión

    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.

    • [C-2-4] DEBE mostrar la suma de comprobación del archivo en O(1) para los archivos habilitados.

  • 9.11. Claves y credenciales:

    Ver revisión

    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-3] DEBE limitar la cantidad de intentos fallidos de autenticación principal.
    • [C-SR-2] SE RECOMIENDA ENERCMENTE implementar un límite superior de 20 intentos de autenticación principales fallidos. Si los usuarios otorgan su consentimiento y habilitan la función, deben realizar un “restablecimiento de la configuración de fábrica” después de exceder el límite de intentos de autenticación principales fallidos.

    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 como una forma segura de bloquear la pantalla, sucederá lo siguiente:

    • [C-SR-3] SE RECOMIENDA QUE un PIN tenga al menos 6 dígitos o una entropía de 20 bits, lo que equivale a 20 bits.
    • [C-2-1] Un PIN de menos de 6 dígitos NO DEBE permitir el ingreso automático sin interacción del usuario para evitar revelar la longitud del PIN.

  • 9.11.1. Proteger la pantalla de bloqueo, la autenticación y los dispositivos virtuales:

    Ver revisión

    Implementaciones en dispositivos:

    • [C-0-1] DEBE limitar la cantidad de intentos fallidos de autenticación principal.
    • [C-SR-5] SE RECOMIENDA ENERCMENTE implementar un límite superior de 20 intentos de autenticación principales fallidos. Si los usuarios otorgan su consentimiento y habilitan la función, realizan un “restablecimiento de la configuración de fábrica” después de exceder el límite de intentos de autenticación principales fallidos.

    Si las implementaciones del dispositivo establecen un PIN numérico como método de autenticación principal recomendado, entonces:

    • [C-SR-6] SE RECOMIENDA QUE un PIN tenga al menos 6 dígitos o una entropía de 20 bits, lo que equivale a 20 bits.
    • [C-SR-7] Se RECOMIENDA QUE NO se permita la entrada automática de un PIN de menos de 6 dígitos para evitar que se revele su longitud.

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

    [C-7-8] 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 72 horas o menos, a menos que la seguridad del usuario (p. ej., la distracción del conductor) sea de interés.

    Si las implementaciones en los 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-10] SE DEBE inhabilitar la instalación de apps iniciadas desde dispositivos virtuales.

  • 9.17. Android Virtualization Framework

    Ver revisión

    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-3] NO DEBE modificar, omitir ni reemplazar las reglas de "Neverallow" presentes en el sistema o 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 "Neverallow" presentes.

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

    • [C-1-5] NO DEBE permitir que una máquina virtual protegida pVM ejecute un código que no sea parte de la imagen de fábrica ni sus actualizaciones. Los elementos que no estén incluidos en el inicio verificado de Android (p.ej., archivos descargados de Internet o transferidos) NO DEBEN ejecutarse en una máquina virtual protegida .

    • [C-1-5] Solo DEBE permitir que una pVM no depurable ejecute código desde la imagen de fábrica o las actualizaciones de su plataforma, lo que también incluye cualquier actualización de apps con privilegios.

    Si el dispositivo implementa la compatibilidad con las APIs de Android Virtualization Framework (android.system.virtualmachine.*), cualquier instancia de máquina virtual protegida pVM :

    • [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-4] NO DEBE modificar, omitir ni reemplazar las reglas de “Neverallow” presentes en el sistema, la directiva o el microdroid que se proporcionan en el Proyecto de código abierto de Android (AOSP) ascendente.

    • [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-6-1] DEBE tener la raíz en la cadena de DICE en un punto que el usuario no pueda modificar, incluso en dispositivos desbloqueados. (para garantizar que no se pueda falsificar la identidad)

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

Volver al principio