Androide 14
8 de abril de 2024
2. Tipos de dispositivos
Ver revisión
Iniciar nuevos requisitos
Si las implementaciones de dispositivos portátiles declaran
FEATURE_BLUETOOTH_LE,:- [ 7.4 .3/H-1-3] DEBE medir y compensar la compensación de Rx para garantizar que el RSSI BLE medio sea -50 dBm +/-15 dB a 1 m de distancia de un dispositivo de referencia que transmita a
ADVERTISE_TX_POWER_HIGH. - [ 7.4 .3/H-1-4] DEBE medir y compensar la compensación de Tx para garantizar que el RSSI BLE medio sea -50 dBm +/-15 dB cuando se escanea desde un dispositivo de referencia ubicado a 1 m de distancia y se transmite a
ADVERTISE_TX_POWER_HIGH.
- [ 7.4 .3/H-1-3] DEBE medir y compensar la compensación de Rx para garantizar que el RSSI BLE medio sea -50 dBm +/-15 dB a 1 m de distancia de un dispositivo de referencia que transmita a
Ver revisión
Si las implementaciones de dispositivos portátiles admiten System API
HotwordDetectionServiceu otro mecanismo para la detección de palabras activas sin indicación de acceso al micrófono,:- [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 activas en cada resultado exitoso de palabras activas , excepto los datos de audio pasados a través de HotwordAudioStream .
Ver revisión
Cambie [9.8/H-1-13] a:
- [9.8/H-SR-3] Se RECOMIENDA ENCARECIDAMENTE reiniciar el proceso que aloja el servicio de detección de palabras activas al menos una vez cada hora o cada 30 eventos de activación de hardware, lo que ocurra primero.
Ver revisión
Requisitos eliminados [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
Ver revisión
Si las implementaciones de dispositivos portátiles devuelven
android.os.Build.VERSION_CODES.Uparaandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, entonces:- [ 7.5 /H-1-3] DEBE admitir la propiedad
android.info.supportedHardwareLevelcomoFULLo mejor para la cámara principal trasera yLIMITEDo mejor para la cámara principal frontal.
- [ 7.5 /H-1-3] DEBE admitir la propiedad
Ver revisión
Si las implementaciones de dispositivos de televisión no tienen una pantalla incorporada, pero admiten una pantalla externa conectada a través de HDMI,:
- [ 5.8 /T-0-1] DEBE configurar el modo de salida HDMI en la resolución más alta para el formato de píxeles elegido que funcione con una frecuencia de actualización de 50 Hz o 60 Hz para la pantalla externa, dependiendo de la frecuencia de actualización de video para la región en la que se vende el dispositivo. pulg.
DEBE configurar el modo de salida HDMI para seleccionar la resolución máxima que puede admitirse con una frecuencia de actualización de 50 Hz o 60 Hz.
- [ 5.8 /T-0-1] DEBE 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, dependiendo de la frecuencia de actualización de video para la región en la que se vende el dispositivo. pulg.
3.software
3.5.1. Restricción de aplicación :
Ver revisión
- Requisito eliminado [C-1-9]
5. Compatibilidad multimedia
Ver revisión
Si las implementaciones de dispositivos declaran compatibilidad con el decodificador Dolby Vision a través de
HDR_TYPE_DOLBY_VISION,:- [C-1-3] DEBE configurar el ID de pista de las capas base compatibles con versiones anteriores (si están presentes) para que sea el mismo que el ID de pista de la capa Dolby Vision combinada.
7. Compatibilidad de hardware
7.1.1.1. Tamaño y forma de pantalla :
Ver revisión
Si las implementaciones de dispositivos admiten pantallas con capacidad de configuración de tamaño
UI_MODE_TYPE_NORMALy utilizan pantallas físicas con esquinas redondeadas para representar estas pantallas, estas:- [C-1-1] DEBE garantizar que se cumpla al menos uno de los siguientes requisitos para cada una de estas exhibiciones:
- Cuando
un cuadro de 15y 18 dp por1518 dp está anclado en cada esquina de la pantalla lógica, al menos un píxel de cada cuadro es visible en la pantalla.
- Cuando
- [C-1-1] DEBE garantizar que se cumpla al menos uno de los siguientes requisitos para cada una de estas exhibiciones:
Ver revisión
Se restablecieron los siguientes requisitos:
Si las implementaciones de dispositivos declaran
FEATURE_BLUETOOTH_LE, ellas:[C-SR-2] Se RECOMIENDA ENCARECIDAMENTE medir y compensar la compensación de Rx para garantizar que el RSSI BLE medio sea -60 dBm +/-10 dB a 1 m de distancia de un dispositivo de referencia que transmite en
ADVERTISE_TX_POWER_HIGH, donde los dispositivos están orientados de manera que estén en 'planos paralelos' con pantallas orientadas en la misma dirección.[C-SR-3] Se RECOMIENDA ENCARECIDAMENTE medir y compensar la compensación de Tx para garantizar que el RSSI BLE medio sea -60 dBm +/-10 dB cuando se escanea desde un dispositivo de referencia ubicado a 1 m de distancia y se transmite en
ADVERTISE_TX_POWER_HIGH, donde los dispositivos están orientados. de modo que estén en "planos paralelos" con pantallas orientadas en la misma dirección.
Ver revisión
Se movieron los requisitos [C-10-3] y [C-10-4] a 2.2.1. Ferretería .
- [C-10-3] DEBE medir y compensar la compensación de Rx para garantizar que el RSSI BLE medio sea -55 dBm +/-10 dB a 1 m de distancia de un dispositivo de referencia que transmita a
ADVERTISE_TX_POWER_HIGH. - [C-10-4] DEBE medir y compensar la compensación de Tx para garantizar que el RSSI BLE medio sea -55 dBm +/-10 dB cuando se escanea 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 dispositivos
Ver revisión
Si las implementaciones de dispositivos portátiles declaran compatibilidad con cualquier ABI de 64 bits (con o sin ABI de 32 bits):
Ver revisión
- [ 7.5 /H-1-13] DEBE admitir la capacidad
LOGICAL_MULTI_CAMERApara la cámara trasera principal si hay más de 1 cámara trasera RGB.
- [ 7.5 /H-1-13] DEBE admitir la capacidad
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.
DEBE configurar el modo de salida HDMI para seleccionar la resolución máxima que puede admitirse con una frecuencia de actualización de 50 Hz o 60 Hz.
Ver revisión
- [9/W-0-1] DEBE declarar la
android.hardware.security.model.compatible feature.
- [9/W-0-1] DEBE declarar la
6. Compatibilidad de opciones y herramientas de desarrollador
6.1. Herramientas de desarrollo :
Ver revisión
- [C-0-12] DEBE escribir un átomo
LMK_KILL_OCCURRED_FIELD_NUMBERen el
Ver revisión
- [C-0-13] DEBE implementar el comando de shell
dumpsys gpu --gpuworkpara mostrar
- [C-0-12] DEBE escribir un átomo
9. Compatibilidad del modelo de seguridad
9.7. Características de seguridad :
Ver revisión
Si las implementaciones de dispositivos utilizan un kernel de Linux que sea capaz de admitir SELinux,:
Ver revisión
Si las implementaciones de dispositivos utilizan un kernel distinto de Linux o Linux sin SELinux,:
4 de octubre de 2023
2. Tipos de dispositivos
Ver revisión
Las implementaciones de dispositivos Android se clasifican como dispositivos portátiles si cumplen con todos los criterios siguientes:
- Tener un tamaño de pantalla diagonal física en el rango de 4 pulgadas,
3,3 pulgadas (o 2,5 pulgadas para implementaciones de dispositivos que se enviaron con el nivel API 29 o anterior)a 8 pulgadas.
Iniciar nuevos requisitos
- Tener una interfaz de entrada de pantalla táctil.
- Tener un tamaño de pantalla diagonal física en el rango de 4 pulgadas,
Ver revisión
Implementaciones de dispositivos portátiles:
- [ 7.1 .1.1/H-0-1] DEBE tener al menos una
pantalla compatible con Android que cumpla con todos los requisitos descritos en este documento.pantalla que mida al menos 2,2” en el borde corto y 3,4” en el borde largo.
Si las implementaciones de dispositivos portátiles admiten la rotación de pantalla del software,:
- [ 7.1 .1.1/H-1-1]* DEBE hacer que la pantalla lógica que esté disponible para aplicaciones de terceros tenga al menos 2 pulgadas en los bordes cortos y 2,7 pulgadas en los bordes largos. Los dispositivos que se enviaron con el nivel 29 de API de Android o anterior PUEDEN estar exentos de este requisito.
Si las implementaciones de dispositivos portátiles no admiten la rotación de pantalla del software, estas:
- [ 7.1 .1.1/H-2-1]* DEBE hacer que la pantalla lógica que esté disponible para aplicaciones de terceros tenga al menos 2,7 pulgadas en los bordes cortos. Los dispositivos que se enviaron con el nivel 29 de API de Android o anterior PUEDEN estar exentos de este requisito.
Iniciar nuevos requisitos
[ 7.1 .1.1/H-0-3]* DEBE asignar cada pantalla
UI_MODE_NORMALdisponible para aplicaciones de terceros en un área de pantalla física sin obstáculos que tenga al menos 2,2 pulgadas en el borde corto y 3,4 pulgadas en el borde largo.[ 7.1 .1.3/H-0-1]* DEBE establecer el valor de
DENSITY_DEVICE_STABLEpara que sea 92% o mayor que la densidad física real de la pantalla correspondiente.
Si las implementaciones de dispositivos portátiles declaran
android.hardware.audio.outputyandroid.hardware.microphone,:[ 5.6 /H-1-1] DEBE tener una latencia media continua de ida y vuelta de 300 milisegundos o menos en 5 mediciones, con una desviación media absoluta inferior a 30 ms , en las siguientes rutas de datos: "altavoz a micrófono", 3,5 mm adaptador de bucle invertido (si es compatible), bucle invertido USB (si es compatible).
[ 5.6 /H-1-2] DEBE tener una latencia promedio de toque a tono de 300 milisegundos o menos en al menos 5 mediciones a través de la ruta de datos del altavoz al micrófono.
Si las implementaciones de dispositivos portátiles incluyen al menos un actuador háptico, estos:
- [ 7.10 /H]* NO DEBE utilizar un actuador háptico (vibrador) de masa giratoria excéntrica (ERM).
- [ 7.10 /H]* DEBE implementar todas las constantes públicas para una háptica clara en android.view.HapticFeedbackConstants , a saber (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START y GESTO_END).
- [ 7.10 /H]* DEBE implementar todas las constantes públicas para hápticos claros en android.os.VibrationEffect , es decir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK y EFFECT_DOUBLE_CLICK) y todas las constantes
PRIMITIVE_*públicas viables para hápticos ricos en android.os.VibrationEffect.Composition , a saber ( CLIC, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, GIRO, SUERTE). Algunas de estas primitivas, como LOW_TICK y SPIN, solo pueden ser factibles si el vibrador puede soportar frecuencias relativamente bajas. - [7.10/H]* DEBE seguir las instrucciones para asignar constantes públicas en android.view.HapticFeedbackConstants a las constantes recomendadas de android.os.VibrationEffect , con las relaciones de amplitud correspondientes.
- [ 7.10 /H]* DEBE seguir la evaluación de calidad para las API createOneShot() y createWaveform() .
- [ 7.10 /H]* DEBE verificar que el resultado de la API pública android.os.Vibrator.hasAmplitudeControl() refleje correctamente las capacidades de su vibrador.
- [ 7.10 /H]* DEBE colocar el actuador cerca del lugar donde normalmente se sostiene o toca el dispositivo con las manos.
Si las implementaciones de dispositivos portátiles incluyen al menos un actuador resonante lineal 7.10 de uso general , estos:
- [ 7.10 /H] DEBE colocar el actuador cerca del lugar donde normalmente se sostiene o toca el dispositivo con las manos.
- [ 7.10 /H] DEBE mover el actuador háptico en el eje X (izquierda-derecha) de la orientación
verticalnatural del dispositivo .
Si las implementaciones de dispositivos portátiles tienen un actuador háptico de uso general que es un actuador resonante lineal (LRA) del eje X,:
- [ 7.10 /H] DEBE tener la frecuencia de resonancia del LRA del eje X por debajo de 200 Hz.
- [ 7.1 .1.1/H-0-1] DEBE tener al menos una
Ver revisión
Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:
- [ 5.2 /H-0-3] AV1
Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:
- [ 5.3 /H-0-6] AV1
Ver revisión
Si las implementaciones del dispositivo, incluida la tecla de navegación de la función reciente, como se detalla en la sección 7.2.3, alteran la interfaz:
- [ 3.8 .3/H-1-1] DEBE implementar el comportamiento de fijación de pantalla y proporcionar al usuario un menú de configuración para alternar la función.
Si las implementaciones de dispositivos portátiles incluyen soporte para
ControlsProviderServiceyControlAPI y permiten que aplicaciones de terceros publiquen controles de dispositivos , entonces:- [ 3.8 .16/H-1-6] Las implementaciones de dispositivos DEBEN ofrecer con precisión las posibilidades del usuario de la siguiente manera:
- Si el dispositivo ha configurado
config_supportsMultiWindow=truey la aplicación declara los metadatosMETA_DATA_PANEL_ACTIVITYen la declaraciónControlsProviderService, incluido el ComponentName de una actividad válida (según lo definido por la API), entonces la aplicación DEBE incorporar dicha actividad en esta posibilidad de usuario. - Si la aplicación no declara metadatos
META_DATA_PANEL_ACTIVITY, DEBE representar los campos especificados proporcionados por la APIControlsProviderService, así como cualquier campo especificado proporcionado por las API de control .
- Si el dispositivo ha configurado
- [ 3.8 .16/H-1-7] Si la aplicación declara los metadatos
META_DATA_PANEL_ACTIVITY, DEBE pasar el valor de la configuración definida en [3.8.16/H-1-5] usandoEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLSal iniciar la actividad integrada.
Si las implementaciones de dispositivos permiten a los usuarios realizar llamadas de cualquier tipo,
- [ 7.4.1.2 /H-0-1] DEBE declarar el indicador de función
android.software.telecom. - [ 7.4.1.2 /H-0-2] DEBE implementar el marco de telecomunicaciones .
2.2.4. Rendimiento y potencia :
Ver revisión
Implementaciones de dispositivos portátiles:
- [ 8.5 /H-0-1] DEBE proporcionar al usuario una opción
en el menú Configuraciónpara ver todas las aplicaciones con servicios en primer plano activos o trabajos iniciados por el usuario, incluida la duración de cada uno de estos servicios desde que se inició, como se describe en el documento SDK. .y la capacidad de detener una aplicación que ejecuta un servicio en primer plano o un trabajo iniciado por el usuario.con la capacidad de detener una aplicación que está ejecutando un servicio en primer plano y mostrar todas las aplicaciones que tienen servicios en primer plano activos y la duración de cada uno de estos servicios desde que se inició, como se describe en el documento SDK .- Algunas aplicaciones PUEDEN estar exentas de ser detenidas o incluidas en una lista de opciones para el usuario como se describe en el documento SDK .
- [ 8.5 /H-0-1] DEBE proporcionar al usuario una opción
- [ 8.5 /H-0-2]DEBE proporcionar al usuario la posibilidad de detener una aplicación que esté ejecutando un servicio en primer plano o un trabajo iniciado por el usuario.
Ver revisión
Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony ,:
- [ 9.5 /H-1-1] NO DEBE establecer
UserManager.isHeadlessSystemUserModeentrue.
Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza, que implementan la API del sistema TrustAgentService , ellos:
- [ 9.11.1 /H-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (por ejemplo, PIN, patrón, contraseña) con más frecuencia que una vez cada 72 horas.
Si las implementaciones de dispositivos portátiles configuran UserManager.isHeadlessSystemUserMode en true ,
Si las implementaciones de dispositivos portátiles admiten System API HotwordDetectionService u otro mecanismo para la detección de palabras activas sin indicación de acceso al micrófono,:
- [9.8/H-1-1] DEBE asegurarse de que el servicio de detección de palabras activas solo pueda transmitir datos al sistema,
ContentCaptureServiceo al servicio de reconocimiento de voz en el dispositivo creado porSpeechRecognizer#createOnDeviceSpeechRecognizer(). - [9.8/H-1-6] NO DEBE permitir que se transmitan más de 100 bytes de datos (excluyendo secuencias de audio) fuera del servicio de detección de palabras activas en cada resultado exitoso de palabra activa.
- [9.8/H-1-15] DEBE garantizar que los flujos de audio proporcionados cuando se obtienen resultados exitosos de palabras activas se transmitan en un sentido desde el servicio de detección de palabras activas al servicio de interacción de voz.
Si las implementaciones del dispositivo incluyen una aplicación que utiliza la API del sistema HotwordDetectionService o un mecanismo similar para la detección de palabras activas sin indicación de uso del micrófono, la aplicación:
- [9.8/H-2-3] NO DEBE transmitir desde el servicio de detección de palabras clave, datos de audio, datos que puedan usarse para reconstruir (total o parcialmente) el audio, o contenidos de audio no relacionados con la palabra clave en sí, excepto al
ContentCaptureServiceo Servicio de reconocimiento de voz en el dispositivo.
Si las implementaciones de dispositivos portátiles admiten la API del sistema VisualQueryDetectionService u otro mecanismo para la detección de consultas sin indicación de acceso al micrófono o la cámara,:
- [9.8/H-3-1] DEBE asegurarse de que el servicio de detección de consultas solo pueda transmitir datos al Sistema, o
ContentCaptureService, o al servicio de reconocimiento de voz en el dispositivo (creado porSpeechRecognizer#createOnDeviceSpeechRecognizer()). - [9.8/H-3-2] NO DEBE permitir que se transmita ninguna información de audio o video fuera de
VisualQueryDetectionService, excepto aContentCaptureServiceo al servicio de reconocimiento de voz en el dispositivo. - [9.8/H-3-3] DEBE mostrar un aviso de usuario en la interfaz de usuario del sistema cuando el dispositivo detecta la intención del usuario de interactuar con la aplicación de asistente digital (por ejemplo, detectando la presencia del usuario a través de la cámara).
- [9.8/H-3-4] DEBE mostrar un indicador de micrófono y mostrar la consulta del usuario detectada en la interfaz de usuario inmediatamente después de que se detecta la consulta del usuario.
- [9.8/H-3-5] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección visual de consultas.
Ver revisión
Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.T para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:
- DEBE cumplir con los requisitos de medios enumerados en la sección 2.2.7.1 de CDD de Android 13 .
Iniciar nuevos requisitos
Si las implementaciones de dispositivos portátiles devuelvenandroid.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:- [5.1/H-1-1] DEBE anunciar el número máximo de sesiones de decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos
CodecCapabilities.getMaxSupportedInstances()yVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-2] DEBE admitir 6 instancias de sesiones de decodificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con 3 sesiones con una resolución de 1080p a 30 fps y 3 sesiones a resolución 4k a 30 fps, a menos que AV1. Los códecs AV1 solo son necesarios para admitir una resolución de 1080p, pero aún así deben admitir 6 instancias a 1080p30fps.
- [5.1/H-1-3] DEBE anunciar el número máximo de sesiones de codificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos
CodecCapabilities.getMaxSupportedInstances()yVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-4] DEBE admitir 6 instancias de sesiones de codificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con 4 sesiones con una resolución de 1080p a 30 fps y 2 sesiones a resolución 4k a 30 fps, a menos que AV1. Los códecs AV1 solo son necesarios para admitir una resolución de 1080p, pero aún así deben admitir 6 instancias a 1080p30fps.
- [5.1/H-1-5] DEBE anunciar el número máximo de sesiones de codificador y decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos
CodecCapabilities.getMaxSupportedInstances()yVideoCapabilities.getSupportedPerformancePoints(). - [5.1/H-1-6] DEBE admitir 6 instancias de sesiones de decodificador de video por hardware (SDR) y codificador de video por hardware (AVC, HEVC, VP9, AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con 3 sesiones en 4K Resolución de @30 fps (a menos que AV1), de las cuales como máximo 2 son sesiones de codificador y 3 sesiones con una resolución de 1080p. Los códecs AV1 solo son necesarios para admitir una resolución de 1080p, pero aún así deben admitir 6 instancias a 1080p30fps.
- [5.1/H-1-19] DEBE admitir 3 instancias de sesiones de decodificador de video por hardware (HDR) y codificador de video por hardware (AVC, HEVC, VP9, AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con una resolución de 4K a 30 fps. (a menos que AV1) de las cuales como máximo 1 es una sesión de codificador, que podría configurarse en formato de entrada RGBA_1010102 a través de una superficie GL. No se requiere la generación de metadatos HDR por parte del codificador si se codifica desde la superficie GL. Las sesiones de códec AV1 solo son necesarias para admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
- [5.1/H-1-7] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de codificación de video de 1080p o menor para todos los codificadores de video de hardware cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de solo video de 1080p a 720p utilizando códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p. Para el códec Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
- [5.1/H-1-8] DEBE tener una latencia de inicialización de códec de 30 ms o menos para una sesión de codificación de audio con una velocidad de bits de 128 kbps o inferior para todos los codificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de solo video de 1080p a 720p utilizando códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p.
- [5.1/H-1-9] DEBE admitir 2 instancias de sesiones seguras de decodificador de video por hardware (AVC, HEVC, VP9, AV1 o posterior) en cualquier combinación de códec que se ejecute simultáneamente con una resolución de 4k a 30 fps (a menos que AV1) para ambos 8- bits (SDR) y contenido HDR de 10 bits. Las sesiones de códec AV1 solo son necesarias para admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
- [5.1/H-1-10] DEBE admitir 3 instancias de sesiones de decodificador de video de hardware no seguro junto con 1 instancia de sesión de decodificador de video de hardware seguro (4 instancias en total) (AVC, HEVC, VP9, AV1 o posterior) en cualquier códec combinación que se ejecuta simultáneamente con 3 sesiones con resolución 4K a 30 fps (a menos que AV1) que incluye una sesión de decodificador seguro y 1 sesión nn-segura con resolución 1080p a 30 fps donde como máximo 2 sesiones pueden ser en HDR de 10 bits. Las sesiones de códec AV1 solo son necesarias para admitir una resolución de 1080p, incluso cuando este requisito requiere 4K.
- [5.1/H-1-11] DEBE admitir un decodificador seguro para cada decodificador de hardware AVC, HEVC, VP9 o AV1 en el dispositivo.
- [5.1/H-1-12] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de decodificación de video de 1080p o menor para todos los decodificadores de video de hardware cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de video de 1080p a 720p únicamente utilizando códecs de video de hardware junto con la inicialización de reproducción de audio y video de 1080p. Para el códec Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
- [5.1/H-1-13] DEBE tener una latencia de inicialización del códec de 30 ms o menos para una sesión de decodificación de audio con una velocidad de bits de 128 kbps o inferior para todos los decodificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de video de 1080p a 720p únicamente utilizando códecs de video de hardware junto con la inicialización de reproducción de audio y video de 1080p.
- [5.1/H-1-14] DEBE admitir el decodificador de hardware AV1 Main 10, nivel 4.1 y grano de película.
- [5.1/H-1-15] DEBE tener al menos 1 decodificador de video de hardware compatible con 4K60.
- [5.1/H-1-16] DEBE tener al menos 1 codificador de video de hardware compatible con 4K60.
- [5.3/H-1-1] NO DEBE perder más de 1 fotograma en 10 segundos (es decir, menos del 0,167 por ciento de pérdida de fotogramas) para una sesión de vídeo 4K a 60 fps bajo carga.
- [5.3/H-1-2] NO DEBE perder más de 1 cuadro en 10 segundos durante un cambio de resolución de video en una sesión de video de 60 fps bajo carga para una sesión de 4K.
- [5.6/H-1-1] DEBE tener una latencia de pulsación para tono de 80 milisegundos o menos usando la prueba de pulsación para tono de CTS Verifier.
- [5.6/H-1-2] DEBE tener una latencia de audio de ida y vuelta de 80 milisegundos o menos en al menos una ruta de datos admitida.
- [5.6/H-1-3] DEBE admitir >= audio de 24 bits para salida estéreo a través de conectores de audio de 3,5 mm si están presentes y a través de audio USB si es compatible con toda la ruta de datos para configuraciones de transmisión y baja latencia. Para la configuración de baja latencia, la aplicación debe utilizar AAudio en modo de devolución de llamada de baja latencia. Para la configuración de transmisión, la aplicación debe utilizar Java AudioTrack. Tanto en la configuración de baja latencia como en la de transmisión, el receptor de salida HAL debe aceptar
AUDIO_FORMAT_PCM_24_BIT,AUDIO_FORMAT_PCM_24_BIT_PACKED,AUDIO_FORMAT_PCM_32_BIToAUDIO_FORMAT_PCM_FLOATpara su formato de salida de destino. - [5.6/H-1-4] DEBE admitir >= dispositivos de audio USB de 4 canales (esto lo utilizan los controladores de DJ para obtener una vista previa de las canciones).
- [5.6/H-1-5] DEBE admitir dispositivos MIDI compatibles con su clase y declarar el indicador de función MIDI.
- [5.6/H-1-9] DEBE admitir al menos 12 canales de mezcla. Esto implica la capacidad de abrir una AudioTrack con máscara de canal 7.1.4 y espacializar o mezclar adecuadamente todos los canales a estéreo.
- [5.6/H-SR] Se RECOMIENDA ENCARECIDAMENTE admitir mezcla de 24 canales con al menos soporte para máscaras de 9.1.6 y 22.2 canales.
- [5.7/H-1-2] DEBE admitir
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALLcon las siguientes capacidades de descifrado de contenido.
| Tamaño mínimo de muestra | 4 MB |
| Número mínimo de submuestras: H264 o HEVC | 32 |
| Número mínimo de submuestras - VP9 | 9 |
| Número mínimo de submuestras - AV1 | 288 |
| Tamaño mínimo del búfer de submuestra | 1 MB |
| Tamaño mínimo del búfer criptográfico genérico | 500 KiB |
| Número mínimo de sesiones simultáneas | 30 |
| Número mínimo de claves por sesión | 20 |
| Número total mínimo de claves (todas las sesiones) | 80 |
| Número total mínimo de claves DRM (todas las sesiones) | 6 |
| Tamaño del mensaje | 16 KiB |
| Cuadros descifrados por segundo | 60 fps |
- [5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes de hardware compatible con AVIF Baseline Profile.
- [5.1/H-1-18] DEBE admitir el codificador AV1 que puede codificar una resolución de hasta 480p a 30 fps y 1 Mbps.
-
[5.12/H-1-1] DEBE[5.12/H-SR] Se recomienda encarecidamente para admitir la funciónFeature_HdrEditingpara todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo. - [5.12/H-1-2] DEBE admitir el formato de color RGBA_1010102 para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
- [5.12/H-1-3] DEBE anunciar soporte para la extensión EXT_YUV_target para muestrear texturas YUV 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 capaces de mostrar contenido de video de 10 bits.
Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e incluyen soporte para un codificador de hardware AVC o HEVC, entonces:
- [5.2/H-2-1] DEBE cumplir con el objetivo de calidad mínimo definido por las curvas de distorsión de velocidad del codificador de video para códecs AVC y HEVC de hardware, como se define en la próxima documentación.
Ver revisión
android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:- [ 7.5 /H-1-1] DEBE tener una cámara principal trasera con una resolución de al menos 12 megapíxeles que admita captura de video a 4k@30fps. La cámara trasera principal es la cámara trasera con el ID de cámara más bajo.
- [ 7.5 /H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 6 megapíxeles y admitir captura de video a 1080p@30fps. La cámara frontal principal es la cámara frontal con el ID de cámara más bajo.
- [ 7.5 /H-1-3] DEBE admitir la propiedad
android.info.supportedHardwareLevelcomo COMPLETA o mejor para ambas cámaras principales. - [ 7.5 /H-1-4] DEBE admitir
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIMEpara ambas cámaras principales. - [ 7.5 /H-1-5] DEBE tener una latencia de captura JPEG de la cámara 2 < 1000
900ms para una resolución de 1080p según lo medido por la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000K) para ambas cámaras principales. - [ 7.5 /H-1-6] DEBE tener una latencia de inicio de la cámara 2 (cámara abierta al primer fotograma de vista previa) < 500 ms, según lo medido por la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000 K) para ambas cámaras principales.
- [ 7.5 /H-1-8] DEBE admitir
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAWyandroid.graphics.ImageFormat.RAW_SENSORpara la cámara trasera principal. - [ 7.5 /H-1-9] DEBE tener una cámara principal orientada hacia atrás que admita 720p o 1080p a 240 fps.
- [ 7.5 /H-1-10] DEBE tener ZOOM_RATIO mínimo < 1.0 para las cámaras principales si hay una cámara RGB ultra ancha orientada en la misma dirección.
- [ 7.5 /H-1-11] DEBE implementar transmisión simultánea de adelante hacia atrás en las cámaras principales.
- [ 7.5 /H-1-12] DEBE admitir
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATIONtanto para la cámara frontal principal como para la cámara trasera principal. - [ 7.5 /H-1-13] DEBE admitir la capacidad
LOGICAL_MULTI_CAMERApara 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_CASEtanto para la cámara frontal principal como para la trasera principal. - [ 7.5 /H-1-15] DEBE admitir extensiones de modo
Bokeh ynocturno a través de las extensiones CameraX y Camera2 para las cámaras principales. - [ 7.5 /H-1-16] DEBE admitir la capacidad DYNAMIC_RANGE_TEN_BIT para las cámaras principales.
- [ 7.5 /H-1-17] DEBE admitir CONTROL_SCENE_MODE_FACE_PRIORITY y detección de rostros ( STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL ) para las cámaras principales.
Ver revisión
android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:- [7.1.1.1/H-2-1] DEBE tener una resolución de pantalla de al menos 1080p.
- [7.1.1.3/H-2-1] DEBE tener una densidad de pantalla de al menos 400 ppp.
- [7.1.1.3/H-3-1] DEBE tener una pantalla HDR que admita al menos 1000 nits en promedio.
- [7.6.1/H-2-1] DEBE tener al menos 8 GB de memoria física.
Ver revisión
android.os.Build.VERSION_CODES.U para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , entonces:- [8.2/H-1-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 150 MB/s.
- [8.2/H-1-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 10 MB/s.
- [8.2/H-1-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 250 MB/s.
- [8.2/H-1-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 100 MB/s.
- [8.2/H-1-5] DEBE garantizar un rendimiento de lectura y escritura secuencial paralela con un rendimiento de lectura 2x y escritura 1x de al menos 50 MB/s.
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:
- [ 5.3.2 /T-0-7] AV1
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 TrustAgentService , ellos:
- [ 9.11.1 /W-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (por ejemplo, PIN, patrón, contraseña) con más frecuencia que una vez cada 72 horas.
Ver revisión
Si las implementaciones de dispositivos incluyen soporte para transmisiones de radio AM/FM y exponen la funcionalidad a cualquier aplicación, estas:
- [ 7.4
.10/A-0-1] DEBE declarar soporte paraFEATURE_BROADCAST_RADIO.
Una cámara de visión exterior es una cámara que captura escenas fuera de la implementación del dispositivo, como la cámara de visión trasera.
Implementaciones de dispositivos automotrices:
- DEBE incluir una o más cámaras de visión exterior.
Si las implementaciones de dispositivos automotrices incluyen una cámara de visión exterior, para dicha cámara:
- [ 7.5 /A-1-1] NO DEBEN tener cámaras de visión exterior accesibles a través de las API de cámara de Android , a menos que cumplan con los requisitos básicos de la cámara.
- [ 7.5 /A-SR-1] Se RECOMIENDA ENCARECIDAMENTE no rotar ni reflejar horizontalmente la vista previa de la cámara.
- [ 7.5 /A-SR-2] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de al menos 1,3 megapíxeles.
- DEBE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
- PUEDE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara.
Si las implementaciones de dispositivos automotrices incluyen una o más cámaras de visión exterior y cargan el servicio del Sistema de visión exterior (EVS), entonces, para dicha cámara:
- [ 7.5 /A-2-1] NO DEBE rotar ni reflejar horizontalmente la vista previa de la cámara.
Implementaciones de dispositivos automotrices:
- PUEDE incluir una o más cámaras que estén disponibles para aplicaciones de terceros.
Si las implementaciones de dispositivos automotrices incluyen al menos una cámara y la ponen a disposición de aplicaciones de terceros, entonces:
- [ 7.5 /A-3-1] DEBE informar el indicador de función
android.hardware.camera.any. - [ 7.5 /A-3-2] No DEBE declarar la cámara como una cámara de sistema .
- PUEDE admitir cámaras externas descritas en la sección 7.5.3 .
- PUEDE incluir funciones (como enfoque automático, etc.) disponibles para las cámaras orientadas hacia atrás como se describe en la sección 7.5.1 .
Una cámara orientada hacia atrás significa una cámara orientada hacia el mundo que puede ubicarse en cualquier lugar del vehículo y está orientada hacia el exterior de la cabina del vehículo; es decir, capta escenas en el lado más alejado de la carrocería del vehículo, como la cámara de visión trasera.
Una cámara frontal significa una cámara orientada al usuario que puede ubicarse en cualquier lugar del vehículo y está orientada hacia el interior de la cabina del vehículo; es decir, imágenes del usuario, como para videoconferencias y aplicaciones similares.
Implementaciones de dispositivos automotrices:
- [7.5/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir una o más cámaras orientadas al mundo.
- PUEDE incluir una o más cámaras orientadas al usuario.
- [7.5/A-SR-2] Se RECOMIENDAN ENCARECIDAMENTE para admitir la transmisión simultánea de múltiples cámaras.
Si las implementaciones de dispositivos automotrices incluyen al menos una cámara orientada al mundo, entonces, para dicha cámara:
- [7.5/A-1-1] debe orientarse para que la dimensión larga de la cámara se alinee con el plano XY de los ejes del sensor automotriz de Android.
- [7.5/A-SR-3] se recomienda encarecidamente tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
- [7.5/A-1-2] debe tener la cámara principal orientada al mundo como la cámara del mundo con la ID de cámara más baja.
Si las implementaciones de dispositivos automotrices incluyen al menos una cámara que está orientada al usuario, entonces para dicha cámara:
- [7.5/A-2-1] La cámara principal orientada al usuario debe ser la cámara orientada al usuario con la ID de cámara más baja.
- Puede orientarse para que la dimensión larga de la cámara se alinee con el plano XY de los ejes del sensor automotriz de Android.
Si las implementaciones de dispositivos automotrices incluyen una cámara a la que se puede acceder a través de android.hardware.Camera o android.hardware.camera2 API, entonces ellos:
- [7.5/A-3-1] debe cumplir con los requisitos de la cámara central en la Sección 7.5.
Si las implementaciones de dispositivos automotrices incluyen una cámara a la que no se puede acceder a través de android.hardware.Camera o android.hardware.camera2 API, entonces ellos:
- [7.5/A-4-1] debe ser accesible a través del servicio del sistema de vista extendida.
Si las implementaciones de dispositivos automotrices incluyen una o más cámaras accesibles a través del servicio del sistema de vista extendida, para dicha cámara, ellos:
- [7.5/A-5-1] no debe girar ni reflejar horizontalmente la vista previa de la cámara.
- [7.5/A-SR-4] se recomienda encarecidamente tener una resolución de al menos 1.3 megapíxeles.
Si las implementaciones de dispositivos automotrices incluyen una o más cámaras a las que se puede acceder a través del servicio del sistema de vista extendida y android.hardware.Camera o android.hardware.Camera2 API Entonces, para dicha cámara, ellos:
- [7.5/A-6-1] debe informar la misma ID de cámara.
Si las implementaciones de dispositivos automotrices proporcionan una API de cámara patentada, ellos:
- [7.5/A-7-1] debe implementar dicha API de la cámara con
android.hardware.camera2API o API del sistema de vista extendida.
Ver Revisión
Implementaciones de dispositivos automotrices:
- [ 3.8 /A-0-1] no debe permitir que los usuarios secundarios completos que no son el usuario actual de primer plano inicien actividades y tengan acceso a la interfaz de usuario en cualquier pantalla.
Ver Revisión
Si las implementaciones de dispositivos automotrices declaran android.hardware.microphone , ellos:
- [ 9.8.2 /a-1-1] debe mostrar el indicador del micrófono cuando una aplicación accede a los datos de audio desde el micrófono, pero no cuando el micrófono solo se accede por
HotwordDetectionService,SOURCE_HOTWORD,ContentCaptureServiceo aplicaciones que contienen los roles que se califican en la sección 9.1 con identificador CDD [C-4-X]. - [ 9.8.2 /a-1-2] no debe ocultar el indicador de micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.
- [ 9.8.2 /a-1-3] debe proporcionar una posibilidad del usuario para alternar el micrófono en la aplicación Configuración.
Si las implementaciones de dispositivos automotrices declaran android.hardware.camera.any , entonces ellos:
- [ 9.8.2 /A-2-1] debe mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando la cámara solo se accede por aplicaciones que sostienen los roles como
se defineen la sección 9.1 permisos con identificador CDD [C-4-X][C-3-X].
- [ 9.8.2 /a-2-3] debe proporcionar una posibilidad del usuario para alternar la cámara en la aplicación Configuración.
- [ 9.8.2 /a-2-4] debe mostrar aplicaciones recientes y activas que usan la cámara que se devuelve de
PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensaje de atribución asociado con ellos.
Si las implementaciones de dispositivos tienen una pantalla de bloqueo seguro e incluyen uno o más agente de confianza, que implementa la API del sistema TrustAgentService , ellos:
- [ 9.11.1 /a-1-1] debe desafiar al usuario para uno de los métodos de autenticación primarios recomendados (por ejemplo: PIN, patrón, contraseña) con más frecuencia que una vez cada 336 horas.
3.software
3.1. Compatibilidad de la API administrada :
Ver Revisión
Implementaciones de dispositivos:
- [C-0-8] no debe admitir la instalación de aplicaciones dirigidas a un nivel de API inferior a 23.
3.2.3.5. Intentos de aplicación condicionales :
Ver Revisión
Si las implementaciones de dispositivos informan
android.hardware.nfc.uiccoandroid.hardware.nfc.ese, ellos:- [C-19-1] debe implementar el NFCADAPTER.ACTION_TRANSACTION_DETECTECted API de intención (como "EVT_TRANSACTION" definido por la especificación técnica de la Asociación GSM Ts.26-Requisitos de teléfonos NFC) .
3.3.1. Aplicación de interfaces binarias :
Ver Revisión
Implementaciones de dispositivos:
- [C-0-12] debe exportar símbolos
VK_KHR_swapchainfunción para los símbolos de función CoreVulkan 1.0VK_KHR_get_physical_device_properties21.1 , así comoVK_KHR_surfacelibvulkan.soVK_KHR_android_surface,VK_KHR_maintenance1Tenga en cuenta que si bien todos los símbolos deben estar presentes, la Sección 7.1.4.2 describe con más detalle los requisitos para cuándo se espera la implementación completa de cada funciones correspondientes.
- [C-0-12] debe exportar símbolos
Ver Revisión
Si las implementaciones del dispositivo incluyen una pantalla de pantalla o video, ellos:
- [C-1-5] debe generar paletas tonales de color dinámicas utilizando estilos de tema de color enumerados en la
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGESTHEME_CUSTOMIZATE_OVERLAY_PACKAGES Documentation (verandroid.theme.customization.theme_styles), a saberTONAL_SPOT,VIBRANT,EXPRESSIVE,SPRITZ,RAINBOW, fruta_salad yFRUIT_SALADy monocromático y monocromático yMONOCHROMATIC.
- [C-1-5] debe generar paletas tonales de color dinámicas utilizando estilos de tema de color enumerados en la
Ver Revisión
Si las implementaciones del dispositivo, incluida la clave de navegación de la función de reciente, como se detalla en la Sección 7.2.3, altere la interfaz, ellos:
- [C-1-2] debe implementar el comportamiento de fijación de pantalla y proporcionar al usuario un menú de configuración para alternar la función.
3.9.2 Soporte de perfil administrado :
Ver Revisión
Si las implementaciones de dispositivos declaran
android.software.managed_users, ellos:- [C-1-10] debe asegurarse de que los datos de captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se captura una captura de pantalla con una ventana
topActivityque tiene enfoque (el que el usuario interactúa con el final entre todas las actividades) y pertenece a un perfil de trabajo aplicación . - [C-1-11] no debe capturar ningún otro contenido de pantalla (barra de sistema, notificaciones o cualquier contenido de perfil personal), excepto por la ventana/ventana de la aplicación de perfil de trabajo al guardar una captura de pantalla en el perfil de trabajo (para garantizar que los datos del perfil personal son no guardado en el perfil de trabajo).
- [C-1-10] debe asegurarse de que los datos de captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se captura una captura de pantalla con una ventana
3.9.5 Marco de resolución de políticas de dispositivo : nueva sección
Ver Revisión
Si las implementaciones de dispositivos informan
android.software.device_adminoandroid.software.managed_users, entonces ellos:- [C-1-1] debe resolver los conflictos de la política del dispositivo como se documenta en la documentación de AOSP.
5. Compatibilidad multimedia
5.1.4. Codificación de imagen :
Ver Revisión
Las implementaciones de dispositivos deben admitir la codificación de la siguiente imagen de codificación:
- [C-0-4] AVIF
- Los dispositivos deben admitir
BITRATE_MODE_CQy perfil de línea de base.
- Los dispositivos deben admitir
- [C-0-4] AVIF
5.1.5. Decodificación de imágenes :
Ver Revisión
Las implementaciones de dispositivos deben admitir la decodificación de la siguiente imagen de la imagen:
[C-0-7] AVIF (perfil de línea de base)
5.1.6. Detalles de códecs de imagen :
Ver Revisión
Formato/códec Detalles Tipos de archivos/formatos de contenedor compatibles JPEG Base+progresivo JPEG (.jpg) GIF Gif (.gif) PNG PNG (.png) BMP BMP (.BMP) WebP Webp (.webp) Crudo Arw (.arw), cr2 (.cr2), dng (.dng), nef (.nef), nrw (.nrw), orf (.orf), pef (.pef), raf (.raf), rw2 ( .rw2), srw (.srw) HEIF Imagen, colección de imágenes, secuencia de imágenes Heif (.heif), heic (.heic) AVIF (perfil de línea de base) Imagen, colección de imágenes, secuencia de imagen Perfil de línea de base Heif Container (.avif) 5.1.8. Lista de códecs de video :
Ver Revisión
Formato/códec Detalles Tipos de archivos/formatos de contenedor para ser compatibles H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificación)
H.264 AVC Consulte la Sección 5.2 y 5.3 para más detalles - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, no solicitable)
- Matroska (.mkv, solo decodificación)
H.265 HEVC Consulte la Sección 5.3 para más detalles - MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificación)
MPEG-2 Perfil principal - MPEG2-TS (.ts, no solicitable)
- 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 Consulte la Sección 5.2 y 5.3 para más detalles - WebM (.webm)
- Matroska (.mkv)
VP9 Consulte la Sección 5.3 para más detalles - WebM (.webm)
- Matroska (.mkv)
AV1 Consulte la Sección 5.2 y la Sección 5.3 para más detalles - MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificación)
5.1.10. Caracterización del códec 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 el códec es compatible con el códec:
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD 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 x 576 PX (H263)
- 640 x 360 PX (VP8, VP9)
- 640 x 480 PX (codificador MPEG4)
- 720 x 480 PX (otro, AV1 )
- 1408 x 1152 PX (H263)
- 1280 x 720 PX (otro, AV1 )
1920 x 1080 PX (que no sea MPEG4, AV1 ) 3840 x 2160 PX (HEVC, VP9, AV1 ) Ver Revisión
Si las implementaciones de dispositivos admiten cualquier codificador de video y lo ponen a disposición de las aplicaciones de terceros, ellos:- No debería ser, en dos ventanas deslizantes, más del 15% sobre la tasa de bits entre los intervalos intraframe (I-Frame).
- No debe ser más del 100% sobre la tasa de bits sobre una ventana deslizante de 1 segundo.
Si las implementaciones de dispositivos admiten cualquier codificador de video y lo pongan a disposición de las aplicaciones de terceros, y establezca el
MediaFormat.KEY_BITRATE_MODEaBITRATE_MODE_VBRpara que el codificador funcione en modo de tasa de bits variable, entonces, siempre que no afecte el piso de calidad mínima , la tasa de bits codificada:-
[C-5-1] no debeser , sobre una ventana deslizante, más del 15% sobre la tasa de bits entre los intervalos intraframe (I-Frame). -
[C-5-2] no debeser más del 100% sobre la tasa de bits sobre una ventana deslizante de 1 segundo.
Si las implementaciones de dispositivos admiten cualquier codificador de video y lo pongan a disposición de las aplicaciones de terceros y establece el
MediaFormat.KEY_BITRATE_MODEenBITRATE_MODE_CBRpara que el codificador funcione en modo de tasa de bits constante, luego la tasa de bits codificada:-
[C-6-1] debe[C-SR-2] se recomienda encarecidamente que no sea más del 15% sobre la tasa de bits objetivo sobre una ventana deslizante de 1 segundo.
Ver Revisión
Si las implementaciones de dispositivos admiten codificadores H.263 y lo ponen a disposición de las aplicaciones de terceros, ellos:
- [C-1-1] debe admitir la resolución QCIF (176 x 144) utilizando el nivel de perfil de referencia 45. La resolución SQCIF es opcional.
-
Debe admitir tasas de bits configurables dinámicamente para el codificador compatible.
Ver Revisión
Si las implementaciones de dispositivos admiten el códec H.265, ellos:
- [C-1-1] debe admitir el nivel de perfil principal 3 hasta 512 x 512 resolución .
-
Debe admitir los perfiles de codificación HD como se indica en la siguiente tabla. - [C-SR-1] se recomienda encarecidamente 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 : nueva sección
Ver Revisión
Si las implementaciones de dispositivos admiten el códec AV1, entonces, ellos:
- [C-1-1] debe admitir el perfil principal que incluye contenido de 8 bits y 10 bits.
[C-1-2] Debe publicar datos de rendimiento IE Informe de datos de rendimiento a través de
getSupportedFrameRatesFor()ogetSupportedPerformancePoints()API para las resoluciones compatibles en la tabla a continuación.[C-1-3] debe aceptar metadatos HDR y emitirlo a la corriente de bits
Si el codificador AV1 está acelerado, entonces:
- [C-2-1] debe admitir hasta e incluir el perfil de codificación HD1080P de la tabla a continuación:
Dakota del Sur alta definición 720p alta definición 1080p HD Resolución de video 720 x 480 PX 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps Bitrate de vídeo 5Mbps 8Mbps 16Mbps 50Mbps Ver Revisión
Si las implementaciones de dispositivos admiten decodificadores H.263, ellos:
- [C-1-1] debe admitir el nivel de perfil de línea de base 30 (resoluciones CIF, QCIF y SQCIF @ 30FPS 384Kbps) y el nivel 45 (resoluciones QCIF y SQCIF @ 30FPS 128kbps) .
Ver Revisión
Si las implementaciones de dispositivos admiten el códec AV1, ellos:- [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 lo ponen a disposición de las aplicaciones de terceros, ellos:
- [C-1-1] debe admitir el perfil principal que incluye contenido de 8 bits y 10 bits.
Si las implementaciones de dispositivos proporcionan soporte para el códec AV1 con un decodificador acelerado de hardware, entonces ellos:
- [C-2-1] debe ser capaz de decodificar al menos perfiles de decodificación de video HD 720p desde la tabla a continuación cuando la altura informada por
Display.getSupportedModes()es igual o superior a 720p. - [C-2-2] debe ser capaz de decodificar al menos perfiles de decodificación de video HD 1080p de la tabla a continuación cuando la altura informada por
Display.getSupportedModes()es igual o superior a 1080p.
Dakota del Sur alta definición 720p alta definición 1080p HD Resolución de video 720 x 480 PX 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps Bitrate de vídeo 5Mbps 8Mbps 16Mbps 50Mbps Si las implementaciones de dispositivos admiten el perfil HDR a través de las API de medios, entonces ellos:
- [C-3-1] debe admitir la extracción y la salida de metadatos HDR desde la corriente de bits y/o el contenedor.
- [C-3-2] debe mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).
5.4.2. Captura para el reconocimiento de voz :
Ver Revisión
Si las implementaciones de dispositivos declaran
android.hardware.microphone, ellos:- Debe establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz se reproduce a un nivel de presión de sonido de 90 dB (SPL) (medido
a una distancia de 30 cm desdeel lado del micrófono) produce una respuesta ideal de RMS 2500 dentro de un rango de 1770 y 3530 para 16 muestras de bits (o -22.35 dB ± 3DB escala completa para muestras de punto flotante/doble precisión) para cada micrófono utilizado para grabar la fuente de audio de reconocimiento de voz.
- Debe establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz se reproduce a un nivel de presión de sonido de 90 dB (SPL) (medido
Ver Revisión
Si las implementaciones de dispositivos declaran la función
android.hardware.audio.output, ellos:- [C-1-4] debe admitir efectos de audio con entrada y salida de punto flotante.
- [C-1-5] debe asegurarse de que los efectos de audio admitan múltiples canales hasta el recuento de canales de mezcladores también conocido como FCC_LIMIT.
Ver Revisión
Si las implementaciones de dispositivos declaran
android.hardware.audio.output, se recomienda encarecidamente cumplir o superar los siguientes requisitos:- [C-SR-4] La marca de tiempo de salida devuelta por AudioTrack.gettimestamp y
AAudioStream_getTimestampes precisa a +/- 1 ms.
- [C-SR-4] Las latencias de viaje de ida y vuelta calculadas basadas en las marcas de tiempo de entrada y salida devueltas por
AAudioStream_getTimestampse recomiendan que estén dentro de los 30 ms de la latencia de ida y vuelta medida paraAAUDIO_PERFORMANCE_MODE_NONEyAAUDIO_PERFORMANCE_MODE_LOW_LATENCYpara altavoces para altavoces, auriculares y WIRENSED.
- [C-SR-4] La marca de tiempo de salida devuelta por AudioTrack.gettimestamp y
7. Compatibilidad de hardware
Ver Revisión
Android incluye instalaciones que ajustan automáticamente los activos de aplicación y los diseños de UI adecuadamente para el dispositivo para garantizar que las aplicaciones de terceros funcionen bien en una
variedad de configuraciones de hardware .Variedad de pantallas y configuraciones de hardware. Una pantalla compatible con Android es una pantalla de pantalla que implementa todos los comportamientos y API descritos en los desarrolladores de Android: descripción general de la compatibilidad de la pantalla , esta sección (7.1) y sus subsecciones, así como cualquier comportamiento específico de tipo de dispositivo adicional documentado en la Sección 2 de este cdd.En las pantalla (s) compatible con Android donde todas las aplicaciones compatibles con Android de terceros pueden ejecutarse, las implementaciones del dispositivo deben implementar correctamente estas API y comportamientos, como se detalla en esta sección.Iniciar nuevos requisitos
Implementaciones de dispositivos:
- [C-0-1] debe, por defecto, representar aplicaciones de terceros solo en pantallas compatibles con Android.
Las unidades a las que se hace referencia por los requisitos en esta sección se definen de la siguiente manera:
- Tamaño diagonal físico . La distancia en pulgadas entre dos esquinas opuestas de la porción iluminada de la pantalla.
-
puntos por pulgada (DPI)densidad . El número de píxeles abarcados por un tramo horizontal o vertical lineal de 1 ” , expresado como píxeles por pulgada (PPI o DPI) . Cuando se enumeran los valoresde PPIy DPI DPI, tanto DPI horizontal como vertical debe caer dentro del rango enumerado . - relación de aspecto . La relación de los píxeles de la dimensión más larga a la dimensión más corta de la pantalla. Por ejemplo, una visualización de 480x854 píxeles sería 854/480 = 1.779, o aproximadamente "16: 9".
- Píxel independiente de la densidad (DP) .
Launidad de píxel A virtual se normalizó a una densidad depantalla de pantalla de 160 dpide 160. Para cierta densidad d, y varios píxeles P, el número de píxeles DPIS de densidad DP, se calcula como:píxeles = dps * (densidad/160)dp = (160 / d) * p .
7.1.1.1. Tamaño y forma de pantalla :
Ver Revisión
Si las implementaciones de dispositivos admiten pantallas capaces de la configuración de tamaño
UI_MODE_TYPE_NORMALeincluyenvisualización física de uso compatible con Android con esquinas redondeadas para representar estas pantallas , ellos:- [C-1-1] debe asegurarse de que se cumplan al menos uno de los siguientes requisitos para cada pantalla :
- El radio de las esquinas redondeadas es menor o igual a 38 dp.
Cuando se ancla un cuadro de 15 dp por 15 dp en cada esquina de la pantalla lógica, se ve al menos un píxel de cada caja en la pantalla.
Debe incluir la posibilidad del usuario para cambiar al modo de visualización con las esquinas rectangulares.
Iniciar nuevos requisitos
Si las implementaciones del dispositivo solo son capaces de configuración del teclado
NO_KEYSy tienen la intención de informar soporte para la configuración del modo UIUI_MODE_TYPE_NORMAL, ellos:- [C-4-1] debe tener un tamaño de diseño, excluyendo cualquier recorte de pantalla, de al menos 596 dp x 384 dp o más.
Si las implementaciones de dispositivos incluyen una (s) pantalla (s) compatible con Android que es plegable, o incluye una bisagra plegable entre múltiples paneles de visualización y pone a disposición de las aplicaciones de terceros, ellos:
- [C-2-1] debe implementar la última versión estable disponible de la API Extensions o la versión estable de la API de Sidecar que se utilizará por Window Manager Jetpack Biblioteca.
Si las implementaciones del dispositivo incluyen una (s) pantalla (s) compatible con Android que es plegable, o incluye una bisagra plegable entre múltiples paneles de pantalla y si la bisagra o pliegue cruza una ventana de aplicación de pantalla completa, ellos:
- [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 API Sidecar a la aplicación.
Si las implementaciones de dispositivos incluyen una o más áreas de visualización compatibles con Android que son plegables, o incluyen una bisagra plegable entre múltiples áreas de panel de visualización compatible con Android y pongan a disposición tales áreas de visualización para aplicaciones, ellos:
- [C-4-1] debe implementar la versión correcta del nivel de API de extensiones del administrador de ventanas como se describe en la próxima documentación.
7.1.1.2. Relación de aspecto de la pantalla : eliminada
7.1.1.3. Densidad de pantalla :
Ver Revisión
Implementaciones de dispositivos:
- [C-0-1]
De forma predeterminada, las implementaciones del dispositivodeben informarsolouna de las densidades de Android Framework que se enumeran enDisplayMetricsa través de la APIDENSITY_DEVICE_STABLEy este valor debe ser un valor estático para cada pantalla físicano debe cambiar en ningún momento; Sin embargo,sin embargo, el dispositivo puede informar unadensidad arbitrariadiferenteDisplayMetrics.density
- Las implementaciones de dispositivos deben definir la densidad de marco de Android estándar que está numéricamente más cercana a la densidad física de la pantalla, a menos que esa densidad lógica empuje el tamaño de la pantalla informado por debajo del mínimo admitido. Si la densidad de marco de Android estándar que está numéricamente más cercana a la densidad física da como resultado un tamaño de pantalla que es más pequeño que el tamaño de pantalla compatible más pequeño compatible (ancho de 320 dp), las implementaciones del dispositivo deben informar la siguiente densidad de marco de Android más baja.
Iniciar nuevos requisitos
- Debería definir la densidad de marco de Android estándar que está numéricamente más cercana a la densidad física de la pantalla, o un valor que se asignaría a las mismas mediciones equivalentes del campo de visión angular equivalente de un dispositivo portátil.
Si las implementaciones de dispositivos proporcionan,
hayla posibilidad de cambiar el tamaño de visualización del dispositivo , ellos :- [C-1-1]
El tamaño de la pantalla no debe escalar,no debe escalar la pantalla mayor de 1.5 vecesDENSITY_DEVICE_STABLEdensidad nativao producir una dimensión de pantalla mínima efectiva menor que 320dp (equivalente al calificador de recursos SW320DP), lo cual es lo primero. - [C-1-2]
El tamaño de la pantalla no debe escalarse,no debe escalar la pantalla menor de 0.85 veces ladensidad nativaDENSITY_DEVICE_STABLE.
- [C-0-1]
Ver Revisión
Si las implementaciones de dispositivos incluyen soporte para Vulkan
1.0 o superior, ellos:[C-1-3] debe implementar completamente las API
Vulkan 1.0Vulkan 1.1 para cadaVkPhysicalDeviceenumerado.[C-1-5] no deben enumerar las capas proporcionadas por bibliotecas fuera del paquete de aplicación, o proporcionar otras formas de rastrear o interceptar la API Vulkan, a menos que la aplicación tenga el atributo
android:debuggableestablecido comotrueo los metadatoscom.android.graphics.injectLayers.enableestablecer entrue.
- Debe admitir
VkPhysicalDeviceProtectedMemoryFeaturesyVK_EXT_global_priority.
- [C-1-13] debe satisfacer los requisitos especificados por el perfil de base 2021 de Android .
[C-SR-5] se recomienda encarecidamente admitir
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemoryyVK_EXT_global_priority.[C-SR-6] se recomienda encarecidamente usar
SkiaVkcon HWUI.
Si las implementaciones del dispositivo incluyen soporte para Vulkan 1.1 y declaran cualquiera de los indicadores de características de Vulkan descritos aquí , ellos:
- [C-SR-7] se recomienda encarecidamente que la extensión
VK_KHR_external_fence_fdesté disponible para aplicaciones de terceros y habilite la aplicación para exportar la carga útil de la cerca y importar la carga útil de la cerca de los descriptores de archivos POSIX como se describe aquí .
7.3.10. Sensores biométricos :
Ver Revisión
Si las implementaciones de dispositivos tienen múltiples sensores biométricos, ellos:
[C-7-1] debe, cuando una biométrica está en bloqueo (es decir, la biométrica está deshabilitada hasta que el usuario desbloquea con autenticación primaria) o bloqueo de tiempo en el tiempo (es decir, la biométrica se deshabilita temporalmente hasta que el usuario espera un intervalo de tiempo) Debido a demasiados intentos fallidos, también bloquee todas las demás biometría de una clase biométrica inferior. En el caso del bloqueo de límite de tiempo, el tiempo de retroceso para la verificación biométrica debe ser el tiempo máximo de retroceso de todas las biométricas en el bloqueo de tiempo límite.
[C-SR-12] se recomiendan fuertemente, cuando un biométrico está en bloqueo (es decir, la biométrica está deshabilitada hasta que el usuario desbloquea con la autenticación primaria) o un bloqueo de tiempo en el tiempo (es decir, la biométrica se deshabilita temporalmente hasta que el usuario espera un tiempo intervalo) debido a demasiados intentos fallidos, para bloquear también todas las demás biometría de la misma clase biométrica. En el caso del bloqueo de límite de tiempo, se recomienda encarecidamente el tiempo de retroceso para la verificación biométrica para ser el tiempo máximo de retroceso de todas las biometría en el bloqueo de tiempo.
[C-7-2] debe desafiar al usuario para la autenticación primaria recomendada (por ejemplo: PIN, patrón, contraseña) para restablecer el contador de bloqueo para que se bloquee un biométrico. Se puede permitir que la biometría de clase 3 restablezca el contador de bloqueo para una biométrica bloqueada de la misma clase o baja. No se debe permitir que la biometría de Clase 2 o Clase 1 complete una operación de bloqueo de reinicio para cualquier biometría.
Si las implementaciones de dispositivos desean tratar un sensor biométrico como clase 1 (anteriormente conveniencia ), ellos:
[C-1-12] debe tener una tasa de aceptación de la falsificación e impostores no superiores al 40% por especie de instrumento de ataque de presentación (PAI) , según lo medido por los protocolos de prueba de biometría de Android .
[C-SR-13] se recomienda encarecidamente tener una tasa de aceptación de la parodia e impostores no superiores al 30% por especie de instrumento de ataque de presentación (PAI) , medido por los protocolos de prueba de biometría Android .
[C-SR-14] se recomienda encarecidamente revelar la clase biométrica del sensor biométrico y los riesgos correspondientes de habilitarlo.
[C-SR-17] se recomiendan encarecidamente implementar las nuevas interfaces de Aidl (como,
IFace.aidleIFingerprint.aidl).
Si las implementaciones de dispositivos desean tratar un sensor biométrico como clase 2 (anteriormente débil ), ellos:
- [C-SR-15] se recomienda encarecidamente tener una tasa de aceptación de la parodia e impostores no superiores al 20% por especie de instrumento de ataque de presentación (PAI) , medido por los protocolos de prueba de biometría Android .
- [C-2-3] debe realizar la coincidencia biométrica en un entorno de ejecución aislado fuera del usuario de Android o el espacio del núcleo, como el entorno de ejecución de confianza (TEE),
oen un chip con un canal seguro al entorno de ejecución aislado o en protegido Máquina virtual que cumple con los requisitos en la Sección 9.17 . - [C-2-4] debe tener todos los datos identificables encriptados y autenticados criptográficamente de tal manera que no se pueden adquirir, leer o alterar fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado como se documenta en las pautas de implementación en el sitio del proyecto de código abierto de Android o una máquina virtual protegida controlada por Hypervisor que cumple con los requisitos en la Sección 9.17 .
- [C-2-5] para biometría basada en cámara, mientras que la autenticación o inscripción basada en biométrica está ocurriendo:
- Debe operar la cámara en un modo que evite que los marcos de la cámara se lean o se alteren fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado o una máquina virtual protegida controlada por Hypervisor que cumple con los requisitos en la Sección 9.17 .
- Para las soluciones de cámara única RGB, los marcos de la cámara pueden ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para la inscripción, pero aún no debe ser alterable.
- [C-2-7] no debe permitir el acceso no encriptado a datos biométricos identificables o cualquier datos derivados de él (como incrustaciones) al procesador de aplicaciones fuera del contexto del TEE o la máquina virtual protegida controlada por Hypervisor que cumple con los requisitos en la sección 9.17 . Los dispositivos de actualización lanzados en Android versión 9 o anterior no están exentos de C-2-7.
Si las implementaciones de dispositivos desean tratar un sensor biométrico como clase 3 (anteriormente fuerte ), ellos:
- [C-SR-16] se recomienda encarecidamente tener una tasa de aceptación de la parodia e impostura no superior al 7% por especie de instrumento de ataque de presentación (PAI) , medido por los protocolos de prueba de biometría de Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Ver Revisión
Si las implementaciones del dispositivo incluyen soporte para 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, ellos:
- [C-1-2] debe informar el indicador de la función de hardware
android.hardware.uwb. - [C-1-3] debe admitir todos los siguientes conjuntos de configuración (combinaciones predefinidas de parámetros FIRA UCI ) definidas en la implementación de AOSP.
-
CONFIG_ID_1:STATIC STS DS-TWRdefinido por FIRA Rango, modo diferido, intervalo de alcance 240 ms. -
CONFIG_ID_2:STATIC STS DS-TWR, modo diferido, intervalo de rango de 200 ms. Caso de uso típico: el teléfono inteligente interactúa con muchos dispositivos inteligentes. -
CONFIG_ID_3: igual queCONFIG_ID_1, excepto que no se informan los datos de ángulo de llegada (AOA). -
CONFIG_ID_4: igual queCONFIG_ID_1, excepto que el modo de seguridad P-STS está habilitado. -
CONFIG_ID_5: igual queCONFIG_ID_2, excepto que el modo de seguridad P-STS está habilitado. -
CONFIG_ID_6: igual queCONFIG_ID_3, excepto que el modo de seguridad P-STS está habilitado. -
CONFIG_ID_7: igual queCONFIG_ID_2, excepto que el modo de tecla de controle individual P-STS está habilitado.
-
- [C-1-4] debe proporcionar un servicio del usuario para permitir al usuario alternar el estado/apagado de la radio UWB.
- [C-1-5] Debe aplicar que las aplicaciones que usan la radio UWB tengan el permiso
UWB_RANGING(bajo el grupo de permisoNEARBY_DEVICES).
Pasar las pruebas de conformidad y certificación relevantes definidas por organizaciones estándar, incluidas FIRA , CCC y CSA, ayuda a garantizar las funciones 802.1.15.4 correctamente.
- [C-1-2] debe informar el indicador de la función de hardware
Ver Revisión
"Telefonía", según lo utilizado por las API de Android, y este documento se refiere específicamente al hardware relacionado con la colocación de llamadas de voz y el envío de mensajes SMS , o establecer datos móviles a través de una red móvil (p. Ej. GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo que admite "telefonía" puede optar por ofrecer algunas o todos los servicios de llamadas, mensajes y datos como se adapta al producto.
a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes, son para el propósito de Android considerado independiente de cualquier conectividad de datos que pueda implementarse utilizando la misma red. En otras palabras, la funcionalidad y las API de Android se refieren específicamente a llamadas de voz y SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas o enviar/recibir mensajes SMS no se consideran un dispositivo de telefonía, independientemente de si usan una red celular para la conectividad de datos.Ver Revisión
Si las implementaciones del dispositivo incluyen soporte para 802.11 y exponen la funcionalidad a una aplicación de terceros, ellos:
- [C-1-4] debe admitir DNS de multidifusión (MDNS) y no debe filtrar paquetes MDNS (224.0.0.251 o FF02 :: FB ) en cualquier momento de la operación, incluido cuando la pantalla no está en un estado activo, a menos que se caiga o se caiga o El filtrado de estos paquetes es necesario para mantenerse dentro de los rangos de consumo de energía requeridos por los requisitos reglamentarios aplicables al mercado objetivo.
Para implementaciones de dispositivos de televisión Android, incluso cuando se encuentran en los estados de energía en espera.
- [C-1-4] debe admitir DNS de multidifusión (MDNS) y no debe filtrar paquetes MDNS (224.0.0.251 o FF02 :: FB ) en cualquier momento de la operación, incluido cuando la pantalla no está en un estado activo, a menos que se caiga o se caiga o El filtrado de estos paquetes es necesario para mantenerse dentro de los rangos de consumo de energía requeridos por los requisitos reglamentarios aplicables al mercado objetivo.
Ver Revisión
Si las implementaciones de dispositivos declaran caracteres_bluetooth_le, ellos:
- [C-SR-2] se recomienda encarecidamente medir y compensar el desplazamiento de RX para garantizar que la mediana de RSSI BLSI sea -60dbm +/- 10 dB a 1 m de distancia desde un dispositivo de referencia que transmite en
ADVERTISE_TX_POWER_HIGH, donde están orientados de tal manera que están orientados de tal manera que están de tal manera que están orientados. en 'planos paralelos' con pantallas que enfrentan la misma dirección. - [C-SR-3] se recomienda encarecidamente medir y compensar el desplazamiento de TX para garantizar que la mediana de RSSI BLSI sea -60dbm +/- 10 dB al escanear desde un dispositivo de referencia colocado a una distancia de 1 m y transmitir a
ADVERTISE_TX_POWER_HIGH, donde los dispositivos están orientados orientados de tal manera que están en 'planos paralelos' con pantallas que enfrentan la misma dirección.
- [C-10-3] debe medir y compensar el desplazamiento de RX para garantizar que la mediana de RSSI BLSI sea -55dbm +/- 10 dB a 1 m de distancia desde un dispositivo de referencia que transmite en
ADVERTISE_TX_POWER_HIGH. - [C-10-4] debe medir y compensar el desplazamiento de TX para garantizar que la mediana de RSSI BLSI sea -55dbm +/- 10 dB al escanear desde un dispositivo de referencia colocado a una distancia de 1 m y transmitir a
ADVERTISE_TX_POWER_HIGH.
Si las implementaciones de dispositivos admiten Bluetooth versión 5.0, entonces ellos:
- [C-SR-4] se recomiendan encarecidamente para brindar apoyo para:
- LE 2M PHY
- Le Codec Phy
- LE Extensión publicitaria
- Publicidad periódica
- Al menos 10 conjuntos de anuncios
- Al menos 8 LE Conexiones concurrentes. Cada conexión puede estar en cualquiera de los roles de topología de conexión.
- LE Link Layer Privacy
- Un tamaño de "lista de resolución" de al menos 8 entradas
- [C-SR-2] se recomienda encarecidamente medir y compensar el desplazamiento de RX para garantizar que la mediana de RSSI BLSI sea -60dbm +/- 10 dB a 1 m de distancia desde un dispositivo de referencia que transmite en
Ver Revisión
- [C-1-7] debe garantizar que la mediana de las mediciones de distancia a 1 m desde el dispositivo de referencia esté dentro de [0.75m, 1.25m], donde la distancia de la verdad del suelo se mide desde el borde superior del DUT.
mantenido boca arriba e inclinado 45 grados.
- [C-1-7] debe garantizar que la mediana de las mediciones de distancia a 1 m desde el dispositivo de referencia esté dentro de [0.75m, 1.25m], donde la distancia de la verdad del suelo se mide desde el borde superior del DUT.
Ver Revisión
Una cámara trasera es una cámara ubicada en el costado del dispositivo frente a la pantalla; Es decir, imágenes de escenas en el lado más alejado del dispositivo, como una cámara tradicional.
Una cámara trasera es una cámara orientada al mundo que imagina escenas en el otro lado del dispositivo, como una cámara tradicional; En dispositivos portátiles, esa es una cámara ubicada en el lado del dispositivo opuesto a la pantalla.
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 se usa típicamente para obtener imágenes del usuario, como para videoconferencias y aplicaciones similares.
Una cámara frontal es una cámara orientada al usuario que generalmente se usa para obtener imágenes del usuario, como para videoconferencias y aplicaciones similares; En dispositivos portátiles, esa es una cámara ubicada en el mismo lado del dispositivo que la pantalla.
Ver Revisión
Una cámara externa es una cámara que se puede conectar o separarse físicamente de la implementación del dispositivo en cualquier momento y puede enfrentar cualquier dirección; como cámaras USB.
7.5.4. Comportamiento de la API de la cámara :
Ver Revisión
Las implementaciones de dispositivos deben implementar los siguientes comportamientos para las API relacionadas con la cámara, para todas las cámaras disponibles. Implementaciones de dispositivos:
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consisting of all of the RGB cameras facing that direction as physical sub-devices.
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
See revision
Devices that fulfill all of the following criteria are exempt from the requirement above:
- Device implementations that are not capable of being rotated by the user such as automotive devices.
See revision
Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.
If device implementations DO NOT include such a general purpose haptic actuator, they:
- [7.10/C] MUST return false for
Vibrator.hasVibrator().
If device implementations DO include at least one such general purpose haptic actuator, they:
- [C-1-1] MUST return true for
Vibrator.hasVibrator(). - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstantsnamely (CLOCK_TICK,CONTEXT_CLICK,KEYBOARD_PRESS,KEYBOARD_RELEASE,KEYBOARD_TAP,LONG_PRESS,TEXT_HANDLE_MOVE,VIRTUAL_KEY,VIRTUAL_KEY_RELEASE,CONFIRM,REJECT,GESTURE_STARTandGESTURE_END). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffectnamely (EFFECT_TICK,EFFECT_CLICK,EFFECT_HEAVY_CLICKandEFFECT_DOUBLE_CLICK) and all feasible publicPRIMITIVE_*constants for rich haptics inandroid.os.VibrationEffect.Compositionnamely (CLICK,TICK,LOW_TICK,QUICK_FALL,QUICK_RISE,SLOW_RISE,SPIN,THUD). Some of these primitives, such asLOW_TICKandSPINmay only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstantsto the recommendedandroid.os.VibrationEffectconstants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()andcreateWaveform()APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl().
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()andandroid.os.Vibrator.arePrimitivesSupported()APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/C] MUST return false for
9. Security Model Compatibility
See revision
Device implementations:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionServicethey:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATIONas the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW -
Intent.ACTION_SENDTO -
Intent.ACTION_SEND -
Intent.ACTION_EDIT -
Intent.ACTION_INSERT -
Intent.ACTION_INSERT_OR_EDIT -
Intent.ACTION_SEND_MULTIPLE -
Intent.ACTION_PICK -
Intent.ACTION_GET_CONTENT -
MediaStore.ACTION_IMAGE_CAPTURE -
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
9.7. Características de seguridad :
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagModemanifest option:- heap buffer overflow
- use after free
- doble gratis
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported.
If device implementations set the system property
ro.arm64.memtag.bootctl_supportedto true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctlto accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag: a Memory Safety technology as defined above is enabled -
memtag-once: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl.[C-3-4] MUST set
arm64.memtag.bootctlto the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay(),VirtualDeviceManager.createVirtualDisplay(), or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()with theandroid.app.role.COMPANION_DEVICE_APP_STREAMINGor theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGdevice profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
ContentCaptureService,AugmentedAutofillService,AppSearchGlobalManager.query, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillServiceto the system. - Any screen or other data accessible via
Content CaptureAPI. - Any screen or other data accessible via
FieldClassificationServiceAPI - Any application data passed to the system via the
AppSearchManagerAPI and accessible viaAppSearchGlobalManager.query.
- Any other events that an application provides to the system via the
Content CaptureAPI or orAppSearchManagerAPI a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord,SoundTriggeror other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is compartido. Unless such functionality is built as an Android SDK API (AmbientContext,HotwordDetectionService).[C-1-6] MUST provide user affordance to erase such data that the
ContentCaptureServiceifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephonyfeature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONYMUST contain at least the following information:-
SubscriptionManagerServicedump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Permiso .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService,WearableSensingService,VisualQueryDetector). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORDas an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANTrole. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionServiceand/orVisualQueryDetectionServiceAndroid APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::queryAPI provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATSpermission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentServiceSystem API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of inquietud.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachinepackage. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the