Androide 14
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_CAMERA
para 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_NUMBER
en el
Ver revisión
- [C-0-13] DEBE implementar el comando de shell
dumpsys gpu --gpuwork
para 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,:
- [ 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_NORMAL
disponible para aplicaciones de terceros en un área de pantalla física sin obstáculos que tenga al menos 2,2 pulgadas en el borde corto y 3,4 pulgadas en el borde largo.[ 7.1 .1.3/H-0-1]* DEBE establecer el valor de
DENSITY_DEVICE_STABLE
para que sea 92% o mayor que la densidad física real de la pantalla correspondiente.
Si las implementaciones de dispositivos portátiles declaran
android.hardware.audio.output
yandroid.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 GESTURE_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
ControlsProviderService
yControl
API 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=true
y la aplicación declara los metadatosMETA_DATA_PANEL_ACTIVITY
en la declaraciónControlsProviderService
, incluido el ComponentName de una actividad válida (según lo define 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_CONTROLS
al 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.isHeadlessSystemUserMode
entrue
.
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,
ContentCaptureService
o 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
ContentCaptureService
o 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 aContentCaptureService
o al servicio de reconocimiento de voz en el dispositivo. - [9.8/H-3-3] DEBE mostrar un aviso de usuario en la interfaz de usuario del sistema cuando el dispositivo detecta la intención del usuario de interactuar con la aplicación de asistente digital (por ejemplo, detectando la presencia del usuario a través de la cámara).
- [9.8/H-3-4] DEBE mostrar un indicador de micrófono y mostrar la consulta del usuario detectada en la interfaz de usuario inmediatamente después de que se detecta la consulta del usuario.
- [9.8/H-3-5] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección visual de consultas.
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 video de 1080p a 720p únicamente 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 video de 1080p a 720p únicamente 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 de 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_BIT
oAUDIO_FORMAT_PCM_FLOAT
para su formato de salida de destino. - [5.6/H-1-4] DEBE admitir >= dispositivos de audio USB de 4 canales (esto lo utilizan los controladores de DJ para obtener una vista previa de las canciones).
- [5.6/H-1-5] DEBE admitir dispositivos MIDI compatibles con su clase y declarar el indicador de función MIDI.
- [5.6/H-1-9] DEBE admitir al menos 12 canales de mezcla. Esto implica la capacidad de abrir una AudioTrack con máscara de canal 7.1.4 y espacializar o mezclar adecuadamente todos los canales a estéreo.
- [5.6/H-SR] Se RECOMIENDA ENCARECIDAMENTE admitir mezcla de 24 canales con al menos soporte para máscaras de 9.1.6 y 22.2 canales.
- [5.7/H-1-2] DEBE admitir
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
con las siguientes capacidades de descifrado de contenido.
Tamaño mínimo de muestra | 4 MB |
Número mínimo de submuestras: H264 o HEVC | 32 |
Número mínimo de submuestras - VP9 | 9 |
Número mínimo de submuestras - AV1 | 288 |
Tamaño mínimo del búfer de submuestra | 1 MB |
Tamaño mínimo del búfer criptográfico genérico | 500 KiB |
Número mínimo de sesiones simultáneas | 30 |
Número mínimo de claves por sesión | 20 |
Número total mínimo de claves (todas las sesiones) | 80 |
Número total mínimo de claves DRM (todas las sesiones) | 6 |
Tamaño del mensaje | 16 KiB |
Cuadros descifrados por segundo | 60 fps |
- [5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes de hardware compatible con AVIF Baseline Profile.
- [5.1/H-1-18] DEBE admitir el codificador AV1 que puede codificar una resolución de hasta 480p a 30 fps y 1 Mbps.
-
[5.12/H-1-1] DEBE[5.12/H-SR] Se recomienda encarecidamente para admitir la funciónFeature_HdrEditing
para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo. - [5.12/H-1-2] DEBE admitir el formato de color RGBA_1010102 para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
- [5.12/H-1-3] DEBE anunciar soporte para la extensión EXT_YUV_target para muestrear texturas YUV tanto en 8 como en 10 bits.
- [7.1.4/H-1-1] DEBE tener al menos 6 superposiciones de hardware en el compositor de hardware (HWC) de la unidad de procesamiento de datos (DPU), y al menos 2 de ellas capaces de mostrar contenido de video de 10 bits.
Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
e incluyen soporte para un codificador de hardware AVC o HEVC, entonces:
- [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 trasera principal con una resolución de al menos 12 megapíxeles que admita captura de video a 4k@30fps. La cámara trasera principal es la cámara trasera con el ID de cámara más bajo.
- [ 7.5 /H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 6 megapíxeles y admitir captura de video a 1080p@30fps. La cámara frontal principal es la cámara frontal con el ID de cámara más bajo.
- [ 7.5 /H-1-3] DEBE admitir la propiedad
android.info.supportedHardwareLevel
como COMPLETA o mejor para ambas cámaras principales. - [ 7.5 /H-1-4] DEBE admitir
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
para ambas cámaras principales. - [ 7.5 /H-1-5] DEBE tener una latencia de captura JPEG de la cámara 2 < 1000
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_RAW
yandroid.graphics.ImageFormat.RAW_SENSOR
para la cámara trasera principal. - [ 7.5 /H-1-9] DEBE tener una cámara principal orientada hacia atrás que admita 720p o 1080p a 240 fps.
- [ 7.5 /H-1-10] DEBE tener ZOOM_RATIO mínimo < 1.0 para las cámaras principales si hay una cámara RGB ultra ancha orientada en la misma dirección.
- [ 7.5 /H-1-11] DEBE implementar transmisión simultánea de adelante hacia atrás en las cámaras principales.
- [ 7.5 /H-1-12] DEBE admitir
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
tanto para la cámara frontal principal como para la cámara trasera principal. - [ 7.5 /H-1-13] DEBE admitir la capacidad
LOGICAL_MULTI_CAMERA
para las cámaras principales si hay más de 1 cámara RGB orientada en la misma dirección. - [ 7.5 /H-1-14] DEBE admitir la capacidad
STREAM_USE_CASE
tanto 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 varias cámaras.
Si las implementaciones de dispositivos automotrices incluyen al menos una cámara orientada al mundo, entonces, para dicha cámara:
- [7.5/A-1-1] DEBE orientarse de modo que la dimensión larga de la cámara se alinee con el plano XY de los ejes de los sensores automotrices de Android.
- [7.5/A-SR-3] Se RECOMIENDA ENCARECIDAMENTE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
- [7.5/A-1-2] DEBE tener la cámara principal orientada al mundo como la cámara orientada al mundo con el ID de cámara más bajo.
Si las implementaciones de dispositivos automotrices incluyen al menos una cámara orientada al usuario, entonces, para dicha cámara:
- [7.5/A-2-1] La cámara principal orientada al usuario DEBE ser la cámara orientada al usuario con la ID de cámara más baja.
- PUEDE orientarse de modo que la dimensión larga de la cámara se alinee con el plano XY de los ejes de los sensores automotrices de Android.
Si las implementaciones de dispositivos automotrices incluyen una cámara a la que se puede acceder a través de la API android.hardware.Camera
o android.hardware.camera2
, entonces:
- [7.5/A-3-1] DEBE cumplir con los requisitos básicos de la cámara en la sección 7.5.
Si las implementaciones de dispositivos automotrices incluyen una cámara a la que no se puede acceder a través de la API android.hardware.Camera
o android.hardware.camera2
, entonces:
- [7.5/A-4-1] DEBE ser accesible a través del servicio Extended View System.
Si las implementaciones de dispositivos automotrices incluyen una o más cámaras accesibles a través del Servicio de sistema de vista extendida, para dicha cámara:
- [7.5/A-5-1] NO DEBE girar ni reflejar horizontalmente la vista previa de la cámara.
- [7.5/A-SR-4] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de al menos 1,3 megapíxeles.
Si las implementaciones de dispositivos automotrices incluyen una o más cámaras a las que se puede acceder a través del Servicio de sistema de vista extendida y de la API android.hardware.Camera
o android.hardware.Camera2
, entonces, para dicha cámara:
- [7.5/A-6-1] DEBE informar la misma ID de cámara.
Si las implementaciones de dispositivos automotrices proporcionan una API de cámara patentada,:
- [7.5/A-7-1] DEBE implementar dicha API de cámara utilizando la API
android.hardware.camera2
o la API del sistema de vista extendida.
Ver revisión
Implementaciones de dispositivos automotrices:
- [ 3.8 /A-0-1] NO DEBE permitir que usuarios secundarios completos que no sean el usuario de primer plano actual inicien actividades y tengan acceso a la interfaz de usuario en ninguna pantalla.
Ver revisión
Si las implementaciones de dispositivos automotrices declaran android.hardware.microphone
,:
- [ 9.8.2 /A-1-1] DEBE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
o aplicaciones que desempeñan los roles mencionados en la sección 9.1 con identificador CDD [C-4-X]. - [ 9.8.2 /A-1-2] No DEBE ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
- [ 9.8.2 /A-1-3] DEBE proporcionar al usuario la posibilidad de alternar el micrófono en la aplicación Configuración.
Si las implementaciones de dispositivos automotrices declaran android.hardware.camera.any
, entonces:
- [ 9.8.2 /A-2-1] DEBE mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando solo acceden a la cámara las aplicaciones que desempeñan las funciones
definidasen la Sección 9.1 Permisos. con identificador CDD [C-4-X][C-3-X].
- [ 9.8.2 /A-2-3] DEBE proporcionar al usuario la posibilidad de alternar la cámara en la aplicación Configuración.
- [ 9.8.2 /A-2-4] DEBE mostrar las aplicaciones recientes y activas que usan la cámara tal como se devuelven desde
PermissionManager.getIndicatorAppOpUsageData()
, junto con cualquier mensaje de atribución asociado con ellas.
Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza, que implementan la API del sistema TrustAgentService
, ellos:
- [ 9.11.1 /A-1-1] DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (por ejemplo, PIN, patrón, contraseña) con más frecuencia que una vez cada 336 horas.
3.software
3.1. Compatibilidad de API administrada :
Ver revisión
Implementaciones de dispositivos:
- [C-0-8] NO DEBE admitir la instalación de aplicaciones dirigidas a un nivel API inferior a 23.
3.2.3.5. Intenciones de aplicación condicional :
Ver revisión
Si las implementaciones de dispositivos informan
android.hardware.nfc.uicc
oandroid.hardware.nfc.ese
,:- [C-19-1] DEBE implementar la API de intención NfcAdapter.ACTION_TRANSACTION_DETECTED (como “EVT_TRANSACTION” definida por la especificación técnica TS.26 de la Asociación GSM - Requisitos de dispositivos NFC) .
3.3.1. Interfaces binarias de aplicación :
Ver revisión
Implementaciones de dispositivos:
- [C-0-12] DEBE exportar símbolos de funciones para los símbolos de funciones principales
de Vulkan 1.0Vulkan 1.1 , así como las extensionesVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
yVK_KHR_get_physical_device_properties2
a través de la bibliotecalibvulkan.so
. Tenga en cuenta que si bien todos los símbolos DEBEN estar presentes, la sección 7.1.4.2 describe con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.
- [C-0-12] DEBE exportar símbolos de funciones para los símbolos de funciones principales
Ver revisión
Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:
- [C-1-5] DEBE generar paletas tonales de colores dinámicas utilizando los estilos de tema de color enumerados en la documentación
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(consulteandroid.theme.customization.theme_styles
), a saber,TONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
yMONOCHROMATIC
. .
- [C-1-5] DEBE generar paletas tonales de colores dinámicas utilizando los estilos de tema de color enumerados en la documentación
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:
- [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
,:- [C-1-10] DEBE garantizar que los datos de la captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se captura una captura de pantalla con una ventana
topActivity
que tiene el foco (aquel con el que el usuario interactuó en último lugar entre todas las actividades) y pertenece a un perfil de trabajo . aplicación . - [C-1-11] NO DEBE capturar ningún otro contenido de la pantalla (barra del sistema, notificaciones o cualquier contenido del perfil personal) excepto la ventana/ventanas de la aplicación del perfil de trabajo al guardar una captura de pantalla en el perfil de trabajo (para garantizar que los datos del perfil personal estén no guardado en el perfil de trabajo).
- [C-1-10] DEBE garantizar que los datos de la captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se captura una captura de pantalla con una ventana
3.9.5 Marco de resolución de políticas de dispositivos : nueva sección
Ver revisión
Si las implementaciones de dispositivos informan
android.software.device_admin
oandroid.software.managed_users
, entonces:- [C-1-1] DEBE resolver los conflictos de políticas de dispositivos como se documenta en la documentación de AOSP.
5. Compatibilidad multimedia
5.1.4. Codificación de imágenes :
Ver revisión
Las implementaciones de dispositivos DEBEN admitir la codificación de la siguiente imagen:
- [C-0-4] AVIF
- Los dispositivos deben admitir
BITRATE_MODE_CQ
y Baseline Profile.
- 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 codificación de imagen:
[C-0-7] AVIF (Perfil de referencia)
5.1.6. Detalles de códecs de imagen :
Ver revisión
Formato/Códec Detalles Tipos de archivos/formatos de contenedor admitidos JPEG Base+progresiva JPEG (.jpg) GIF GIF (.gif) PNG PNG (.png) BMP BMP (.bmp) WebP WebP (.webp) Crudo ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 ( .rw2), SRW (.srw) HEIF Imagen, Colección de imágenes, Secuencia de imágenes HEIF (.heif), HEIC (.heic) AVIF (Perfil de referencia) Imagen, colección de imágenes, secuencia de imágenes Perfil de referencia Contenedor HEIF (.avif) 5.1.8. Lista de códecs de vídeo :
Ver revisión
Formato/Códec Detalles Tipos de archivos/formatos de contenedor que se admitirán H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificar)
H.264 AVC Consulte las secciones 5.2 y 5.3 para obtener más detalles. - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, no buscable)
- Matroska (.mkv, solo decodificar)
H.265 HEVC Consulte la sección 5.3 para obtener más detalles. - MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificar)
MPEG-2 Perfil principal - MPEG2-TS (.ts, no buscable)
- MPEG-4 (.mp4, solo decodificar)
- Matroska (.mkv, solo decodificar)
MPEG-4SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificar)
VP8 Consulte las secciones 5.2 y 5.3 para obtener más detalles. - WebM (.webm)
- Matroska (.mkv)
VP9 Consulte la sección 5.3 para obtener más detalles. - WebM (.webm)
- Matroska (.mkv)
AV1 Consulte la sección 5.2 y la sección 5.3 para obtener más detalles. - MPEG-4 (.mp4)
- Matroska (.mkv, solo decodificar)
5.1.10. Caracterización del códec de medios :
Ver revisión
Si las implementaciones de dispositivos admiten códecs de vídeo:
- [C-2-1] Todos los códecs de video DEBEN publicar datos de velocidad de fotogramas alcanzables para los siguientes tamaños si el códec lo admite:
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD Resolución de video - 176 x 144 píxeles (H263, MPEG2, MPEG4)
- 352 x 288 píxeles (codificador MPEG4, H263, MPEG2)
- 320 x 180 píxeles (VP8, VP8)
- 320 x 240 píxeles (otro)
- 704 x 576 píxeles (H263)
- 640 x 360 píxeles (VP8, VP9)
- 640 x 480 píxeles (codificador MPEG4)
- 720 x 480 px (otro, AV1 )
- 1408 x 1152 píxeles (H263)
- 1280 x 720 px (otro, AV1 )
1920 x 1080 px (distinto de MPEG4, AV1 ) 3840 x 2160 píxeles (HEVC, VP9, AV1 ) Ver revisión
Si las implementaciones de dispositivos admiten cualquier codificador de vídeo y lo ponen a disposición de aplicaciones de terceros:- NO DEBE ser, en dos ventanas deslizantes, más del 15% sobre la tasa de bits entre intervalos intracuadro (I-frame).
- NO DEBE superar el 100 % de la tasa de bits en una ventana deslizante de 1 segundo.
Si las implementaciones del dispositivo admiten cualquier codificador de video y lo ponen a disposición de aplicaciones de terceros, y configuran el
MediaFormat.KEY_BITRATE_MODE
aBITRATE_MODE_VBR
para que el codificador funcione en modo de tasa de bits variable, luego, siempre que no afecte el piso mínimo de calidad , la tasa de bits codificada:-
[C-5-1]NO DEBE ser, en una ventana deslizante, más del 15% de la tasa de bits entre intervalos intracuadro (I-frame). -
[C-5-2]NO DEBE superar el 100% de la tasa de bits en una ventana deslizante de 1 segundo.
Si las implementaciones del dispositivo admiten cualquier codificador de video y lo ponen a disposición de aplicaciones de terceros y configuran
MediaFormat.KEY_BITRATE_MODE
enBITRATE_MODE_CBR
para que el codificador funcione en modo de tasa de bits constante, entonces la tasa de bits codificada:-
[C-6-1] DEBE[C-SR-2] SE RECOMIENDA ENCARECIDAMENTE NO exceder más del 15% de la tasa de bits objetivo durante una ventana deslizante de 1 segundo.
Ver revisión
Si las implementaciones de dispositivos admiten codificadores H.263 y lo ponen a disposición de aplicaciones de terceros, estos:
- [C-1-1] DEBE admitir la resolución QCIF (176 x 144) utilizando el nivel de perfil básico 45. La resolución SQCIF es opcional.
-
DEBE admitir velocidades de bits configurables dinámicamente para el codificador admitido.
Ver revisión
Si las implementaciones de dispositivos admiten el códec H.265,:
- [C-1-1] DEBE admitir perfil principal nivel 3 con una resolución de hasta 512 x 512 .
-
DEBE admitir los perfiles de codificación HD como se indica en la siguiente tabla. - Se RECOMIENDA ENCARECIDAMENTE que [C-SR-1] admita el perfil SD de 720 x 480 y los perfiles de codificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
5.2.6. AV1 : nueva sección
Ver revisión
Si las implementaciones de dispositivos admiten el códec AV1, entonces:
- [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.
[C-1-2] DEBE publicar datos de rendimiento, es decir, informar datos de rendimiento a través de las API
getSupportedFrameRatesFor()
ogetSupportedPerformancePoints()
para las resoluciones admitidas en la siguiente tabla.[C-1-3] DEBE aceptar metadatos HDR y enviarlos al flujo de bits
Si el codificador AV1 está acelerado por hardware, entonces:
- [C-2-1] DEBE admitir hasta el perfil de codificación HD1080p incluido de la siguiente tabla:
Dakota del Sur alta definición 720p alta definición 1080p HD Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps Bitrate de vídeo 5Mbps 8Mbps 16Mbps 50Mbps Ver revisión
Si las implementaciones de dispositivos admiten decodificadores H.263,:
- [C-1-1] DEBE admitir el nivel de perfil de referencia 30 (resoluciones CIF, QCIF y SQCIF a 30 fps 384 kbps) y el nivel 45 (resoluciones QCIF y SQCIF a 30 fps 128 kbps) .
Ver revisión
Si las implementaciones de dispositivos admiten el códec AV1,:- [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 aplicaciones de terceros,:
- [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.
Si las implementaciones de dispositivos brindan soporte para el códec AV1 con un decodificador acelerado por hardware, entonces:
- [C-2-1] DEBE poder decodificar al menos los perfiles de decodificación de video HD 720p de la siguiente tabla cuando la altura informada por el método
Display.getSupportedModes()
es igual o mayor que 720p. - [C-2-2] DEBE poder decodificar al menos los perfiles de decodificación de video HD 1080p de la siguiente tabla cuando la altura informada por el método
Display.getSupportedModes()
es igual o mayor que 1080p.
Dakota del Sur alta definición 720p alta definición 1080p HD Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps Bitrate de vídeo 5Mbps 8Mbps 16Mbps 50Mbps Si las implementaciones de dispositivos admiten el perfil HDR a través de las API de medios, entonces:
- [C-3-1] DEBE admitir la extracción y salida de metadatos HDR desde el flujo de bits y/o el contenedor.
- [C-3-2] DEBE mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).
5.4.2. Captura para reconocimiento de voz :
Ver revisión
Si las implementaciones de dispositivos declaran
android.hardware.microphone
,:- DEBE configurar la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz reproducida a un nivel de presión sonora (SPL) de 90 dB (medido
a una distancia de 30 cm allado del micrófono) produzca una respuesta ideal de 2500 RMS dentro de un rango de 1770 y 3530 para muestras de 16 bits (o -22,35 db ±3dB de escala completa para muestras de punto flotante/doble precisión) para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio de reconocimiento de voz.
- DEBE configurar la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz reproducida a un nivel de presión sonora (SPL) de 90 dB (medido
Ver revisión
Si las implementaciones de dispositivos declaran la función
android.hardware.audio.output
,:- [C-1-4] DEBE admitir efectos de audio con entrada y salida de punto flotante.
- [C-1-5] DEBE asegurarse de que los efectos de audio admitan múltiples canales hasta el recuento de canales del mezclador, también conocido como FCC_LIMIT.
Ver revisión
Si las implementaciones de dispositivos declaran
android.hardware.audio.output
, se RECOMIENDA ENCARECIDAMENTE que cumplan o superen los siguientes requisitos:- [C-SR-4] La marca de tiempo de salida devuelta por AudioTrack.getTimestamp y
AAudioStream_getTimestamp
tiene una precisión de +/- 1 ms.
- [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE que las latencias de ida y vuelta calculadas basadas en las marcas de tiempo de entrada y salida devueltas por
AAudioStream_getTimestamp
estén dentro de los 30 ms de la latencia de ida y vuelta medida paraAAUDIO_PERFORMANCE_MODE_NONE
yAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
para parlantes y auriculares con cable e inalámbricos.
- [C-SR-4] La marca de tiempo de salida devuelta por AudioTrack.getTimestamp y
7. Compatibilidad de hardware
Ver revisión
Android incluye funciones que ajustan automáticamente los activos de las aplicaciones y los diseños de la interfaz de usuario de manera apropiada para el dispositivo para garantizar que las aplicaciones de terceros se ejecuten bien en una
variedad de configuraciones de hardware .variedad de pantallas y configuraciones de hardware. Una pantalla compatible con Android es una pantalla que implementa todos los comportamientos y API descritos en Desarrolladores de Android: descripción general de compatibilidad de pantalla , esta sección (7.1) y sus subsecciones, así como cualquier comportamiento adicional específico del tipo de dispositivo documentado en la sección 2 de este CDD.En las pantallas compatibles con Android donde se pueden ejecutar todas las aplicaciones de terceros compatibles con Android, las implementaciones de dispositivos DEBEN implementar correctamente estas API y comportamientos, como se detalla en esta sección.Iniciar nuevos requisitos
Implementaciones de dispositivos:
- [C-0-1] DEBE, de forma predeterminada, representar aplicaciones de terceros solo en pantallas compatibles con Android.
Las unidades a las que hacen referencia los requisitos de esta sección se definen de la siguiente manera:
- Tamaño diagonal físico . La distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
- Densidad
de puntos por pulgada (ppp). El número de píxeles abarcados por un intervalo lineal horizontal o vertical de 1” , expresado como píxeles por pulgada (ppi o ppp) . Cuando se enumeran valoresde ppp, ppp y ppp , tanto los ppp horizontales como los verticales deben estar dentro del rango indicado . - relación de aspecto . La relación entre los píxeles de la dimensión más larga y la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480x854 píxeles sería 854/480 = 1,779, o aproximadamente “16:9”.
- Píxel independiente de la densidad (dp) .
Launidad de píxeles virtuales normalizada a unapantalla de 160 ppptiene una densidad de pantalla de 160. Para una densidad d y un número de píxeles p, el número de píxeles independientes de la densidad dp se calcula como:píxeles = dps * (densidad/160)dp = (160/d) * p .
7.1.1.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_NORMAL
e incluyen pantallas físicascompatibles con Androidcon esquinas redondeadas para representar estas pantallas , estas:- [C-1-1] DEBE garantizar que se cumpla al menos uno de los siguientes requisitos para cada una de estas pantallas :
- El radio de las esquinas redondeadas es menor o igual a 38 dp.
Cuando un cuadro de 15 dp por 15 dp está anclado en cada esquina de la pantalla lógica, al menos un píxel de cada cuadro es visible en la pantalla.
DEBE incluir la posibilidad de que el usuario cambie al modo de visualización con las esquinas rectangulares.
Iniciar nuevos requisitos
Si las implementaciones de dispositivos solo son capaces de configurar el teclado
NO_KEYS
y tienen la intención de informar soporte para la configuración del modoUI_MODE_TYPE_NORMAL
,:- [C-4-1] DEBE tener un tamaño de diseño, excluyendo cualquier recorte de pantalla, de al menos 596 dp x 384 dp o más.
Si las implementaciones de dispositivos incluyen una pantalla compatible con Android que es plegable o incluye una bisagra plegable entre varios paneles de pantalla y hace que dichas pantallas estén disponibles para representar aplicaciones de terceros, estas:
- [C-2-1] DEBE implementar la última versión estable disponible de la API de extensiones o la versión estable de la API sidecar para ser utilizada por la biblioteca Jetpack de Window Manager .
Si las implementaciones de dispositivos incluyen una pantalla compatible con Android que es plegable o incluye una bisagra plegable entre varios paneles de pantalla y si la bisagra o el pliegue cruza una ventana de aplicación de pantalla completa,:
- [C-3-1] DEBE informar a la aplicación la posición, los límites y el estado de la bisagra o plegado a través de extensiones o API de sidecar.
Si las implementaciones de dispositivos incluyen una o más áreas de visualización compatibles con Android que son plegables, o incluyen una bisagra plegable entre múltiples áreas de paneles de visualización compatibles con Android y ponen dichas áreas de visualización a disposición de las aplicaciones, estas:
- [C-4-1] DEBE implementar la versión correcta del nivel API de Extensiones de Window Manager como se describe en la próxima documentación.
7.1.1.2. Relación de aspecto de pantalla : eliminado
7.1.1.3. Densidad de la pantalla :
Ver revisión
Implementaciones de dispositivos:
- [C-0-1]
De forma predeterminada, las implementaciones de dispositivosDEBEN informarsolouna de las densidades del marco de Android que se enumeran enDisplayMetrics
a través de la APIDENSITY_DEVICE_STABLE
y este valor debe ser un valor estático para cada pantalla físicaNO DEBE cambiar en ningún momento;sin embargo,el dispositivo PUEDE informar unadensidad arbitrariadiferenteDisplayMetrics.density
según los cambios de configuración de pantalla realizados por el usuario (por ejemplo, tamaño de pantalla) establecidos después del arranque inicial.
- Las implementaciones de dispositivos DEBEN definir la densidad del marco de Android estándar que sea numéricamente más cercana a la densidad física de la pantalla, a menos que esa densidad lógica empuje el tamaño de pantalla informado por debajo del mínimo admitido. Si la densidad del marco de Android estándar que es numéricamente más cercana a la densidad física da como resultado un tamaño de pantalla más pequeño que el tamaño de pantalla compatible más pequeño admitido (320 dp de ancho), las implementaciones del dispositivo DEBEN informar la siguiente densidad de marco de Android estándar más baja.
Iniciar nuevos requisitos
- DEBE definir la densidad estándar del marco de Android que sea numéricamente más cercana a la densidad física de la pantalla, o un valor que se asigne a las mismas medidas de campo de visión angular equivalentes de un dispositivo portátil.
Si las implementaciones del dispositivo ofrecen
laposibilidad de cambiar el tamaño de visualización del dispositivo , estas :- [C-1-1]
El tamaño de la pantalla NO DEBE ampliarse. NODEBE escalar la pantalla a más de 1,5 vecesla densidad nativaDENSITY_DEVICE_STABLE
ni producir una dimensión de pantalla mínima efectiva inferior a 320 dp (equivalente al calificador de recursos sw320dp), lo que ocurra primero. - [C-1-2]
El tamaño de la pantalla NO DEBE escalarse.NO DEBE escalar la pantalla a menos 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
de Vulkan 1.0Vulkan 1.1 para cadaVkPhysicalDevice
enumerado.[C-1-5] NO DEBE enumerar capas proporcionadas por bibliotecas fuera del paquete de la aplicación, ni proporcionar otras formas de rastrear o interceptar la API de Vulkan, a menos que la aplicación tenga el atributo
android:debuggable
establecido comotrue
o los metadatoscom.android.graphics.injectLayers.enable
establecido entrue
.
- DEBE admitir
VkPhysicalDeviceProtectedMemoryFeatures
yVK_EXT_global_priority
.
- [C-1-13] DEBE satisfacer los requisitos especificados por el perfil Android Baseline 2021 .
[C-SR-5] Se RECOMIENDA ENCARECIDAMENTE admitir
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
yVK_EXT_global_priority
.[C-SR-6] Se RECOMIENDA ENCARECIDAMENTE utilizar
SkiaVk
con HWUI.
Si las implementaciones de dispositivos 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 hacer que la extensión
VK_KHR_external_fence_fd
esté disponible para aplicaciones de terceros y permitir que la aplicación exporte la carga útil de la cerca e importe la carga útil de la cerca desde 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, estos:
[C-7-1] DEBE, cuando un elemento biométrico está bloqueado (es decir, el elemento biométrico está deshabilitado hasta que el usuario lo desbloquea con autenticación primaria) o bloqueo por tiempo determinado (es decir, el elemento biométrico está deshabilitado temporalmente hasta que el usuario espere un intervalo de tiempo) debido a demasiados intentos fallidos, bloquee también todos los demás datos biométricos de una clase biométrica inferior. En el caso de un bloqueo con límite de tiempo, el tiempo de retraso para la verificación biométrica DEBE ser el tiempo de retraso máximo de todos los datos biométricos en el bloqueo con límite de tiempo.
[C-SR-12] Se RECOMIENDAN ENCARECIDAMENTE cuando un dispositivo biométrico está bloqueado (es decir, el dispositivo biométrico está deshabilitado hasta que el usuario lo desbloquea con autenticación primaria) o bloqueo por tiempo determinado (es decir, el dispositivo biométrico está temporalmente deshabilitado hasta que el usuario espere un tiempo). intervalo) debido a demasiados intentos fallidos, para bloquear también todos los demás datos biométricos de la misma clase biométrica. En el caso de un bloqueo con límite de tiempo, se RECOMIENDA ENCARECIDAMENTE que el tiempo de retraso para la verificación biométrica sea el tiempo de retraso máximo de todos los datos biométricos en el bloqueo con límite de tiempo.
[C-7-2] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) para restablecer el contador de bloqueo de un elemento biométrico que se está bloqueando. Se PUEDE permitir que los datos biométricos de clase 3 restablezcan el contador de bloqueo de un elemento biométrico bloqueado de la misma clase o de una clase inferior. NO SE DEBE permitir que los datos biométricos de Clase 2 o Clase 1 completen una operación de bloqueo de reinicio para ningún elemento biométrico.
Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 1 (anteriormente Conveniencia ), deben:
[C-1-12] DEBE tener una tasa de aceptación de falsificaciones e impostores que no supere el 40 % por especie de instrumento de ataque de presentación (PAI) , según lo medido por los protocolos de prueba biométrica de Android .
[C-SR-13] Se RECOMIENDA ENCARECIDAMENTE tener una tasa de aceptación de falsificaciones e impostores que no supere el 30 % por especie de instrumento de ataque de presentación (PAI) , según lo medido por los protocolos de prueba biométrica de Android .
[C-SR-14] Se RECOMIENDA ENCARECIDAMENTE divulgar la clase biométrica del sensor biométrico y los riesgos correspondientes de habilitarlo.
[C-SR-17] Se RECOMIENDA ENCARECIDAMENTE implementar las nuevas interfaces AIDL (como
IFace.aidl
eIFingerprint.aidl
).
Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 2 (anteriormente Débil ), deben:
- [C-SR-15] Se RECOMIENDA ENCARECIDAMENTE tener una tasa de aceptación de falsificaciones e impostores que no supere el 20 % por especie de instrumento de ataque de presentación (PAI) , según lo medido por los protocolos de prueba biométrica de Android .
- [C-2-3] DEBE realizar la comparación biométrica en un entorno de ejecución aislado fuera del espacio del kernel o del usuario de Android, como el entorno de ejecución confiable (TEE),
oen un chip con un canal seguro hacia el entorno de ejecución aislado o en un entorno protegido. Máquina virtual que cumple con los requisitos de la Sección 9.17 . - [C-2-4] DEBE tener todos los datos identificables cifrados y autenticados criptográficamente de manera que no puedan adquirirse, leerse o modificarse fuera del entorno de ejecución aislado o un chip con un canal seguro hacia el entorno de ejecución aislado como se documenta en las pautas de implementación . en el sitio del Proyecto de código abierto de Android o en una máquina virtual protegida controlada por un hipervisor que cumpla con los requisitos de la Sección 9.17 .
- [C-2-5] Para datos biométricos basados en cámaras, mientras se realiza la autenticación o inscripción biométrica:
- DEBE operar la cámara en un modo que impida que los fotogramas de la cámara se lean o alteren fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado o una Máquina Virtual Protegida controlada por un hipervisor que cumpla con los requisitos de la Sección 9.17 .
- Para las soluciones RGB de una sola cámara, los marcos de la cámara PUEDEN ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para el registro, pero aún así NO DEBEN ser modificables.
- [C-2-7] NO DEBE permitir el acceso no cifrado a datos biométricos identificables o cualquier dato derivado de ellos (como incrustaciones) al Procesador de Aplicaciones fuera del contexto del TEE o la Máquina Virtual Protegida controlada por un hipervisor que cumpla con los requisitos de la Sección 9.17 . La actualización de dispositivos lanzados con la versión 9 de Android o anterior no está exenta de C-2-7.
Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 3 (anteriormente Strong ), deben:
- [C-SR-16] Se RECOMIENDA ENCARECIDAMENTE tener una tasa de aceptación de falsificaciones e impostores que no supere el 7 % por especie de instrumento de ataque de presentación (PAI) , según lo medido por los protocolos de prueba biométrica de Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Ver revisión
Si las implementaciones de dispositivos 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 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 ) definidos en la implementación de AOSP.
-
CONFIG_ID_1
: alcanceSTATIC STS DS-TWR
de unidifusión definido por FiRa, modo diferido, intervalo de alcance de 240 ms. -
CONFIG_ID_2
: alcanceSTATIC STS DS-TWR
de uno a muchos definido por FiRa, modo diferido, intervalo de alcance 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 del á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 clave de control individual P-STS está habilitado.
-
- [C-1-4] DEBE proporcionar una opción al usuario que le permita alternar el estado de encendido/apagado de la radio UWB.
- [C-1-5] DEBE exigir que las aplicaciones que usan radio UWB tengan el permiso
UWB_RANGING
(bajo el grupo de permisosNEARBY_DEVICES
).
Pasar las pruebas de conformidad y certificación pertinentes definidas por organizaciones estándar, incluidas FIRA , CCC y CSA , ayuda a garantizar que 802.1.15.4 funcione correctamente.
- [C-1-2] DEBE informar el indicador de función de hardware
Ver revisión
"Telefonía" tal como la utilizan las API de Android y este documento se refiere específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS , o el establecimiento de datos móviles a través de una red móvil (por ejemplo, GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo compatible con “Telefonía” puede optar por ofrecer algunos o todos los servicios de llamadas, mensajería y datos según corresponda al producto.
a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes, a los efectos de Android se consideran independientes de cualquier conectividad de datos que pueda implementarse utilizando la misma red. En otras palabras, la funcionalidad de “telefonía” y las API de Android se refieren específicamente a llamadas de voz y SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar/recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si utilizan una red celular para la conectividad de datos.Ver revisión
Si las implementaciones de dispositivos 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, incluso cuando la pantalla no está en un estado activo, a menos que se caiga o Filtrar estos paquetes es necesario para mantenerse dentro de los rangos de consumo de energía requeridos por los requisitos reglamentarios aplicables al mercado objetivo.
Para implementaciones de dispositivos Android Television, incluso en estados de energía en espera.
- [C-1-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, incluso cuando la pantalla no está en un estado activo, a menos que se caiga o Filtrar 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 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 colocado a 1 m de distancia y se transmite en
ADVERTISE_TX_POWER_HIGH
, donde los dispositivos están orientados. de modo que estén en "planos paralelos" con pantallas orientadas en la misma dirección.
- [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
.
Si las implementaciones de dispositivos admiten la versión 5.0 de Bluetooth, entonces:
- [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE brindar soporte para:
- LE 2M FÍSICO
- Códec LE PHY
- Extensión de publicidad LE
- Publicidad periódica
- Al menos 10 conjuntos de anuncios.
- Al menos 8 conexiones LE simultáneas. Cada conexión puede estar en cualquiera de los roles de topología de conexión.
- Privacidad de la capa de enlace LE
- Un tamaño de "lista de resolución" de al menos 8 entradas
- [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
Ver revisión
- [C-1-7] DEBE garantizar que la mediana de las mediciones de distancia a 1 m del dispositivo de referencia esté dentro de [0,75 m, 1,25 m], donde la distancia real del terreno se mide desde el borde superior del DUT.
sostenido boca arriba e inclinado 45 grados.
- [C-1-7] DEBE garantizar que la mediana de las mediciones de distancia a 1 m del dispositivo de referencia esté dentro de [0,75 m, 1,25 m], donde la distancia real del terreno se mide desde el borde superior del DUT.
Ver revisión
Una cámara trasera es una cámara ubicada en el lado del dispositivo opuesto a la pantalla; es decir, captura escenas en el lado opuesto del dispositivo, como una cámara tradicional.
Una cámara trasera es una cámara orientada al mundo que captura escenas en el lado opuesto del dispositivo, como una cámara tradicional; en dispositivos portátiles, 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 que normalmente se utiliza para tomar imágenes del usuario, como por ejemplo para videoconferencias y aplicaciones similares.
Una cámara frontal es una cámara orientada al usuario que normalmente se utiliza para obtener imágenes del usuario, como por ejemplo para videoconferencias y aplicaciones similares; en dispositivos portátiles, 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 desconectar físicamente de la implementación del dispositivo en cualquier momento y puede mirar en 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] Para dispositivos con varias cámaras RGB muy cerca y orientadas en la misma dirección, se RECOMIENDA ENCARECIDAMENTE admitir un dispositivo de cámara lógica que enumere la capacidad
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, que consta de todas las cámaras RGB orientadas en esa dirección como subdispositivos físicos.
- [C-SR-1] Para dispositivos con varias cámaras RGB muy cerca y orientadas en la misma dirección, se RECOMIENDA ENCARECIDAMENTE admitir un dispositivo de cámara lógica que enumere la capacidad
7.5.5. Orientación de la cámara :
Ver revisión
Los dispositivos que cumplan con todos los criterios siguientes están exentos del requisito anterior:
- Implementaciones de dispositivos que el usuario no puede girar, como dispositivos automotrices.
Ver revisión
Los dispositivos destinados a ser portátiles o usados pueden incluir un actuador háptico de uso general, disponible para aplicaciones con fines que incluyen llamar la atención a través de tonos de llamada, alarmas, notificaciones, así como también respuesta táctil general.
Si las implementaciones de dispositivos NO incluyen un actuador háptico de uso general, estos:
- [7.10/C] DEBE devolver false para
Vibrator.hasVibrator()
.
Si las implementaciones de dispositivos SÍ incluyen al menos uno de estos actuadores hápticos de uso general, estos:
- [C-1-1] DEBE devolver verdadero para
Vibrator.hasVibrator()
. - NO DEBE utilizar un actuador háptico (vibrador) de masa giratoria excéntrica (ERM).
- 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
yGESTURE_END
). - DEBE implementar todas las constantes públicas para hápticos claros en
android.os.VibrationEffect
, es decir (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
yEFFECT_DOUBLE_CLICK
) y todas las constantes públicasPRIMITIVE_*
viables para hápticos ricos enandroid.os.VibrationEffect.Composition
, a saber (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Algunas de estas primitivas, comoLOW_TICK
ySPIN
, solo pueden ser factibles si el vibrador puede soportar frecuencias relativamente bajas. - DEBE seguir las instrucciones para asignar constantes públicas en
android.view.HapticFeedbackConstants
a las constantes recomendadasandroid.os.VibrationEffect
, con las relaciones de amplitud correspondientes. - DEBE utilizar estas asignaciones de constantes hápticas vinculadas.
- DEBE seguir la evaluación de calidad para las API
createOneShot()
ycreateWaveform()
. - DEBE verificar que el resultado de la API pública
android.os.Vibrator.hasAmplitudeControl()
refleje correctamente las capacidades de su vibrador. - Debe verificar las capacidades para la escalabilidad de amplitud ejecutando
android.os.Vibrator.hasAmplitudeControl()
.
Si las implementaciones del dispositivo siguen la asignación de constantes hápticas, ellos:
- Debe verificar el estado de implementación ejecutando
android.os.Vibrator.areAllEffectsSupported()
yandroid.os.Vibrator.arePrimitivesSupported()
API. - Debe realizar una evaluación de calidad para constantes hápticas.
- Debe verificar y actualizar si es necesario la configuración de retroceso para primitivas no compatibles como se describe en la guía de implementación para constantes.
- Debe proporcionar soporte respaldo para mitigar el riesgo de falla como se describe aquí .
Consulte la Sección 2.2.1 para ver los requisitos específicos del dispositivo.
- [7.10/C] DEBE devolver false para
9. Compatibilidad del modelo de seguridad
Ver Revisión
Implementaciones de dispositivos:
- [C-0-4] debe tener una y solo una implementación de ambas interfaces de usuario.
Si las implementaciones de dispositivos preinstalan cualquier paquete que contenga cualquiera de la inteligencia de la interfaz de usuario del sistema , inteligencia de audio ambiental del sistema , inteligencia de audio del sistema , inteligencia de notificación del sistema , inteligencia de texto del sistema o roles de inteligencia visual del sistema , los paquetes:
- [C-4-1] debe cumplir con todos los requisitos descritos para las implementaciones de dispositivos en las secciones
"9.8.6 Captura de contenido""9.8.6 Datos de nivel de sistema operativo y ambiental y 9.8.15 implementaciones de API de sandboxed".
- [C-4-2] no debe tener Android.Permission.Internet permiso. Esto es más estricto que el muy recomendado en la lista en la Sección 9.8.6.
- [C-4-3] no debe vincularse a otras aplicaciones, excepto las siguientes aplicaciones del sistema: Bluetooth, Contactos, Medios, Telefonía, SystemUI y Componentes que proporcionan API de Internet. Esto es más estricto que el muy recomendado en la lista en la Sección 9.8.6.
Si las implementaciones del dispositivo incluyen una aplicación predeterminada para admitir
VoiceInteractionService
ellos:- [C-5-1] no debe otorgar
ACCESS_FINE_LOCATION
como el valor predeterminado para esa aplicación.
9.5. Soporte de usuarios múltiples :
Ver Revisión
Si las implementaciones del dispositivo crean el perfil de usuario adicional discutido anteriormente, entonces ellos:
- [C-4-5] debe distinguir visualmente los iconos de la aplicación de instancia dual cuando los iconos se presentan a los usuarios.
- [C-4-6] debe proporcionar una afordancia de usuario para eliminar los datos completos de perfil de clones.
- [C-4-7] debe desinstalar todas las aplicaciones de clones, eliminar los directorios de datos de aplicaciones privadas y su contenido, y eliminar datos de perfil de clones, cuando el usuario elija eliminar los datos completos del perfil de clones.
- Debe solicitar al usuario que elimine los datos completos de perfil de clon cuando se elimine la última aplicación Clone.
- [C-4-8] debe informar al usuario que los datos de la aplicación se eliminarán cuando la aplicación clon no esté instalada, o proporcione una opción a los usuarios para mantener los datos de la aplicación cuando la aplicación no esté instalada desde el dispositivo.
- [C-4-9] debe eliminar los directorios de datos de la aplicación privada y su contenido, cuando el usuario elige eliminar los datos durante la desinstalación.
[C-4-1] debe permitir que los intentos a continuación se originen del perfil adicional sean manejados por aplicaciones del usuario primario en el dispositivo:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] debe heredar todas las restricciones de usuario de la política del dispositivo y las restricciones no usadas seleccionadas (lista a continuación) aplicadas en el usuario principal del dispositivo a este perfil de usuario adicional.
[C-4-3] Solo debe permitir la escritura de contactos de este perfil adicional a través de los siguientes intentos:
[C-4-4] no debe tener sincronizaciones de contacto que se ejecuten para aplicaciones que se ejecutan en este perfil de usuario adicional.
- [C-4-14] debe tener un permiso separado y una gestión de almacenamiento para las aplicaciones que se ejecutan en este perfil adicional
- [C-4-5] solo debe permitir aplicaciones en el perfil adicional que tienen una actividad de lanzador para acceder a contactos a los que ya están accesibles para el perfil de usuario principal.
9.7. Características de seguridad :
Ver Revisión
Una tecnología de seguridad de la memoria es una tecnología que mitiga al menos las siguientes clases de errores con una probabilidad alta (> 90%) en aplicaciones que usan la opción Manifiester
android:memtagMode
:- desbordamiento del búfer de montón
- Usar después de gratis
- Doble libre
- Wild Free (libre de un puntero no malloc)
Implementaciones de dispositivos:
- [C-SR-15] se recomienda encarecidamente establecer
ro.arm64.memtag.bootctl_supported
.
Si las implementaciones del dispositivo establecen la propiedad del sistema
ro.arm64.memtag.bootctl_supported
a verdadero, ellos:[C-3-1] debe permitir que la propiedad del sistema
arm64.memtag.bootctl
acepte una lista separada por comas de los siguientes valores, con el efecto deseado aplicado en el siguiente reinicio posterior:-
memtag
: una tecnología de seguridad de memoria como se definió anteriormente está habilitado -
memtag-once
: una tecnología de seguridad de memoria como se define anteriormente está habilitada transitoriamente, y se deshabilita automáticamente, el siguiente reinicio -
memtag-off
: una tecnología de seguridad de memoria como se definió anteriormente está deshabilitado
-
[C-3-2] debe permitir que el usuario de Shell establezca
arm64.memtag.bootctl
.[C-3-3] debe permitir que cualquier proceso lea
arm64.memtag.bootctl
.[C-3-4] debe establecer
arm64.memtag.bootctl
al estado solicitado actualmente al arranque, también debe actualizar la propiedad, si la implementación del dispositivo permite modificar el estado sin cambiar la propiedad del sistema.[C-SR-16] se recomienda encarecidamente para mostrar una configuración de desarrollador que establece MEMTAG-ONCE y reinicia el dispositivo. Con un gestor de arranque compatible, el proyecto de código abierto de Android cumple con los requisitos anteriores a través del protocolo de cargador de arranque MTE .
- [C-SR-17] se recomienda encarecidamente que muestre una configuración en el menú Configuración de seguridad que permite al usuario habilitar
memtag
.
Ver Revisión
Implementaciones de dispositivos:
- [C-0-2] debe mostrar una advertencia del usuario y obtener un consentimiento explícito del usuario que permita que cualquier información confidencial que se muestre en la pantalla del usuario se captura
habilitado que incluya exactamente el mismo mensaje que AOSPcada vezque cada vez que una sesión capture la sesión para capturar laLa fundición de pantalla o la grabación de pantallasehabilitana través deMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
o API propiadas.No debe proporcionar a los usuarios la posibilidad de deshabilitar la visualización futura del consentimiento del usuario.
[C-SR-1] se recomienda encarecidamente mostrar una advertencia del usuario que es exactamente el mismo mensaje implementado en AOSP, pero puede modificarse siempre que el mensaje advierte claramente al usuario que se captura cualquier información confidencial en la pantalla del usuario.
[C-0-4] no debe proporcionar a los usuarios la posibilidad de deshabilitar las indicaciones futuras del consentimiento del usuario para capturar la pantalla, a menos que la sesión sea iniciada por una aplicación del sistema que el usuario ha permitido
associate()
conandroid.app.role.COMPANION_DEVICE_APP_STREAMING
o el perfil del dispositivoandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
Device.
- [C-0-2] debe mostrar una advertencia del usuario y obtener un consentimiento explícito del usuario que permita que cualquier información confidencial que se muestre en la pantalla del usuario se captura
9.8.6. Datos de nivel del sistema operativo y ambiental : esta sección pasó a llamarse de captura de contenido y búsqueda de aplicaciones a datos de nivel del sistema operativo y ambiental .
Ver Revisión
Android, a través de la API del sistema
,, admite un mecanismo para las implementaciones de dispositivos para capturar las siguientesContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, o por otros medios patentadosinteracciones de datos entre las aplicaciones y losdatos confidenciales del usuario:- Cualquier pantalla u otros datos enviados a través del
AugmentedAutofillService
al sistema. - Cualquier pantalla u otros datos accesibles a través de la API
Content Capture
. - Cualquier pantalla u otros datos accesibles a través de
FieldClassificationService
API - Cualquier datos de aplicación pasados al sistema a través de la API
AppSearchManager
y accesible a través deAppSearchGlobalManager.query
.
- Cualquier otro evento que proporcione una aplicación al sistema a través de la API
Content Capture
o la APIAppSearchManager
una API de Android y patentado similares.
- Los datos de audio obtenidos como resultado del uso de
SpeechRecognizer#onDeviceSpeechRecognizer()
por la implementación del reconocimiento de voz. - Datos de audio obtenidos en segundo plano (continuamente) a través
AudioRecord
,SoundTrigger
u otras API de audio, y no dio como resultado un indicador visible del usuario - Datos de la cámara obtenidos en el fondo (continuamente) a través del camarógrafo u otras API de la cámara, y no dan como resultado un indicador visible del usuario
Si las implementaciones de dispositivos capturan alguno de los datos anteriores, ellos:
[C-1-3] solo debe enviar todos estos datos
y la sesiónde la sesión del dispositivo utilizando un mecanismo de preservación de la privacidad , excepto con el consentimiento explícito del usuario cada vez que se comparten los datos . El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o los resultados derivados a los usuarios individuales", para evitar que los datos por usuario sean introspectables (por ejemplo, implementados utilizando una tecnología de privacidad diferencial comoRAPPOR
).[C-1-5] no debe compartir dichos datos con otros componentes del sistema operativo que no sigan los requisitos descritos en la sección actual (9.8.6
Contenido Capturelos datos del nivel del sistema operativo y ambiental ), excepto con el consentimiento explícito del usuario cada vez que es compartido. A menos que dicha funcionalidad se construya como una API SDK de Android (AmbientContext
,HotwordDetectionService
).[C-1-6] debe proporcionar el servicio del usuario para borrar dichos datos que la implementación
o el medio de propiedad se recopileContentCaptureService
sicuando los datos se almacenan en cualquier forma en el dispositivo. Si el usuario elige borrar los datos, debe eliminar todos los datos históricos recopilados.
- [C-SR-3] se recomienda que se implementen con API SDK de Android o un repositorio de código abierto de propiedad OEM similar; y / o realizarse en una implementación de sandboxed (ver 9.8.15 implementaciones de API de sandboxed).
Android, a través de
SpeechRecognizer#onDeviceSpeechRecognizer()
proporciona la capacidad de realizar el reconocimiento de voz en el dispositivo, sin involucrar la red. Cualquier implementación de SpeechRecognizer en el dispositivo debe seguir las políticas descritas en esta sección.- Cualquier pantalla u otros datos enviados a través del
9.8.10. Informe de errores de conectividad :
Ver Revisión
Si las implementaciones de dispositivos declaran el indicador de funciones
android.hardware.telephony
, ellos:- [C-1-4] Los informes generados con
BUGREPORT_MODE_TELEPHONY
deben contener al menos la siguiente información:-
SubscriptionManagerService
vertedero
-
- [C-1-4] Los informes generados con
9.8.14. Gerente de credenciales : eliminado
9.8.15. Implementaciones de API de sandboxed : nueva sección
Ver Revisión
Android, a través de un conjunto de API delegadas, proporciona un mecanismo para procesar datos seguros de nivel de sistema operativo y ambiental. Dicho procesamiento puede delegarse a un APK preinstalado con acceso privilegiado y capacidades de comunicación reducidas, conocidas como implementación de API de sandboxed.
Cualquier implementación de API de sandboxed:
- [C-0-1] no debe solicitar el permiso de Internet.
- [C-0-2] solo debe acceder a Internet a través de API estructuradas respaldadas por implementaciones de código abierto disponibles públicamente utilizando mecanismos de preservación de la privacidad, o indirectamente a través de API SDK de Android. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o los resultados derivados a los usuarios individuales", para evitar que los datos por usuario sean introspectables (por ejemplo, implementados utilizando una tecnología de privacidad diferencial como Rappor ).
- [C-0-3] debe mantener los servicios separados de otros componentes del sistema (por ejemplo, no vincular el servicio o compartir ID de proceso), excepto los siguientes:
- Telefonía, contactos, interfaz de usuario del sistema y medios
- [C-0-4] no debe permitir a los usuarios reemplazar los servicios con una aplicación o servicio instalable por el usuario
- [C-0-5] solo debe permitir que los servicios preinstalados capturen dichos datos. A menos que la capacidad de reemplazo esté integrada en AOSP (por ejemplo, para aplicaciones de asistente digital).
- [C-0-6] no debe permitir que ninguna aplicación que no sea el mecanismo de servicios preinstalado pueda capturar dichos datos. A menos que dicha capacidad de captura se implementa con una API SDK de Android.
- [C-0-7] debe proporcionar el objetivo del usuario para deshabilitar los servicios.
- [C-0-8] no debe omitir el acceso del usuario para administrar los permisos de Android que mantienen los servicios y seguir el modelo de permisos de Android como se describe en la Sección 9.1. Permiso .
9.8.16. Datos continuos de audio y cámara : nueva sección
Ver Revisión
Además de los requisitos que se describen en 9.8.2 grabación, 9.8.6 datos de nivel de sistema operativo y ambiental, y 9.8.15 implementaciones de API de sandboxed, implementaciones que utilizan datos de audio obtenidos en segundo plano (continuamente) a través de Audiorecord, SoundRigger u otras API de audio O datos de la cámara obtenidos en el fondo (continuamente) a través del camarógrafo u otras API de la cámara:
- [C-0-1] debe hacer cumplir un indicador correspondiente (cámara y/o micrófono según la Sección 9.8.2 Grabación), a menos:
- Este acceso se realiza en una implementación de Sandbox (ver 9.8.15 implementación de API de sandbox), a través de un paquete que tiene uno o más de los siguientes roles: inteligencia de la interfaz de usuario del sistema , inteligencia ambiental del sistema , inteligencia de audio del sistema , inteligencia de notificación del sistema , inteligencia de texto del sistema o inteligencia visual del sistema .
- El acceso se realiza a través de una caja de arena, implementada y aplicada a través de mecanismos en AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - La aplicación de asistente digital realiza el acceso a audio con fines de asistencia, suministrando
SOURCE_HOTWORD
como fuente de audio. - El sistema es realizado por el sistema e implementado con código de código abierto.
- [C-SR-1] se recomienda encarecidamente que requiera el consentimiento del usuario para cada funcionalidad que utilice dichos datos y se deshabilite de forma predeterminada.
- [C-SR-2] se recomienda aplicar el mismo tratamiento (es decir, siga las restricciones descritas en 9.8.2 grabación, 9.8.6 datos de nivel de sistema operativo y ambiental, 9.8.15 implementaciones de API de arena y 9.8.16 audio continuo y continuo Datos de la cámara) a los datos de la cámara que provienen de un dispositivo portátil remoto.
Si los datos de la cámara se suministran desde un dispositivo portátil remoto y se accede en una forma no cifrada fuera del sistema operativo Android, implementación de sandboxed o una funcionalidad de sandboxed creada por
WearableSensingManager
, entonces ellos:- [C-1-1] debe indicar al dispositivo portátil remoto para mostrar un indicador adicional allí.
Si los dispositivos proporcionan capacidad para interactuar con una aplicación de asistente digital sin la palabra clave asignada (ya sea manejando consultas genéricas de usuario o analizar la presencia del usuario a través de la cámara):
- [C-2-1] debe garantizar que dicha implementación sea proporcionada por un paquete que contenga el rol
android.app.role.ASSISTANT
. - [C-2-2] debe garantizar que dicha implementación utilice
HotwordDetectionService
y/oVisualQueryDetectionService
API de Android.
- [C-0-1] debe hacer cumplir un indicador correspondiente (cámara y/o micrófono según la Sección 9.8.2 Grabación), a menos:
9.8.17. Telemetría : nueva sección
Ver Revisión
Android almacena el sistema y los registros de aplicaciones utilizando API STATSLOG. Estos registros se administran a través de las API StatsManager que pueden ser utilizadas por aplicaciones de sistemas privilegiadas.
StatsManager también proporciona una forma de recopilar datos clasificados como sensibles a la privacidad de los dispositivos con un mecanismo de preservación de privacidad. En particular,
StatsManager::query
API proporciona la capacidad de consultar categorías de métricas restringidas definidas en STATSLOG .Cualquier consulta de implementación y recopilación de métricas restringidas de Statsmanager:
- [C-0-1] debe ser la única aplicación/implementación en el dispositivo y mantener el permiso
READ_RESTRICTED_STATS
. - [C-0-2] solo debe enviar datos de telemetría y el registro del dispositivo utilizando un mecanismo de preservación de la privacidad. El mecanismo de preservación de la privacidad se define como "aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o los resultados derivados a los usuarios individuales", para evitar que los datos por usuario sean introspectables (por ejemplo, implementados utilizando una tecnología de privacidad diferencial como Rappor ).
- [C-0-3] no debe asociar dichos datos con ninguna identidad del usuario (como la cuenta ) en el dispositivo.
- [C-0-4] no debe compartir dichos datos con otros componentes del sistema operativo que no sigan los requisitos descritos en la sección actual (9.8.17 Telemetría de preservación de la privacidad).
- [C-0-5] debe proporcionar una posibilidad del usuario para habilitar/deshabilitar la recopilación, uso y intercambio de telemetría de preservación de la privacidad.
- [C-0-6] debe proporcionar el servicio del usuario para borrar dichos datos que la implementación recopila si los datos se almacenan en cualquier formulario en el dispositivo. Si el usuario eligió borrar los datos, debe eliminar todos los datos actualmente almacenados en el dispositivo.
- [C-0-7] debe revelar la implementación subyacente de protocolo de preservación de la privacidad en un repositorio de código abierto.
- [C-0-8] debe hacer cumplir las políticas de salida de datos en esta sección a la recopilación de datos de compuerta en categorías de métricas restringidas definidas en STATSLOG .
- [C-0-1] debe ser la única aplicación/implementación en el dispositivo y mantener el permiso
9.10. Integridad del dispositivo :
Ver Revisión
Implementaciones de dispositivosSi las implementaciones de dispositivos tienen la capacidad de verificar el contenido del archivo por página, entonces ellos :
[
C-0-3C-2-1 ] Admite verificar criptográficamente el contenido del archivocontra una clave confiablesin leer todo el archivo.[
C-0-4C-2-2 ] no debe permitir que las solicitudes de lectura en un archivo protegido tengan éxito cuando el contenido de lecturano verifique contra una clave confiableno se verifica por [C-2-1] anterior .
- [C-2-4] debe devolver la suma de verificación de archivos en o (1) para archivos habilitados.
Ver Revisión
El sistema Android Keystore permite a los desarrolladores de aplicaciones almacenar claves criptográficas en un contenedor y usarlas en operaciones criptográficas a través de la API del llavero o la API de la tienda de claves . Implementaciones de dispositivos:
- [C-0-3] debe limitar el número de intentos de autenticación primarios fallidos.
- [C-SR-2] se recomienda encarecidamente implementar un límite superior de 20 intentos de autenticación primarios fallidos y si los usuarios consienten y optan en la función, realice un "reinicio de datos de fábrica" después de exceder el límite de los intentos de autenticación primaria fallida.
Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo si se basan en un secreto conocido y usan un nuevo método de autenticación para ser tratado como una forma segura de bloquear la pantalla, luego:
- [C-SR-3] Se recomienda encarecidamente un PIN para tener al menos 6 dígitos, o de manera equivalente una entropía de 20 bits.
- [C-2-1] Un pin de una longitud inferior a 6 dígitos no debe permitir la entrada automática sin interacción del usuario para evitar revelar la longitud del pasador.
9.11.1. Pantalla de bloqueo seguro, autenticación y dispositivos virtuales :
Ver Revisión
Implementaciones de dispositivos:
- [C-0-1] debe limitar el número de intentos de autenticación primarios fallidos.
- [C-SR-5] se recomiendan fuertemente implementar un límite superior de 20 intentos de autenticación primarios fallidos y si los usuarios consienten y optan en la función, realice un "reinicio de datos de fábrica" después de exceder el límite de los intentos de autenticación primaria fallida.
Si las implementaciones del dispositivo establecen un PIN numérico como el método de autenticación primaria recomendado, entonces:
- [C-SR-6] Se recomienda encarecidamente un PIN para tener al menos 6 dígitos, o de manera equivalente una entropía de 20 bits.
- [C-SR-7] Se recomienda encarecidamente un PIN de una longitud de menos de 6 dígitos para no permitir la entrada automática sin la interacción del usuario para evitar revelar la longitud del pasador.
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:[C-7-8] El usuario debe ser desafiado por uno de los métodos de autenticación primaria (p. Ej. inquietud.Si las implementaciones de dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y admitan eventos de entrada asociados, como VirtualDeviceManager y las pantallas no están marcadas con virtual_display_flag_secure, ellos:
[C-13-10] debe deshabilitar la instalación de aplicaciones iniciadas a partir de dispositivos virtuales.9.17. Marco de virtualización de Android :
Ver Revisión
Si el dispositivo implementa el soporte para la virtualización de Android API (
android.system.virtualmachine.*
), El host de Android::- [C-1-1] debe admitir todas las API definidas por el paquete
android.system.virtualmachine
. - [C-1-2] no debe modificar el modelo de Android Selinux y permiso para la administración de máquinas virtuales protegidas (PVM) .
- [C-1-3] no debe modificar, omitir o reemplazar las reglas NeverLlow presentes dentro del sistema/sepolicy proporcionada en el Proyecto de código abierto de Android (AOSP) aguas arriba y la política debe compilar con todas las reglas Neverlow presentes.
- [C-1-4] Solo debe permitir que el código firmado de la plataforma y las aplicaciones privilegiadas
no deben permitir que el código no confiable (por ejemplo, las aplicaciones 3P)cree y ejecute una máquina PVMvirtual protegida. Nota: Esto podría cambiar en futuras versiones de Android.
- [C-1-5] no debe permitir un
Máquina virtual protegidaPVM para ejecutar código que no es parte de la imagen de fábrica o sus actualizaciones.No se debe permitir cualquier cosa que no esté cubierta por el arranque verificado de Android (por ejemplo, los archivos descargados de Internet o la respuesta lateral) no se debe ejecutar en una máquina virtual protegida.
- [C-1-5] solo debe permitir que un PVM no deBuggable ejecute código desde la imagen de fábrica o sus actualizaciones de plataforma que también incluye cualquier actualización de aplicaciones privilegiadas.
Si el dispositivo implementa el soporte para la virtualización Android APIS (
android.system.virtualmachine.*
), Entonces cualquier instancia de PVMde máquina virtual protegida:- [C-2-1] debe poder ejecutar todos los sistemas operativos disponibles en el ápice de virtualización en una
máquina virtual protegidaPVM . - [C-2-2] no debe permitir que una
máquina virtual protegidaPVM ejecute un sistema operativo que no está firmado por el implementador del dispositivo o el proveedor del sistema operativo. - [C-2-3] no debe permitir que una
máquina virtual protegidaPVM ejecute datos como código (por ejemplo, Selinux Never Allow ExecMem).
- [C-2-4] no debe modificar, omitir o reemplazar las reglas NeverLlow presentes dentro del sistema/Sepolicy/MicroDroid proporcionado en el proyecto de código abierto de Android (AOSP) ascendente.
- [C-2-5] debe implementar mecanismos de defensa de defensa PVM
de máquina virtual protegida(por ejemplo, Selinux para PVMS) incluso para sistemas operativos no microdoides. - [C-2-6] debe asegurarse de que el PVM falla
el firmware se niegaa arrancar sino puede verificar las imágenes inicialesque la VM ejecutará no se puede verificar. La verificación debe realizarse dentro de la VM. - [C-2-7] debe asegurarse de que el PVM falla
el firmware se niegaa arrancar si la integridad de la instancia.img se ve comprometida.
Si el dispositivo implementa el soporte para la virtualización Android APIS (
android.system.virtualmachine.*
), Entonces el hipervisor:- [C-3-1] debe garantizar que las páginas de memoria propiedad exclusivamente de una VM (ya sea PVM o VM host) solo sean accesibles a la máquina virtual en sí o al hipervisor, no por otras máquinas virtuales, ya sea protegidas o no protegidas.
No debe permitir que ningún PVM tenga acceso a una página que pertenezca a otra entidad (es decir, otro PVM o Hypervisor), a menos que el propietario de la página lo comparta explícitamente. Esto incluye el host VM. Esto se aplica a los accesos de CPU y DMA. - [C-3-2] debe borrar una página después de que sea usado por un PVM y antes de que se devuelva al host (por ejemplo, el PVM se destruye).
- [C-
3-3SR-1 ] se recomienda encarecidamente para garantizarque debe asegurarsede que el firmware de PVM esté cargado y ejecutado antes de cualquier código en un PVM. - [C-3-4] debe asegurarse de que cada VM deriva un secreto por VM que
{cadena de certificado de arranque (BCC) e identificador de dispositivo compuesto (CDIS) proporcionado a una instancia de PVMsolo pueden derivarse mediante esa instancia de VM particular y cambia sobre Restablecimiento de fábrica y OTA.
Si el dispositivo implementa el soporte para las API del marco de virtualización de Android, entonces en todas las áreas:
- [C-4-1] no debe proporcionar funcionalidad a un PVM que permita pasar por alto el modelo de seguridad de Android.
Si el dispositivo implementa soporte para las API del marco de virtualización de Android, entonces:
- [C-5-1] debe ser capaz de admitir la compilación aislada , pero puede deshabilitar la función de compilación aislada en el envío del dispositivo
de una actualización de tiempo de ejecución de ART.
Si el dispositivo implementa el soporte para las API del marco de virtualización de Android, entonces para la administración de claves:
- [C-6-1] debe rootear la cadena de dados en un punto que el usuario no puede modificar, incluso en dispositivos desbloqueados. (Para asegurarse de que no se pueda falsificar).
- [C- SR-2
6-2] se recomienda encarecidamente usar dados como el mecanismo de derivación secreta por VM.Debe hacer dados correctamente, es decir, proporcionar los valores correctos.
- [C-1-1] debe admitir todas las API definidas por el paquete