Definición de compatibilidad de Android 14

1. Introducción

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

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

Como se usa en este documento, un “implementador de dispositivos” o "implementador" es una persona o una organización que desarrolle una solución de hardware o software que ejecute Una “implementación de dispositivos” o "implementación" es el una solución de hardware o software tan desarrollada.

Para que se considere compatible con Android 14, el dispositivo implementaciones DEBEN cumplir con los requisitos que se presentan en esta guía Definición, incluidos los documentos incorporados a través de referencia.

En los casos en que esta definición o las pruebas de software descritas en la sección 10 es silenciosa, ambigua o incompleto, es responsabilidad del implementador de dispositivos asegurar compatibilidad con las implementaciones existentes.

Por este motivo, el Proyecto de código abierto de Android es la referencia y la implementación preferida de Android. Dispositivo se les RECOMIENDA que los implementadores basen sus implementaciones posible en la plataforma "upstream" de código fuente disponible en la Proyecto de código abierto de Android Si bien algunos componentes pueden ser hipotéticamente por implementaciones alternativas, SE RECOMIENDA NO sigue esta práctica, ya que pasar las pruebas de software se convertirá sea más difícil. Es responsabilidad del implementador garantizar compatibilidad de comportamiento con la implementación estándar de Android, lo que incluye y más allá del Conjunto de pruebas de compatibilidad. Por último, ten en cuenta que ciertos componentes este documento prohíbe explícitamente las sustituciones y las modificaciones.

Muchos de los recursos vinculados en este documento derivan directamente o indirectamente desde el SDK de Android y serán funcionalmente idénticas al en la documentación del SDK. En los casos en que esta compatibilidad La definición o el conjunto de pruebas de compatibilidad no están de acuerdo con el SDK la del SDK se considera fidedigna. Cualquiera de los recursos técnicos los detalles que se proporcionan en los recursos vinculados a lo largo de este documento se que la inclusión forma parte de esta definición de compatibilidad.

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

El Artículo 2 contiene todos los requisitos que se aplican a un el tipo de dispositivo específico. Cada subsección de la Sección 2 es dedicada a un tipo de dispositivo específico.

Los demás requisitos, que se aplican universalmente a cualquier dispositivo Android implementaciones, se enumeran en las secciones posteriores a la Sección 2. Estos requisitos se denominan "Requisitos principales". en este documento.

1.1.2. ID de requisito

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

• El ID se asigna solo para los requisitos MUST.
• Los requisitos ESPECIAMENTE RECOMENDADOS se marcan como [SR], pero no se asigna el ID.
• El ID consiste en lo siguiente : ID de tipo de dispositivo - ID de condición - ID de requisito (p.ej., C-0-1).

Cada ID se define de la siguiente manera:

• ID del tipo de dispositivo (obtén más información en 2. Device Types)
  • C: Core (requisitos que se aplican a todas las implementaciones de dispositivos Android)
  • H: Dispositivo de mano Android
  • T: dispositivo de televisión Android
  • A: Implementación de Android Automotive
  • W: Implementación de Android Watch
  • Pestaña: Implementación en tablets Android
• ID de condición
  • Cuando el requisito es incondicional, este ID se establece en 0.
  • Cuando el requisito es condicional, se asigna 1 al 1er condición, y el número se incrementa en 1 dentro de la misma sección y el mismo tipo de dispositivo.
• ID de requisito
  • Este ID comienza desde 1 y aumenta de a 1 dentro de la misma sección y la misma condición.

1.1.3 ID de requisito en la sección 2

Los IDs de los requisitos en la Sección 2 tienen dos partes. La primera corresponde a un ID de sección, como se describió anteriormente. La segunda parte identifica entre el factor de forma y los requisitos específicos del factor de forma.

seguida del ID de requisito descrito anteriormente.

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

2. Tipos de dispositivo

El Proyecto de código abierto de Android ofrece una pila de software que puede usarse para varios tipos de dispositivos y factores de forma. Para admitir la seguridad en los dispositivos, la pila de software, incluido cualquier SO de reemplazo o un kernel alternativo del proyecto se ejecute en un entorno seguro, como se describe en la sección 9 y en otras secciones de este CDD. Existen diferentes tipos de dispositivos que cuentan con un ecosistema de distribución de aplicaciones mejor establecido.

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

Todas las implementaciones en dispositivos Android que no encajan en ninguna de las implementaciones descritas Los tipos de dispositivos DEBEN cumplir con todos los requisitos de las otras secciones de este Definición de compatibilidad.

2.1 Configuraciones del dispositivo

Para conocer las principales diferencias en la configuración de hardware por dispositivo , consulta los requisitos específicos de cada dispositivo que se incluyen más abajo en esta sección.

2.2. Requisitos para dispositivos portátiles

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

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

• Tener una fuente de alimentación que brinde movilidad, como una batería
• Tener un tamaño de pantalla diagonal físico dentro del rango de 4 pulgadas 3,3 pulgadas (o 2.5 pulgadas para implementaciones en dispositivos que se enviaron con nivel de API 29 o antes) a 8 pulgadas.
• Tener una interfaz de entrada con pantalla táctil.

Los requisitos adicionales que se incluyen en el resto de esta sección son específicos de Android. Implementaciones de dispositivos de mano

2.2.1. Hardware

Implementaciones en dispositivos de mano:

• [7.1.1.1/H-0-1] DEBE tener al menos una. Pantalla compatible con Android que cumple con todos los requisitos que se describe en este documento. pantalla que mide al menos 2,2" en el borde corto y 3.4" en el borde largo.

• [7.1.1.3/H-SR-1] SE RECOMIENDA ENERGMENTE a Brindan a los usuarios la posibilidad de cambiar el tamaño de visualización (densidad de pantalla).

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

Si las implementaciones de dispositivos de mano declaran compatibilidad con el alto rango dinámico. muestra hasta Configuration.isScreenHdr() :

• [7.1.4.5/H-1-1] SE DEBE promocionar la compatibilidad con el EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace y VK_EXT_hdr_metadata.

Implementaciones en dispositivos de mano:

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

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

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

Implementaciones en dispositivos de mano:

• [7.1.5/H-0-1] DEBE incluir compatibilidad con sistemas modo de compatibilidad de aplicaciones tal como lo implementa el sistema de apertura de Android ascendente código fuente. Es decir, las implementaciones en dispositivos NO DEBEN alterar los desencadenantes o en los que el modo de compatibilidad está activado y NO DEBE alterar del modo de compatibilidad.
• [7.2.1/H-0-1] DEBE incluir compatibilidad con herramientas Aplicaciones del Editor de método de entrada (IME).
• [7.2.3/H-0-2] SE DEBE enviar la acción de mantener presionado y al mantener presionado con normalidad. evento de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano. El sistema NO DEBE consumir estos eventos. y puede activarse desde fuera del dispositivo Android (p.ej., hardware externo teclado conectado al dispositivo Android).
• [7.2.3/H-0-3] SE DEBE proporcionar la función Inicio en todas las pantallas compatibles con Android que proporcionan la pantalla principal.
• [7.2.3/H-0-4] SE DEBE proporcionar la función Atrás en todos los compatibles con Android y la función Recientes en al menos uno de en las pantallas compatibles con Android.
• [7.2.4/H-0-1] DEBE ser compatible con la entrada de pantalla táctil.
• [7.2.4/H-SR-1] SE RECOMIENDA MUY BIEN iniciar el aplicación de asistencia seleccionada por el usuario; en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que controla ACTION_ASSIST al mantener presionado KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no controla esos eventos de presión prolongada.
• [7.3.1/H-SR-1] SE RECOMIENDA MUY BIEN que incluyan un panel de acelerómetro.

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

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

Si las implementaciones en dispositivos portátiles incluyen un receptor GPS/GNSS e informará el capacidad a las aplicaciones a través de la función android.hardware.location.gps marca, ellos:

• [7.3.3/H-2-1] SE DEBE informar las mediciones de GNSS en cuanto se aunque todavía no se haya informado una ubicación calculada a partir del GPS/GNSS.
• [7.3.3/H-2-2] SE DEBE informar pseudorangos y pseudorangos GNSS tarifas, que, en condiciones a cielo abierto después de determinar la ubicación, mientras que estacionario o en movimiento a menos de 0.2 metros por segundo al cuadrado aceleración, son suficientes para calcular la posición dentro de 20 metros, y la velocidad en un radio de 0.2 metros por segundo, al menos, el 95% del tiempo.

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

• [7.3.4/H-3-1] SE DEBE poder informar eventos con una frecuencia determinada. de al menos 100 Hz.
• [7.3.4/H-3-2] DEBE ser capaz de medir los cambios de orientación. hasta 1,000 grados por segundo.

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

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

Implementaciones en dispositivos de mano:

• [7.3.11/H-SR-1] SE RECOMIENDA ES IMPORTANTE para admitir el sensor de postura con 6 grados de libertad.
• [7.4.3/H] SE DEBE incluir compatibilidad con Bluetooth y Bluetooth de bajo consumo

Si los dispositivos admiten el protocolo Wi-Fi de Neighbor Awareness Networking (NAN) declarando PackageManager.FEATURE_WIFI_AWARE y ubicación de Wi-Fi (redonda de Wi-Fi) Duración del viaje: RTT) declarando PackageManager.FEATURE_WIFI_RTT; luego, hará lo siguiente:

• [7.4.2.5/H-1-1] DEBE informar el rango con precisión a en +/-1 metro a 160 MHz de ancho de banda en el percentil 68 (según se calcule (con la función de distribución acumulativa), +/-2 metros con un ancho de banda de 80 MHz en el percentil 68, +/-4 metros con un ancho de banda de 40 MHz en el percentil 68, y +/-8 metros a un ancho de banda de 20 MHz en el percentil 68 a distancias de 10 cm, 1 m, 3 m y 5 m, según se observa mediante la API de WifiRttManager#startRanging para Android.

• [7.4.2.5/H-SR-1] SE RECOMIENDA ENERCMENTE que informen los rango con precisión dentro de +/-1 metro a 160 MHz en el ancho de banda en percentil (como se calcula con la función de distribución acumulativa), +/-2 metros a 80 MHz de ancho de banda en el percentil 90, +/-4 metros a 40 MHz ancho de banda en el percentil 90 y +/-8 metros en el ancho de banda de 20 MHz en el percentil 90 a distancias de 10 cm, según se observa a través de la API de WifiRttManager#startRanging para Android.

SE RECOMIENDA MUY BIEN seguir los pasos para configurar la medición especificados en Calibración de presencias.

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

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

Implementaciones en dispositivos de mano:

• [7.6.1/H-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para datos privados de la aplicación (también conocida como partición “/data”).
• [7.6.1/H-0-2] DEBE mostrar “true” para ActivityManager.isLowRamDevice() cuando hay menos de 1 GB de memoria que están disponibles para el kernel y el espacio del usuario.

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

• [7.6.1/H-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de 416 MB como mínimo si la pantalla predeterminada usa el búfer de fotogramas. de hasta qHD (por ejemplo, FWVGA).

• [7.6.1/H-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 592 MB si la pantalla predeterminada usa el búfer de fotogramas. de resolución hasta HD+ (por ejemplo, HD, WSVGA).

• [7.6.1/H-3-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de, al menos, 896 MB si la pantalla predeterminada usa el búfer de fotogramas. hasta resolución FHD (p.ej., WSXGA+).

• [7.6.1/H-4-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de, al menos, 1344 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta QHD (por ejemplo, QWXGA).

Si las implementaciones de dispositivos de mano declaran la compatibilidad con cualquier ABI de 64 bits (con o sin alguna ABI de 32 bits), haz lo siguiente:

• [7.6.1/H-5-1] La memoria disponible para el kernel y el espacio del usuario DEBEN debe ser de al menos 816 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas superiores a qHD (por ejemplo, FWVGA).

• [7.6.1/H-6-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser, 944 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta HD+ (p.ej., HD o WSVGA).

• [7.6.1/H-7-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser, 1280 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta FHD (p.ej., WSXGA+).

• [7.6.1/H-8-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser, 1,824 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta QHD (p.ej., QWXGA).

Ten en cuenta que la “memoria disponible para el kernel y el espacio del usuario” anterior se refiere a la espacio de memoria proporcionado, además de cualquier memoria que ya esté dedicada al hardware como radio, video, etc., que no están incluidos en la memoria flash del en implementaciones del dispositivo.

Si las implementaciones en dispositivos de mano incluyen 1 GB de memoria o menos disponibles para el kernel y el espacio del usuario:

• [7.6.1/H-9-1] SE DEBE declarar la marca de función. android.hardware.ram.low
• [7.6.1/H-9-2] DEBE tener al menos 1.1 GB de almacenamiento no volátil para aplicaciones datos privados (también conocidos como partición “/data”).

Si las implementaciones en dispositivos de mano incluyen más de 1 GB de memoria disponible. al kernel y al espacio de usuario:

• [7.6.1/H-10-1] DEBE tener al menos 4 GB de el almacenamiento no volátil disponible datos privados de la aplicación (también conocidos como partición “/data”).
• SE DEBE declarar la marca de función android.hardware.ram.normal.

Si las implementaciones en dispositivos de mano incluyen 2 GB o más y menos de 4 GB de memoria disponible para el kernel y el espacio del usuario, hacen lo siguiente:

• [7.6.1/H-SR-1] SE RECOMIENDA ENERGENTE para admitir solo un espacio de usuario de 32 bits (tanto las apps como el código del sistema)

Si las implementaciones en dispositivos de mano incluyen menos de 2 GB de memoria disponible para kernel y el espacio de usuario:

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

Implementaciones en dispositivos de mano:

• [7.6.2/H-0-1] NO DEBE enviar una solicitud. el almacenamiento compartido es inferior a 1 GiB.
• [7.7.1/H] SE DEBE incluir un puerto USB que admita el modo periférico.

Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con periféricos , ellos:

• [7.7.1/H-1-1] SE DEBE implementar el Accesorio abierto de Android (AOA). API de gcloud.

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

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

Implementaciones en dispositivos de mano:

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

Si las implementaciones en dispositivos portátiles pueden alcanzar todas las requisitos para admitir el modo RV e incluir compatibilidad con él, deben cumplir con lo siguiente:

• [7.9.1/H-1-1] SE DEBE declarar el Marca de función android.hardware.vr.high_performance.
• [7.9.1/H-1-2] DEBE incluir una solicitud. implementar android.service.vr.VrListenerService que se puede habilitar mediante RV aplicaciones a través de android.app.Activity#setVrModeEnabled.

Si las implementaciones de dispositivos de mano incluyen uno o más puertos USB-C en el host e implementar (clase de audio USB), además de los requisitos en sección 7.7.2, hace lo siguiente:

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

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

• [7.8.2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG. en una inserción de enchufe, pero solo después de que las interfaces y los extremos de audio USB se enumeraron correctamente para identificar el tipo de terminal conectado.

Cuando se detecta el tipo de terminal de audio USB 0x0302, sucede lo siguiente:

• [7.8.2.2/H-2-1] SE DEBE transmitir el intent ACTION_HEADSET_PLUG con "micrófono" extra establecido en 0.

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

• [7.8.2.2/H-3-1] SE DEBE transmitir el intent ACTION_HEADSET_PLUG con "micrófono" extra establecido en 1.

Cuando se llama a la API AudioManager.getDevices() mientras se realiza esta acción con el periférico USB. conectaron:

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

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

• [7.8.2.2/H-4-3] DEBE mostrar un tipo de dispositivo. AudioDeviceInfo.TYPE_USB_HEADSET y rol isSource() si el terminal de audio USB es 0x0402.

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

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

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

• [7.8.2.2/H-4-7] DEBE mostrar un tipo de dispositivo. AudioDeviceInfo.TYPE_USB_DEVICE y rol isSource() si el terminal de audio USB tipo es 0x400.

• [7.8.2.2/H-SR-1] SE RECOMIENDEN ENERGMENTE cuando se conecta un Periférico de audio USB-C, para realizar la enumeración de descriptores USB, identifica tipos de terminal y el intent de transmisión ACTION_HEADSET_PLUG en menos de 1,000 milisegundos

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

• [5.6/H-1-1] DEBE tener un ida y vuelta promedio continuo. una latencia de 300 milisegundos menos de 5 mediciones, con una desviación absoluta media menor que 30 ms, superior las siguientes rutas de datos: "de la bocina al micrófono", Adaptador de bucle invertido de 3.5 mm (si es compatible) y adaptador de bucle invertido de USB (si es compatible).

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

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

Si las implementaciones en dispositivos de mano incluyen al menos un 7.10 de uso general. con un accionador de resonancia lineal:

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

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

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

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

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

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

• [7.10/H]* SE DEBE verificar y actualizar el resguardo si es necesario para primitivas incompatibles, como se describe en el orientación para la implementación para constantes.

2.2.2. Multimedia

Las implementaciones en dispositivos portátiles DEBEN admitir la siguiente codificación de audio y decodificando formatos y ponerlos a disposición de aplicaciones de terceros:

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

Las implementaciones en dispositivos portátiles DEBEN admitir la siguiente codificación de video y ponerlos a disposición de aplicaciones de terceros:

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

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

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

2.2.3. Software

Implementaciones en dispositivos de mano:

• [3.2.3.1/H-0-1] DEBE tener una aplicación que procesa las ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, y ACTION_CREATE_DOCUMENT intents, como se describe en los documentos del SDK, y proporcionar la indicación visual para acceder a los datos del proveedor de documentos mediante la API de DocumentsProvider.
• [3.2.3.1/H-0-2]* SE DEBE precargar uno. o más aplicaciones o componentes de servicio con un controlador de intents, para todos los patrones de filtro de intents públicos definidos por la siguiente aplicación intents enumerados aquí.
• [3.2.3.1/H-SR-1] Son DESARROLLO EFICAZ RECOMMENDED para precargar una aplicación de correo electrónico que pueda procesar ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE para enviar un correo electrónico.
• [3.4.1/H-0-1] DEBE proporcionar un implementación de la API de android.webkit.Webview.
• [3.4.2/H-0-1] DEBE incluir un navegador independiente. para navegar por la Web en general.
• [3.8.1/H-SR-1] SE RECOMIENDA COMPLETAMENTE para implementar un selector predeterminado que admita la fijación de combinaciones de teclas en la app widgets y widgetFeatures.
• [3.8.1/H-SR-2] SE RECOMIENDA COMPLETAMENTE implementar un selector predeterminado que proporcione acceso rápido a las bibliotecas combinaciones de teclas proporcionadas por apps de terceros mediante shortManager API de gcloud.
• [3.8.1/H-SR-3] SE RECOMIENDA COMPLETAMENTE para incluir una app de selector predeterminada que muestre insignias para los íconos de las apps.
• [3.8.2/H-SR-1] SE RECOMIENDA COMPLETAMENTE para admitir widgets de apps de terceros.
• [3.8.3/H-0-1] DEBE permitir la visualización de para notificar a los usuarios sobre eventos destacados mediante Notification y NotificationManager Clases de API.
• [3.8.3/H-0-2] DEBE ser compatible con contenido enriquecido. notificaciones.
• [3.8.3/H-0-3] SE DEBE admitir avisos notificaciones.
• [3.8.3/H-0-4] DEBE incluir un panel de notificaciones, que le brinda al usuario la capacidad de controlar directamente (p.ej., responder, posponer, descartar o bloquear) las notificaciones con la opción del usuario, como botones de acción o el panel de control, como se implementa en el AOSP.
• [3.8.3/H-0-5] SE DEBE mostrar las opciones. proporcionada a través de RemoteInput.Builder setChoices() en el panel de notificaciones.
• [3.8.3/H-SR-1] SE RECOMIENDA COMPLETAMENTE para mostrar la primera opción proporcionada a través de RemoteInput.Builder setChoices() en el panel de notificaciones sin interacción adicional del usuario.
• [3.8.3/H-SR-2] SE RECOMIENDA COMPLETAMENTE para mostrar todas las opciones proporcionadas mediante RemoteInput.Builder setChoices() en el panel de notificaciones cuando el usuario expande todas las notificaciones en la panel de notificaciones.
• [3.8.3.1/H-SR-1] SE RECOMIENDAN SÓLIDAMENTE para mostrar acciones para las que Notification.Action.Builder.setContextual se configure como true, en línea con las respuestas que muestra Notification.Remoteinput.Builder.setChoices
• [3.8.4/H-SR-1] SE RECOMIENDA COMPLETAMENTE para implementar un asistente en el dispositivo para controlar la acción de asistencia.

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

• [3.8.3.1/H-SR-2] SE RECOMIENDAN SÓLIDAMENTE para proporcionar una indicación visual de usuario (por ejemplo, un selector de salida) a la que se pueda acceder IU del sistema que permite a los usuarios cambiar entre el contenido multimedia disponible correspondiente rutas (por ejemplo, dispositivos Bluetooth y rutas proporcionadas a MediaRouter2Manager). cuando una app publica una notificación de MediaStyle con un token de MediaSession

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

• [3.8.4/H-SR-2] SE RECOMIENDA COMPLETAMENTE para usar mantener presionada la tecla HOME como la interacción designada para iniciar aplicación de asistencia, como se describe en la sección 7.2.3. DEBE iniciar la aplicación de asistencia seleccionada por el usuario; en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que controle el intent ACTION_ASSIST.

Si las implementaciones de dispositivos de mano admiten conversation notifications y agruparlos en una sección aparte de las alertas y los mensajes las notificaciones:

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

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

• [3.8.10/H-1-1] SE DEBE mostrar el ícono de bloqueo Notificaciones de pantalla, incluida la Plantilla de notificación multimedia.

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

• [3.9/H-1-1] SE DEBE implementar la gama completa de administración de dispositivos definidas en la documentación del SDK de Android.

Si las implementaciones en dispositivos de mano incluyen compatibilidad con ControlsProviderService y Control APIs y permiten que aplicaciones de terceros publiquen controles de dispositivos, y luego:

• [3.8.16/H-1-1] SE DEBE declarar la función. marca android.software.controls y lo establecimos en true.
• [3.8.16/H-1-2] DEBE proporcionar un indicación visual con la capacidad de agregar, editar, seleccionar y operar controles de dispositivos favoritos de los controles que registró el tercero aplicaciones a través de la ControlsProviderService y la Control APIs
• [3.8.16/H-1-3] DEBE proporcionar acceso a esta indicación visual del usuario en tres interacciones desde un selector predeterminado.

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

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

Por el contrario, si las implementaciones de dispositivos de mano no implementan dichos controles, hacen lo siguiente:

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

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

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

Implementaciones en dispositivos de mano:

• [3.10/H-0-1] SE DEBE admitir la accesibilidad de terceros. de Google Cloud.
• [3.10/H-SR-1] SE RECOMIENDA EXITOSAMENTE que se precargan servicios de accesibilidad en el dispositivo comparables con funciones superiores o superiores de Accesibilidad con interruptores y TalkBack (para los idiomas compatibles con la configuración servicios de accesibilidad como los que se proporcionan en talkback open proyecto de origen.
• [3.11/H-0-1] DEBE admitir la instalación de motores de TTS de terceros.
• [3.11/H-SR-1] SE RECOMIENDA MUY BIEN incluir un Motor de TTS compatible con los idiomas disponibles en el dispositivo.
• [3.13/H-SR-1] SE RECOMIENDA MUY BIEN incluir un Componente de IU de Configuración rápida

Si las implementaciones de dispositivos de mano Android declaran FEATURE_BLUETOOTH o Compatibilidad con FEATURE_WIFI, les permite hacer lo siguiente:

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

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

• [7.2.3/H] La zona de reconocimiento de gestos de la pantalla principal la función DEBE tener una altura no superior a 32 dp desde la parte inferior en la pantalla.

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

• [7.2.3/H-0-1] El área de gestos de la función de navegación DEBE tener menos de 40 dp de ancho en cada lado. El área de gestos DEBE El ancho predeterminado es de 24 dp.

Si las implementaciones de dispositivos de mano admiten una pantalla de bloqueo segura y tienen mayor iguales o inferiores a 2 GB de memoria disponibles para el kernel y el espacio del usuario, hacen lo siguiente:

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

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

• [7.5.4/H-1-1] DEBE respetar el error android.media.action.STILL_IMAGE_CAMERA y android.media.action.STILL_IMAGE_CAMERA_SECURE. e inicia la cámara en modo de imagen estática, como se describe en el SDK.
• [7.5.4/H-1-2] DEBE respetar el error android.media.action.VIDEO_CAMERA para iniciar la cámara en el modo de video, como se describe en el SDK.

Si la aplicación de configuración de la implementación del dispositivo implementa una funcionalidad dividida con la incorporación de actividades:

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

2.2.4. Rendimiento y potencia

• [8.1/H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas no es uniforme o un retraso en la renderización de fotogramas NO DEBE ocurrir más. a menudo de 5 fotogramas en un segundo y DEBERÍA ser inferior a 1 fotogramas en un segundo.
• [8.1/H-0-2] Latencia de la interfaz de usuario. Las implementaciones en dispositivos DEBEN garantizar una experiencia del usuario de baja latencia desplazando un lista de 10,000 entradas de lista según lo define el Conjunto de pruebas de compatibilidad de Android (CTS) en menos de 36 segundos.
• [8.1/H-0-3] Cambio de tareas. Cuándo varias aplicaciones, relanzamiento de una aplicación una vez iniciada, DEBE tardar menos de 1 segundo.

Implementaciones en dispositivos de mano:

• [8.2/H-0-1] DEBE asegurar una secuencia de al menos 5 MB/s.
• [8.2/H-0-2] SE DEBE garantizar una escritura aleatoria. de al menos 0.5 MB/s.
• [8.2/H-0-3] SE DEBE garantizar una lectura secuencial. y un rendimiento mínimo de 15 MB/s.
• [8.2/H-0-4] SE DEBE garantizar una lectura aleatoria. de al menos 3.5 MB/s.

Si las implementaciones en dispositivos de mano incluyen funciones para mejorar la energía del dispositivo del AOSP incluidas en el AOSP o extender las funciones en el AOSP, realiza lo siguiente:

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

Implementaciones en dispositivos de mano:

• [8.4/H-0-1] DEBE proporcionar un perfil de energía por componente que define el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería causado con el paso del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
• [8.4/H-0-2] SE DEBE informar toda la energía. de consumo en miliamperios-hora (mAh).
• [8.4/H-0-3] SE DEBE informar la potencia de la CPU. consumo por cada UID de proceso. El Proyecto de código abierto de Android cumple con los a través de la implementación del módulo de kernel uid_cputime.
• [8.4/H-0-4] SE DEBE hacer que este uso de energía disponible a través de adb shell dumpsys batterystats de shell al desarrollador de la app.
• [8.4/H] SE DEBE atribuir a la el componente de hardware en sí, si no es posible atribuir el uso de energía de los componentes de hardware a una aplicación.

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

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

Implementaciones en dispositivos de mano:

• [8.5/H-0-1] DEBE proporcionar una opción de usuario en el menú de configuración para ver todas las apps que tienen servicios activos en primer plano o tareas iniciadas por el usuario, incluida la duración de cada uno de estos servicios ya que comenzó como se describe en el documento del SDK. y la capacidad de detener una app que ejecuta un servicio en primer plano o una tarea iniciada por el usuario.con capacidad de detener una app que ejecuta un servicio en primer plano y muestra todas las aplicaciones que tienen servicios activos en primer plano y la duración de cada uno estos servicios desde que comenzó, como se describe en el Documento del SDK.
  • Algunas apps PUEDEN estar exentas de que se detengan o se incluyan en dichas la prestación del servicio, como se describe en el documento del SDK.

2.2.5. Modelo de seguridad

Implementaciones en dispositivos de mano:

• [9/H-0-1] SE DEBE declarar android.hardware.security.model.compatible. .
• [9.1/H-0-1] DEBE permitir que apps de terceros accedan a la estadísticas de uso a través del permiso android.permission.PACKAGE_USAGE_STATS y proporcionar un mecanismo al que el usuario pueda acceder para conceder o revocar el acceso a dichas aplicaciones en respuesta a la android.settings.ACTION_USAGE_ACCESS_SETTINGS .

Implementaciones en dispositivos de mano:

• [9.11/H-0-2] SE DEBE crear una copia de seguridad de la implementación del almacén de claves. con un entorno de ejecución aislado.
• [9.11/H-0-3] DEBE tener implementaciones de RSA, AES, Algoritmos criptográficos de ECDSA y HMAC, y familias MD5, SHA1 y SHA-2 hash para admitir correctamente las funciones en un área aislada de forma segura del código que se ejecuta kernel y versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos por qué código del espacio del usuario o kernel puede acceder al estado interno del entorno aislado, incluida la DMA. El código abierto de Android ascendente El Proyecto (AOSP) cumple este requisito por medio de la implementación de Trusty, pero Solución basada en ARM TrustZone o una versión segura revisada por terceros implementación de un aislamiento adecuado basado en un hipervisor son alternativas opciones de estado.
• [9.11/H-0-4] SE DEBE ejecutar la pantalla de bloqueo. autenticación en el entorno de ejecución aislado y solo cuando correctamente, permite que se usen las claves vinculadas a la autenticación. Pantalla de bloqueo las credenciales DEBEN almacenarse de forma tal que solo se permita para realizar la autenticación con la pantalla de bloqueo. El servicio upstream de Android El Proyecto de código abierto brinda Capa de abstracción de hardware (HAL) del recepcionista y Trusty, que pueden usarse para cumplir con este requisito.
• [9.11/H-0-5] SE DEBE admitir la certificación de claves donde de certificación de Google Cloud está protegida con hardware seguro, y la firma se que se ejecuta en hardware seguro. Las claves de firma de certificación SE DEBEN compartir en una cantidad de dispositivos lo suficientemente grande para evitar que se usen las claves como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir el misma clave de certificación, salvo que se envíen al menos 100,000 unidades de un SKU determinado producidos. Si se producen más de 100,000 unidades de un SKU, se puede usar una PUEDE usarse para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se lanzó en una versión anterior de Android versión, este dispositivo está exento del requisito de tener un almacén de claves. está respaldado por un entorno de ejecución aislado y admite la certificación de claves. a menos que declare la función android.hardware.fingerprint que requiera un de código abierto respaldado por un entorno de ejecución aislado.

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

• [9.11/H-1-1] DEBE permitir que el usuario elija la extensión más corta tiempo de espera de suspensión, que es un tiempo de transición entre el desbloqueo y el bloqueo de 15 segundos o menos.
• [9.11/H-1-2] DEBE proporcionar al usuario la indicación visual para ocultar e inhabilitar todas las formas de autenticación, excepto la autenticación principal descrita en 9.11.1 Pantalla de bloqueo segura. El AOSP cumple con de bloqueo como modo de bloqueo.

Si las implementaciones en dispositivos de mano incluyen varios usuarios y No declaras la marca de función android.hardware.telephony:

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

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

• [9.5/H-3-1] NO DEBE admitir restricciones restringidas perfiles, pero DEBEN alinearse con la implementación de controles del AOSP para permitir o impedir que otros usuarios accedan a las llamadas de voz y a los SMS.

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

Si las implementaciones de dispositivos de mano admiten la API del sistema HotwordDetectionService o algún otro mecanismo para la detección de palabras clave sin indicación de acceso al micrófono:

• [9.8/H-1-1] DEBE asegurarse de que el servicio de detección de palabras clave solo pueda transmitir datos al sistema, ContentCaptureService, o un servicio de reconocimiento de voz integrado en el dispositivo creado por SpeechRecognizer#createOnDeviceSpeechRecognizer()
• [9.8/H-1-2] DEBE asegurarse de que el servicio de detección de palabras clave solo pueda transmitir datos de audio del micrófono o los datos derivados de él al servidor del sistema mediante API de HotwordDetectionService, o a ContentCaptureService mediante API de ContentCaptureManager.
• [9.8/H-1-3] NO SE DEBE proporcionar audio del micrófono que dure más de 30 segundos en un una solicitud individual activada por hardware al servicio de detección de palabras clave.
• [9.8/H-1-4] NO DEBES suministrar audio del micrófono almacenado en búfer con más de 8 segundos de antigüedad para un cada solicitud individual al servicio de detección de palabras clave.
• [9.8/H-1-5] NO se DEBE suministrar al micrófono el audio del micrófono almacenado en búfer con más de 30 segundos de antigüedad servicio de interacción de voz o una entidad similar.
• [9.8/H-1-6] NO DEBE permitir más de 100 bytes de datos transmitirse fuera del servicio de detección de palabras clave en cada resultado de palabra clave excepto para los datos de audio pasados HotwordAudioStream.
• [9.8/H-1-7] NO DEBE permitir que se transmitan más de 5 bits de datos del servicio de detección de palabras clave en cada resultado negativo.
• [9.8/H-1-8] Solo DEBE permitir la transmisión de datos fuera de la palabra clave. de detección de intrusiones en una solicitud de validación de palabras clave desde el servidor del sistema.
• [9.8/H-1-9] NO DEBE permitir que una aplicación instalable por el usuario proporcione la de detección de palabras clave.
• [9.8/H-1-10] NO DEBE aparecer en la IU cuantitativos sobre el uso del micrófono por el servicio de detección de palabras clave.
• [9.8/H-1-11] SE DEBE registrar la cantidad de bytes incluidos en cada transmisión. del servicio de detección de palabras clave para permitir la inspección investigadores.
• [9.8/H-1-12] DEBE admitir un modo de depuración que registre el contenido sin procesar de cada de detección de palabras clave para permitir la inspección investigadores de seguridad.
• [9.8/H-1-14] SE DEBE mostrar el indicador del micrófono, como se describe en la sección 9.8.2, cuando se transmite una palabra clave correcta a la voz de interacción o una entidad similar.

• [9.8/H-SR-1] SE RECOMIENDA MUY BIEN notificar a los usuarios antes de configurar una como proveedor del servicio de detección de palabras clave.
• [9.8/H-SR-2] SE RECOMIENDA IMPORTANTEMENTE para impedir la transmisión de datos no estructurados fuera del servicio de detección de palabras clave.
• [9.8/H-SR-3] SE RECOMIENDA SER RECOMENDADO que reinicien el proceso que aloja el de detección de palabras clave al menos una vez cada hora o cada 30 de hardware, lo que ocurra primero.

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

• [9.8/H-2-1] SE DEBE proporcionar un aviso explícito al usuario para cada frase de palabra clave. no es compatible.
• [9.8/H-2-2] NO DEBE conservar datos de audio sin procesar ni datos derivados de ellos. a través del servicio de detección de palabras clave.
• [9.8/H-2-3] NO se debe transmitir desde el servicio de detección de palabras clave, el audio datos, datos que se pueden utilizar para reconstruir (total o parcialmente) el audio, o contenidos de audio no relacionados con la palabra clave en sí, excepto por el ContentCaptureService o voz integrada en el dispositivo de reconocimiento de imágenes.

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

• [9.8.2/H-4-1] SE DEBE mostrar el indicador del micrófono cuando accede a datos de audio desde el micrófono, pero no cuando solo accede al micrófono HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService o aplicaciones que tienen los roles llamados en la sección 9.1 con el identificador de CDD [C-4-X].
• [9.8.2/H-4-2] SE DEBE mostrar la lista de Recientes y Activos. apps que usan el micrófono como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier atribución mensajes asociados.

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

• [9.8.2/H-5-1] SE DEBE mostrar el indicador de la cámara cuando se accede a los datos de la cámara en vivo, pero no cuando la cámara a las que acceden las aplicaciones que tienen los roles designados artículo 9.1 con el identificador de CDD [C-4-X].
• [9.8.2/H-5-2] SE DEBE mostrar apps recientes y activas con cámara como se devuelve en PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados.

2.2.6. Compatibilidad de las Herramientas y opciones para desarrolladores

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

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

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

• Perfetto
  • [6.1/H-0-2]* DEBE exponer un /system/bin/perfetto. binario al usuario de shell y cmdline cumple la documentación de perfetto.
  • [6.1/H-0-3]* El objeto binario de perfetto DEBE aceptar como ingresar una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/H-0-4]* El objeto binario de perfetto DEBE escribir como genera un seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/H-0-5]* SE DEBE proporcionar, a través del perfetto. binario, al menos las fuentes de datos descritas en la documentación de perfetto.
  • [6.1/H-0-6]* El daemon rastreado por perfetto DEBE habilitado de forma predeterminada (propiedad del sistema persist.traced.enable).

2.2.7. Clase de rendimiento del contenido multimedia portátil

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

2.2.7.1. Contenido multimedia

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T. para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, luego:

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

2.2.7.2. Cámara

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T. para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, luego:

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

2.2.7.3 Hardware

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.T durante android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, luego:

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

2.2.7.4. Rendimiento

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.T durante android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, luego:

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

2.3. Requisitos de televisión

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

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

• Proporcionaron un mecanismo para controlar de forma remota la interfaz de usuario renderizada en la pantalla que podría colocarse a tres metros de distancia del usuario.
• Tener una pantalla integrada con una longitud diagonal superior a 24 pulgadas O incluir un puerto de salida de video, como VGA, HDMI, DisplayPort o un puerto inalámbrico para la pantalla.

Los requisitos adicionales que se incluyen en el resto de esta sección son específicos de Android. Implementaciones de dispositivos de televisión

2.3.1. Hardware

Implementaciones de dispositivos de televisión:

• [7.2.2/T-0-1] DEBE ser compatible con el pad direccional.
• [7.2.3/T-0-1] SE DEBE proporcionar las secciones principal y posterior. funciones.
• [7.2.3/T-0-2] SE DEBE enviar la acción de mantener presionado un elemento normal y otro evento de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
• [7.2.6.1/T-0-1] DEBE incluir compatibilidad con el juego. controles y declarar la marca de función android.hardware.gamepad.
• [7.2.7/T] SE DEBE proporcionar un control remoto desde el cual los usuarios pueden acceder a la navegación no táctil y las entradas de las teclas de navegación principales.

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

• [7.3.4/T-1-1] SE DEBE poder informar eventos hasta un de al menos 100 Hz.
• [7.3.4/T-1-2] DEBE ser capaz de medir los cambios de orientación. hasta 1,000 grados por segundo.

Implementaciones de dispositivos de televisión:

• [7.4.3/T-0-1] DEBE ser compatible con Bluetooth y Bluetooth de bajo consumo
• [7.6.1/T-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para datos privados de la aplicación (también conocida como partición “/data”).

Si las implementaciones de dispositivos de televisión incluyen un puerto USB compatible con el modo host, hace lo siguiente:

• [7.5.3/T-1-1] DEBE incluir compatibilidad con una cámara externa. que se conecta a través de este puerto USB, pero que no siempre está conectado.

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

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

  • 400 dpi o más en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

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

• [7.6.1/T-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se usan usado:

  • 400 dpi o más en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

Ten en cuenta que la “memoria disponible para el kernel y el espacio del usuario” anterior se refiere a la espacio de memoria proporcionado, además de los que ya dedicados a componentes de hardware, como radio, video, etc., que no estén bajo el control del kernel sobre implementaciones en dispositivos.

Implementaciones de dispositivos de televisión:

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

2.3.2. Multimedia

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

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

Las implementaciones de dispositivos de televisión DEBEN admitir la siguiente codificación de video y ponerlos a disposición de aplicaciones de terceros:

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

Implementaciones de dispositivos de televisión:

• [5.2.2/T-SR-1] SE RECOMIENDA COMPLETAMENTE asistencia Codificación H.264 de videos con resoluciones de 720p y 1080p a 30 fotogramas por segundo

Las implementaciones en dispositivos de televisión DEBEN admitir la siguiente decodificación de video y ponerlos a disposición de aplicaciones de terceros:

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

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

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

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

• [5.3.4/T-1-1] HD 1080p a 60 fotogramas por segundo con Perfil de Baseline
• [5.3.4/T-1-2] HD 1080p a 60 fotogramas por segundo con Perfil principal
• [5.3.4/T-1-3] HD 1080p a 60 fotogramas por segundo con Nivel de perfil alto 4.2

Las implementaciones en dispositivos de televisión con decodificadores de hardware H.265 DEBEN ser compatibles Decodificación de H.265, como se detalla en la sección 5.3.5, a velocidades de fotogramas de video estándar y resoluciones, que incluya lo siguiente:

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

Si las implementaciones de dispositivos de televisión con decodificadores de hardware H.265 admiten La decodificación de H.265 y el perfil de decodificación de UHD:

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

Las implementaciones en dispositivos de televisión DEBEN admitir la decodificación de VP8, como se detalla en Artículo 5.3.6, con velocidades y resoluciones de fotogramas de video estándar de hasta como:

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

Las implementaciones en dispositivos de televisión con decodificadores de hardware de VP9 DEBEN ser compatibles con VP9. como se detalla en la sección 5.3.7, a velocidades de fotogramas de video estándar y resoluciones, que incluyen lo siguiente:

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

Si las implementaciones de dispositivos de televisión con decodificadores de hardware de VP9 admiten VP9 y el perfil de decodificación en UHD, hacen lo siguiente:

• [5.3.7/T-2-1] DEBE ser compatible con el perfil de decodificación en UHD. a 60 fotogramas por segundo con el perfil 0 (profundidad de color de 8 bits).
• [5.3.7/T-SR1] SE RECOMIENDA ENERCMENTE que respalden el Perfil de decodificación UHD a 60 fotogramas por segundo con perfil 2 (profundidad de color de 10 bits).

Implementaciones de dispositivos de televisión:

• [5.5/T-0-1] DEBE incluir compatibilidad con la instancia principal del sistema. Atenuación del volumen y el volumen de la salida de audio digital en las salidas compatibles excepto la salida de transferencia de audio comprimido (en el que no se realiza ninguna decodificación de audio) en el dispositivo).

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

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

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

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

Si las implementaciones de dispositivos de televisión no admiten la decodificación UHD, pero en su lugar, admiten una pantalla externa conectada a través de HDMI, sino que:

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

2.3.3. Software

Implementaciones de dispositivos de televisión:

• [3/T-0-1] SE DEBE declarar las funciones. android.software.leanback y android.hardware.type.television.
• [3.2.3.1/T-0-1] DEBE precargar uno o más aplicaciones o componentes de servicio con un controlador de intents, para todas las patrones de filtro de intents públicos definidos por los siguientes intents de aplicación que se indican aquí.
• [3.4.1/T-0-1] DEBE proporcionar un implementación de la API de android.webkit.Webview.

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

• [3.8.10/T-1-1] SE DEBE mostrar el ícono de bloqueo Notificaciones de pantalla, incluida la Plantilla de notificación multimedia.

Implementaciones de dispositivos de televisión:

• [3.8.14/T-SR-1] SE RECOMIENDAN SÓLIDAMENTE para admitir el modo multiventana (PIP).
• [3.10/T-0-1] DEBE ser compatible con la accesibilidad de terceros. de Google Cloud.
• [3.10/T-SR-1] SE RECOMIENDA ENERGMENTE a precargar servicios de accesibilidad en el dispositivo comparables con o superiores de Accesibilidad con interruptores y TalkBack (para idiomas compatibles con servicios de accesibilidad preinstalados del motor de texto a voz), tal como se proporciona en el proyecto de código abierto de TalkBack.

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

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

Implementaciones de dispositivos de televisión:

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

2.3.4. Rendimiento y potencia

• [8.1/T-0-1] Latencia de fotogramas coherente. La latencia de fotogramas no es uniforme o un retraso en la renderización de fotogramas NO DEBE ocurrir más. a menudo de 5 fotogramas en un segundo y DEBERÍA ser inferior a 1 fotogramas en un segundo.
• [8.2/T-0-1] DEBE asegurar una secuencia y escribir un rendimiento de al menos 5 MB/s.
• [8.2/T-0-2] SE DEBE garantizar una escritura aleatoria. de al menos 0.5 MB/s.
• [8.2/T-0-3] DEBE asegurar una secuencia de lectura de al menos 15 MB/s.
• [8.2/T-0-4] SE DEBE garantizar una lectura aleatoria de al menos 3.5 MB/s.

Si las implementaciones en dispositivos de televisión incluyen funciones para mejorar la energía del dispositivo del AOSP incluidas en el AOSP o extender las funciones en el AOSP, realiza lo siguiente:

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

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

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

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

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

Implementaciones de dispositivos de televisión:

• [8.4/T-0-1] DEBE proporcionar un perfil de energía por componente que define el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería causado con el paso del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
• [8.4/T-0-2] SE DEBE informar toda la energía. de consumo en miliamperios-hora (mAh).
• [8.4/T-0-3] SE DEBE informar la potencia de la CPU consumo por cada UID de proceso. El Proyecto de código abierto de Android cumple con los a través de la implementación del módulo de kernel uid_cputime.
• [8.4/T] SE DEBE atribuir al el componente de hardware en sí, si no es posible atribuir el uso de energía de los componentes de hardware a una aplicación.
• [8.4/T-0-4] DEBE hacer que este uso de energía disponible a través de adb shell dumpsys batterystats de shell al desarrollador de la app.

2.3.5. Modelo de seguridad

Implementaciones de dispositivos de televisión:

• [9/T-0-1] DEBE declarar android.hardware.security.model.compatible. .
• [9.11/T-0-1] SE DEBE crear una copia de seguridad de la implementación del almacén de claves. con un entorno de ejecución aislado.
• [9.11/T-0-2] DEBE tener implementaciones de RSA, AES, Algoritmos criptográficos de ECDSA y HMAC y familia MD5, SHA1 y SHA-2 hash para admitir correctamente las funciones en un área aislada de forma segura del código que se ejecuta kernel y versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos por qué código del espacio del usuario o kernel puede acceder al estado interno del entorno aislado, incluida la DMA. El código abierto de Android ascendente El Proyecto (AOSP) cumple este requisito por medio de la implementación de Trusty, pero Solución basada en ARM TrustZone o una versión segura revisada por terceros implementación de un aislamiento adecuado basado en un hipervisor son alternativas opciones de estado.
• [9.11/T-0-3] SE DEBE ejecutar la pantalla de bloqueo autenticación en el entorno de ejecución aislado y solo cuando correctamente, permite que se usen las claves vinculadas a la autenticación. Pantalla de bloqueo las credenciales DEBEN almacenarse de forma tal que solo se permita para realizar la autenticación con la pantalla de bloqueo. El servicio upstream de Android El Proyecto de código abierto brinda Capa de abstracción de hardware (HAL) del recepcionista y Trusty, que pueden usarse para cumplir con este requisito.
• [9.11/T-0-4] SE DEBE admitir la certificación de claves donde de certificación de Google Cloud está protegida con hardware seguro, y la firma se que se ejecuta en hardware seguro. Las claves de firma de certificación SE DEBEN compartir en una cantidad de dispositivos lo suficientemente grande para evitar que se usen las claves como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir el misma clave de certificación, salvo que se envíen al menos 100,000 unidades de un SKU determinado producidos. Si se producen más de 100,000 unidades de un SKU, se puede usar una PUEDE usarse para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se lanzó en una versión anterior de Android versión, este dispositivo está exento del requisito de tener un almacén de claves. está respaldado por un entorno de ejecución aislado y admite la certificación de claves. a menos que declare la función android.hardware.fingerprint que requiera un de código abierto respaldado por un entorno de ejecución aislado.

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

• [9.11/T-1-1] DEBE permitir que el usuario elija la opción de tiempo de espera para la transición del estado desbloqueado al bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos o menos.

Si las implementaciones en dispositivos de televisión incluyen varios usuarios y No declaras la marca de función android.hardware.telephony:

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

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

• [9.5/T-3-1] NO DEBE admitir restricciones perfiles, pero DEBEN alinearse con la implementación de controles del AOSP para permitir o impedir que otros usuarios accedan a las llamadas de voz y a los SMS.

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

• [9.8.2/T-4-1] SE DEBE mostrar el indicador del micrófono cuando accede a datos de audio desde el micrófono, pero no cuando solo accede al micrófono mediante HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o las aplicaciones que tienen las funciones mencionadas en la sección 9.1 Permisos con identificador de CDD C-3-X].
• [9.8.2/T-4-2] No se DEBE ocultar el indicador del micrófono para del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

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

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

2.3.6. Compatibilidad de las Herramientas y opciones para desarrolladores

Implementaciones de dispositivos de televisión:

• Perfetto
  • [6.1/T-0-1] DEBE exponer un /system/bin/perfetto. binario al usuario de shell y cmdline cumple la documentación de perfetto.
  • [6.1/T-0-2] El objeto binario de perfetto DEBE aceptar como ingresar una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/T-0-3] El objeto binario de perfetto DEBE escribir como genera un seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/T-0-4] SE DEBE proporcionar a través del perfetto. binario, al menos las fuentes de datos descritas en la documentación de perfetto.

2.4. Requisitos para el reloj

Un dispositivo de reloj Android hace referencia a una implementación de dispositivo Android destinada a llevarse en el cuerpo, quizás en la muñeca.

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

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

Los requisitos adicionales que se incluyen en el resto de esta sección son específicos de Android. Implementaciones de dispositivos de supervisión

2.4.1. Hardware

Implementaciones de dispositivos de reloj:

• [7.1.1.1/W-0-1] DEBE tener una pantalla con los física diagonal en el rango de 1.1 a 2.5 pulgadas.

• [7.2.3/W-0-1] DEBE tener disponible la función de inicio. al usuario y la función Atrás, excepto cuando está en UI_MODE_TYPE_WATCH.

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

• [7.3.1/W-SR-1] SE RECOMIENDA MUY BIEN que incluyan un panel de acelerómetro.

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

• [7.3.3/W-1-1] SE DEBE informar las mediciones de GNSS en cuanto se aunque todavía no se haya informado una ubicación calculada a partir del GPS/GNSS.
• [7.3.3/W-1-2] SE DEBE informar pseudorangos y pseudorangos GNSS tarifas, que, en condiciones a cielo abierto después de determinar la ubicación, mientras que estacionario o en movimiento a menos de 0.2 metros por segundo al cuadrado aceleración, son suficientes para calcular la posición dentro de 20 metros, y la velocidad en un radio de 0.2 metros por segundo, al menos, el 95% del tiempo.

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

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

Implementaciones de dispositivos de reloj:

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

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

• [7.6.1/W-0-2] DEBE tener al menos 416 MB de memoria que están disponibles para el kernel y el espacio del usuario.

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

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

2.4.2. Multimedia

Sin requisitos adicionales.

2.4.3. Software

Implementaciones de dispositivos de reloj:

• [3/W-0-1] SE DEBE declarar la función. android.hardware.type.watch
• [3/W-0-2] DEBE admitir uiMode =. UI_MODE_TYPE_WATCH:
• [3.2.3.1/W-0-1] SE DEBE precargar uno. o más aplicaciones o componentes de servicio con un controlador de intents, para todos los patrones de filtro de intents públicos definidos por la siguiente aplicación intents enumerados aquí.

Implementaciones de dispositivos de reloj:

• [3.8.4/W-SR-1] SE RECOMIENDAN SÓLIDAMENTE para implementar un asistente en el dispositivo para controlar la acción de asistencia.

Implementaciones de dispositivos de reloj que declaran android.hardware.audio.output marca de función:

• [3.10/W-1-1] SE DEBE admitir la accesibilidad de terceros. de Google Cloud.
• [3.10/W-SR-1] SE RECOMIENDA EXITOSAMENTE que se precargan servicios de accesibilidad en el dispositivo comparables con funciones superiores o superiores de Accesibilidad con interruptores y TalkBack (para los idiomas compatibles con la configuración servicios de accesibilidad de texto a voz) como se proporciona en proyecto de código abierto de TalkBack.

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

• [3.11/W-SR-1] SE RECOMIENDA MUY BIEN incluir un Motor de TTS compatible con los idiomas disponibles en el dispositivo.

• [3.11/W-0-1] DEBE admitir la instalación de motores de TTS de terceros.

2.4.4. Rendimiento y potencia

Si las implementaciones en dispositivos de reloj incluyen funciones para mejorar la energía del dispositivo del AOSP incluidas en el AOSP o extender las funciones en el AOSP, realiza lo siguiente:

• [8.3/W-SR-1] SE RECOMIENDA ENcarecidamente proporcionar la indicación visual del usuario para mostrar todas las apps exentas de App Standby y Modos de ahorro de energía Descanso
• [8.3/W-SR-2] SE RECOMIENDA ENcarecidamente proporcionar la indicación del usuario para habilitar e inhabilitar la función de ahorro de batería.

Implementaciones de dispositivos de reloj:

• [8.4/W-0-1] DEBE proporcionar un perfil de energía por componente que define el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería causado con el paso del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
• [8.4/W-0-2] SE DEBE informar toda la energía. de consumo en miliamperios-hora (mAh).
• [8.4/W-0-3] SE DEBE informar la potencia de la CPU consumo por cada UID de proceso. El Proyecto de código abierto de Android cumple con los a través de la implementación del módulo de kernel uid_cputime.
• [8.4/W-0-4] DEBE hacer que este consumo de energía disponible a través de adb shell dumpsys batterystats de shell al desarrollador de la app.
• [8.4/W] SE DEBE atribuir al el componente de hardware en sí, si no es posible atribuir el uso de energía de los componentes de hardware a una aplicación.

2.4.5. Modelo de seguridad

Implementaciones de dispositivos de reloj:

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

Si las implementaciones en dispositivos de reloj incluyen múltiples usuarios No declaras la marca de función android.hardware.telephony:

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

Si las implementaciones en dispositivos de reloj incluyen múltiples usuarios declaran la marca de función android.hardware.telephony, hacen lo siguiente:

• [9.5/W-2-1] NO DEBE admitir restricciones perfiles, pero DEBEN alinearse con la implementación de controles del AOSP para permitir o impedir que otros usuarios accedan a las llamadas de voz y a los SMS.

2.5 Requisitos de la industria automotriz

La implementación de Android Automotive hace referencia a la consola central de un vehículo Android como sistema operativo para todo el sistema o una parte de él las funciones de infoentretenimiento.

Las implementaciones en dispositivos Android se clasifican como Automotive si las declaran la función android.hardware.type.automotive o cumplir con todas las con tus criterios.

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

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

2.5.1. Hardware

Implementaciones en dispositivos de Automotive:

• [7.1.1.1/A-0-1] DEBE tener una pantalla de al menos 6. pulgadas en tamaño diagonal físico.
• [7.1.1.1/A-0-2] DEBE tener un diseño de tamaño de pantalla. de, al menos, 750 dp x 480 dp.
• [7.2.3/A-0-1] DEBE proporcionar la función Inicio y PUEDE proporcionar las funciones Atrás y Recientes.
• [7.2.3/A-0-2] SE DEBE enviar la acción de mantener presionado un elemento normal y otro evento de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
• [7.3/A-0-1] SE DEBE implementar y, luego, informar GEAR_SELECTION: NIGHT_MODE, PERF_VEHICLE_SPEED y PARKING_BRAKE_ON.
• [7.3/A-0-2] El valor de NIGHT_MODE marca DEBE ser coherente con el modo diurno/nocturno del panel y DEBE basarse en entrada del sensor de luz ambiente. PUEDE QUE el sensor de luz ambiente subyacente sea el mismo como Fotómetro.
• [7.3/A-0-3] SE DEBE proporcionar el campo de información adicional del sensor. TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor proporcionado.
• [7.3/A-SR1] MAYÚSCULA Ubicación fusionando GPS/GNSS con otros sensores. Si Location se considera absolutamente muerto, SE RECOMIENDA EXIGENTEMENTE implementar e informar los Sensor correspondiente tipos o IDs de propiedades del vehículo que se usan.

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

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

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

• [7.3/A-SR-2] Tienen StrongLY_RECOMMENDED para implementar y reportar Sensor TYPE_HEADING.

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

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

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

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

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

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

Si las implementaciones en dispositivos de Automotive incluyen un acelerómetro con un valor de en 3 ejes:

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

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

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

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

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

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

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

Si las implementaciones en dispositivos de Automotive incluyen un receptor de GPS/GNSS, pero no incluyen conectividad de datos basada en redes móviles, ellos:

• [7.3.3/A-3-1] DEBE determinar la ubicación la primera vez. cuando el receptor de GPS/GNSS esté encendido o después de 4 días o más en un plazo de 60 segundos
• [7.3.3/A-3-2] DEBE cumplir con los criterios de tiempo para la primera solución, como descritos en 7.3.3/C-1-2 y 7.3.3/C-1-6 para todas las demás solicitudes de ubicación (es decir, las que no son la primera vez siempre o después de 4 días o más). El requisito 7.3.3/C-1-2 es en vehículos sin conectividad de datos basada en redes móviles, con predicciones de órbita de GNSS calculadas en el receptor, o bien la última ubicación conocida del vehículo, junto con la posibilidad de usar Derew reckon en 60 segundos, con una precisión de posición que satisfaga 7.3.3/C-1-3 o una combinación de ambas.

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

• [7.3.4/A-4-3] SE DEBE poder informar eventos con una frecuencia determinada. de al menos 1 Hz.
• [7.3.4/A-SR-3] Se te recomendó informar eventos de hasta un de al menos 10 Hz.
• DEBE hacer referencia al norte geográfico.
• DEBERÍA estar disponible incluso cuando el vehículo está quieto.
• DEBE tener una resolución de al menos 1 grado.

Implementaciones en dispositivos de Automotive:

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

• [7.4.3/A-SR-1] SE RECOMIENDA EXCELENTEMENTE que brinden asistencia Perfil de acceso a mensajes (MAP).

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

• [7.4.5/A] PUEDE usar la API del sistema Constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID para que deben estar disponibles para las apps del sistema.

Implementaciones en dispositivos de Automotive:

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

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

Si las implementaciones en dispositivos de Automotive proporcionan almacenamiento externo compartido a través de un del almacenamiento interno no extraíble:

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

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

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

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

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

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

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

  • 400 dpi o más en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

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

  • 560 dpi o más en pantallas pequeñas o normales
  • 400 dpi o más en pantallas grandes
  • xhdpi o superior en pantallas extragrandes

Ten en cuenta que la “memoria disponible para el kernel y el espacio del usuario” anterior se refiere a la espacio de memoria proporcionado, además de cualquier memoria que ya esté dedicada al hardware como radio, video, etc., que no están incluidos en la memoria en implementaciones del dispositivo.

Implementaciones en dispositivos de Automotive:

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

Implementaciones en dispositivos de Automotive:

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

Implementaciones en dispositivos de Automotive:

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

2.5.2. Multimedia

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

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

Las implementaciones en dispositivos de Automotive DEBEN admitir la siguiente codificación de video y ponerlos a disposición de aplicaciones de terceros:

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

Las implementaciones en dispositivos de Automotive DEBEN admitir la siguiente decodificación de video y ponerlos a disposición de aplicaciones de terceros:

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

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

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

2.5.3. Software

Implementaciones en dispositivos de Automotive:

• [3/A-0-1] SE DEBE declarar la función. android.hardware.type.automotive

• [3/A-0-2] DEBE admitir uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] SE DEBE admitir todas las APIs públicas del android.car.* espacio de nombres.

Si las implementaciones en dispositivos de Automotive proporcionan una API de su propiedad con android.car.CarPropertyManager con android.car.VehiclePropertyIds, hacen lo siguiente:

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

Implementaciones en dispositivos de Automotive:

• [3.2.1/A-0-1] SE DEBE admitir y aplicar todas Las constantes de permisos, como se documenta en la página de referencia de Permisos de Automotive

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

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

• [3.8.3/A-0-1] SE DEBE mostrar las notificaciones que usan el ícono Notification.CarExtender API cuando lo soliciten aplicaciones de terceros.

• [3.8.4/A-SR-1] Son muy recomendados para implementar un asistente en el dispositivo para controlar la acción de asistencia.

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

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

Implementaciones en dispositivos de Automotive:

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

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

• [3.9.3/A-1-1] SE DEBE implementar todos los Propiedades del ciclo de vida de los usuarios
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER

Implementaciones en dispositivos de Automotive:

• [3.14/A-0-1] DEBE incluir un framework de IU para admitir Apps de terceros que usan las APIs de contenido multimedia, como se describe en la sección 3.14
• [3.14/A-0-2] DEBE permitir que el usuario interactúe de manera segura con las aplicaciones de contenido multimedia mientras conduces.
• [3.14/A-0-3] DEBE admitir las CAR_INTENT_ACTION_MEDIA_TEMPLATE la acción de intent implícita con el CAR_EXTRA_MEDIA_PACKAGE adicionales.
• [3.14/A-0-4] DEBE proporcionar una indicación visual para navegar a de una aplicación multimedia preferencia actividad, pero DEBE habilitarlo solo cuando no estén vigentes las Restricciones para la UX del Vehículo.
• [3.14/A-0-5] SE DEBE mostrar mensajes de error establecido por las aplicaciones de medios, y DEBE admitir los servicios adicionales opcionales ERROR_RESOLUTION_ACTION_LABEL y ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] DEBE admitir una indicación visual de búsqueda en la app para y apps que permiten realizar búsquedas.
• [3.14/A-0-7] DEBE respetar CONTENT_STYLE_BROWSABLE_HINT y CONTENT_STYLE_PLAYABLE_HINT. al mostrar el objeto MediaBrowser en la nube.

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

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

Implementaciones en dispositivos de Automotive:

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

2.5.4. Rendimiento y potencia

Implementaciones en dispositivos de Automotive:

• [8.2/A-0-1] SE DEBE informar la cantidad de de bytes leídos y escritos en el almacenamiento no volátil por el UID de cada proceso, por lo que las estadísticas están disponibles para los desarrolladores a través de la API del sistema android.car.storagemonitoring.CarStorageMonitoringManager Abierto de Android El proyecto de origen cumple con los requisitos a través del módulo de kernel uid_sys_stats.
• [8.3/A-1-3] DEBE admitir el modo garaje.
• [8.3/A] SE DEBE estar en modo garaje durante al menos 15 minutos después de cada viaje, a menos que ocurra lo siguiente:
  • Se agotó la batería.
  • No se programaron trabajos inactivos.
  • El conductor sale del modo garaje.
• [8.4/A-0-1] DEBE proporcionar un perfil de energía por componente que define el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería causado con el paso del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
• [8.4/A-0-2] SE DEBE informar toda la energía de consumo en miliamperios-hora (mAh).
• [8.4/A-0-3] SE DEBE informar la potencia de la CPU. consumo por cada UID de proceso. El Proyecto de código abierto de Android cumple con los a través de la implementación del módulo de kernel uid_cputime.
• [8.4/A] SE DEBE atribuir a la el componente de hardware en sí, si no es posible atribuir el uso de energía de los componentes de hardware a una aplicación.
• [8.4/A-0-4] SE DEBE hacer que este uso de energía disponible a través de adb shell dumpsys batterystats de shell al desarrollador de la app.

2.5.5. Modelo de seguridad

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

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

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

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

Implementaciones en dispositivos de Automotive:

• [9/A-0-1] DEBE declarar android.hardware.security.model.compatible. .
• [9.11/A-0-1] SE DEBE crear una copia de seguridad de la implementación del almacén de claves. con un entorno de ejecución aislado.
• [9.11/A-0-2] DEBE tener implementaciones de RSA, AES, Algoritmos criptográficos de ECDSA y HMAC y familia MD5, SHA1 y SHA-2 hash para admitir correctamente las funciones en un área aislada de forma segura del código que se ejecuta kernel y versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos por qué código del espacio del usuario o kernel puede acceder al estado interno del entorno aislado, incluida la DMA. El código abierto de Android ascendente El Proyecto (AOSP) cumple este requisito por medio de la implementación de Trusty, pero Solución basada en ARM TrustZone o una versión segura revisada por terceros implementación de un aislamiento adecuado basado en un hipervisor son alternativas opciones de estado.
• [9.11/A-0-3] SE DEBE ejecutar la pantalla de bloqueo autenticación en el entorno de ejecución aislado y solo cuando correctamente, permite que se usen las claves vinculadas a la autenticación. Pantalla de bloqueo las credenciales DEBEN almacenarse de forma tal que solo se permita para realizar la autenticación con la pantalla de bloqueo. El servicio upstream de Android El Proyecto de código abierto brinda Capa de abstracción de hardware (HAL) del recepcionista y Trusty, que pueden usarse para cumplir con este requisito.
• [9.11/A-0-4] SE DEBE admitir la certificación de claves donde de certificación de Google Cloud está protegida con hardware seguro, y la firma se que se ejecuta en hardware seguro. Las claves de firma de certificación SE DEBEN compartir en una cantidad de dispositivos lo suficientemente grande para evitar que se usen las claves como identificadores de dispositivos. Una forma de cumplir con este requisito es compartir el misma clave de certificación, salvo que se envíen al menos 100,000 unidades de un SKU determinado producidos. Si se producen más de 100,000 unidades de un SKU, se puede usar una PUEDE usarse para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se lanzó en una versión anterior de Android versión, este dispositivo está exento del requisito de tener un almacén de claves. está respaldado por un entorno de ejecución aislado y admite la certificación de claves. a menos que declare la función android.hardware.fingerprint que requiera un de código abierto respaldado por un entorno de ejecución aislado.

Implementaciones en dispositivos de Automotive:

• [9.14/A-0-1] DEBEN mensajes de guardia de subsistemas del vehículo del framework de Android, p.ej., mensajes permitidos tipos y fuentes de mensajes.
• [9.14/A-0-2] DEBE guardián contra ataques de denegación del servicio del framework de Android o de apps de terceros. Esta brinda protección contra software malicioso que inunda de tráfico la red del vehículo lo que podría provocar fallas en los subsistemas de los vehículos.

2.5.6. Compatibilidad de las Herramientas y opciones para desarrolladores

Implementaciones en dispositivos de Automotive:

• Perfetto
  • [6.1/A-0-1] DEBE exponer un /system/bin/perfetto. binario al usuario de shell y cmdline cumple la documentación de perfetto.
  • [6.1/A-0-2] El objeto binario de perfetto DEBE aceptar como ingresar una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/A-0-3] El objeto binario de perfetto DEBE escribir como genera un seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [6.1/A-0-4] SE DEBE proporcionar a través del perfetto. binario, al menos las fuentes de datos descritas en la documentación de perfetto.

2.6. Requisitos de las tabletas

Una tablet Android hace referencia a una implementación de dispositivo Android que normalmente cumple todos los siguientes criterios:

• Se usa con ambas manos.
• No tiene una configuración convertible ni convencional.
• Implementaciones de teclado físico que se usan con el dispositivo conectado por se realiza a través de una conexión estándar (por ejemplo, USB, Bluetooth).

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

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

Las implementaciones en dispositivos tablet tienen requisitos similares a los de dispositivos de mano de Google Cloud. Las excepciones se indican con un * en esa sección. y se mencionan a modo de referencia en esta sección.

2.6.1. Hardware

Giroscopio

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

• [7.3.4/Tab-1-1] SE DEBE poder medir la orientación. cambia hasta 1,000 grados por segundo.

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

Las densidades de pantalla indicadas para pantallas pequeñas/normales del dispositivo portátil requisitos no se aplican a las tabletas.

Modo periférico USB (sección 7.7.1)

Si las implementaciones en tablets incluyen un puerto USB compatible con periféricos , ellos:

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

Modo de realidad virtual (sección 7.9.1)

Realidad virtual con alto rendimiento (Artículo 7.9.2)

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

2.6.2. Modelo de seguridad

Claves y credenciales (Sección 9.11)

Consulta la sección [9.11].

Si las implementaciones en dispositivos Tablet incluyen varios usuarios y No declaras la marca de función android.hardware.telephony:

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

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

• [9.5/T-2-1] NO DEBE admitir restricciones restringidas perfiles, pero DEBEN alinearse con la implementación de controles del AOSP para permitir o impedir que otros usuarios accedan a las llamadas de voz y a los SMS.

2.6.2. Software

• [3.2.3.1/Tab-0-1] SE DEBE precargar uno. o más aplicaciones o componentes de servicio con un controlador de intents, para todas las patrones de filtro de intents públicos definidos por los siguientes intents de aplicación que se indican aquí.

3. Software

3.1. Compatibilidad con APIs administradas

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

Implementaciones en dispositivos:

• [C-0-1] DEBE proporcionar implementaciones completas, incluidas todas las de cualquier API documentada expuesta por el SDK de Android o cualquier API decorada con el marcador "@SystemApi" en la versión ascendente de Android código fuente.

• [C-0-2] DEBE admitir o preservar todas las clases, los métodos y los elementos asociados marcados por la anotación TestApi (@TestApi).

• [C-0-3] NO DEBE omitir ninguna API administrada, alterar las interfaces o firmas de las API, desviarse del comportamiento documentado o incluir no-ops, excepto cuando permitidos específicamente por esta definición de compatibilidad.

• [C-0-4] DEBE mantener las APIs presentes y comportarse. de manera razonable, incluso cuando algunas funciones de hardware para “incluye APIs” se omiten. Consulte la sección 7. para requisitos específicos de esta situación.

• [C-0-5] NO DEBE permitir que apps de terceros usen interfaces que no pertenezcan al SDK, lo que se definen como métodos y campos en los paquetes de lenguaje Java que se en la ruta de clase de inicio en AOSP y que no forman parte de la red de Google Cloud. Esto incluye las APIs decoradas con la anotación @hide, pero no con Un @SystemAPI, como se describe en los documentos del SDK y miembros de clases private y package-private.

• [C-0-6] SE DEBE enviar con todas y cada una de las interfaces que no pertenecen al SDK en la misma proporcionadas por las marcas provisionales y de listas de bloqueo en prebuilts/runtime/appcompat/hiddenapi-flags.csv para la rama del nivel de API correspondiente en el AOSP.

• [C-0-7] DEBE admitir la configuración firmada. Mecanismo de actualización dinámica para quitar interfaces que no pertenecen al SDK de una lista restringida. a través de la incorporación de la configuración firmada en cualquier APK con las claves públicas existentes presentes en el AOSP.

  Sin embargo, lograron lo siguiente:

  • PUEDE, si falta una API oculta o se implementa de otra manera en el dispositivo mover la API oculta a la lista de bloqueo u omitirla del todas las listas restringidas.
  • MAYOR, si una API oculta aún no existe en el AOSP, agrega la API oculta API a cualquiera de las listas restringidas.

3.1.1. Extensiones de Android

Android admite la extensión de la superficie de API administrada de un nivel de API en particular actualizando la versión de la extensión para ese nivel de API. El La API de android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) muestra el versión de la extensión del apiLevel proporcionado, si hay extensiones para él Nivel de API.

Implementaciones en dispositivos Android:

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

• [C-0-2] Solo DEBE devolver un número de versión de extensión válido que se definidas por el AOSP.

• [C-0-3] DEBE admitir todas las APIs definidas por las versiones de extensión devuelto por android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la misma manera que se admiten otras APIs administradas, según las requisitos en la sección 3.1.

3.1.2. Biblioteca de Android

Debido a la baja del cliente HTTP de Apache, implementaciones en dispositivos:

• [C-0-1] NO DEBE colocar la biblioteca de org.apache.http.legacy en el bootclasspath.
• [C-0-2] SE DEBE agregar la biblioteca org.apache.http.legacy a la aplicación. la ruta de clase solo cuando la app cumple con una de las siguientes condiciones:
  • Se orienta al nivel de API 28 o versiones anteriores.
  • Declara en su manifiesto que necesita la biblioteca estableciendo la Atributo android:name de <uses-library> a org.apache.http.legacy.

La implementación de AOSP cumple con estos requisitos.

3.2. Compatibilidad con la API de Soft

Además de las APIs administradas de la sección 3.1, Android también incluye una API “secundaria” significativa solo de tiempo de ejecución, en la forma de las intenciones, los permisos y aspectos similares de las aplicaciones para Android que no se puede aplicar durante el tiempo de compilación de la aplicación.

3.2.1. Permisos

• [C-0-1] Los implementadores de dispositivos DEBEN admitir y aplicar todos los permisos constantes, según lo documentado en la página de referencia de permisos. Ten en cuenta que en la sección 9 se enumeran los requisitos relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de compilación

Las Android API incluyen una serie de constantes en la Clase android.os.Build que están diseñados para describir el dispositivo actual.

• [C-0-1] Para proporcionar valores coherentes y significativos en todo el dispositivo de aplicaciones, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores, las implementaciones del dispositivo DEBEN cumplir.

Parámetro	Detalles
VERSION.LANZAMIENTO	Es la versión del sistema Android en ejecución actualmente, en formato legible por humanos. de un conjunto de datos tengan un formato común. Este campo DEBE tener uno de los valores de cadena definidos en Strings de versión permitidas para Android 14.
VERSION.SDK	Es la versión del sistema Android en ejecución actualmente, en un formato. accesible para el código de apps de terceros. En Android 14, este campo DEBE tener el valor entero 14_INT.
VERSION.SDK_INT	Es la versión del sistema Android en ejecución actualmente, en un formato. accesible para el código de apps de terceros. En Android 14, este campo DEBE tener el valor entero 14_INT.
VERSION.INCREMENTAL	Un valor elegido por el implementador de dispositivos que designa la compilación específica del sistema Android en ejecución en un formato legible por humanos. Esta NO DEBE volver a usarse en las diferentes compilaciones que se ponen a disposición de los usuarios finales. R se suele utilizar para indicar qué número de compilación o Se usó el identificador de cambio de control de fuente para generar la compilación. El valor de este campo SE DEBE codificar como ASCII imprimible de 7 bits y debe coincidir con expresión regular “^[^ :\/~]+$”.
JUEGOS DE MESA	Es un valor elegido por el implementador de dispositivos que identifica la el hardware interno que usa el dispositivo, en un formato legible por humanos Una posible este campo es para indicar la revisión específica de la alimentación de la placa el dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincide con la expresión regular “^[a-zA-Z0-9_-]+$”.
SEGURIDAD	Un valor que refleja el nombre de la marca asociada con el dispositivo, como se indica en los usuarios finales. DEBE tener un formato legible por humanos y DEBERÍA representar fabricante del dispositivo o la marca de la empresa bajo la cual se encuentra comercializados. El valor de este campo SE DEBE codificar como ASCII de 7 bits y debe coincidir la expresión regular “^[a-zA-Z0-9_-]+$”.
ABIS_COMPATIBLES	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del formato nativo código. Consulta la sección 3.3. API nativa Compatibilidad.
ABIS_COMPATIBLES_32_BIT	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del formato nativo código. Consulta la sección 3.3. API nativa Compatibilidad.
ABIS_COMPATIBLES_64_BIT	El nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) de código nativo. Consulta la sección 3.3. Nativo Compatibilidad de la API.
ABI_de_CPU	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del formato nativo código. Consulta la sección 3.3. API nativa Compatibilidad.
ABI2 de CPU	El nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) de código nativo. Consulta la sección 3.3. Nativo Compatibilidad de la API.
DISPOSITIVO	Un valor elegido por el implementador de dispositivos que contiene el nombre de desarrollo o nombre interno que identifica la configuración de las funciones de hardware y diseño industrial del dispositivo. El valor de este campo DEBE ser codificable. como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9_-]+$". El nombre de este dispositivo NO DEBE cambiar durante el el ciclo de vida del producto.
IMPRESIÓN DE DEDOS	Es una cadena que identifica esta compilación de forma única. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por ejemplo: acme/miproducto/ midispositivo:14/LMYXX/3359:userdebug/test-keys La huella digital NO DEBE incluir caracteres de espacio en blanco. El valor de este campo SE DEBE codificar como ASCII de 7 bits.
HARDWARE	Es el nombre del hardware (de la línea de comandos del kernel o /proc). Integra DEBE ser razonablemente legible por humanos. El valor de este campo DEBE ser se puede codificar como ASCII de 7 bits y coincide con la expresión regular "^[a-zA-Z0-9_-]+$".
ORGANIZADOR	Una cadena que identifica de forma exclusiva el host en el que se compiló la compilación, en en un formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
ID	Es un identificador elegido por el implementador de dispositivos para hacer referencia a un nombre específico en un formato legible por humanos. Este campo puede ser igual al android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor lo suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con el expresión “^[a-zA-Z0-9._-]+$”.
FABRICANTE	El nombre comercial del fabricante del equipo original (OEM) del producto. No hay requisitos para el formato específico de este campo excepto que NO DEBE ser nulo ni la cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
FABRICANTE_SOC	El nombre comercial del fabricante del sistema principal en (SOC) que se usa en el producto. Dispositivos con el mismo fabricante de SOC deberías usar el mismo valor constante. Solicite al fabricante del SOC la constante correcta que se debe usar. El valor de este campo DEBE ser codificable. como ASCII de 7 bits, DEBE coincidir con la expresión regular “^([0-9A-Za-z ]+)”, NO DEBE empezar ni terminar con un espacio en blanco, y NO DEBE ser igual a “desconocido”. Este campo NO DEBE cambiar durante el el ciclo de vida del producto.
SOC_MODEL	El nombre del modelo del sistema principal en un chip (SOC) que se usa en el producto. Los dispositivos con el mismo modelo SOC deben usar la misma constante valor. Solicita al fabricante del SOC la constante correcta que debes usar. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con el la expresión regular “^([0-9A-Za-z ._/+-]+)$”, NO DEBE comenzar o terminan con un espacio en blanco y NO DEBE ser igual a “desconocido”. Este campo NO DEBE cambiar durante la vida útil del producto.
MODELO.	Es un valor elegido por el implementador de dispositivos que contiene el nombre del elemento dispositivo, como lo conoce el usuario final. Debe ser el mismo nombre con el cual El dispositivo se comercializa y vende a usuarios finales. No hay requisitos en el formato específico de este campo, con la excepción de que NO DEBE ser nulo ni el string vacía (""). Este campo NO DEBE cambiar durante el el ciclo de vida del producto.
PRODUCTO	Un valor elegido por el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno del producto específico (SKU) que DEBE ser único misma marca. DEBE ser legible por humanos, pero no necesariamente está destinado a visualizarse por los usuarios finales. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincide con la expresión regular “^[a-zA-Z0-9_-]+$”. Este producto El nombre del producto NO DEBE cambiar durante la vida útil del producto.
SKU_ODM	Un valor opcional elegido por el implementador de dispositivos que contiene SKU (Stock Keeping Unit) que se usa para realizar un seguimiento de configuraciones específicas de la dispositivo, por ejemplo, cualquier periférico incluido con el dispositivo cuando se vende. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con el la expresión regular ^([0-9A-Za-z.,_-]+)$.
SERIE	SE DEBE mostrar "UNKNOWN".
ETIQUETAS	Una lista de etiquetas separadas por comas elegidas por el implementador de dispositivos que que distinga aún más la compilación. Las etiquetas DEBEN poder codificarse como ASCII de 7 bits y coincidan con la expresión regular “^[a-zA-Z0-9._-]+” y DEBE tienen uno de los valores correspondientes a los tres modelos de firma: claves de lanzamiento, claves de desarrollo y claves de prueba.
TIEMPO	Un valor que representa la marca de tiempo del momento en que se produjo la compilación.
TIPO	Un valor elegido por el implementador de dispositivos que especifica el entorno de ejecución configuración de la compilación. Este campo DEBE tener uno de los valores correspondiente a las tres configuraciones típicas de tiempo de ejecución de Android: usuario, userdebug o eng.
USUARIO	Un nombre o ID de usuario del usuario (o usuario automatizado) que generó el compilar. No hay requisitos para el formato específico de este campo excepto que NO DEBE ser nulo ni la cadena vacía ("").
PANTALLA_SEGURIDAD	Es un valor que indica el nivel de parche de seguridad de una compilación. DEBE significar que la compilación no sea de ninguna manera vulnerable a ninguno de los problemas descritos el Boletín de seguridad pública de Android designado. DEBE estar en el formato [AAAA-MM-DD], que coincida con una cadena definida documentada en el Seguridad pública de Android Boletín o en el Asesoramiento de seguridad de Android, por ejemplo, “2015-11-01”.
BASE_SO	Un valor que representa el parámetro FINGERPRINT de la compilación que se iguales a esta compilación, excepto por los parches proporcionados en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si esa compilación no existe, informa que hay una cadena vacía ("").
CARGADOR DE ARRANQUE	Es un valor elegido por el implementador de dispositivos que identifica la versión interna del bootloader que se usó en el dispositivo, en un formato legible por humanos El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con el expresión regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion(),	DEBE (ser o mostrar) un valor elegido por el implementador de dispositivos. identificar la versión interna específica de la radio/módem que se usó en el dispositivo en un formato legible por humanos. Si un dispositivo no tiene radio/módem, DEBE mostrar NULL. El valor de este campo DEBE ser se puede codificar como ASCII de 7 bits y coincide con la expresión regular "^[a-zA-Z0-9._-,]+$".
getSerial().	DEBE (ser o devolver) un número de serie de hardware, que DEBE estar disponible. y única en todos los dispositivos, con el mismo MODELO y FABRICANTE. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9]+$".

3.2.3. Compatibilidad con intents

3.2.3.1. Intents de aplicaciones comunes

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

Implementaciones en dispositivos:

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

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

3.2.3.2. Resolución de intents

• [C-0-1] Como Android es una plataforma extensible, las implementaciones en dispositivos DEBEN Permitir cada patrón de intent al que se hace referencia en la sección 3.2.3.1 , excepto Configuración, para que la anulen las aplicaciones de terceros. El La implementación ascendente de código abierto de Android lo permite de forma predeterminada.

• [C-0-2] Los implementadores de dispositivos NO DEBEN adjuntar privilegios especiales al sistema aplicaciones' el uso de estos patrones de intenciones o impedir que las aplicaciones de terceros de vincularse a estos patrones y asumir el control de ellos. Esta prohibición incluye, entre otros, la inhabilitación del usuario "Selector". que permite al usuario seleccionar entre varias aplicaciones que todas manejar el mismo patrón de intents.

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

• Sin embargo, PODRÍAN proporcionar actividades predeterminadas en las implementaciones en los dispositivos para actividades Patrones de URI (p.ej., http://play.google.com) cuando la actividad predeterminada proporcione una un atributo más específico para el URI de datos. Por ejemplo, un patrón de filtro de intents especificar el URI de datos "http://www.android.com" es más específico que el patrón de intent principal del navegador para “http://”.

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

• [C-0-4] DEBE intentar validar cualquier filtro de intents realizando la pasos de validación que se definen en la especificación de Vínculos de recursos digitales implementada por el Administrador de paquetes en la canalización de código abierto de Android Proyecto.
• [C-0-5] SE DEBE intentar la validación de los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de URI validados correctamente como controladores de app predeterminados para sus URI.
• PUEDE establecer filtros de intents de URI específicos como controladores predeterminados de la app para sus URI, si se verifican correctamente, pero fallan otros filtros de URI candidatos verificación. Si una implementación de dispositivo hace esto, DEBE proporcionar la anulaciones de patrones por URI apropiadas para el usuario en el menú de configuración.
• DEBE proporcionarle al usuario controles de App Links por app en Configuración, como sigue:
  • [C-0-6] El usuario DEBE poder anular de manera integral la app predeterminada el comportamiento de los vínculos para una app: abrir siempre, preguntar siempre o no abrir nunca, que debe aplicarse a todos los filtros de intents de URI candidatos por igual.
  • [C-0-7] El usuario DEBE poder ver una lista del intent de URI candidato filtros.
  • La implementación del dispositivo PUEDE brindar al usuario la capacidad de realizar lo siguiente: anular filtros de intents de URI candidatos específicos que se hayan verificado, por filtro de intent.
  • [C-0-8] La implementación del dispositivo DEBE brindar a los usuarios la capacidad de realizar lo siguiente: ver y anular filtros de intents de URI candidatos específicos si el dispositivo La implementación permite que algunos filtros de intents de URI candidatos tengan éxito. la verificación mientras que otras pueden fallar.

3.2.3.3 Espacios de nombres de intents

• [C-0-1] Las implementaciones en dispositivos NO DEBEN incluir ningún componente de Android que respeta cualquier intent nuevo o patrón de intent de transmisión con una acción ACTION, CATEGORY otra cadena de clave en el espacio de nombres android.* o com.android.*.
• [C-0-2] Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respetan cualquier intent nuevo o patrón de intent de transmisión con una acción ACTION, CATEGORY o una cadena de clave en un espacio de paquete que pertenece a otra organización.
• [C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni extender ninguna de las intenciones patrones enumerados en la sección 3.2.3.1.
• Las implementaciones en dispositivos PUEDEN incluir patrones de intent usando espacios de nombres de forma clara y se asocian con su propia organización. Esta prohibición es análogo al especificado para las clases de lenguaje Java en la sección 3.6.

3.2.3.4. Intents de transmisión

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

Implementaciones en dispositivos:

• [C-0-1] DEBE transmitir los intents de transmisión pública que se indican aquí. en respuesta a los eventos del sistema adecuados, como se describe en la documentación del SDK. Ten en cuenta que este requisito no entra en conflicto con el artículo 3.5, ya que de las aplicaciones en segundo plano también se describen en el SDK en la documentación de Google Cloud. Algunos intents de transmisión son condicionales del hardware soporte, si el dispositivo admite el hardware necesario, DEBE transmitir el y proporcionar el comportamiento alineado con la documentación del SDK.

3.2.3.5 Intents de aplicaciones condicionales

Android incluye parámetros de configuración que les permiten a los usuarios seleccionar fácilmente aplicaciones predeterminadas, como la pantalla principal o los SMS.

Cuando sea conveniente, las implementaciones en dispositivos DEBEN proporcionar una configuración similar y deben ser compatibles con el patrón de filtro de intents y los métodos de la API descritos en la documentación del SDK, como se muestra a continuación.

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

• [C-1-1] DEBE respetar el android.settings.HOME_SETTINGS. para mostrar un menú de configuración predeterminada de la app para la pantalla principal.

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

• [C-2-1] DEBE ofrecer un menú de configuración que llame al android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar un cuadro de diálogo que cambie la aplicación de SMS predeterminada.

• [C-2-2] DEBE respetar el android.telecom.action.CHANGE_DEFAULT_DIALER. intent de mostrar un diálogo que permita al usuario cambiar la configuración predeterminada de Phone y mantener la integridad de su aplicación.

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

• [C-2-3] DEBE respetar la android.telecom.action.CHANGE_PHONE_ACCOUNTS. para proporcionar la indicación visual del usuario para configurar ConnectionServices asociado con el PhoneAccounts, como así como una PhoneAccount predeterminada que el proveedor de servicios de telecomunicaciones usar para realizar llamadas salientes. La implementación del AOSP cumple con este requisito, ya que incluida la "opción de llamadas telefónicas", dentro de la sección "Llamadas" desde el menú de configuración.

• [C-2-4] DEBE permitir android.telecom.CallRedirectionService para una app que contiene android.app.role.CALL_REDIRECTION en el área de la seguridad en la nube.

• [C-2-5] DEBE proporcionar al usuario la posibilidad de elegir una app que tenga las android.app.role.CALL_REDIRECTION en el área de la seguridad en la nube.

• [C-2-6] DEBE respetar el error android.intent.action.SENDTO y android.intent.action.VIEW y proporcionan una actividad para enviar o mostrar mensajes SMS.

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE respetar android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL con una aplicación de marcador precargada que puede controlar estos intents y proporcionar entregas como se describe en el SDK.

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

• [C-3-1] DEBE respetar el error android.settings.NFC_PAYMENT_CONFIGURACIÓN para mostrar un menú de configuración predeterminada de la app para el pago sin contacto.
• [C-3-2] DEBE respetar android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT. mostrar una actividad que abre un diálogo para solicitarle al usuario que cambie la servicio de emulación de tarjetas predeterminado para una categoría determinada, como se describe en el SDK.

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

• [C-4-1] DEBE respetar estos intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, para mostrar una actividad que cumpla con las expectativas del desarrollador en relación con estos intents como que se describe en el SDK.

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

• [C-5-1] DEBE respetar el error ‘android.bluetooth.adapter.action.REQUEST_ENABLE’. y mostrará una actividad del sistema para permitir que el usuario active el Bluetooth.
• [C-5-2] DEBE respetar el “android.bluetooth.adapter.action.REQUEST_DISCOVERABLE” y muestran una actividad del sistema que solicita el modo detectable.

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

• [C-6-1] DEBE implementar una actividad que responda al intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, que, para las implementaciones con UI_MODE_TYPE_NORMAL, DEBE ser una actividad en la que el usuario puede otorgar o denegar a la app el acceso a configuraciones de políticas de DND.

Si las implementaciones en dispositivos permiten que los usuarios utilicen métodos de entrada de terceros en el el dispositivo móvil, hace lo siguiente:

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

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, sucederá lo siguiente:

• [C-8-1] DEBE respetar el android.settings.ACCESSIBILITY_SETTINGS. proporcionar un mecanismo al que el usuario pueda acceder para habilitar e inhabilitar la servicios de accesibilidad de terceros junto con la configuración de Google Cloud.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Easy Connect, de Google Cloud a apps de terceros, hacen lo siguiente:

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

Si las implementaciones de dispositivos proporcionan el modo de Ahorro de datos, sucederá lo siguiente:

• [C-10-1] DEBE incluir una interfaz de usuario en la configuración que controle las Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS , permitir que los usuarios agreguen o quiten aplicaciones de la lista de permitidos.

Si las implementaciones de dispositivos no proporcionan el modo de Ahorro de datos, sucederá lo siguiente:

• [C-11-1] DEBE tener una actividad que controle las Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS pero PUEDE implementarlo como una no-op.

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

• [C-12-3] DEBE controlar y solo permitir aplicaciones para Android preinstaladas. para manejar los siguientes intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, y MediaStore.ACTION_VIDEO_CAPTURE como se describe en el documento SDK.

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

• [C-13-1] DEBE respetar el intent android.app.action.ADD_DEVICE_ADMIN para invocar una IU para que el usuario agregue el administrador de dispositivos en el sistema (o permitirles que lo rechacen).

• [C-13-2] DEBE respetar los intents. android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION y tener una actividad para proporcionar entregas a esos intents, como se describe en el SDK aquí.

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

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

Si las implementaciones en dispositivos incluyen una app preinstalada o quieres permitir para acceder a las estadísticas de uso:

• [C-SR-2] SE RECOMIENDEN ENERGMENTE proporcionar un mecanismo accesible para el usuario para otorgar o revocar el acceso a las estadísticas de uso en respuesta al android.settings.ACTION_USAGE_ACCESS_CONFIGURACIÓN intent para apps que declaran el android.permission.PACKAGE_USAGE_STATS permiso.

Si las implementaciones en dispositivos no permiten el uso de alguna app, incluidas las apps instaladas de usar las apps, desde el acceso a las estadísticas de uso, hacen lo siguiente:

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

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

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

Si las implementaciones de dispositivos admiten VoiceInteractionService y tienen más en más de una aplicación que use esta API instalada a la vez:

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

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

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

Android admite los protectores de pantalla interactivos, a los que se hace referencia anteriormente. como Sueños. Los protectores de pantalla permiten a los usuarios interactuar con aplicaciones cuando un dispositivo conectado a una fuente de alimentación esté inactivo o en la estación de carga para escritorio. Implementaciones en dispositivos:

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

3.2.4. Actividades en pantallas secundarias o múltiples

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

• [C-1-1] DEBE establecer la android.software.activities_on_secondary_displays. marca de función.
• [C-1-2] DEBE garantizar la compatibilidad de la API similar a una actividad que se ejecuta en la pantalla principal.
• [C-1-3] DEBE colocar la actividad nueva en la misma pantalla que la actividad que que lo lanzó, cuando la nueva actividad se lanza sin especificar un objetivo mostrar mediante ActivityOptions.setLaunchDisplayId() API de gcloud.
• [C-1-4] DEBE destruir todas las actividades cuando una pantalla con el Display.FLAG_PRIVATE se quita la marca de verificación.
• [C-1-5] SE DEBE ocultar de manera segura el contenido en todas las pantallas cuando el dispositivo está bloqueado. con una pantalla de bloqueo segura, a menos que la app acepte aparecer en la parte superior del bloqueo pantalla con Activity#setShowWhenLocked() API de gcloud.
• DEBERÍA tener android.content.res.Configuration que corresponde a esa visualización para ser mostrada, operar correctamente y mantener la compatibilidad si se inicia una actividad en pantalla secundaria.

Si las implementaciones en el dispositivo permiten iniciar actividades de Android normales en una y una secundaria tiene el campo android.view.Display.FLAG_PRIVATE. marca:

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

3.3. Compatibilidad con APIs nativas

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

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

3.3.1. Interfaces binarias de la aplicación

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

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con una o más ABI del NDK de Android definidas.
• [C-0-2] DEBE incluir compatibilidad con el código que se ejecuta en el entorno administrado para llamar a código nativo mediante la interfaz nativa de Java (JNI) estándar semántica.
• [C-0-3] DEBE ser compatible con la fuente (es decir, con el encabezado) y compatible con objetos binarios (para la ABI) con cada biblioteca obligatoria de la lista a continuación.
• [C-0-5] SE DEBE informar con precisión la interfaz binaria de la aplicación nativa (ABI) compatibles con el dispositivo, a través del android.os.Build.SUPPORTED_ABIS android.os.Build.SUPPORTED_32_BIT_ABIS y Parámetros android.os.Build.SUPPORTED_64_BIT_ABIS, cada uno separado por comas de ABI ordenadas de la más a la menos preferida.

• [C-0-6] SE DEBE informar, a través de los parámetros anteriores, un subconjunto de los siguientes de ABI y NO DEBE informar ninguna ABI que no esté en la lista.

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

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

  • libaaudio.so (compatibilidad con audio nativo de AAudio)
  • libamidi.so (compatibilidad con MIDI nativo, si la función es android.software.midi se reclama según se describe en el Artículo 5.9)
  • libandroid.so (compatibilidad con actividades nativas de Android)
  • libc (biblioteca C)
  • libcamera2ndk.so
  • libdl (vinculador dinámico)
  • libEGL.so (administración de superficie nativa de OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (registro de Android)
  • libmediandk.so (compatibilidad con APIs de medios nativos)
  • libm (biblioteca de matemáticas)
  • libneuralnetworks.so (API de redes neuronales)
  • libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
  • libOpenSLES.so (compatibilidad con audio de OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (compatibilidad mínima con C++)
  • libvulkan.so (Vulkan)
  • libz (compresión Zlib)
  • Interfaz JNI

• [C-0-8] NO DEBE agregar ni quitar las funciones públicas para las bibliotecas nativas. que se mencionaron anteriormente.

• [C-0-9] DEBE enumerar otras bibliotecas que no sean del AOSP expuestas directamente a apps de terceros en /vendor/etc/public.libraries.txt.

• [C-0-10] NO DEBE exponer ninguna otra biblioteca nativa, ya sea implementada e proporcionados en AOSP como bibliotecas del sistema a apps de terceros orientadas a la API nivel 24 o superior, ya que están reservados.

• [C-0-11] SE DEBE exportar todo el OpenGL ES 3.1 y el paquete de extensión de Android símbolos de función, como se define en el NDK, mediante la biblioteca libGLESv3.so. Tenga en cuenta que, si bien todos los símbolos DEBEN estar presentes, en la sección 7.1.4.1 se describe en más detalle los requisitos para cuando se complete la implementación las funciones correspondientes.

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

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

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

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

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

• [C-3-1] también DEBE admitir armeabi-v7a e informar su compatibilidad, como armeabi es solo para retrocompatibilidad con apps anteriores.

Si las implementaciones de dispositivos informan la compatibilidad de la ABI armeabi-v7a, en el caso de las apps con esta ABI:

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

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

• [C-2-2] Siempre DEBE mantener disponibles las siguientes operaciones, aun en el caso en el que la ABI se implemente en una arquitectura ARMv8, ya sea a través de compatibilidad con CPU nativa o a través de emulación de software:

  • Instrucciones SWP y SWPB
  • operaciones de barrera CP15ISB, CP15DSB y CP15DMB.

• [C-2-3] DEBE incluir compatibilidad con SIMD avanzada. (también conocida como NEON).

3.4. Compatibilidad con la Web

3.4.1. Compatibilidad con WebView

Si las implementaciones en dispositivos proporcionan una implementación completa del android.webkit.Webview, hace lo siguiente:

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

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

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

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

• El componente WebView DEBE incluir compatibilidad con tantas funciones HTML5 como y, si admite la función, DEBE cumplir con las Especificación de HTML5.

• [C-1-4] SE DEBE renderizar el contenido proporcionado o el contenido de la URL remota en un proceso que es diferente de la aplicación que crea una instancia de WebView. Específicamente, el proceso separado del renderizador DEBE tener un privilegio inferior, se como un ID de usuario independiente, no tienes acceso al directorio de datos de la app no tienen acceso directo a la red y solo tienen acceso del sistema a través de Binder. La implementación de WebView del AOSP cumple este requisito.

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

3.4.2. Compatibilidad del navegador

Si las implementaciones en dispositivos incluyen una aplicación de navegador independiente de uso general la navegación web:

• [C-1-1] DEBE admitir cada una de estas APIs asociadas con HTML5:
  • la caché de la aplicación/operación sin conexión
  • <Video> etiqueta
  • ubicación geográfica
• [C-1-2] DEBE ser compatible con HTML5/W3C. API de webstorage y SE DEBEN admitir las solicitudes API de IndexedDB. Ten en cuenta que, como la Web los organismos de estándares de desarrollo están haciendo una transición para favorecer a IndexedDB por sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio en un y futura de Android.
• PUEDE enviar una cadena de usuario-agente personalizada a la aplicación independiente del navegador.
• SE RECOMIENDA implementar la asistencia para HTML5 tanto como sea posible en la plataforma Aplicación de navegador (ya sea que se base en el navegador WebKit ascendente) una aplicación de prueba o un reemplazo de terceros).

Sin embargo, si las implementaciones en dispositivos no incluyen un navegador independiente de la aplicación, hacen lo siguiente:

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

3.5 Compatibilidad de comportamiento de las APIs

Implementaciones en dispositivos:

• [C-0-9] DEBE asegurarse de que se aplique la compatibilidad de comportamiento de la API para todos las apps instaladas, a menos que estén restringidas como se describe en Artículo 3.5.1.
• [C-0-10] NO DEBE implementar el enfoque de lista de entidades permitidas que garantiza que la API compatibilidad de comportamiento solo para apps seleccionadas por dispositivo implementadores.

Los comportamientos de cada uno de los tipos de API (administradas, de software, nativas y web) deben coherente con la implementación preferida del flujo de Proyecto de código abierto de Android Algunas áreas específicas de compatibilidad son los siguientes:

• [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent estándar.
• [C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etcétera)
• [C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
• Los dispositivos NO DEBEN alterar las limitaciones que se aplican a las aplicaciones en segundo plano. Más específicamente, para las aplicaciones en segundo plano:
  • [C-0-4] DEBEN dejar de ejecutar devoluciones de llamada registradas por el app para recibir resultados de GnssMeasurement y GnssNavigationMessage.
  • [C-0-5] DEBEN limitar la frecuencia de las actualizaciones que proporcionados a la aplicación a través de la LocationManager la clase de API WifiManager.startScan() .
  • [C-0-6] Si la aplicación está orientada al nivel de API 25 o superior, NO DEBEN permiten registrar receptores de emisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la app, a menos que la transmisión el intent requiere un elemento "signature" o "signatureOrSystem" protectionLevel permiso o están en la lista de exenciones.
  • [C-0-7] si la aplicación está orientada al nivel de API 25 o superior, DEBE detenerse. los servicios en segundo plano de la app, como si esta hubiera llamado servicios stopSelf() a menos que la app se ubique en una lista temporal de entidades permitidas para controlar tarea que es visible para el usuario.
  • [C-0-8] si la aplicación está orientada al nivel de API 25 o superior, DEBE libera los bloqueos de activación que contiene la app.
• [C-0-11] Los dispositivos DEBEN devolver los siguientes proveedores de seguridad como primero siete valores de array a partir de la Security.getProviders() en el orden especificado y con los nombres indicados (como los devuelve Provider.getName()) y las clases, a menos que la aplicación haya modificado la lista mediante insertProviderAt() o removeProvider(). Dispositivos PUEDE devolver proveedores adicionales después de la lista de proveedores especificada a continuación.
  1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider: sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCMétodo alternativo: android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC: com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

La lista anterior no es exhaustiva. Pruebas del Conjunto de pruebas de compatibilidad (CTS) partes significativas de la plataforma para la compatibilidad con el comportamiento, pero no todas. El implementador es responsable de garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android. Por este motivo, los implementadores de dispositivos SE DEBE usar el código fuente disponible a través del Proyecto de código abierto de Android donde en lugar de reimplementar partes significativas del sistema.

3.5.1. Restricción de aplicaciones

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

• [C-1-1] DEBE permitir que el usuario vea la lista de apps restringidas.
• [C-1-2] DEBE proporcionar al usuario la posibilidad de activar / desactivar todas estas opciones. restricciones propias de cada app.

• [C-1-3] No DEBEN aplicar automáticamente estas restricciones de propiedad sin evidencia de mal comportamiento en el estado del sistema, pero PUEDE aplicar las restricciones en las aplicaciones tras detectar un mal comportamiento del sistema, como bloqueos de activación sostenidos, servicios y otros criterios. El dispositivo PUEDE determinar los criterios implementadores, pero DEBE estar relacionada con el impacto de la app en el estado del sistema. Otra opción criterios que no están relacionados puramente con el estado del sistema, como la configuración la falta de popularidad en el mercado, NO DEBE utilizarse como criterio.

• [C-1-4] No DEBEN aplicar automáticamente estas restricciones de propiedad para las apps Cuando un usuario desactiva las restricciones de aplicaciones manualmente, y PUEDE sugerirle para aplicar estas restricciones de propiedad.

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

• [C-1-6] DEBE mostrar true para ActivityManager.isBackgroundRestricted(). para cualquier llamada a la API desde una app.

• [C-1-7] NO DEBE restringir la aplicación en primer plano superior que utiliza explícitamente del usuario.

• [C-1-8] DEBE suspender estas restricciones de propiedad en una aplicación siempre que se el usuario comienza a usar explícitamente la aplicación y la convierte en la que está en primer plano. y mantener la integridad de su aplicación.

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

  • Condiciones de activación para restricciones de propiedad.
  • Qué y cómo se puede restringir una app
  • Cómo se puede excluir una app de esas restricciones
  • Cómo una app puede solicitar una exención de restricciones de propiedad en caso de que admiten esta exención para las apps que el usuario puede instalar.

Si una app está preinstalada en el dispositivo y ninguna persona la usó explícitamente usuario durante más de 30 días, [C-1-3] [C-1-5] están exentos.

Si las implementaciones de dispositivos extienden las restricciones de apps implementadas en el AOSP, realiza lo siguiente:

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

3.5.2. Hibernación de aplicaciones

Si las implementaciones de dispositivos incluyen la hibernación de apps, que se incluye en el AOSP. extiende la función incluida en el AOSP, realiza lo siguiente:

• [C-1-1] DEBE cumplir con todos los requisitos de la sección 3.5.1, excepto por [C-1-6] y [C-1-3].
• [C-1-2] Solo DEBE aplicar la restricción en la app para un usuario cuando pruebas de que el usuario no ha usado la aplicación durante un período determinado. Esta se recomienda que la duración sea de un mes o más. El uso DEBE tener definidos por la interacción explícita del usuario a través del UsageStats#getLastTimeVisible() API o cualquier otra cosa que haga que una app salga del estado de detención forzada como vinculaciones de servicios, vinculaciones de proveedores de contenido, transmisiones explícitas, etcétera. que será rastreado por una nueva API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] Solo se DEBEN aplicar restricciones que afecten a todos los usuarios de dispositivos cuando sea evidencia de que NINGÚN usuario utilizó el paquete durante un período de tiempo. SE RECOMIENDA QUE esta duración sea de un mes o más.
• [C-1-4] NO DEBE hacer que la aplicación no pueda responder a intents de actividad. vinculaciones de servicios, solicitudes al proveedor de contenido o transmisiones explícitas.

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

3.6 Espacios de nombres de API

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

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

Es decir, ellos hacen lo siguiente:

• [C-0-1] NO DEBE modificar las APIs expuestas públicamente en la plataforma de Android. cambiando algún método o firma de clases, o quitando clases o .
• [C-0-2] NO DEBE agregar ningún elemento expuesto públicamente (como clases o interfaces, campos o métodos a clases o interfaces existentes) o Probar o las APIs del sistema a las APIs en los espacios de nombres anteriores. Una categoría "expuesta públicamente elemento" es cualquier construcción que no esté decorada con el elemento "@hide" marcar como que se usa en el código fuente upstream de Android.

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

• [C-0-3] NO DEBE afectar el comportamiento indicado ni la firma en lenguaje Java de las APIs expuestas públicamente.
• [C-0-4] NO DEBE anunciarse ni exponerse de ninguna otra manera a los desarrolladores.

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

• [C-0-5] NO DEBE estar en un espacio de nombres que pertenezca a otro o que haga referencia a otro. para que se adapten a las necesidades de tu organización. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs a la com.google.* o un espacio de nombres similar: solo Google puede hacerlo. De forma similar, Google NO DEBE agregar APIs a las aplicaciones los espacios de nombres.
• [C-0-6] SE DEBE empaquetar en una biblioteca compartida de Android para que solo las aplicaciones que los usan de forma explícita (a través del mecanismo <uses-library>) se por el aumento en el uso de memoria de esas APIs.

Los implementadores de dispositivos PUEDEN agregar APIs personalizadas en idiomas nativos, fuera del NDK pero las personalizadas:

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

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

Ten en cuenta que las restricciones anteriores corresponden a las convenciones estándar de asignación de nombres las APIs en el lenguaje de programación Java; esta sección simplemente apunta a reforzar esas convenciones y hacerlas vinculantes a través de la inclusión en este documento Definición.

3.7 Compatibilidad del entorno de ejecución

Implementaciones en dispositivos:

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

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

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

• SE RECOMIENDAN realizar pruebas de Fuzz con varios modos de ejecución arquitecturas de destino y destino para garantizar la estabilidad del tiempo de ejecución. Consulta JFuzz y DexFuzz en el sitio web del Proyecto de código abierto de Android.

Ten en cuenta que los valores de memoria que se especifican a continuación se consideran valores mínimos las implementaciones en dispositivos PUEDEN asignar más memoria por aplicación.

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

3.8. Compatibilidad con la interfaz de usuario

3.8.1. Selector (pantalla principal)

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

Si las implementaciones del dispositivo permiten que aplicaciones de terceros lo reemplacen en la pantalla principal:

• [C-1-1] SE DEBE declarar la función android.software.home_screen de la plataforma.
• [C-1-2] SE DEBE devolver el AdaptiveIconDrawable. cuando la aplicación de terceros usa la etiqueta <adaptive-icon> para proporcionar su ícono, y la PackageManager para recuperar íconos.

Si las implementaciones en dispositivos incluyen un selector predeterminado compatible con anuncios fijar combinaciones de teclas:

• [C-2-1] DEBE informar true de ShortcutManager.isRequestPinShortcutSupported()
• [C-2-2] DEBE tener indicación visual sobre el usuario antes de agregar un atajo solicitado. de las apps mediante ShortcutManager.requestPinShortcut() método de API.
• [C-2-3] DEBE admitir accesos directos fijos y combinaciones de teclas dinámicas y estáticas. que se documentan en la página Accesos directos a aplicaciones.

Por el contrario, si las implementaciones en dispositivos no admiten la fijación en la app de atajos:

• [C-3-1] DEBE informar false de ShortcutManager.isRequestPinShortcutSupported()

Si las implementaciones de dispositivos implementan un lanzador predeterminado que brinda acceso a combinaciones de teclas adicionales proporcionadas por apps de terceros a través de la Atajoso de la API de Google Ads, les permiten hacer lo siguiente:

• [C-4-1] DEBE admitir todas las funciones de accesos directos documentadas (p.ej., estáticas y atajos dinámicos y fijación de combinaciones de teclas) e implementar completamente las APIs de la ShortcutManager clase de API.

Si las implementaciones de dispositivos incluyen una app de selector predeterminada que muestra insignias para los iconos de las aplicaciones:

• [C-5-1] DEBE respetar las NotificationChannel.setShowBadge() método de API. En otras palabras, muestra una indicación visual asociada con el ícono de la app si la el valor se establece como true y no muestra ningún esquema de insignias de íconos de la app cuando todas de los canales de notificaciones de la app establecieron el valor como false.
• PUEDE anular las insignias del ícono de la app con su esquema de insignias propio cuando las aplicaciones de terceros indican la compatibilidad con el esquema de insignias propio con APIs propias, pero DEBERÍAS usar los recursos y valores que se proporcionan mediante las APIs de insignias de notificación que se describen en el SDK , como Notification.Builder.setNumber() y la Notification.Builder.setBadgeIconType() API de gcloud.

Si las implementaciones de dispositivos admiten monocromo , estos íconos:

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

3.8.2. Widgets

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

Si las implementaciones de dispositivos admiten widgets de apps de terceros, sucederán lo siguiente:

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

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

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

• PUEDE admitir widgets de apps en la pantalla de bloqueo.

Si las implementaciones de dispositivos admiten widgets de apps de terceros y anuncios en la app fijar combinaciones de teclas:

• [C-2-1] DEBE informar true de AppWidgetManager.html.isRequestPinAppWidgetSupported()
• [C-2-2] DEBE tener indicación visual sobre el usuario antes de agregar un atajo solicitado. de las apps mediante AppWidgetManager.requestPinAppWidget() método de API.

3.8.3. Notificaciones

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

3.8.3.1. Presentación de notificaciones

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

• [C-1-1] DEBE admitir notificaciones que usan funciones de hardware, como se describe en la documentación del SDK y, en la medida de lo posible, con la implementación del dispositivo hardware. Por ejemplo, si la implementación de un dispositivo incluye un vibrador, DEBE implementar correctamente las APIs de vibración. Si la implementación de un dispositivo no las APIs correspondientes DEBEN implementarse como modalidad no-ops. Este comportamiento es se detalla con más detalle en la sección 7.
• [C-1-2] DEBE renderizar correctamente todos los recursos (íconos, archivos de animación, etc.) proporcionados en las APIs o en la Guía de estilo de los íconos de la barra de estado/sistema aunque PODRÍAN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de código abierto de Android de referencia.
• [C-1-3] DEBE respetar e implementar correctamente los comportamientos descritos para las APIs para actualizar, quitar y agrupar notificaciones.
• [C-1-4] DEBE proporcionar el comportamiento completo de NotificationChannel. API documentada en el SDK.
• [C-1-5] DEBE brindar una indicación visual al usuario para bloquear y modificar un determinado de apps de terceros por canal y nivel de paquete de app.
• [C-1-6] También DEBE proporcionar una indicación visual del usuario para mostrar la notificación eliminada. canales.

• [C-1-7] DEBE renderizar correctamente todos los recursos (imágenes, calcomanías, íconos, etc.) proporcionado a través de Notification.MessagingStyle junto con el texto de la notificación, sin interacción adicional del usuario. Para ejemplo, DEBE mostrar todos los recursos, incluidos los íconos proporcionados a través de android.app.Persona en una conversación grupal que se establece a través de setGroupConversation.

• [C-SR-1] SE RECOMIENDA ENERGENTEmente para proporcionar una indicación visual para que el usuario controlar las notificaciones que se exponen a las aplicaciones a las que se les otorgó el Permiso de objeto de escucha de notificaciones. El nivel de detalle DEBE ser para que el usuario pueda controlar qué tipos de notificaciones son para cada objeto de escucha de notificaciones se conecta con este oyente. Los tipos DEBEN incluir "conversaciones", "alertas", "silencioso" e "importante en curso" notificaciones.

• [C-SR-2] Se RECOMIENDA ENERGMENTE proporcionar una indicación visual para que los usuarios especifiquen para excluir de notificar a cualquier objeto de escucha de notificaciones específico.

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

• DEBE admitir notificaciones enriquecidas.

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

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

• ES POSIBLE que solo administre la visibilidad y los horarios de las notificaciones de las apps de terceros a los usuarios de eventos notables para mitigar problemas de seguridad, como la distracción del conductor.

Android 11 presenta compatibilidad con notificaciones de conversaciones, que son Notificaciones que usan MessagingStyle y proporciona un ID de acceso directo de Personas publicado.

Implementaciones en dispositivos:

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

Si las implementaciones de dispositivos admiten conversation notifications y la aplicación proporciona los datos necesarios para bubbles, hizo lo siguiente:

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

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

• [C-2-1] DEBE usar los recursos exactos que proporcionados mediante Notification.Style La clase de API y sus subclases para los elementos de recursos presentados
• SE DEBE presentar todos y cada uno de los elementos del recurso (p.ej., ícono, título y texto de resumen) definidos en el archivo Notification.Style. Clase de API y subclases

Las notificaciones de atención son aquellas que se presentan al usuario a medida que ingresan, independientemente de la superficie en la que estén . Si las implementaciones de dispositivos admiten avisos notificaciones, les permite hacer lo siguiente:

• [C-3-1] SE DEBE usar la vista de notificaciones de atención y los recursos. como se describe en Notification.Builder La clase de API cuando se presentan notificaciones de atención.
• [C-3-2] DEBE mostrar las acciones proporcionadas a través de Notification.Builder.addAction() junto con el contenido de la notificación, sin interacción adicional del usuario como se describe en el SDK.

3.8.3.2. Servicio de escucha de notificaciones

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

Implementaciones en dispositivos:

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

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

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

3.8.3.3 No interrumpir (No interrumpir) / Modo de prioridad

Si las implementaciones en dispositivos admiten la función No interrumpir (también llamado Modo de prioridad), hacen lo siguiente:

• [C-1-1] DEBE, cuando la implementación del dispositivo haya brindado al usuario los medios necesarios para otorgar o denegar el acceso de apps de terceros a la configuración de la política de No interrumpir mostrar Reglas automáticas de No interrumpir que crean las aplicaciones junto con las reglas predefinidas y creadas por el usuario.
• [C-1-3] DEBE respetar el suppressedVisualEffects. valores pasados junto con el NotificationManager.Policy y si una aplicación estableció cualquiera de los parámetros SUPPRESSED_Effect_SCREEN_ON, DEBE indicar al usuario que los efectos visuales se suprimen en el menú de configuración de No interrumpir.

3.8.4. API de Assist

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

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

• [C-2-1] DEBE indicar claramente al usuario final cuando se comparte el contexto, una de las siguientes opciones:
  • Cada vez que la aplicación de asistencia accede al contexto, se muestra un ícono alrededor de los bordes de la pantalla que alcanza o supera la duración y el brillo de la implementación del Proyecto de código abierto de Android.
  • En el caso de la aplicación de asistencia preinstalada, proporcionar una indicación visual del usuario a más de dos navegaciones de distancia el menú de configuración predeterminado de la entrada de voz y de la app del Asistente y solo comparte el contexto cuando la aplicación de asistencia se invoca explícitamente por al usuario mediante una palabra clave o la entrada de una tecla de navegación de asistencia.
• [C-2-2] Interacción designada para iniciar la aplicación de asistencia como se describe en la sección 7.2.3 DEBE iniciar la aplicación de selección app de asistencia; en otras palabras, la app que implementa VoiceInteractionService o una actividad que controle el intent ACTION_ASSIST.

3.8.5. Alertas y avisos

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

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

• [C-1-1] DEBE proporcionar una indicación visual del usuario para bloquear una app para que no muestre una alerta. ventanas que usan TYPE_APPLICATION_OVERLAY de Google Cloud. La implementación del AOSP cumple con este requisito, ya que tiene controles en el panel de notificaciones.

• [C-1-2] DEBE respetar la API de avisos y mostrar avisos de las aplicaciones a los usuarios finales en algunos de manera visible.

3.8.6. Temas

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

Android incluye "Holo" y "Material" de la familia de temas como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si quieren hacer coincidir el Aspecto del tema Holo según lo que define el SDK de Android.

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

• [C-1-1] NO DEBE alterar ninguno de los atributos del tema Holo expuestos a aplicaciones.
• [C-1-2] SE DEBE admitir la familia de temas “Material” y NO DEBE alterar ninguno de los atributos del tema de Material o sus activos expuestos a las aplicaciones.

• [C-1-3] DEBE establecer la configuración “sans-serif” familia de fuentes en Roboto versión 2.x para los idiomas que admite Roboto u ofrecer una indicación visual para cambiar la fuente que se usa de "sans-serif" familia de fuentes a Roboto versión 2.x para los idiomas que admite Roboto.

• [C-1-4] DEBE generar paletas de tonos de color dinámicas como se especifica en el AOSP. documentación de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (consulta android.theme.customization.system_palette y android.theme.customization.theme_style).

• [C-1-5] DEBE generar paletas tonales de color dinámicas con estilos de temas de color. que se enumeran en el archivo Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentación (consulta android.theme.customization.theme_styles), es decir, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ y RAINBOW FRUIT_SALAD y MONOCHROMATIC.

  "Color de origen" se usan para generar paletas de tonos de color dinámicas cuando se envían con android.theme.customization.system_palette (como se documenta en Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

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

  • SE DEBE derivar del fondo de pantalla mediante com.android.systemui.monet.ColorScheme#getSeedColors, que proporciona múltiples colores de origen válidos para elegir uno.

  • SE DEBE usar el valor 0xFF1B6EF3 si ninguno de los colores proporcionados cumple el requisito de color de origen anterior.

Android también incluye una familia de temas "Predeterminado del dispositivo" como un conjunto de estilos definidos que pueden usar los desarrolladores de aplicaciones si desean adaptarse al aspecto de la tema del dispositivo, según lo define el implementador de dispositivos.

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

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

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

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

3.8.7. Fondos de pantalla animados

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

Se considera que el hardware es capaz de ejecutar fondos de pantalla animados de manera confiable si puede hacerlo. Todos los fondos de pantalla animados, sin limitaciones de funcionalidad, en un fotograma razonable sin efectos adversos en otras aplicaciones. Si las limitaciones en el el hardware hace que los fondos de pantalla o las aplicaciones fallen, fallen, consuman una potencia excesiva de CPU o batería, o a velocidades de fotogramas inaceptables bajas, se considera que el hardware no es capaz de ejecutar fondos de pantalla animados. Por ejemplo, algunas los fondos de pantalla animados pueden usar un contexto OpenGL 2.0 o 3.x para renderizar su contenido. El fondo animado no se ejecutará de manera confiable en un hardware que no admite varias Contextos de OpenGL porque puede entrar en conflicto el uso del fondo animado de un contexto de OpenGL con otras aplicaciones que también usan un contexto OpenGL.

• Implementaciones en dispositivos capaces de ejecutar fondos de pantalla animados de manera confiable, como se describe arriba SE DEBE implementar fondos de pantalla animados.

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

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

3.8.8. Cambio de actividad

El código fuente ascendente de Android incluye la pantalla de información general, una interfaz de usuario a nivel del sistema para cambiar de tarea y mostrar las que se accedieron recientemente actividades y tareas mediante una imagen en miniatura del gráfico de la cuando el usuario abandonó la aplicación por última vez.

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

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

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

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

3.8.9. Administración de entradas

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

Si las implementaciones en dispositivos permiten que los usuarios utilicen métodos de entrada de terceros en el el dispositivo móvil, hace lo siguiente:

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

3.8.10. Control multimedia de la pantalla de bloqueo

La API del cliente de control remoto es obsoleta a partir de Android 5.0 y se reemplazó por el Plantilla de notificación de medios que permite a las aplicaciones multimedia integrarse con los controles de reproducción que son que se muestra en la pantalla de bloqueo.

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

Consulta la sección 3.2.3.5 para obtener información sobre la configuración. para configurar protectores de pantalla.

3.8.12. Ubicación

Si las implementaciones de dispositivos incluyen un sensor de hardware (p.ej., GPS) capaz de de proporcionar las coordenadas de la ubicación,

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

3.8.13. Unicode y fuentes

Android admite los caracteres emoji que se definen en Unicode 10.0

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

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

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

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

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

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

• [C-2-1] DEBE renderizar el texto con una fuente compatible con Unicode de forma predeterminada. las fuentes que no son compatibles con Unicode NO DEBEN establecerse como fuente predeterminada, a menos que el usuario lo elige en el selector de idioma.
• [C-2-2] DEBE admitir una fuente Unicode y una que no sea compatible con Unicode si se si se admite una fuente que no es compatible con Unicode en el dispositivo. Sin Unicode fuente compatible NO DEBE quitar ni reemplazar la fuente Unicode.
• [C-2-3] DEBE renderizar el texto con una fuente que no sea compatible con Unicode SOLO SI una código de idioma con código de secuencia de comandos Qaag (por ejemplo, my-Qaag). No hay ningún otro idioma ISO ni código de región (ya sea asignados, no asignados o reservados) se pueden utilizar para hacer referencia a aquellos que no sean Unicode. compatible con Birmania. Los desarrolladores de apps y los autores de páginas web pueden especificar my-Qaag como el código de idioma designado, como lo haría para cualquier otro idioma.

3.8.14. Multiventana

Si las implementaciones de dispositivos tienen la capacidad de mostrar varias actividades en al mismo tiempo, hacen lo siguiente:

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

Si las implementaciones de dispositivos admiten modos multiventana, y la pantalla dividida. , ellos:

• [C-2-2] DEBE recortar la actividad anclada de una multiventana con pantalla dividida, pero SE DEBE mostrar parte del contenido si la app de Launcher es la ventana enfocada.
• [C-2-3] DEBE respetar el AndroidManifestLayout_minWidth declarado. y AndroidManifestLayout_minHeight de la aplicación de selector de terceros y no anular estos valores en el transcurso de mostrar parte del contenido de la actividad de la estación de carga.

Si las implementaciones de dispositivos admiten los modos multiventana y pantalla en pantalla modo multiventana, hacen lo siguiente:

• [C-3-1] DEBE iniciar actividades en el modo multiventana de pantalla en pantalla. cuando la app: * Se orienta al nivel de API 26 o versiones posteriores, y declara android:supportsPictureInPicture * Se orienta al nivel de API 25 o versiones anteriores, y declara android:resizeableActivity y android:supportsPictureInPicture.
• [C-3-2] DEBE exponer las acciones en su SystemUI como especificada por la actividad de PIP actual a través de setActions() API de gcloud.
• [C-3-3] DEBE admitir relaciones de aspecto superiores o iguales a 1:2.39 y menor o igual que 2.39:1, como se especifica en la actividad de PIP mediante el setAspectRatio() API de gcloud.
• [C-3-4] DEBE usar KeyEvent.KEYCODE_WINDOW para controlar la ventana de PIP; si el modo PIP no se implementa, la clave DEBE disponibles para la actividad en primer plano.
• [C-3-5] DEBE proporcionar una indicación visual del usuario para bloquear la visualización de una app en modo PIP; la implementación del AOSP cumple con este requisito, ya que tiene en el panel de notificaciones.

• [C-3-6] DEBE asignar el siguiente ancho y alto mínimos para la PIP cuando una aplicación no declara ningún valor para AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight:

  • Dispositivos con el Configuration.uiMode configurado con un valor distinto del UI_MODE_TYPE_TELEVISION DEBE asignar un ancho y una altura mínimos de 108 dp.
  • Dispositivos con el Configuration.uiMode configurado como UI_MODE_TYPE_TELEVISION SE DEBE asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.

3.8.15. Recorte de pantalla

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

Si las implementaciones de dispositivos incluyen cortes de pantalla, sucederá lo siguiente:

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

3.8.16. Controles de dispositivos

Android incluye ControlsProviderService y Control APIs para permitir que aplicaciones de terceros publiquen controles de dispositivos para agilizar el estado y acción de los usuarios.

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

3.8.17. Portapapeles

Implementaciones en dispositivos:

• [C-0-1] NO DEBE enviar datos del portapapeles a ningún componente, actividad, servicio o en cualquier conexión de red, sin la acción explícita del usuario (por ejemplo, presionar una en la superposición), excepto para los servicios mencionados en 9.8.6 Captura de Contenido y Búsqueda de Aplicaciones.

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

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

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

3.9 Administración del dispositivo

Android incluye funciones que permiten que las apps adaptadas a la seguridad realicen funciones de administración de dispositivos a nivel del sistema, como la aplicación forzosa de contraseñas o la eliminación remota de datos, a través del API de administración de dispositivos Android.

Si las implementaciones de dispositivos implementan la gama completa de administración de dispositivos definidas en la documentación del SDK de Android, hacen lo siguiente:

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

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

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

• [C-1-1] DEBE admitir la inscripción de un Cliente de política de dispositivo (DPC) como App del propietario del dispositivo como se describe a continuación:
  • Cuando la implementación del dispositivo tenga ni usuarios ni de los datos del usuario configurados, hace lo siguiente:
    • [C-1-5] SE DEBE inscribir la aplicación de DPC como la aplicación del propietario del dispositivo. o habilita la app de DPC para elegir convertirte en propietario del dispositivo o del perfil, si el dispositivo declara compatibilidad con las Comunicaciones de campo cercano (NFC) mediante la marca de función android.hardware.nfc y recibe un mensaje NFC que contiene un registro con un tipo de MIME MIME_TYPE_PROVISIONING_NFC
    • [C-1-8] DEBE enviar el ACTION_GET_PROVISIONING_MODE. después de que se active el aprovisionamiento La app de DPC puede elegir si convertirse en propietario del dispositivo o en un perfil Propietario, según los valores de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, a menos que se pueda determinar a partir de contexto que solo hay una opción válida.
    • [C-1-9] DEBE enviar el ACTION_ADMIN_POLICY_COMPLIANCE intent en la app del propietario del dispositivo si se establece uno durante el aprovisionamiento, independientemente del método de aprovisionamiento que se use. El usuario no debe poder continuar en el asistente de configuración hasta que Finaliza la app del propietario del dispositivo.
  • Cuando la implementación del dispositivo tenga usuarios o usuarios los datos del usuario:
    • [C-1-7] No se DEBE inscribir ninguna aplicación de DPC como la aplicación del propietario del dispositivo. ya no.

• [C-1-2] DEBE mostrar un aviso de divulgación adecuado. (como como se indica en el AOSP) y obtener el consentimiento afirmativo del usuario final antes de iniciar una app. se está estableciendo como propietario del dispositivo, a menos que el dispositivo esté configurado de forma programática para el modo de demo para punto de venta antes de la interacción en pantalla con el usuario final. Si las implementaciones de dispositivos declaran android.software.device_admin, pero también incluyen una versión patentada de administración de dispositivos y proporcionan un mecanismo para promocionar una aplicación configurada en su solución como "Propietario del dispositivo" equivalente" con la opción estándar “Propietario del dispositivo” según lo reconoce el sistema estándar de Android DevicePolicyManager APIs, les permiten hacer lo siguiente:

• [C-2-1] DEBE tener un proceso para verificar que la aplicación específica promocionado pertenece a una cuenta legítima de administración y se configuró en la solución patentada tengan el equivalente de derechos como "Propietario del dispositivo".

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

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

3.9.1.2 Aprovisionamiento de perfiles administrados

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

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

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

• [C-1-3] DEBE proporcionar las siguientes condiciones de usuario en la Configuración para le indican al usuario cuándo una función específica del sistema ha sido inhabilitada por el controlador de política de dispositivo (DPC):

  • Un ícono coherente u otra indicación visual del usuario (por ejemplo, el ícono de información del AOSP) para representar cuándo un parámetro de configuración en particular está restringido por un Administrador de dispositivos.
  • Un mensaje de explicación breve proporcionado por el Administrador del dispositivo a través del setShortSupportMessage
  • Ícono de la aplicación de DPC

• [C-1-4] DEBE iniciar el controlador de ACTION_PROVISIONING_SUCCESSFUL. intent en el perfil de trabajo si se establece un propietario del perfil cuando android.app.action.PROVISION_MANAGED_PROFILE inicia el aprovisionamiento. y el DPC implementó el controlador.

• [C-1-5] DEBE enviar ACTION_PROFILE_PROVISIONING_COMPLETE al DPC del perfil de trabajo cuando el DPC inicia el aprovisionamiento android.app.action.PROVISION_MANAGED_PROFILE .

• [C-1-6] DEBE enviar el ACTION_GET_PROVISIONING_MODE. después de que se active el aprovisionamiento del propietario del perfil para que la app de DPC puede elegir entre ser propietario del dispositivo o propietario del perfil, excepto cuando el aprovisionamiento se activa por el intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] SE DEBE enviar la ACTION_ADMIN_POLICY_COMPLIANCE intent en el perfil de trabajo cuando se establece un propietario del perfil durante el aprovisionamiento sin importar el método de aprovisionamiento, excepto Cuando el intent android.app.action.PROVISION_MANAGED_PROFILE activa el aprovisionamiento. El usuario no debe poder continuar con el asistente de configuración hasta que se cree el perfil La app del propietario finaliza.

• [C-1-8] DEBE enviar ACTION_MANAGED_PROFILE_PROVISIONED al DPC del perfil personal cuando se establece un propietario del perfil, sin importar el método de aprovisionamiento que se use.

3.9.2 Asistencia para perfiles administrados

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

• [C-1-1] DEBE admitir perfiles administrados a través de android.app.admin.DevicePolicyManager. APIs
• [C-1-2] DEBE permitir que se cree un solo perfil administrado.
• [C-1-3] SE DEBE usar una insignia de ícono (similar a la insignia de trabajo upstream de AOSP) para hacer lo siguiente: representar las aplicaciones y los widgets administrados, y otros elementos de la IU con insignias como Recientes y Notificaciones.
• [C-1-4] DEBE mostrar un ícono de notificación (similar al trabajo upstream de AOSP). insignia) para indicar que el usuario se encuentra en una aplicación de perfil administrado.
• [C-1-5] DEBE mostrar un aviso que indique que el usuario está en el perfil si se activa el dispositivo (ACTION_USER_PRESENT) y el aplicación en primer plano esté dentro del perfil administrado.
• [C-1-6] Cuando existe un perfil administrado, DEBE mostrar una indicación visual en la Selector de intents para permitir que el usuario reenvíe el intent desde el al usuario principal o viceversa (si la política de dispositivos lo habilitó) Controlador
• [C-1-7] Donde existe un perfil administrado, DEBE exponer al siguiente usuario condiciones para el usuario principal y el perfil administrado:
  • Contabilización independiente de la batería, la ubicación, los datos móviles y el uso del almacenamiento para el usuario principal y el perfil administrado.
  • Administración independiente de aplicaciones de VPN instaladas en la instancia principal usuario o perfil administrado.
  • Administración independiente de aplicaciones instaladas en el usuario principal o perfil administrado.
  • Administración independiente de las cuentas del usuario principal o de las cuentas administradas perfil.
• [C-1-8] SE DEBE asegurarse de que el marcador, los contactos y los mensajes preinstalados las aplicaciones pueden buscar y buscar información del emisor desde la red (si existiera) junto con los del perfil principal, en caso de que El controlador de política de dispositivo lo permite.
• [C-1-9] SE DEBE asegurarse de que cumpla con todos los requisitos de seguridad. aplicable a un dispositivo que tiene habilitados varios usuarios (consulta la sección 9.5), a pesar de que el perfil administrado no se cuenta como otro usuario además del usuario principal.

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

• [C-2-1] DEBE admitir la posibilidad de especificar otra reunión con la pantalla de bloqueo. los siguientes requisitos para otorgar acceso a las apps que se ejecutan en una perfil.
  • Las implementaciones en dispositivos DEBEN cumplir con las DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent y muestra una interfaz para configurar una pantalla de bloqueo independiente del perfil administrado.
  • Las credenciales de la pantalla de bloqueo del perfil administrado DEBEN usar el mismo de almacenamiento y administración de credenciales como el perfil superior como se documenta en el Sitio del Proyecto de código abierto de Android.
  • Las políticas de contraseñas de DPC DEBE aplicarse solo a las credenciales de la pantalla de bloqueo del perfil administrado, a menos que llama a la instancia DevicePolicyManager devuelta por getParentProfileInstance.
• Cuándo se muestran los contactos del perfil administrado en el registro de llamadas preinstalado, la IU de llamadas entrantes, las llamadas en curso y las llamadas perdidas notificaciones, contactos y apps de mensajería que DEBEN usar la insignia misma insignia que se usa para indicar las aplicaciones de perfil administrado.

3.9.3 Asistencia para usuarios administrados

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

• [C-1-1] DEBE proporcionar una indicación para salir del usuario actual y vuelve al usuario principal en una sesión de varios usuarios cuando isLogoutEnabled muestra true. Se DEBE poder acceder a la indicación visual del usuario desde la pantalla de bloqueo. sin desbloquearlo.

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

• [C-SR-1] Se RECOMIENDA EXIENTEMENTE que muestren el mismo consentimiento del propietario del dispositivo del AOSP. divulgaciones que se mostraron en el flujo que inició android.app.action.PROVISION_MANAGED_DEVICE antes de permitir que se agreguen cuentas en el nuevo Usuario secundario, para que los usuarios sepan que el dispositivo está administrado.

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

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

• [C-1-1] DEBE admitir el rol de administración de políticas de dispositivos, tal como se define en artículo 9.1. La aplicación que tiene la función de administración de políticas de dispositivos SE PUEDE definir mediante la configuración de config_devicePolicyManagement en el nombre del paquete. El nombre del paquete DEBE estar seguido de : y del certificado de firma, a menos que la aplicación esté precargada.

Si no se define un nombre de paquete para config_devicePolicyManagement como descritos anteriormente:

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

Si se define un nombre de paquete para config_devicePolicyManagement como se describe. arriba:

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

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

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

3.10. Accesibilidad

Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a realizar lo siguiente: a navegar sus dispositivos más fácilmente. Además, Android proporciona APIs de plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamada para los usuarios y eventos de sistema, y generar mecanismos alternativos de retroalimentación, como texto a voz, respuesta táctil y navegación con bola de seguimiento o pad direccional.

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, sucederá lo siguiente:

• [C-1-1] DEBE implementar la accesibilidad de Android. como se describe en el APIs de accesibilidad documentación del SDK.
• [C-1-2] DEBE generar eventos de accesibilidad y brindar los AccessibilityEvent, visible para todos los usuarios registrados AccessibilityService implementaciones, como se documenta en el SDK.
• [C-1-4] DEBE proporcionar una indicación visual al usuario para controlar la accesibilidad. servicios que declaran el AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Ten en cuenta que, en las implementaciones en dispositivos con una barra de navegación del sistema, SE DEBE permitir que el usuario tenga la opción de un botón en el barra de navegación para controlar estos servicios.

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

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

3.11. Text-to-Speech

Android incluye APIs que permiten que las aplicaciones usen texto a voz (TTS) y les permite a los proveedores de servicios implementar de Google Cloud.

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

• [C-1-1] DEBE admitir el Marco de trabajo de TTS de Android APIs

Si las implementaciones de dispositivos admiten la instalación de motores de TTS de terceros, sucederá lo siguiente:

• [C-2-1] DEBE proporcionar la indicación visual del usuario para permitirle seleccionar una TTS. para usarlo a nivel del sistema.

3.12. Framework de entrada de TV

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

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

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

3.13. Configuración rápida

Android ofrece un componente de IU de Configuración rápida que permite acceder rápidamente a acciones utilizadas con frecuencia o necesarias con urgencia.

Si las implementaciones en dispositivos incluyen un componente de IU de Configuración rápida y admiten aplicaciones de terceros La Configuración rápida les permite hacer lo siguiente:

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

3.14. IU multimedia

Si las implementaciones de dispositivos incluyen aplicaciones que no se activan por voz (las Aplicaciones) que interactúan con de aplicaciones de terceros mediante MediaBrowser o MediaSession, la aplicación:

• [C-1-2] DEBE mostrar claramente los íconos y los títulos obtenidos con getIconBitmap() o getIconUri(). obtenido a través de getTitle(), como se describe en MediaDescription. Los títulos pueden acortarse para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor).

• [C-1-3] DEBE mostrar el ícono de la aplicación de terceros siempre que muestre contenido proporcionado por esta aplicación de terceros.

• [C-1-4] DEBE permitir que el usuario interactúe con toda la MediaBrowser en la nube. PUEDE restringir el acceso a partes de la jerarquía para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor), pero NO DEBE dar un trato preferencial según el contenido o proveedor de contenido.

• [C-1-5] DEBES considerar presionar dos veces KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3.15. Apps instantáneas

Si las implementaciones de dispositivos admiten apps instantáneas, DEBEN cumplir con lo siguiente requisitos:

• [C-1-1] Apps instantáneas DEBE obtener permisos con los android:protectionLevel se define en "instant".
• [C-1-2] Las Apps instantáneas NO DEBEN interactuar con las apps instaladas a través de intents implícitos salvo que se cumpla una de las siguientes condiciones:
  • El filtro de patrón de intents del componente está expuesto y tiene CATEGORY_BROWSABLE
  • La acción es una de las siguientes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
  • El destino se expone de forma explícita con android:visibleToInstantApps.
• [C-1-3] Las Apps instantáneas NO DEBEN interactuar explícitamente con las apps instaladas, a menos que se expone a través de android:visibleToInstantApps.
• [C-1-4] Las aplicaciones instaladas NO DEBEN ver los detalles de las Apps instantáneas en la dispositivo, a menos que la App instantánea se conecte explícitamente al aplicación instalada.

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

  • [C-1-5] DEBE proporcionar una indicación visual al usuario para ver y borrar Apps instantáneas. en caché de forma local para cada paquete individual de la app.
  • [C-1-6] DEBE brindar una notificación de usuario persistente que se pueda contraído mientras se ejecuta una app instantánea en primer plano. Este usuario notificación DEBE incluir que las Apps instantáneas no requieren instalación y proporcionan una indicación visual que lo dirija a la aplicación en Configuración. Para las apps instantáneas iniciadas a través de intents web, como se define con un intent con una acción establecida en Intent.ACTION_VIEW y con un esquema "http" o “https”, una indicación visual adicional SE DEBE permitir que el usuario no inicie la app instantánea y iniciar el vínculo asociado con el navegador web configurado, si un navegador está disponible en el dispositivo.
  • [C-1-7] DEBE permitir el acceso a las Apps instantáneas en ejecución desde Recientes. si está disponible en el dispositivo.

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

3.16. Sincronización de dispositivos complementarios

Android admite la vinculación de dispositivos complementarios para administrar de forma más eficaz. asociada con dispositivos complementarios y proporciona la CompanionDeviceManager API para que las apps accedan a esta función.

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

• [C-1-1] SE DEBE declarar la marca de función FEATURE_COMPANION_DEVICE_SETUP de Google Cloud.
• [C-1-2] DEBE asegurarse de que las APIs en el android.companion del paquete se haya implementado por completo.
• [C-1-3] DEBE proporcionar las indicaciones visuales del usuario para que seleccione o confirme un complemento. el dispositivo esté presente y en funcionamiento.

3.17. Aplicaciones pesadas

Si las implementaciones de dispositivos declaran la función FEATURE_CANT_SAVE_STATE, entonces:

• [C-1-1] DEBE tener solo una aplicación instalada que especifique cantSaveState que se ejecutan en el sistema a la vez. Si el usuario abandona esa app sin salir de ella explícitamente (por ejemplo, presionando inicio mientras deja una actividad activa en el sistema, en lugar de presionar Atrás sin actividades restantes activas en el sistema) las implementaciones en dispositivos DEBEN priorizar esa app en la RAM como lo hacen para otras elementos que se espera que continúen ejecutándose, como servicios en primer plano. Mientras la app se encuentre en segundo plano, el sistema podrá seguir usando energía de administración de configuraciones, como limitar el acceso a la CPU y a la red.
• [C-1-2] DEBE proporcionar una indicación visual de la IU para elegir la app que no participan en el mecanismo de guardado/restablecimiento de estado normal una vez que el usuario inicia una segunda app declarada con cantSaveState .
• [C-1-3] NO DEBE aplicar otros cambios en la política a las aplicaciones que especifican cantSaveState, como cambiar el rendimiento de la CPU o cambiar la priorización de la programación.

Si las implementaciones en dispositivos no declaran la función FEATURE_CANT_SAVE_STATE, entonces:

• [C-1-1] DEBE ignorar cantSaveState. atributo establecido por las aplicaciones y NO DEBE cambiar el comportamiento de la aplicación según ese .

3.18. Contactos

Android incluye lo siguiente: Contacts Provider API que permiten a las aplicaciones administrar la información de contacto almacenada en el dispositivo. Los datos de contacto que se ingresan directamente en el dispositivo suelen sincronizarse con un servicio web, pero los datos también PUEDEN residir solo a nivel local en el dispositivo. Los contactos que solo se almacenan en el dispositivo se conocen como contactos locales contactos.

Contactos sin procesar están "asociados a" o "almacenados en" un Cuenta cuando el ACCOUNT_NAME, y ACCOUNT_TYPE, las columnas de los contactos sin procesar coinciden con el Nombre.de.cuenta y Tipo de cuenta campos de la cuenta.

Cuenta local predeterminada: una cuenta para contactos sin procesar que solo se almacenan en el dispositivo y no está asociado con una Cuenta en el Administrador de cuentas, que se crean con valores null para el ACCOUNT_NAME, y ACCOUNT_TYPE, columnas.

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

Implementaciones en dispositivos:

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

Si las implementaciones de dispositivos usan una cuenta local personalizada:

• [C-1-1] El ACCOUNT_NAME, de la cuenta local personalizada DEBE ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] El ACCOUNT_TYPE, de la cuenta local personalizada DEBE ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Contactos sin procesar insertados por aplicaciones de terceros con la cuenta local predeterminada (es decir, al establecer valores nulos para ACCOUNT_NAME y ACCOUNT_TYPE) DEBEN insertarse en la columna local personalizada .
• [C-1-4] Los contactos sin procesar insertados en la cuenta local personalizada no DEBEN cuando se agregan o eliminan cuentas.
• [C-1-5] Operaciones de eliminación realizadas en la cuenta local personalizada DEBE provocar que los contactos sin procesar se borren de forma inmediata y definitiva (como si el CALLER_IS_SYNCADAPTER se estableció como verdadero), incluso si se estableció el parámetro CALLER\_IS\_SYNCADAPTER como falso o sin especificar.

4. Compatibilidad con paquetes de aplicaciones

Implementaciones en dispositivos:

• [C-0-1] DEBE ser capaz de instalar y ejecutar el archivo “.apk” de Android archivos como generado por el comando “aapt” herramienta incluida en el SDK oficial de Android.

  • Dado que el requisito anterior puede ser desafiante, las implementaciones en dispositivos son SE RECOMIENDA usar la administración de paquetes de la implementación de referencia de AOSP. en un sistema de archivos.

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

• [C-0-3] NO DEBE extender el .apk; Manifiesto de Android, Código de bytes Dalvik o RenderScript de tal manera que evita que esos archivos instalar y ejecutar correctamente en otros dispositivos compatibles.

• [C-0-4] NO DEBE permitir aplicaciones que no sean la actual "instalador de registros" para que el paquete desinstale la app de forma silenciosa sin ninguna confirmación del usuario, tal como se documenta en el SDK para el DELETE_PACKAGE permiso. Las únicas excepciones son la administración de apps del verificador de paquetes del sistema PACKAGE_NEEDS_VERIFICATION y la app de administración de almacenamiento ACTION_MANAGE_STORAGE .

• [C-0-5] DEBE tener una actividad que controle las android.settings.MANAGE_UNKNOWN_APP_SOURCES .

• [C-0-6] NO DEBES instalar paquetes de aplicaciones desde aplicaciones desconocidas. a menos que la aplicación que solicita la instalación cumpla con todos los siguientes requisitos:

  • Se DEBE declarar el REQUEST_INSTALL_PACKAGES. permiso o establecer el android:targetSdkVersion en 24 o menos.
  • DEBE tener el permiso del usuario para instalar apps desde fuentes desconocidas.

• DEBERÍAS proporcionar una indicación visual de usuario para otorgar o revocar el permiso instalar apps desde fuentes desconocidas por aplicación, pero PUEDE optar por implementarlas esto como no-op y se muestra RESULT_CANCELED para startActivityForResult(), si la implementación del dispositivo no permite que los usuarios tengan esta opción. Sin embargo, incluso en tales casos, DEBEN indicar al usuario por qué no hay se presenta tal elección.

• [C-0-7] DEBE mostrar un diálogo de advertencia con la cadena de advertencia que proporcionado a través de la API PackageManager.setHarmfulAppWarning del sistema al usuario antes de iniciar una actividad en una aplicación marcada por la misma API de sistema PackageManager.setHarmfulAppWarning que potencialmente o peligros.

• DEBES proporcionar una indicación visual al usuario para que decida desinstalar o lanzar una aplicación en el cuadro de diálogo de advertencia.

• [C-0-8] SE DEBE implementar la compatibilidad con el sistema de archivos incrementales como se indica aquí.

• [C-0-9] DEBE admitir la verificación de archivos .apk con el Esquema de firma de APK v4 y Esquema de firma de APK v4.1

5. Compatibilidad multimedia

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con los formatos multimedia, los codificadores, los decodificadores, los tipos de archivo y de contenedores definidos en la sección 5.1 para cada códec declarado por MediaCodecList.
• [C-0-2] DEBE declarar e informar la compatibilidad de los codificadores o decodificadores disponibles. a aplicaciones de terceros mediante MediaCodecList
• [C-0-3] DEBE ser capaz de decodificarse correctamente y ponerlo a disposición de terceros en todos los formatos que puede codificar. Esto incluye todos los flujos de bits a los que se generan los codificadores y los perfiles informados en su CamcorderProfile

Implementaciones en dispositivos:

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

Todos los códecs enumerados en la siguiente sección se proporcionan como software en la implementación preferida de Android desde el módulo Proyecto fuente.

Ten en cuenta que ni Google ni Open Handset Alliance toman que estos códecs no tienen patentes de terceros. Los que se recomienda que uses este código fuente en productos de hardware o software que las implementaciones de este código, incluso en software de código abierto o shareware, puede requerir licencias de patentes de los titulares pertinentes de las patentes.

5.1. Códecs de contenido multimedia

5.1.1 Codificación de audio

Puedes obtener más detalles en la sección 5.1.3. Detalles de los códecs de audio.

Si las implementaciones de dispositivos declaran android.hardware.microphone, DEBE admitir la codificación de los siguientes formatos de audio y ponerlos a disposición a aplicaciones de terceros:

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

Todos los codificadores de audio DEBEN admitir lo siguiente:

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

5.1.2. Decodificación de audio

Puedes obtener más detalles en la sección 5.1.3. Detalles de los códecs de audio.

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

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

Si las implementaciones de dispositivos admiten la decodificación de los búferes de entrada AAC de de transmisión multicanal (es decir, más de dos canales) a PCM mediante la configuración predeterminada decodificador de audio AAC en la API de android.media.MediaCodec, se DEBE compatibles:

• [C-2-1] La decodificación DEBE realizarse sin mezclar (p. ej., AAC 5.0). la transmisión se debe decodificar en cinco canales de PCM, se debe decodificar una transmisión 5.1 AAC a seis canales de PCM).
• [C-2-2] Los metadatos de rango dinámico DEBEN ser los definidos en “Control de rango dinámico” (RDC)" en ISO/IEC 14496-3 y las claves android.media.MediaFormat del DRC para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. El Las claves de DRC de AAC se introdujeron en el nivel de API 21 y son las siguientes: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL y KEY_AAC_ENCODED_TARGET_LEVEL
• [C-SR-1] SE RECOMIENDA ENcarecidamente que los requisitos C-2-1 y C-2-2 mencionados anteriormente sean satisfechos con todos los decodificadores de audio de AAC.

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

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

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

• PUEDE admitir el control de volumen y rango dinámico con la norma ISO/IEC 23003-4 Perfil de control de rango dinámico.

Si se admite ISO/IEC 23003-4 y si tanto ISO/IEC 23003-4 como Los metadatos ISO/IEC 14496-3 están presentes en un flujo de bits decodificado. Luego, sucede lo siguiente:

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

Todos los decodificadores de audio DEBEN admitir la salida:

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

Si las implementaciones de dispositivos admiten la decodificación de los búferes de entrada AAC de de transmisión multicanal (es decir, más de dos canales) a PCM mediante la configuración predeterminada decodificador de audio AAC en la API de android.media.MediaCodec, entonces lo siguiente DEBE compatibles:

• [C-7-1] SE DEBE poder configurar a través de la aplicación usando el método con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se mezcla en estéreo (cuando se usa un valor de 2) o se emite con el número nativo de canales (cuando se usa un valor igual o mayor a ese número). Por ejemplo, un valor de 6 o más configuraría y un decodificador para entregar 6 canales cuando se ingresa contenido 5.1.
• [C-7-2] Durante la decodificación, el decodificador DEBE anunciar la máscara de canal que se está utilizando. en el formato de salida con la KEY_CHANNEL_MASK con las constantes android.media.AudioFormat (por ejemplo: CHANNEL_OUT_5POINT1).

Si las implementaciones del dispositivo admiten decodificadores de audio distintos del AAC predeterminado de audio y pueden emitir audio multicanal (es decir, más de 2 canales) cuando se proporciona contenido multicanal comprimido, entonces:

• [C-SR-2] SE RECOMIENDA EL SÓLIDAMENTE que el decodificador pueda ser configurado por el aplicación usando la decodificación con la clave KEY_MAX_OUTPUT_CHANNEL_COUNT para controlar si el contenido se mezcla en estéreo (cuando se usa un valor de 2) o se emite con el número nativo de canales (cuando se usa un valor igual o mayor a ese número). Por ejemplo, un valor de 6 o más configuraría y un decodificador para entregar 6 canales cuando se ingresa contenido 5.1.
• [C-SR-3] Cuando se decodifica, se RECOMIENDA EL DEcodificador para que anuncie el máscara de canal que se usa en el formato de salida con el KEY_CHANNEL_MASK con las constantes android.media.AudioFormat (por ejemplo: CHANNEL_OUT_5POINT1).

5.1.3 Detalles de los códecs de audio

Formato/códec	Detalles	Tipos de archivos/formatos de contenedor que se admitirán
Perfil MPEG-4 AAC (AAC LC)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con estándar con una tasa de muestreo de 8 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC sin formato ADTS (.aac, ADIF no es compatible) MPEG-TS (.ts, no permite búsquedas, solo decodificación) Matroska (.mkv, solo decodificación)
Perfil MPEG-4 HE AAC (AAC+)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con estándar con una tasa de muestreo de 16 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Perfil (AAC+ mejorado)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con estándar con una tasa de muestreo de 16 kHz a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC mejorado de bajo retraso)	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 7.35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4.75 a 12.2 Kbps con muestreo a 8 kHz	3GPP (.3gp)
AMR-WB	9 tasas de 6.60 kbit/s a 23.85 kbit/s de muestra a 16 kHz, como se define en AMR-WB, Códec de voz adaptable, de múltiples velocidades y banda ancha	3GPP (.3gp)
FLAC	Tanto para el codificador como el decodificador: al menos, los modos Mono y estéreo DEBEN ser no es compatible. DEBEN ser compatibles las tasas de muestreo de hasta 192 kHz. 16 y 24 bits resolución DEBE ser compatible. El manejo de datos de audio FLAC de 24 bits DEBE tener disponible con la configuración de audio de punto flotante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv, solo decodificación)
MP3	Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv, solo decodificación)
MIDI	MIDI tipo 0 y 1. Versión 1 y 2 de DLS. XMF y Mobile XMF. Compatibilidad con Formatos de tono de llamada RTTTL/RTX, OTA y iMelody	Tipos 0 y 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Decodificación: compatibilidad con contenido mono, estéreo, 5.0 y 5.1 con muestreo 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. Codificación: compatibilidad con contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) Webm (.webm)
PCM/WAVE	El códec PCM DEBE admitir PCM lineal de 16 bits y número de punto flotante de 16 bits. SALUD el extractor debe admitir PCM lineal de 16 bits, 24 bits y 32 bits, y un número de punto flotante de 32 bits (las tarifas llegan hasta el límite de hardware). Las tasas de muestreo DEBEN ser compatibles con De 8 kHz a 192 kHz	WAVE (.wav)
Opus	Decodificación: Compatibilidad con contenido mono, estéreo, 5.0 y 5.1 con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. Codificación: Compatibilidad con contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) Webm (.webm)

5.1.4. Codificación de imágenes

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

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

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

Si las implementaciones de dispositivos admiten la codificación HEIC a través de android.media.MediaCodec para el tipo de medio MIMETYPE_IMAGE_ANDROID_HEIC hacen lo siguiente:

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

5.1.5 Decodificación de imágenes

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

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

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Sin procesar
• [C-0-7] AVIF (perfil de Baseline)

Si las implementaciones de dispositivos admiten la decodificación de video HEVC, sucederá lo siguiente: * [C-1-1] DEBE admitir la decodificación de imágenes HEIF (HEIC).

Decodificadores de imágenes que admiten un formato de profundidad de bits alta (más de 9 bits por canal):

• [C-2-1] DEBE admitir la salida en un formato equivalente de 8 bits si así lo solicita el la aplicación, por ejemplo, mediante ARGB_8888 configuración de android.graphics.Bitmap.

5.1.6. Detalles de los códecs de imagen

Formato/códec	Detalles	Tipos de archivos/formatos de contenedor admitidos
JPEG	Básica + progresiva	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Sin procesar		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf) PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Imagen, colección de imágenes, secuencia de imágenes	HEIF (.heif), HEIC (.heic)
AVIF (perfil de Baseline)	Imagen, colección de imágenes, secuencia de imágenes Perfil de Baseline	Contenedor HEIF (.avif)

Codificadores y decodificadores de imágenes expuestos a través de la API de MediaCodec

• [C-1-1] DEBE admitir color flexible YUV420 8:8:8. formato (COLOR_FormatYUV420Flexible) a CodecCapabilities.

• [C-SR-1] SE RECOMIENDA RECOMENDADAMENTE para admitir el formato de color RGB888 para la superficie de entrada. .

• [C-1-3] DEBE soportar al menos uno de los planos de plano o semiplanar. YUV420 Formato de color 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). SE RECOMIENDA ENERGMENTE que respalden ambos.

5.1.7 Códecs de video

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

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

• [C-1-1] Los códecs de video DEBEN admitir tamaños de búfer de bytes de entrada y salida para alojar el fotograma comprimido y descomprimido más grande posible el estándar y la configuración, pero no la generalización.

• [C-1-2] Los codificadores y decodificadores de video DEBEN ser compatibles con YUV420 en color flexible 8:8:8 formatos (COLOR_FormatYUV420Flexible) a CodecCapabilities.

• [C-1-3] Los codificadores y decodificadores de video DEBEN admitir al menos uno de los Formato de color semiplanar YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar) SE RECOMIENDA ENERGMENTE para respaldar ambos.

• [C-SR-1] SE RECOMIENDA QUE los codificadores y decodificadores de video sean compatibles al menos uno de los colores planos o semiplanar YUV420 con optimización de hardware, 8:8:8 (YV12, NV12, NV21 o formato optimizado por el proveedor equivalente).

• [C-1-5] Decodificadores de video que admiten un formato de profundidad de bits alta (9 o más bits por canal) DEBEN admitir la salida en un formato equivalente de 8 bits si solicitada por la aplicación. Esto DEBE reflejarse respaldando un YUV420 con formato de color 8:8:8 mediante android.media.MediaCodecInfo.

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

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

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

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

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

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

5.1.8. Lista de códecs de video

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

5.1.9 Seguridad de códecs multimedia

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

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

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

• [C-1-1] DEBE admitir códecs multimedia a través de OMX o Codec 2.0. (o ambas), como en el Proyecto de código abierto de Android, y no inhabilitarlas eludir las protecciones de seguridad. Esto no significa que cada El códec DEBE usar el OMX o la API de Codec 2.0, solo que admite al menos una de estas APIs DEBE estar disponible, y la compatibilidad con las APIs disponibles DEBE incluyen las protecciones de seguridad presentes.
• [C-SR-1] SE RECOMIENDA ENERCMENTE incluir compatibilidad con la API de códec 2.0.

Si las implementaciones de dispositivos no son compatibles con la API de Codec 2.0, sucederá lo siguiente:

• [C-2-1] DEBE incluir el códec de software OMX correspondiente del Android Es un proyecto de código abierto (si está disponible) para cada tipo y formato de medios. (codificador o decodificador) compatible con el dispositivo.
• [C-2-2] Códecs cuyos nombres comienzan con "OMX.google". DEBE basarse en el código fuente del Proyecto de código abierto de Android.
• [C-SR-2] SE RECOMIENDA ENERCMENTE que los códecs de software OMX se ejecuten en un códec que no tiene acceso a controladores de hardware que no sean mappers de memoria.

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

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

5.1.10. Caracterización de códecs de medios

Si las implementaciones de dispositivos admiten códecs multimedia, sucederá lo siguiente:

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

En particular:

• [C-1-2] Códecs cuyos nombres comienzan con "OMX". DEBE usar las APIs de OMX y que tengan nombres que cumplan con las pautas de nomenclatura de OMX IL.
• [C-1-3] Códecs cuyos nombres comienzan con "c2". DEBEN usar la API de Codec 2.0 y tienen nombres que cumplen con las pautas de denominación de Codec 2.0 para Android.
• [C-1-4] Códecs cuyos nombres comienzan con "OMX.google". o "c2.android". DEBEN NO se puede caracterizar como proveedor ni acelerado por hardware.
• [C-1-5] Códecs que se ejecutan en un proceso de códecs (proveedor o sistema) con el acceso a controladores de hardware que no sean asignadores y mappers de memoria se caracterizan como si solo fueran software.
• [C-1-6] Los códecs no están presentes en el Proyecto de código abierto de Android o no están basados en del código fuente de ese proyecto DEBE caracterizarse como proveedor.
• [C-1-7] Los códecs que usan aceleración de hardware SE DEBEN caracterizar con la aceleración por hardware.
• [C-1-8] Los nombres de códecs NO DEBEN ser engañosos. Por ejemplo, los códecs llamados "decodificadores" DEBE admitir la decodificación, y los denominados “codificadores” DEBE admitir o la codificación. Los códecs con nombres que contienen formatos de medios DEBEN admitir esos formatos.

Si las implementaciones de dispositivos admiten códecs de video:

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

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

• [C-2-2] Los códecs de video caracterizados como acelerados por hardware DEBEN publicar información sobre los puntos de rendimiento. DEBE cada lista compatible puntos de rendimiento estándar (se indican en PerformancePoint) API), a menos que estén cubiertas por otro punto de rendimiento estándar admitido.
• Además, DEBEN publicar puntos de rendimiento extendidos si admiten un rendimiento sostenido de video distinto de los estándares mencionados.

5.2 Codificación de videos

Si las implementaciones en los dispositivos incluyen una visualización de pantalla incorporada con el elemento diagonal de al menos 2,5 pulgadas o incluya un puerto de salida de video o declarar la compatibilidad con una cámara mediante android.hardware.camera.any marca de función, hace lo siguiente:

• [C-1-1] DEBE incluir la compatibilidad con al menos uno de los videos VP8 o H.264 codificadores y ponerlo a disposición de aplicaciones de terceros.
• SE DEBE admitir codificadores de video VP8 y H.264, y debe estar disponible. para aplicaciones de terceros.

Si las implementaciones de dispositivos admiten cualquiera de los formatos de video H.264, VP8, VP9 o HEVC codificadores y ponerlo a disposición de aplicaciones de terceros, ellos hacen lo siguiente:

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

Si las implementaciones de dispositivos admiten el codificador de video MPEG-4 SP que están disponibles para apps de terceros:

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

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

• [C-4-1] Todos los codificadores de imagen y video acelerados por hardware DEBEN ser compatibles codificar fotogramas de las cámaras de hardware.
• SE DEBE admitir la codificación de fotogramas de las cámaras de hardware en todo el video o codificadores de imágenes.

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

• [C-SR-1] SE RECOMIENDA ENERGENTE para proporcionar un complemento para el API de transcodificación sin inconvenientes para convertir de formato HDR a SDR.

5.2.1 H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y están disponibles a apps de terceros, hacen lo siguiente:

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

5.2.2. H.264

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

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

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

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

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

5.2.3 VP8

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

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

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

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

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

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

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

	SD	HD: 720p	HD: 1080 p	UHD
Resolución de video	720 × 480 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones de dispositivos afirman admitir el Perfil 2 o el Perfil 3 a través de la APIs de medios:

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

5.2.5 H.265

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

• [C-1-1] SE DEBE admitir el perfil principal de nivel 3 hasta el Resolución de 512 x 512.
• SE RECOMIENDA admitir los perfiles de codificación HD como se indica en la siguiente tabla.
• [C-SR-1] SE RECOMIENDA ENERGMENTE para respaldar el El perfil SD de 720 x 480 perfiles de codificación HD, como se indica en la siguiente tabla, si hay un de hardware.

	SD	HD: 720p	HD: 1080 p	UHD
Resolución de video	720 × 480 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3 Decodificación de video

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

• [C-1-1] DEBE admitir la resolución de video dinámica y el cambio de velocidad de fotogramas con las API estándar de Android en la misma transmisión Códecs H.264 y H.265 en tiempo real y hasta la resolución máxima admitida por cada códec en el dispositivo.

5.3.1. MPEG-2

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

• [C-1-1] DEBE admitir el perfil principal de alto nivel.

5.3.2. H.263

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

• [C-1-1] DEBE admitir el perfil de Baseline de nivel 30. (Resoluciones CIF, QCIF y SQCIF a 30 FPS) 384 Kbps) y el nivel 45 (Resoluciones QCIF y SQCIF a 30 fps 128 Kbps).

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

Si la altura que informa el método Display.getSupportedModes() es igual o superior a la resolución de video, las implementaciones en dispositivos:

• [C-2-1] DEBE admitir los perfiles de decodificación de video HD 720p en los siguientes desde una tabla de particiones.
• [C-2-2] DEBE admitir los perfiles de decodificación de video HD 1080p en los siguientes desde una tabla de particiones.

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

5.3.5 H.265 (HEVC)

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

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

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

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

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

Si las implementaciones del dispositivo afirman admitir un perfil HDR a través del contenido multimedia APIs:

• [C-3-1] Las implementaciones en dispositivos DEBEN aceptar los metadatos de HDR requeridos de la aplicación, y admitir la extracción y generación de los valores de HDR requeridos metadatos del flujo de bits o del contenedor.
• [C-3-2] Las implementaciones en dispositivos DEBEN mostrar correctamente el contenido HDR en el en la pantalla del dispositivo o en un puerto de salida de video estándar (p.ej., HDMI).

5.3.6. VP8

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

• [C-1-1] DEBE admitir los perfiles de decodificación SD en la siguiente tabla.
• DEBES usar un códec de hardware VP8 que cumpla con los requisitos.
• SE RECOMIENDA admitir los perfiles de decodificación HD que se indican en la siguiente tabla.

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

• [C-2-1] Las implementaciones en dispositivos DEBEN admitir perfiles de 720p en el siguiente tabla.
• [C-2-2] Las implementaciones en dispositivos DEBEN admitir perfiles de 1080p en el siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	30 FPS (60 FPS Televisión)	30 (60 FPS Televisión)
Tasa de bits del video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

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

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

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

• [C-2-1] DEBE admitir los perfiles de decodificación HD como se indica a continuación desde una tabla de particiones.

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

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

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080 p	UHD
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 FPS (60 FPS Televisión con decodificación por hardware de VP9)	60 fps
Tasa de bits del video	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones en dispositivos afirman admitir VP9Profile2 o VP9Profile3. a través del "CodecProfileLevel" APIs multimedia:

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

Si las implementaciones en dispositivos afirman admitir un perfil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) hasta el APIs multimedia:

• [C-4-1] Las implementaciones en dispositivos DEBEN aceptar los metadatos de HDR requeridos. (KEY_HDR_STATIC_INFO) para todos los perfiles HDR, así como “KEY_HDR10_PLUS_INFO” para perfiles HDR10Plus) desde la aplicación. También DEBEN admitir la extracción y la salida de los los metadatos de HDR requeridos del flujo de bits o del contenedor.
• [C-4-2] Las implementaciones en dispositivos DEBEN mostrar correctamente el contenido HDR en el en la pantalla del dispositivo o en un puerto de salida de video estándar (p.ej., HDMI).

5.3.8. Dolby Vision

Si las implementaciones de dispositivos declaran la compatibilidad con el decodificador Dolby Vision a través de HDR_TYPE_DOLBY_VISION :

• [C-1-1] DEBE incluir un extractor compatible con Dolby Vision.
• [C-1-2] DEBE mostrar correctamente el contenido de Dolby Vision en la pantalla del dispositivo. en un puerto de salida de video estándar (p.ej., HDMI).
• [C-1-3] SE DEBE establecer el ID de pista. de capas base retrocompatibles (si las hay) de modo que sean iguales al combinó el ID de pista de la capa de Dolby Vision.

5.3.9. AV1

5.4. Grabación de audio

Si bien algunos de los requisitos que se describen en esta sección se indican como SE DEBEN a partir de Android 4.3, la definición de compatibilidad para versiones futuras para cambiarlos a DEBE. Los dispositivos Android existentes y nuevos tienen un rendimiento EFICIENTE RECOMENDADA para cumplir con los requisitos que se indican como DEBEN o no podrá ser compatible con Android cuando se actualice a una versión futura versión.

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

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

• [C-1-1] DEBE permitir la captura de contenido de audio sin procesar para cualquier flujo de INPUT AudioRecord o AAudio que se abra con éxito. Como mínimo, se DEBEN admitir las siguientes características:

  • Formato: PCM lineal, 16 bits
  • Tasas de muestreo: 8,000, 11,025, 16,000, 44,100, 48,000 Hz
  • Canales: Mono
  • Fuentes de audio: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION: VOICE_COMMUNICATION: UNPROCESSED: o VOICE_PERFORMANCE. Esto también se aplica a los ajustes predeterminados de entrada equivalentes en AAudio, por por ejemplo, AAUDIO_INPUT_PRESET_CAMCORDER.

• SE DEBE permitir la captura de contenido de audio sin procesar con lo siguiente características:

  • Formato: PCM lineal, 16 bits y 24 bits
  • Tasas de muestreo: 8000, 11025, 16000, 22050, 24000, 32000, 44100 48,000 Hz
  • Canales: tantos canales como la cantidad de micrófonos en la dispositivo

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

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

• DEBES permitir la captura con calidad de radio AM y DVD de contenido de audio sin procesar, lo que tiene las siguientes características:

  • Formato: PCM lineal, 16 bits
  • Tasas de muestreo: 22,050, 48,000 Hz
  • Canales: estéreo

• [C-1-4] DEBE respetar la API de MicrophoneInfo. y complete correctamente la información de los micrófonos disponibles en el dispositivo. accesibles a aplicaciones de terceros a través de la AudioManager.getMicrophones() API, para AudioRecord activo con MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED o VOICE_PERFORMANCE. Si las implementaciones en el dispositivo permiten la captura de audio sin procesar con calidad de radio AM y DVD contenido:

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

• [C-2-2] DEBE incluir un filtro de suavizado de contorno adecuado para cualquier sobremuestreo. o submuestreo.

5.4.2. Capturar para el reconocimiento de voz

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

• [C-1-1] DEBE capturar android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION fuente de audio en una de las tasas de muestreo, 44,100 y 48,000.
• [C-1-2] DEBE, de manera predeterminada, inhabilitar cualquier procesamiento de audio de reducción de ruido cuando grabando una transmisión de audio a partir del audio AudioSource.VOICE_RECOGNITION fuente.

• [C-1-3] DEBE inhabilitar, de forma predeterminada, cualquier control de ganancia automático durante la grabación. una reproducción de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.

• SE RECOMIENDA exhibir aproximadamente características planas de amplitud frente a frecuencia en el rango de frecuencia media: específicamente ±3dB de 100 Hz a 4000 Hz para cada y todos los micrófonos que se usan para grabar la fuente de audio de reconocimiento de voz.

• [C-SR-1] se RECOMIENDA ENERGENTE para mostrar niveles de amplitud en la de frecuencia: específicamente de ±20 dB de 30 Hz a 100 Hz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos que se usan para grabar la voz fuente de audio de reconocimiento.

• [C-SR-2] se RECOMIENDA ENERGENTE para mostrar niveles de amplitud en las de frecuencia: específicamente de ±30 dB de 4000 Hz a 22 KHz en comparación con el rango de frecuencia media de todos y cada uno de los micrófonos que se usan para grabar la voz fuente de audio de reconocimiento.

• SE RECOMIENDA establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz se reproduce a un nivel de presión sonora (SPL) de 90 dB (medido) a una distancia de 30 cm de junto a el micrófono) produce una respuesta ideal de RMS 2500 dentro de un rango de 1770 y 3530 para 16 muestras de bits (o -22.35 db ±3 dB a escala completa para punto flotante/precisión doble) muestras) para todos y cada uno de los micrófonos que se utilizan para grabar el reconocimiento de voz fuente de audio.

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

• DEBERÍA grabar la reproducción de audio de reconocimiento de voz con armónico total distorsión (THD) inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone y ruido de supresión (reducción) ajustadas para el reconocimiento de voz, hacen lo siguiente:

• [C-2-1] DEBE permitir que este efecto de audio se pueda controlar con el API de android.media.audiofx.NoiseSuppressor.
• [C-2-2] DEBE identificar de manera única cada tecnología de reducción de ruido implementación a través del campo AudioEffect.Descriptor.uuid.

5.4.3. Captura para el redireccionamiento de la reproducción

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

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

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

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

5.4.4. Cancelador de eco acústico

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

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

Si las implementaciones en dispositivos proporcionan un cancelador de eco acústico que se insertará en la ruta de acceso de la captura de audio cuando AudioSource.VOICE_COMMUNICATION selecciona esta opción:

• Los [C-SR-1] tienen la SECCIÓN RECOMENDADA para declarar esto a través de AcousticEchoCanceler. Método de la API AcousticEchoCanceler.isAvailable()
• [C-SR-2] son STRONGLY_RECOMMENDED para permitir que este efecto de audio se se puede controlar con el AcousticEchoCanceler API de gcloud.
• Los [C-SR-3] se StrongLY_RECOMMENDED para identificar cada tecnología de AEC de manera única implementación a través de AudioEffect.Descriptor.uuid .

5.4.5. Captura simultánea

Si las implementaciones de dispositivos declaran android.hardware.microphone,DEBEN implementa la captura simultánea, como se describe en este documento. Más precisamente:

• [C-1-1] DEBE permitir el acceso simultáneo al micrófono a través de un elemento de accesibilidad. captura de servicio con AudioSource.VOICE_RECOGNITION y al menos uno la captura de aplicaciones con cualquier AudioSource.
• [C-1-2] DEBE permitir el acceso simultáneo al micrófono por parte de un dispositivo preinstalado una aplicación que tenga un rol de Asistente y, al menos, una aplicación mediante cualquier AudioSource, excepto por AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
• [C-1-3] DEBE silenciar la captura de audio para cualquier otra aplicación, excepto para un servicio de accesibilidad, mientras que una aplicación está capturando con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Sin embargo, cuando una app está capturando contenido a través de AudioSource.VOICE_COMMUNICATION y, luego, otra app puedes capturar la llamada de voz si es una app privilegiada (preinstalada) con el permiso CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Si dos o más aplicaciones están capturando al mismo tiempo Ninguna app tiene una IU en la parte superior, la que comenzó a capturar la más reciente recibe audio.

5.5 Reproducción de audio

Android admite que las apps reproduzcan audio a través del audio. de salida, según se define en la sección 7.8.2.

5.5.1 Reproducción de audio sin procesar

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

• [C-1-1] DEBE permitir la reproducción de contenido de audio sin procesar con lo siguiente características:

  • Formatos de origen: PCM lineal, 16 bits, 8 bits, flotante
  • Canales: Mono, estéreo, configuraciones multicanal válidas con hasta 8 canales
  • Tasas de muestreo (en Hz):
    • 8000, 11025, 16,000, 22050, 24,000, 32,000, 44100, 48,000 en el canal de configuración que se mencionaron anteriormente
    • 96,000 en mono y estéreo

5.5.2. Efectos de audio

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

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

• [C-1-1] DEBE admitir EFFECT_TYPE_EQUALIZER y Implementaciones de EFFECT_TYPE_LOUDNESS_ENHANCER controlables a través de la Las subclases de AudioEffect Equalizer y LoudnessEnhancer
• [C-1-2] DEBE admitir la implementación de la API del visualizador, que se puede controlar a través de la clase Visualizer
• [C-1-3] DEBE admitir la implementación de EFFECT_TYPE_DYNAMICS_PROCESSING. se puede controlar mediante la subclase AudioEffect DynamicsProcessing.

• SE DEBE admitir EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Implementaciones de EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER se pueden controlar mediante las subclases AudioEffect, BassBoost, EnvironmentalReverb, PresetReverb y Virtualizer.
• [C-SR-1] SE RECOMIENDA COMPLETAMENTE para admitir efectos en el punto flotante y multicanal.

5.5.3. Volumen de audio saliente

Implementaciones en dispositivos de Automotive:

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

5.5.4. Descarga de audio

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

• [C-SR-1] SE RECOMIENDA EXITOSAMENTE para cortar el contenido de audio sin interrupciones que se reproduce entre dos clips con el mismo formato cuando se especifica mediante el API sin espacios de AudioTrack y el contenedor de medios para MediaPlayer.

5.6. Latencia de audio

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

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

• latencia de salida. El intervalo entre el momento en que una aplicación escribe una trama de datos codificados en PCM y cuando el sonido correspondiente se presenta en el entorno en un transductor integrado en el dispositivo o si la señal sale del dispositivo mediante un y pueden observarse externamente.
• latencia de salida en frío. El tiempo transcurrido entre el inicio de una transmisión de salida y la tiempo de presentación del primer fotograma basado en marcas de tiempo, cuando la salida de audio estado inactivo y apagado antes de la solicitud.
• latencia de salida continua. La latencia de salida para los fotogramas posteriores luego de que el dispositivo esté reproduciendo audio.
• latencia de entrada. El intervalo entre cuando presenta un sonido entorno al dispositivo en un transductor integrado o una señal que ingrese al dispositivo a través de un puerto, y cuando una aplicación lee la trama correspondiente de datos codificados en PCM.
• entrada perdida. La parte inicial de una señal de entrada que no se puede usar disponible.
• latencia de entrada en frío. El tiempo transcurrido entre el inicio de la transmisión y el momento en que se recibe la primera trama válida, cuando el sistema de entrada de audio ha estado inactivo y apagarse antes de la solicitud.

• latencia de entrada continua. La latencia de entrada para los fotogramas posteriores, mientras el dispositivo captura audio.

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

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

• API de audio nativo de AAudio. El conjunto de APIs de AAudio en el NDK de Android.

• Marca de tiempo: Un par compuesto por una posición relativa de marco dentro de una de transmisión y el tiempo estimado cuando ese fotograma entra o sale de la de procesamiento de audio en el extremo asociado. Consulta también AudioTimestamp:

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

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

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

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

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

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

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

Si las implementaciones de dispositivos declaran android.hardware.audio.output, sucederá lo siguiente: SE RECOMIENDA cumplir o superar los siguientes requisitos:

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

Si las implementaciones en dispositivos cumplen con los requisitos anteriores, después de cualquier calibración, cuando se usa la API de audio nativo de AAudio, para salida continua y latencia de salida en frío en al menos un audio compatible de salida, son:

• [C-SR-5] SE RECOMIENDA ENRENDER informar el audio de baja latencia declarando Marca de función android.hardware.audio.low_latency.
• [C-SR-6] SE RECOMIENDA IMPORTANTE para cumplir con los requisitos de latencia baja audio mediante la API de AAudio.
• [C-SR-7] SE RECOMIENDA ENRENDIDAMENTE para garantizar que las transmisiones que AAUDIO_PERFORMANCE_MODE_LOW_LATENCY desde AAudioStream_getPerformanceMode(), el valor que devuelve AAudioStream_getFramesPerBurst() es menor o igual que el valor mostrado por android.media.AudioManager.getProperty(String) para la clave de propiedad AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Si las implementaciones en dispositivos no cumplen con los requisitos del audio de baja latencia, haz lo siguiente: con la API de audio nativo de AAudio, pueden:

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

Si las implementaciones de dispositivos incluyen android.hardware.microphone, DEBE cumplir con estos requisitos de audio de entrada:

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

Si las implementaciones de dispositivos incluyen android.hardware.microphone, son SE RECOMIENDA COMPLETAMENTE cumplir con estos requisitos de audio de entrada:

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

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

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

• [C-SR-12] SE RECOMIENDA ENRENDIDAMENTE que tengan una latencia continua media de ida y vuelta de 50 milisegundos o menos en 5 mediciones, con una desviación absoluta media menos de 10 ms, en al menos una ruta admitida.

5.7. Protocolos de red

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

Por cada códec y formato de contenedor en el que se requiere la implementación de un dispositivo la implementación de dispositivos:

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

• [C-1-2] DEBE admitir los formatos de segmentos de medios correspondientes, como se muestra en la tabla de formatos de segmento de medios sobre Protocolo de borrador de transmisión en vivo HTTP, versión 7.

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

Formatos de segmentos de medios

Formatos de segmentos	Referencias	Compatibilidad con códecs requeridos
MPEG-2 Transport Stream	ISO 13818	Códecs de video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sección 5.1.8 para obtener detalles sobre H264 AVC, MPEG2-4 SP, y MPEG-2. Códecs de audio: AAC Consulta la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
AAC con enmarcado ADTS y etiquetas ID3	ISO 13818‐7	Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
WebVTT	WebVTT

RTSP (RTP, SDP)

Nombre del perfil	Referencias	Compatibilidad con códecs requeridos
H264 AVC	RFC 6184	Consulta la sección 5.1.8 para obtener información detallada sobre H264 AVC
MP4A-LATM	RFC 6416	Consulta la sección 5.1.3 para obtener detalles sobre AAC y sus variantes
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulta la sección 5.1.8 para obtener detalles sobre H263.
H263-2000	RFC 4629	Consulta la sección 5.1.8 para obtener detalles sobre H263.
AMR	RFC 4867	Consulta la sección 5.1.3 para obtener detalles sobre AMR-NB
AMR-WB	RFC 4867	Consulta la sección 5.1.3 para obtener detalles sobre AMR-WB
MP4V‐ES	RFC 6416	Consulta la sección 5.1.8 para obtener información detallada sobre MPEG-4 SP
MPEG-4-genérico	RFC 3640	Consulta la sección 5.1.3 para obtener detalles sobre AAC y sus variantes
MP2T	RFC 2250	Consulta MPEG-2 Transport Stream debajo de HTTP Live Streaming para obtener más detalles.

5.8. Contenido multimedia seguro

Si las implementaciones de dispositivos admiten salida de video segura y son capaces de que admiten plataformas seguras:

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

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y compatibilidad protocolo de pantalla inalámbrica, les permiten hacer lo siguiente:

• [C-2-1] DEBE asegurar el vínculo con un mecanismo criptográfico sólido como como HDCP 2.x o superior para las pantallas conectadas a través de protocolos inalámbricos como Miracast.

Si las implementaciones de dispositivos declaran la compatibilidad con Display.FLAG_SECURE y admiten pantallas externas con cable, tienen las siguientes características:

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

5.9 Interfaz digital para instrumentos musicales (MIDI)

Si las implementaciones de dispositivos informan compatibilidad con la función android.software.midi mediante el android.content.pm.PackageManager clase, deben hacer lo siguiente:

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

  • Modo de host USB, sección 7.7
  • Funcionamiento central de MIDI por Bluetooth de bajo consumo (sección 7.4.3)

• [C-1-2] DEBE admitir el transporte de software MIDI entre apps (dispositivos MIDI virtuales)

• [C-1-3] DEBE incluir libamidi.so (compatibilidad nativa con MIDI)

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

5.10. Audio profesional

Si las implementaciones de dispositivos informan compatibilidad con la función android.hardware.audio.pro mediante el android.content.pm.PackageManager clase, deben hacer lo siguiente:

• [C-1-1] DEBE informar de la compatibilidad con la función. android.hardware.audio.low_latency
• [C-1-2] DEBE tener la latencia de audio de ida y vuelta continua, como se define en sección 5.6 Latencia de audio de 25 milisegundos o menos en al menos una ruta admitida.
• [C-1-3] DEBE incluir uno o más puertos USB que admitan el modo de host USB y USB modo periférico.
• [C-1-4] DEBE informar la compatibilidad con la función android.software.midi.
• [C-1-5] DEBE cumplir con los requisitos de latencia y audio USB con el Audio nativo de AAudio API y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] DEBE tener una latencia de salida en frío de 200 milisegundos o menos.
• [C-1-7] DEBE tener una latencia de entrada en frío de 200 milisegundos o menos.

• [C-1-8] DEBE tener una latencia promedio de Tono para presionar de 80 milisegundos o menos. más de 5 mediciones a través de la ruta de datos de la bocina al micrófono.

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

• [C-SR-2] SE RECOMIENDA COMPLETAMENTE cumplir con los requisitos de Pro Audio para latencia de audio de ida y vuelta continua, latencia de entrada en frío y salida en frío latencia y requisitos de audio USB con la API de audio nativo de AAudio sobre la ruta MMAP.

• [C-SR-3] SE RECOMIENDA IMPORTANTEMENTE para proporcionar un nivel coherente de CPU el rendimiento mientras el audio está activo y la carga de la CPU varía. Esto se debe probar con la app para Android SynthMark. SynthMark usa un sintetizador de software que se ejecuta en un framework de audio simulado. que mide el rendimiento del sistema. Consulta la Documentación de SynthMark para obtener una explicación de las comparativas. SynthMark la aplicación debe ejecutarse con “Prueba automatizada” y logren los siguientes resultados:

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

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

• SE RECOMIENDA minimizar el desvío del reloj de audio relacionado con la CPU CLOCK_MONOTONIC cuando ambos están activos.

• SE DEBE minimizar la latencia de audio en los transductores integrados en el dispositivo.

• SE DEBE minimizar la latencia de audio mediante audio digital USB.

• SE RECOMIENDA documentar las mediciones de latencia de audio en todas las rutas de acceso.

• SE RECOMIENDA minimizar el jitter en los tiempos de entrada de devolución de llamada de finalización del búfer de audio, ya que afecta el porcentaje utilizable del ancho de banda total de la CPU por parte de la devolución de llamada.

• SE DEBE proporcionar cero fallas de audio en condiciones de uso normal con la latencia informada.

• SE DEBE proporcionar una diferencia de latencia entre canales de cero.

• DEBES minimizar la latencia media de MIDI en todos los transportes.

• SE RECOMIENDA minimizar la variabilidad de la latencia MIDI bajo carga (jitter) en todos los transportes.

• DEBERÍAS proporcionar marcas de tiempo MIDI precisas en todos los transportes.

• SE RECOMIENDA minimizar el ruido de la señal de audio a través de los transductores integrados en el dispositivo, incluido el inmediatamente después del inicio en frío.

• SE DEBE proporcionar una diferencia de reloj de audio de cero entre los lados de entrada y salida de con los extremos correspondientes cuando ambos están activos. Ejemplos de consultas los extremos incluyen el micrófono y la bocina integrados en el dispositivo o la entrada de conector de audio y salida.

• DEBE controlar las devoluciones de llamada de finalización del búfer de audio para los lados de entrada y salida. de extremos correspondientes en el mismo subproceso cuando ambos están activos y, luego, la devolución de llamada de salida inmediatamente después del retorno de la devolución de llamada de entrada. O Si no es posible manejar las devoluciones de llamada en el mismo subproceso, ingresa el de salida poco después de ingresar la devolución de llamada de entrada para permitir de la aplicación tenga una sincronización coherente en los extremos de entrada y salida.

• Se recomienda minimizar la diferencia de fase entre el almacenamiento en búfer de audio de HAL para la entrada y lados de salida de los extremos correspondientes.

• SE DEBE minimizar la latencia táctil.

• SE DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).

Si las implementaciones de dispositivos cumplen con todos los requisitos anteriores, sucederá lo siguiente:

• [C-SR-4] SE RECOMIENDA ENRENDER que informes la compatibilidad con la función android.hardware.audio.pro por el android.content.pm.PackageManager clase.

Si las implementaciones de los dispositivos incluyen un conector de audio de 4 conductores de 3.5 mm, sucede lo siguiente:

• [C-2-1] DEBE tener una latencia de audio de ida y vuelta continua media, como se define en sección 5.6 Latencia de audio, de 20 milisegundos o menos, más de 5 mediciones con una desviación absoluta media inferior a 5 milisegundos la ruta del conector de audio con un Llave de bucle invertido de audio.

• [C-SR-5] RECOMENDACIÓN ENERGENTE de cumplir con Sección Especificaciones del dispositivo móvil (conector) de la Especificación de auriculares de audio con cable (v1.1).

Si las implementaciones del dispositivo omiten un conector de audio de 4 conductores de 3,5 mm y incluyen uno o varios puertos USB compatibles con el modo de host USB, pueden:

• [C-3-1] SE DEBE implementar la clase de audio USB.
• [C-3-2] DEBE tener una latencia de audio de ida y vuelta continua promedio de 25 milisegundos o menos, más de 5 mediciones con una desviación absoluta media Menos de 5 milisegundos en el puerto USB del modo de host con la clase de audio USB. (Se puede medir con un adaptador USB de 3.5 mm y un bucle invertido de audio. un adaptador o una interfaz de audio USB con cables de conexión que conectan el entradas a salidas).
• [C-SR-6] SE RECOMIENDA EXITOSAMENTE para admitir la E/S simultánea de hasta 8 canales. en cada dirección, una tasa de muestreo de 96 kHz y una profundidad de 24 bits o 32 bits, cuando se usa con periféricos de audio USB que también admiten estos requisitos.
• [C-SR-7] SE RECOMIENDA ENERCMENTE cumplir con este grupo de requisitos mediante la API de audio nativo de AAudio a través de la ruta de acceso MMAP.

Si las implementaciones de dispositivos incluyen un puerto HDMI, sucederá lo siguiente:

• DEBE admitir salida en estéreo y en ocho canales a 20 bits o Profundidad de 24 bits y 192 kHz sin pérdida de profundidad de bits ni remuestreo en al menos una configuración.

5.11. Captura para contenido sin procesar

Android admite la grabación de audio sin procesar a través del Fuente de audio de android.media.MediaRecorder.AudioSource.UNPROCESSED. En OpenSL ES, se puede acceder con el ajuste predeterminado de grabación. SL_ANDROID_RECORDING_PRESET_UNPROCESSED

Si las implementaciones del dispositivo intentan admitir fuentes de audio sin procesar y hacer que está disponible para apps de terceros:

• [C-1-1] SE DEBE informar la asistencia a través del android.media.AudioManager. propiedad PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DEBE mostrar una amplitud frente a frecuencia plana aproximadamente. en el rango de frecuencia media: específicamente ±10 dB de 100 Hz a 7,000 Hz para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio.

• [C-1-3] DEBE exhibir niveles de amplitud en la frecuencia baja. específicamente de ±20 dB de 5 z a 100 Hz en comparación con rango de frecuencia media para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

• [C-1-4] DEBE exhibir niveles de amplitud en alta frecuencia. específicamente de ±30 dB de 7000 Hz a 22 KHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

• [C-1-5] SE DEBE establecer la sensibilidad de entrada de audio de modo que una frecuencia sinusoidal de 1,000 Hz tomada a un nivel de presión sonora (SPL) de 94 dB arroja una respuesta con RMS de 520 para muestras de 16 bits (o -36 dB de escala completa para punto flotante/doble) muestras de precisión) para todos y cada uno de los micrófonos que se usaron para grabar la fuente de audio.

• [C-1-6] DEBE tener una relación señal/ruido (SNR) de 60 dB o superior para todos y cada uno de los micrófonos que se usan para grabar la fuente de audio sin procesar. (mientras que la SNR se mide como la diferencia entre 94 dB de SPL y una SPL de ruido propio, ponderado A).

• [C-1-7] DEBE tener una distorsión armónica total (THD) menor que 1% para 1 kHZ a un nivel de entrada de SPL de 90 dB en cada uno de los micrófonos que se utilizan para grabar la fuente de audio sin procesar.

• [C-1-8] No DEBE tener otro procesamiento de señal (p. ej., ganancia automática). control, filtro de paso alto o cancelación de eco) en la ruta que no sea un multiplicador de niveles para llevar el nivel al rango deseado. En otras palabras:

  • [C-1-9] Si hay procesamiento de señal presente en la arquitectura para cualquier por el motivo, DEBE inhabilitarse e introducir de manera eficaz un retraso nulo o latencia adicional en la ruta de acceso de la señal.
  • [C-1-10] Si bien el multiplicador de nivel puede estar en el camino, NO DEBE ingresar retraso o latencia a la ruta de acceso de la señal.

Todas las mediciones del SPL se realizan directamente junto al micrófono que se está probando. Para varias configuraciones de micrófono, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone, pero no lo hacen admiten fuentes de audio sin procesar, son las siguientes:

• [C-2-1] DEBE devolver null para el AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED). método de API, para indicar correctamente la falta de compatibilidad.
• Aún se RECOMIENDA [C-SR-1] para satisfacer la mayor cantidad de requisitos para la ruta de acceso de la señal para la fuente de registro no procesada.

5.12. Video HDR

Android 13 admite las tecnologías HDR como se describe en un documento próximo.

Formato de píxeles

Si un decodificador de video anuncia la compatibilidad con COLOR_FormatYUVP010, entonces:

• [C-1-1] DEBE admitir el formato P010 para operaciones de lectura de CPU (ImageReader, MediaImage, ByteBuffer). En Android 13, se relaja el P010 para permitir el segmento arbitrario para el Y y planos UV.

• [C-1-2] La GPU DEBE tener el muestreo del búfer de salida P010 (cuando asignada con el uso de GPU_SAMPLING). Esto habilita la composición de GPU y y la asignación de tonos por parte de apps.

Si un decodificador de video indica la compatibilidad con COLOR_Format32bitABGR2101010, sucede lo siguiente:

• [C-2-1] DEBE admitir el formato RGBA_1010102 para la superficie de salida y Legible por la CPU (salida de ByteBuffer).

Si un codificador de video indica que es compatible con COLOR_FormatYUVP010, sucede lo siguiente:

• [C-3-1] DEBE admitir el formato P010 para la superficie de entrada y la capacidad de escritura en la CPU. (ImageWriter, MediaImage, ByteBuffer).

Si un codificador de video indica que es compatible con COLOR_Format32bitABGR2101010, sucede lo siguiente:

• [C-4-1] DEBE admitir el formato RGBA_1010102 para la superficie de entrada y la capacidad de escritura en la CPU. (ImageWriter, ByteBuffer). Nota: Conversión entre varias transferencias para los codificadores.

Requisitos de la captura HDR

Para todos los codificadores de video compatibles con perfiles HDR, las implementaciones en dispositivos deben cumplir con lo siguiente:

• [C-5-1] NO DEBE suponer que los metadatos de HDR son precisos. Por ejemplo, el puede tener píxeles superiores al nivel de luminancia máximo, o es posible que el histograma no sea representativo del fotograma.

• SE DEBE agregar metadatos dinámicos de HDR para generar imágenes estáticas de HDR adecuadas. metadatos para transmisiones codificadas, y deben emitirlos al final de cada sesión de codificación.

Si las implementaciones de dispositivos admiten la captura HDR con las APIs de CamcorderProfile entonces:

• [C-6-1] también DEBE admitir la captura HDR a través de las APIs de Camera2.

• [C-6-2] DEBE admitir al menos un codificador de video acelerado por hardware para cada tecnología HDR compatible.

• [C-6-3] DEBE admitir (como mínimo) la captura HLG.

• [C-6-4] DEBE admitir la escritura de los metadatos de HDR (si corresponde al HDR). tecnología) en el archivo de video capturado. Para AV1, HEVC y DolbyVision esto significa incluir los metadatos en el flujo de bits codificado.

• [C-6-5] DEBE admitir P010 y COLOR_FormatYUVP010.

• [C-6-6] DEBE ser compatible con la asignación de tonos de HDR a SDR en la configuración predeterminada. con aceleración de hardware para el perfil capturado. En otras palabras, Si un dispositivo puede capturar HDR10+ HEVC, el decodificador HEVC predeterminado DEBE tener para decodificar la transmisión capturada en SDR.

Requisitos para la edición HDR

Si las implementaciones en dispositivos incluyen codificadores de video compatibles con la edición HDR, hace lo siguiente:

• DEBES usar una latencia mínima para generar metadatos de HDR cuando no estén presentes. y DEBERÍA manejar correctamente las situaciones en las que los metadatos están presentes para algunos y no para otros. Estos metadatos DEBEN ser precisos (por ejemplo, representa la luminancia máxima real y el histograma real del fotograma).

Si la implementación de dispositivos incluye códecs que admiten FEATURE_HdrEditing, entonces esos códecs:

• [C-7-1] DEBE admitir al menos un perfil HDR.

• [C-7-2] DEBE admitir FEATURE_HdrEditing para todos los perfiles HDR anunciados por ese códec. En otras palabras, DEBEN admitir la generación de metadatos HDR cuando no está presente para todos los perfiles HDR compatibles que usan metadatos HDR.

• [C-7-3] DEBE ser compatible con los siguientes formatos de entrada de codificador de video que conservar la señal decodificada HDR:

  • RGBA_1010102 (ya en la curva de transferencia de destino) para ambas entradas. plataforma y ByteBuffer, y DEBE anunciar la compatibilidad con COLOR_Format32bitABGR2101010;

Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, el dispositivo:

• [C-7-4] DEBE anunciar compatibilidad con la extensión de OpenGL EXT_YUV_target.

6. Compatibilidad de las Herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con las herramientas para desarrolladores de Android que se proporcionan en el de Google Cloud.

• Android Debug Bridge (adb)

  • [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y en la shell. comandos proporcionados en el AOSP, que pueden usar los desarrolladores de apps, incluido dumpsys cmd stats
  • [C-0-11] DEBE admitir el comando de shell cmd testharness. Actualización implementaciones de dispositivo de una versión anterior de Android sin un el bloque de datos persistentes PUEDE estar exento de C-0-11.
  • [C-0-3] NO DEBE alterar el formato ni el contenido del sistema del dispositivo. eventos (batterystats , diskstats, huella digital, graphicsstats, netstats, notificación, procstats) registrada con el comando dumpsys.
  • [C-0-10] DEBE grabar, sin omisiones, y realizar los siguientes eventos. accesible y disponible para el comando de shell cmd stats y el Clase de API del sistema StatsManager.
    • ActivityForegroundStateChanged
    • Anomalía detectada
    • Informado por rutas de navegación de aplicaciones
    • Falla de la app
    • Inicio de la aplicación
    • Nivel de batería cambiado
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • Cambio de estado de carga
    • ModificaciónDeEstadoDeModoIddeDispositivos.
    • ForegroundServiceStateChanged
    • Modificación del estado del objeto GPSScan
    • Cambio de estado del trabajo
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • Cambio de estado de pantalla
    • Estado de sincronización cambiado
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • Modificación del estado de bloqueo de activación
    • Se produjo la alarma de despertador
    • Modificación del estado de bloqueo de Wi-Fi
    • Wi-FiMulticastLockStateChanged
    • Wi-FiScanStateChanged
  • [C-0-4] DEBE tener el daemon adb del dispositivo estar inactivo de forma predeterminada y DEBE haber un mecanismo al que el usuario pueda acceder para activar Android Debug puente.
  • [C-0-5] DEBE admitir adb seguro. Android incluye compatibilidad con sistemas adb adb seguro habilita adb en hosts autenticados conocidos.
  • [C-0-6] DEBE proporcionar un mecanismo que permita conectar adb desde un máquina anfitrión. Más precisamente:

  Si las implementaciones de dispositivos sin un puerto USB admiten el modo periférico, sucederá lo siguiente:

  • [C-3-1] DEBE implementar adb a través de una red de área local (como Ethernet). o Wi-Fi).
  • [C-3-2] DEBE proporcionar controladores para Windows 7, 8 y 10, lo que permite los desarrolladores se conecten al dispositivo usando el protocolo adb.

  Si las implementaciones de dispositivos admiten conexiones adb a una máquina anfitrión a través de Wi-Fi o Ethernet:

  • [C-4-1] DEBE tener el método AdbManager#isAdbWifiSupported(). Se muestra true.

  Si las implementaciones de dispositivos admiten conexiones adb a una máquina anfitrión a través de Wi-Fi o Ethernet, y incluye al menos una cámara, estos:

  • [C-5-1] DEBE tener el método AdbManager#isAdbWifiQrSupported(). Se muestra true.

• Servicio Dalvik Debug Monitor (ddms)

  • [C-0-7] DEBE admitir todas las funciones de DDMS, tal como se documenta en el SDK de Android. Como ddms usa adb, la compatibilidad con DDMS DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario active Android Debug Bridge, como se muestra arriba.

• SysTrace

  • [C-0-9] DEBE admitir la herramienta systrace tal como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un servidor accesible para el usuario mecanismo para activar Systrace.

• Perfetto

  • [C-SR-1] SE RECOMIENDA EXITOSAMENTE que expongan un /system/bin/perfetto. binario al usuario de shell y cmdline cumple la documentación de perfetto.
  • [C-SR-2] SE RECOMIENDA EL SOFTWARE OFICIAL DE perfetto para aceptarlo como entrada configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [C-SR-3] Se RECOMIENDA EL PERFECTO Y EL Objeto binario perfetto para que escriba como salida una seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto.
  • [C-SR-4] SE RECOMIENDA COMPLETAMENTE proporcionar, a través del objeto binario perfetto, al menos, las fuentes de datos descritas en la documentación de perfetto.

• Optimizador de memoria baja

  • [C-0-12] SE DEBE escribir un Atom LMK_KILL_OCCURRED_FIELD_NUMBER en la registro Statsd cuando el optimizador de poca memoria finaliza una app.

• Modo de agente de prueba Si las implementaciones del dispositivo admiten el comando shell cmd testharness y ejecuta cmd testharness enable, hace lo siguiente:

  • [C-2-1] DEBE devolver true por ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DEBE implementar el modo de agente de prueba como se describe en Documentación del modo de agente de prueba.

• Información del trabajo de la GPU

  Implementaciones en dispositivos:

  • [C-0-13] DEBE implementar el comando de shell dumpsys gpu --gpuwork para mostrar Los datos agregados del trabajo de la GPU que muestra el kernel power/gpu_work_period tracepoint o no mostrar datos si este no es compatible. AOSP implementación es frameworks/native/services/gpuservice/gpuwork/.

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o superior a través del Las marcas de función de android.hardware.vulkan.version hacen lo siguiente:

• [C-1-1] DEBE proporcionar una indicación visual para que el desarrollador de la app habilite o inhabilite. Capas de depuración de GPU
• [C-1-2] DEBE, cuando las capas de depuración de GPU están habilitadas, DEBE enumerar las capas en bibliotecas proporcionadas por herramientas externas (es decir, que no sean parte de la plataforma o paquete de aplicación) que se encuentran en aplicaciones depurables directorio base a compatibilidad con vkEnumerateInstanceLayerProperties() y vkCreateInstance() métodos de API.

6.2. Opciones para desarrolladores

Android admite que los desarrolladores configuren configuración relacionada con el desarrollo.

Las implementaciones en dispositivos DEBEN proporcionar una experiencia coherente para Opciones para desarrolladores:

• [C-0-1] DEBE respetar el android.settings.APPLICATION_DEVELOPMENT_CONFIGURACIÓN para mostrar la configuración relacionada con el desarrollo de aplicaciones. El servicio upstream de Android implementación oculta el menú Opciones para desarrolladores de forma predeterminada y permite a los usuarios Inicia las Opciones para desarrolladores después de presionar siete (7) veces en Configuración > Acerca del dispositivo > Elemento de menú Número de compilación.
• [C-0-2] DEBE ocultar las Opciones para desarrolladores de forma predeterminada.
• [C-0-3] DEBE brindar un mecanismo claro que no brinde preferencias tratamiento a una app de terceros en lugar de otra para permitir que las Opciones. DEBE proporcionar un documento o sitio web visible públicamente que describa cómo habilita Opciones para desarrolladores. Este documento o sitio web SE DEBE vincular desde los documentos del SDK de Android.
• DEBERÍA tener una notificación visual continua para el usuario cuando el Las opciones están habilitadas y la seguridad del usuario es motivo de preocupación.
• PUEDE limitar temporalmente el acceso al menú Opciones para desarrolladores, mediante imágenes ocultar o inhabilitar el menú, para evitar la distracción en situaciones en las que la la seguridad del usuario es algo que nos preocupa.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware específico que tiene un API para desarrolladores externos:

• [C-0-1] La implementación del dispositivo DEBE implementar eso. API como se describe en la documentación del SDK de Android.

Si una API en el SDK interactúa con un componente de hardware que se indica como opcional y el la implementación del dispositivo no posee ese componente:

• [C-0-2] Definiciones de la clase completas (según se documentan en el SDK) para el componente Las APIs se DEBEN presentar.
• [C-0-3] Los comportamientos de la API DEBEN implementarse como no-ops en algunas operaciones a la moda.
• [C-0-4] Los métodos de API DEBEN mostrar valores nulos cuando el SDK lo permita en la documentación de Google Cloud.
• [C-0-5] Los métodos de API DEBEN mostrar implementaciones no-op de clases con valores nulos no están permitidos en la documentación del SDK.
• [C-0-6] Los métodos de la API NO DEBEN generar excepciones no documentadas por el SDK en la documentación de Google Cloud.
• [C-0-7] Las implementaciones en dispositivos DEBEN informar de manera coherente la precisión del hardware información de configuración a través de getSystemAvailableFeatures() y métodos hasSystemFeature(String) en la android.content.pm.PackageManager para la misma huella digital de compilación.

Un ejemplo típico de una situación en la que se aplican estos requisitos es la de API: Incluso en dispositivos que no sean teléfonos, estas APIs deben implementarse de la forma no-ops.

7.1. Pantalla y gráficos

Android incluye servicios que ajustan automáticamente los recursos de aplicación y la IU adecuados para el dispositivo a fin de garantizar que las aplicaciones de terceros se ejecutan bien en una variedad de configuraciones de hardware. una variedad de pantallas y configuraciones de hardware. Los Una pantalla compatible con Android es una pantalla que implementa todas las los comportamientos y las APIs que se describen en Android Developers: Compatibilidad de pantalla general, este sección (7.1) y sus subsecciones, así como cualquier tipo de comportamientos específicos documentados en la sección 2 de este CDD. En las pantallas compatibles con Android en las que todos los dispositivos de terceros las aplicaciones puedan ejecutarse, las implementaciones en dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

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

• tamaño diagonal físico. La distancia en pulgadas entre dos opuestos esquinas de la parte iluminada de la pantalla.
• puntos por pulgada (dpi)densidad. Es la cantidad de píxeles que abarca una línea intervalo horizontal o vertical de 2,5 cm, expresado en píxeles por pulgada (ppp o DPI). Donde dpi ppi y dpi, los DPI horizontal y vertical deben estar dentro de los valores de la lista del rango de destino de la ruta.
• relación de aspecto. Proporción entre los píxeles de la dimensión más larga y la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480 x 854 píxeles puede ser 854/480 = 1.779, o aproximadamente “16:9”.
• píxel independiente de la densidad (dp). El Una unidad de píxeles virtuales normalizado en una pantalla de 160 dpi densidad de pantalla de 160. Para algo de densidad d y un número de píxeles p, la cantidad de píxeles independientes de la densidad dp, es se calcula de la siguiente manera: píxeles = dps * (densidad/160) dp = (160 / d) * p .

7.1.1 Configuración de pantalla

7.1.1.1. Tamaño y forma de la pantalla

El framework de la IU de Android admite una variedad de diseños de pantalla lógicos diferentes. y permite a las aplicaciones consultar la pantalla de la configuración actual tamaño del diseño a través de Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK y Configuration.smallestScreenWidthDp.

Implementaciones en dispositivos:

• [C-0-1] SE DEBE informar el tamaño de diseño correcto para el Configuration.screenLayout, como se define en la documentación del SDK de Android. Específicamente, las implementaciones en dispositivos DEBEN informar dimensiones de la pantalla de píxeles independientes de la densidad (dp), como se muestra a continuación:

  • Dispositivos con el Configuration.uiMode configurado como cualquier valor distinto de UI_MODE_TYPE_WATCH e informa un tamaño small para el Configuration.screenLayout, DEBE tener, al menos, 426 dp x 320 dp.
  • Dispositivos que informan un tamaño de normal para el Configuration.screenLayout, DEBE tener, al menos, 480 dp x 320 dp.
  • Dispositivos que informan un tamaño de large para el Configuration.screenLayout, DEBE tener, al menos, 640 dp x 480 dp.
  • Dispositivos que informan un tamaño de xlarge para el Configuration.screenLayout, DEBE tener, al menos, 960 dp x 720 dp.

• [C-0-2] DEBE respetar correctamente las aplicaciones indicó compatibilidad con tamaños de pantalla mediante <supports-screens> en el archivo AndroidManifest.xml, como se describe en la documentación del SDK de Android.

• PUEDE tener pantallas compatibles con Android con esquinas redondeadas.

Si las implementaciones de dispositivos admiten pantallas capaces de hacer lo siguiente: Configuración del tamaño de UI_MODE_TYPE_NORMAL y incluyen dispositivos Android usar pantallas físicas con esquinas redondeadas para renderizar estas pantallas, hace lo siguiente:

• [C-1-1] DEBE asegurarse de que al menos uno de los siguientes requisitos se cumple en cada pantalla:

  • El radio de las esquinas redondeadas es menor o igual que 38 dp.
  • Cuando a 15an 18 dp por 1518 cuadro dp está anclado en cada esquina de la pantalla lógica, al menos una el píxel de cada cuadro sea visible en la pantalla.

• SE RECOMIENDA incluir la indicación visual del usuario para cambiar al modo de visualización con los esquinas rectangulares.

Para obtener más información sobre la implementación correcta de las APIs de sidecar o de extensión, consulta la documentación pública de Window Manager Jetpack.

7.1.1.3. Densidad de la pantalla

El framework de la IU de Android define un conjunto de densidades lógicas estándar para ayudar desarrolladores de aplicaciones se orientan a los recursos de la aplicación.

Implementaciones en dispositivos:

• [C-0-1] De forma predeterminada, las implementaciones en dispositivos DEBE informar solo uno de los del framework de Android que se enumeran en DisplayMetrics a través de la API de DENSITY_DEVICE_STABLE y este valor debe ser un valor estático para cada pantalla física. NO DEBE cambiar en ningún momento. Sin embargo, Sin embargo, PUEDE QUE el dispositivo informar una densidad arbitraria diferente DisplayMetrics.density de acuerdo con los cambios en la configuración de pantalla que hizo el usuario (para ejemplo, tamaño de visualización) establecido después del inicio inicial.

Si las implementaciones de dispositivos proporcionan existe una indicación visual cambiar el tamaño de visualización del dispositivo ,

• [C-1-1] El tamaño de la pantalla NO se DEBE ajustar NO SE DEBE ajustar el tamaño de la pantalla. superior a 1.5 veces la DENSITY_DEVICE_STABLE densidad nativa o producir una dimensión de pantalla mínima eficaz inferior a 320 dp (equivalente al calificador de recursos sw320dp), lo que ocurra primero.
• [C-1-2] El tamaño de la pantalla NO se DEBE ajustar NO SE DEBE ajustar el tamaño de la pantalla. inferior a 0.85 veces la densidad nativa de la DENSITY_DEVICE_STABLE.
• Para garantizar una buena usabilidad y tamaños de fuente coherentes, SE RECOMIENDA que el el escalamiento de las opciones de anuncios gráficos nativos (siempre que se cumplan los límites) especificadas anteriormente)
  • Pequeño: 0.85x
  • Predeterminado: 1x (escala de visualización nativa)
  • Grande: 1.15x
  • Más grande: 1.3 veces
  • Mayor 1.45 veces

7.1.2. Métricas de Display

Si las implementaciones en dispositivos incluyen pantallas compatibles con Android o salida de video en pantallas compatibles con Android:

• [C-1-1] SE DEBE informar los valores correctos para todas las pantallas compatibles con Android. métricas definidas en el API de android.util.DisplayMetrics.

Si las implementaciones en dispositivos no incluyen una pantalla incorporada o salida de video, hacen lo siguiente:

• [C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android. como se define en la API de android.util.DisplayMetrics para el view.Display predeterminado emulado.

7.1.3 Orientación de pantalla

Implementaciones en dispositivos:

• [C-0-1] DEBE informar qué orientaciones de pantalla admite. (android.hardware.screen.portrait o android.hardware.screen.landscape) y DEBE informar, al menos, uno de los casos orientación. Por ejemplo, un dispositivo con una orientación horizontal fija como un televisor o una computadora portátil, solo DEBERÁ informar android.hardware.screen.landscape.
• [C-0-2] SE DEBE informar el valor correcto para el valor actual del de orientación cuando se realice una consulta a través del android.content.res.Configuration.orientation, android.view.Display.getOrientation() o alguna otra API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla, sucederá lo siguiente:

• [C-1-1] DEBE admitir la orientación dinámica de las aplicaciones a pantalla horizontal o vertical. orientación. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una pantalla específica orientación.
• [C-1-2] NO DEBE cambiar la densidad o el tamaño de pantalla informados cuando se cambia la orientación.
• PUEDES seleccionar la orientación vertical u horizontal como opción predeterminada.

7.1.4. Aceleración de gráficos 2D y 3D

7.1.4.1 OpenGL ES

Implementaciones en dispositivos:

• [C-0-1] DEBE identificar correctamente las versiones de OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) a través de las APIs administradas (por ejemplo, a través del GLES10.getString()) y las APIs nativas.
• [C-0-2] DEBE incluir compatibilidad con todas las APIs administradas correspondientes y APIs nativas para cada versión de OpenGL ES que identificaban.

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

• [C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, tal como se incluye y se detalla en la documentación del SDK de Android.
• [C-SR-1] SE RECOMIENDA ENcarecidamente que sean compatibles con OpenGL ES 3.1.
• SE DEBE admitir OpenGL ES 3.2.

Las pruebas dEQP de OpenGL ES se dividen en varias listas de prueba, cada una con una fecha o número de versión asociado. Están en el árbol de fuentes de Android en external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt Un dispositivo que es compatible con OpenGL ES, esto indica que puede pasar el en todas las listas de prueba de este nivel y de versiones anteriores.

Si las implementaciones de dispositivos admiten alguna de las versiones de OpenGL ES, sucederá lo siguiente:

• [C-2-1] SE DEBE informar a través de las APIs administradas y las APIs nativas de OpenGL ES, cualquiera otras extensiones de OpenGL ES que hayan implementado y, a la inversa, DEBEN NO informar cadenas de extensión que no admitan.
• [C-2-2] DEBE admitir EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable y EGL_ANDROID_GLES_layers.
• [C-2-3] SE DEBE informar la versión máxima de las pruebas dEQP de OpenGL ES compatible con la marca de función android.software.opengles.deqp.level.
• [C-2-4] DEBE, al menos, admitir la versión 132383489 (del 1 de marzo de 2020), ya que se informa en la marca de función android.software.opengles.deqp.level.
• [C-2-5] DEBE superar todas las pruebas de dEQP de OpenGL ES en las listas de prueba entre las versiones 132383489 y la versión especificada en el Marca de función android.software.opengles.deqp.level para cada función compatible Versión de OpenGL ES.
• [C-SR-2] SON RECOMENDADAS EN FUERTE que respalden EGL_KHR_partial_update y OES_EGL_image_external extensiones.

• SE DEBE informar con precisión a través del método getString(), cualquier textura formato de compresión que admiten, que suele ser específico del proveedor.

• SE DEBE admitir EGL_IMG_context_priority y EGL_EXT_protected_content extensiones.

Si las implementaciones de dispositivos declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2, suceden lo siguiente:

• [C-3-1] DEBE exportar los símbolos de función correspondientes para estas versiones en además de los símbolos de la función OpenGL ES 2.0 en la biblioteca libGLESv2.so.
• [C-SR-3] SE RECOMIENDA EXITOSAMENTE que respalden el OES_EGL_image_external_essl3 .

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

• [C-4-1] DEBE admitir el paquete de extensiones de Android para OpenGL ES en su totalidad.

Si las implementaciones de dispositivos admiten el Android Extension Pack de OpenGL ES en su en su totalidad, hacen lo siguiente:

• [C-5-1] SE DEBE identificar la asistencia a través del android.hardware.opengles.aep marca de función.

Si las implementaciones de dispositivos exponen la compatibilidad con EGL_KHR_mutable_render_buffer de la extensión, hacen lo siguiente:

• [C-6-1] también DEBE admitir EGL_ANDROID_front_buffer_auto_refresh. .

7.1.4.2 Vulkan

Android admite Vulkan. , una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento.

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

• [C-SR-1] SE RECOMIENDA ENERCMENTE incluir asistencia para Vulkan 1.3
• [C-4-1] NO DEBE admitir una versión de variante de Vulkan (es decir, la variante parte de la versión principal de Vulkan DEBE ser cero).

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

• [C-SR-2] SE RECOMIENDA ENERCMENTE incluir asistencia para Vulkan 1.3

Las pruebas de dEQP de Vulkan se dividen en varias listas, cada una con un fecha o versión asociada. Están en el árbol de fuentes de Android en external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt Un dispositivo que admite Vulkan en un nivel autoinformado, esto indica que puede pasar el en todas las listas de prueba de este nivel y de versiones anteriores.

Si las implementaciones en dispositivos son compatibles con Vulkan La versión 1.0 o una posterior hacen lo siguiente:

• [C-1-1] DEBE informar el valor de número entero correcto con el android.hardware.vulkan.level y android.hardware.vulkan.version marcas de función.
• [C-1-2] SE DEBE enumerar, al menos, un VkPhysicalDevice para Vulkan. API nativa vkEnumeratePhysicalDevices().
• [C-1-3] SE DEBE implementar por completo Vulkan 1.0. APIs de Vulkan 1.1 para cada una VkPhysicalDevice
• [C-1-4] SE DEBE enumerar las capas, contenidas en bibliotecas nativas denominadas como libVkLayer*.so en el directorio de la biblioteca nativa del paquete de la aplicación mediante las APIs nativas de Vulkan vkEnumerateInstanceLayerProperties() y vkEnumerateDeviceLayerProperties().
• [C-1-5] NO DEBE enumerar las capas proporcionadas por bibliotecas fuera del paquete de aplicación ni proporcionar otras formas de rastrear o interceptar el API de Vulkan, a menos que la aplicación tenga el atributo android:debuggable establecer como true o el metadato com.android.graphics.injectLayers.enable Se estableció en true .
• [C-1-6] DEBE informar todas las cadenas de extensión que sí admiten a través del APIs nativas de Vulkan y, por el contrario, NO DEBEN informar cadenas de extensión que no admiten correctamente.
• [C-1-7] DEBE admitir VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain. y VK_KHR_incremental_present.
• [C-1-8] SE DEBE informar la versión máxima de las pruebas de dEQP de Vulkan. compatible con la marca de función android.software.vulkan.deqp.level.
• [C-1-9] DEBE al menos admitir la versión 132317953 (a partir del 1 de marzo de 2019) como se informa en la marca de función android.software.vulkan.deqp.level.
• [C-1-10] DEBE superar todas las pruebas de dEQP de Vulkan en las listas de prueba entre versión 132317953 y la versión especificada en el La marca de función android.software.vulkan.deqp.level.
• [C-1-11] NO DEBE mencionar la compatibilidad con la VK_KHR_video_queue. VK_KHR_video_decode_queue o VK_KHR_video_encode_queue.
• [C-SR-3] SE RECOMIENDA EXITOSAMENTE que respalden el VK_KHR_driver_properties y VK_GOOGLE_display_timing.

• [C-1-12] NO DEBE mencionar la compatibilidad con la extensión VK_KHR_performance_query.

• [C-SR-4] SE RECOMIENDEN ENERGMENTE para cumplir con los requisitos especificados por el perfil de Android Baseline 2022.

Si las implementaciones en dispositivos no incluyen compatibilidad con Vulkan 1.0, sucederá lo siguiente:

• [C-2-1] NO DEBE declarar ninguna de las marcas de función de Vulkan (p.ej., android.hardware.vulkan.level y android.hardware.vulkan.version).
• [C-2-2] NO DEBE enumerar ningún VkPhysicalDevice para la API nativa de Vulkan. vkEnumeratePhysicalDevices()

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

• [C-3-1] DEBE exponer la compatibilidad con el semáforo y el controlador externos SYNC_FD. y la extensión VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Las implementaciones en dispositivos DEBEN admitir Android RenderScript, como se detalla. en la documentación del SDK de Android.

7.1.4.4 Aceleración de gráficos 2D

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D a nivel de la aplicación, la actividad Nivel de ventana o vista mediante una etiqueta de manifiesto android:hardwareAccelerated o llamadas directas a la API.

Implementaciones en dispositivos:

• [C-0-1] DEBE habilitar la aceleración de hardware de forma predeterminada y DEBE inhabilitar la aceleración de hardware si el desarrollador lo solicita estableciendo android:hardwareAccelerated="false” o cómo inhabilitar la aceleración de hardware directamente a través de las APIs de Android View.
• [C-0-2] DEBE exhibir un comportamiento coherente con el Documentación del SDK de Android sobre la aceleración de hardware

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas de OpenGL ES con aceleración de hardware como objetivos de renderización en una jerarquía de IU.

Implementaciones en dispositivos:

• [C-0-3] DEBE admitir la API de TextureView y DEBE exhibir comportamiento coherente con la implementación ascendente de Android.

7.1.4.5 Pantallas de amplia gama

Si las implementaciones de dispositivos afirman ser compatibles con pantallas de amplia gama a través de Configuration.isScreenWideColorGamut() :

• [C-1-1] DEBE tener una pantalla con calibración de color.
• [C-1-2] DEBE tener una pantalla cuyo gamut cubra el gamut de colores sRGB. completamente en el espacio CIE 1931 xyY.
• [C-1-3] DEBE tener una pantalla cuyo gamut tenga un área de al menos el 90% de DCI-P3 en el espacio CIE 1931 xyY.
• [C-1-4] SE DEBE admitir OpenGL ES 3.1 o 3.2, y se debe informar correctamente.
• [C-1-5] DEBE anunciar compatibilidad con EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear y EGL_EXT_gl_colorspace_display_p3_passthrough extensiones.
• [C-SR-1] SE RECOMIENDA ENERGENTE para admitir GL_EXT_sRGB.

Por el contrario, si las implementaciones de dispositivos no admiten pantallas de amplia gama, sucederá lo siguiente:

• [C-2-1] SE DEBE abarcar el 100% o más de sRGB en el espacio xyY de CIE 1931, aunque la gama de colores de la pantalla no está definida.

7.1.5 Modo de compatibilidad de aplicaciones heredadas

Android especifica un “modo de compatibilidad” en el que el framework opera en un 'normal' [normal] de tamaño de pantalla equivalente (320 dp de ancho) para el beneficio de la versión heredada. aplicaciones no desarrolladas para versiones anteriores de Android anteriores a la la independencia del tamaño de la pantalla.

7.1.6. Tecnología de pantalla

La plataforma de Android incluye API que permiten que las aplicaciones rendericen datos enriquecidos gráficos en una pantalla compatible con Android. Los dispositivos DEBEN admitir todas estas opciones APIs definidas por el SDK de Android, a menos que se permitan específicamente en este documento.

Todas las pantallas compatibles con Android de una implementación de dispositivo:

• [C-0-1] DEBE ser capaz de renderizar gráficos de colores de 16 bits.
• SE RECOMIENDA admitir pantallas que admitan gráficos de color de 24 bits.
• [C-0-2] DEBE ser capaz de renderizar animaciones.
• [C-0-3] DEBE tener una relación de aspecto de píxeles (PAR) entre 0.9 y 1.15. Es decir, la relación de aspecto de los píxeles DEBE ser cercana al cuadrado. (1.0) con una tolerancia del 10% al 15%.

7.1.7 Pantallas secundarias

Android admite pantallas secundarias compatibles con Android para habilitar. capacidades de uso compartido de contenido multimedia y APIs de desarrollador para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa, ya sea a través de un cable, inalámbrica o una conexión de pantalla adicional incorporada:

• [C-1-1] DEBE implementar la DisplayManager servicio del sistema y la API, como se describe en la documentación del SDK de Android.

7.2. Dispositivos de entrada

Implementaciones en dispositivos:

• [C-0-1] DEBE incluir un mecanismo de entrada, como un pantalla táctil o navegación no táctil, para navegar entre los elementos de la IU.

7.2.1. Teclado

Si las implementaciones en dispositivos admiten Editor de método de entrada (IME) permite hacer lo siguiente:

• [C-1-1] DEBE declarar el android.software.input_methods. marca de función.
• [C-1-2] DEBE implementar completamente Input Management Framework
• [C-1-3] DEBE tener un teclado en pantalla preinstalado.

Implementaciones en dispositivos:

• [C-0-1] NO DEBE incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.teclado. (QWERTY o 12 teclas).
• SE RECOMIENDA incluir implementaciones adicionales de teclado en pantalla.
• PUEDE incluir un teclado de hardware.

7.2.2. Navegación no táctil

Android incluye compatibilidad con pad direccional, bola de seguimiento y rueda como mecanismos para navegación no táctil.

Implementaciones en dispositivos:

• [C-0-1] SE DEBE informar el valor correcto para android.content.res.Configuration.navigation

Si las implementaciones de dispositivos no tienen navegaciones no táctiles, sucede lo siguiente:

• [C-1-1] DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para el selección y edición de texto, compatible con los motores de administración de entradas. El la implementación ascendente de código abierto de Android incluye un mecanismo de selección adecuado para su uso con dispositivos que carecen de entradas de navegación no táctiles.

7.2.3. Teclas de navegación

La Página principal, Recientes, y Atrás funciones que, por lo general, se proporcionan mediante la interacción con un botón físico exclusivo o una porción distinta de la pantalla táctil, son esenciales para el dispositivo paradigma de navegación y, por lo tanto, en las implementaciones en dispositivos:

• [C-0-1] DEBE proporcionar una indicación visual del usuario para iniciar las aplicaciones instaladas. que tengan una actividad con el elemento <intent-filter> configurado con ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para el dispositivo de televisión de Google Cloud. La función Inicio DEBE ser el mecanismo de esta indicación del usuario.
• SE DEBE proporcionar botones para las funciones Recientes y Atrás.

Si se proporcionan las funciones Inicio, Recientes o Atrás, significan lo siguiente:

• [C-1-1] SE DEBE poder acceder a él con una sola acción (por ejemplo, tocar, hacer doble clic o gesto) cuando cualquiera de ellos es accesible.
• [C-1-2] DEBE proporcionar una indicación clara de qué acción se activaría. cada función. Tener un ícono visible impreso en el botón que muestra un software en la parte de la barra de navegación de la pantalla, o guiar al usuario a través de una de demostración guiada paso a paso durante la experiencia de configuración lista para usar ejemplos de este tipo de indicación.

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE no proporcionar el mecanismo de entrada para el Función de menú ya que dejó de estar disponible y se reemplazó por la barra de acciones desde Android 4.0.

• [C-SR-2] SE RECOMIENDEN ENERGENTEmente para proporcionar todas las funciones de navegación como cancelable. "Cancelable" se define como la capacidad del usuario de evitar la no se ejecute la función de navegación (p.ej., ir a la página principal, volver, etc.) si la el deslizamiento no se libera después de un umbral determinado.

Si las implementaciones de dispositivos proporcionan la función Menú, sucederá lo siguiente:

• [C-2-1] SE DEBE mostrar el botón de ampliación de acciones cuando la acción la ventana emergente del menú ampliado no está vacía y la barra de acciones está visible.
• [C-2-2] NO DEBE modificar la posición de la ventana emergente de ampliación de acciones se muestra seleccionando el botón de menú ampliado en la barra de acciones, pero PUEDE renderizar la ventana emergente del menú ampliado de acciones en una posición modificada de la pantalla cuando que aparece seleccionando la función Menú.

Si las implementaciones en dispositivos no proporcionan la función Menú, para versiones anteriores compatibles, hacen lo siguiente:

• [C-3-1] DEBE hacer que la función Menú esté disponible para las aplicaciones cuando targetSdkVersion es menor que 10, ya sea por un botón físico, una llave de software, o gestos. Se debe poder acceder a esta función de menú, a menos que esté oculta junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función Assist, hacen lo siguiente:

• [C-4-1] DEBE hacer que la función Assist sea accesible con una sola acción. (p.ej., presionar, hacer doble clic o hacer un gesto) cuando se puede acceder a otras teclas de navegación.
• [C-SR-3] RECOMENDACIÓN DE MANTENER PRESIONADO mantener presionada la función INICIO de esta forma para la interacción designada.

Si las implementaciones de dispositivos usan una parte distinta de la pantalla para mostrar el las teclas de navegación, les permiten hacer lo siguiente:

• [C-5-1] Las teclas de navegación DEBEN usar una parte distinta de la pantalla, disponible para las aplicaciones y NO DEBE ocultar o interferir de ninguna otra manera con la parte de la pantalla disponible para las aplicaciones.
• [C-5-2] DEBE poner una parte de la pantalla disponible para las aplicaciones que cumpla con los requisitos definidos en el artículo 7.1.1
• [C-5-3] DEBE respetar las marcas establecidas por la app a través de View.setSystemUiVisibility(). método de API, de modo que esta parte distinta de la pantalla (también conocida como barra de navegación) esté correctamente oculta, como se documenta en el SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() Solo DEBE usarse para informar el área de reconocimiento de gestos de la pantalla principal.
• [C-6-2] Gestos que comienzan dentro de un rectángulo de exclusión proporcionado por el aplicación en primer plano mediante View#setSystemGestureExclusionRects(), pero fuera de WindowInsets#getMandatorySystemGestureInsets(), NO SE DEBE interceptar para la función de navegación siempre que la exclusión rect está permitido dentro del límite máximo de exclusión que se especifica en el documentación para View#setSystemGestureExclusionRects().
• [C-6-3] DEBE enviar a la aplicación en primer plano un MotionEvent.ACTION_CANCEL cuando los toques empiezan a ser interceptados por un gesto del sistema, si la app en primer plano ya recibió un MotionEvent.ACTION_DOWN evento.
• [C-6-4] DEBE ofrecer una indicación visual al usuario para cambiar a un modo en pantalla la navegación basada en botones (por ejemplo, en Configuración).
• Se DEBE mostrar la función de inicio deslizando el dedo hacia arriba desde el borde inferior de orientación actual de la pantalla.
• SE DEBE proporcionar la función Recientes al deslizar hacia arriba y mantener presionado antes del lanzamiento, desde en la misma área que el gesto de la página principal.
• Los gestos que comienzan dentro de WindowInsets#getMandatorySystemGestureInsets() NO DEBEN verse afectados por los rectángulos de exclusión proporcionados por el primer plano aplicación mediante View#setSystemGestureExclusionRects()

Si se proporciona una función de navegación desde cualquier parte de los bordes izquierdo y derecho de la orientación actual de la pantalla:

• [C-7-1] La función de navegación DEBE volver atrás y proporcionarse como desliza el dedo desde los bordes izquierdo y derecho de la orientación actual de la en la pantalla.
• [C-7-2] Si se proporcionan paneles del sistema deslizables y personalizados a la izquierda o en los bordes derechos, DEBEN colocarse dentro del 1/3 superior de la pantalla con una indicación visual clara y persistente de que arrastrar invocará la paneles mencionados y, por lo tanto, no de Atrás. Un panel del sistema PUEDE ser configurado por un usuario de modo que quede por debajo del 1/3 superior de la pantalla de los bordes, pero el panel del sistema NO DEBE usar más de un tercio.
• [C-7-3] Cuando la aplicación en primer plano tiene View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY WindowInsetsController.BEHAVIOR_DEFAULT, o Marcas de WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE configuradas, deslizar desde los bordes DEBE comportarse como se implementó en AOSP, lo cual documentados en el SDK.
• [C-7-4] Cuando la aplicación en primer plano tiene View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY WindowInsetsController.BEHAVIOR_DEFAULT, o Marcas de WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE configuradas, los paneles del sistema deslizables y personalizados DEBEN ocultarse hasta que el usuario entre o elimina las barras del sistema (también conocidas como barra de navegación y de estado) a medida que se implementen en el AOSP.

Si se proporciona la función de navegación hacia atrás y el usuario cancela el botón y, luego, haz lo siguiente:

• [C-8-1] Se DEBE llamar a OnBackInvokedCallback.onBackCancelled().
• [C-8-2] NO SE DEBE llamar a OnBackInvokedCallback.onBackInvoked().
• [C-8-3] NO DEBE enviar el evento KEYCODE_BACK.

Si se proporciona la función de navegación hacia atrás, pero la aplicación en primer plano sí NO tener un OnBackInvokedCallback registrado, entonces:

• El sistema DEBE proporcionar una animación para la aplicación en primer plano que sugiere que el usuario regresará, como se indica en AOSP.

Si las implementaciones de dispositivos proporcionan compatibilidad con la API del sistema setNavBarMode: permitir que cualquier app del sistema con el permiso android.permission.STATUS_BAR configure la modo de barra de navegación, luego:

• [C-9-1] DEBE ser compatible con íconos o botones basados en niños navegación, como se proporciona en el código del AOSP.

7.2.4. Entrada de pantalla táctil

Android admite una variedad de sistemas de entrada de punteros, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctiles falsos. Implementaciones de dispositivos basados en pantallas táctiles están asociadas a una pantalla, de modo que el usuario tenga la impresión de manipular elementos en pantalla. Como el usuario toca directamente la pantalla, el sistema no requiere indicadores adicionales para indicar los objetos que se está manipulando.

Implementaciones en dispositivos:

• DEBERÍA tener algún tipo de sistema de entrada del puntero (ya sea similar a un mouse o táctil).
• SE RECOMIENDA admitir punteros con seguimiento independiente en su totalidad.

Si las implementaciones del dispositivo incluyen una pantalla táctil (de un solo toque o mejor) en un pantalla principal compatible con Android, hacen lo siguiente:

• [C-1-1] DEBE informar TOUCHSCREEN_FINGER para el Configuration.touchscreen campo de API.
• [C-1-2] DEBE informar el android.hardware.touchscreen y Marcas de función de android.hardware.faketouch.

Si las implementaciones del dispositivo incluyen una pantalla táctil que pueda rastrear más de con solo tocar una pantalla en una pantalla principal compatible con Android:

• [C-2-1] SE DEBE informar las marcas de función adecuadas android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct y android.hardware.touchscreen.multitouch.jazzhand correspondiente al tipo de pantalla táctil específica del dispositivo.

Si las implementaciones de dispositivos dependen de un dispositivo de entrada externo, como un mouse o de seguimiento (es decir, sin tocar directamente la pantalla) para realizar una entrada en una pantalla compatible con Android y que cumpla con los requisitos de entrada táctil falsa en sección 7.2.5, hace lo siguiente:

• [C-3-1] NO DEBE informar ninguna marca de función que comience con android.hardware.touchscreen
• [C-3-2] DEBE informar solo android.hardware.faketouch.
• [C-3-3] DEBE informar TOUCHSCREEN_NOTOUCH para el Configuration.touchscreen campo de API.

7.2.5. Entrada táctil falsa

La interfaz táctil falsa proporciona un sistema de entrada de usuario que se aproxima a un subconjunto de capacidades de pantalla táctil. Por ejemplo, un mouse o un control remoto que conduzca un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o y, luego, haz clic. una gran variedad de dispositivos de entrada, como mouse, panel táctil y giroscopio. mouse de aire, puntero giroscópico, joystick y panel táctil multitáctil pueden soportar interacciones táctiles. Android incluye la constante de función android.hardware.faketouch, que corresponde a una actividad no táctil de alta fidelidad dispositivo de entrada (basado en un puntero), como un mouse o un panel táctil que puede emular entradas táctiles (incluida la compatibilidad básica con gestos) e indica que el dispositivo admite un subconjunto emulado de la funcionalidad de pantalla táctil.

Si las implementaciones del dispositivo no incluyen una pantalla táctil, pero sí incluyen de entrada de puntero que quieren poner a disposición:

• SE DEBE declarar la compatibilidad con la marca de función android.hardware.faketouch.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch, hacen lo siguiente:

• [C-1-1] SE DEBE informar las posiciones X e Y absolutas de la pantalla. de la ubicación del puntero y mostrar un puntero visual en la pantalla.
• [C-1-2] DEBE informar un evento táctil con el código de acción que especifica el cambio de estado que se produce en el puntero hacia abajo o hacia arriba en la pantalla.
• [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en pantalla, lo que permite a los usuarios emular el toque en un objeto en pantalla.
• [C-1-4] DEBE admitir puntero hacia abajo, puntero hacia arriba, puntero hacia abajo y, luego, hacia arriba. en el mismo lugar de un objeto en la pantalla dentro de un umbral de tiempo, lo que permite que los usuarios emulen la función de presionar dos veces en un objeto en la pantalla.
• [C-1-5] DEBE admitir el puntero hacia abajo en un punto arbitrario de la pantalla, movimiento del puntero a cualquier otro punto arbitrario de la pantalla, seguido de un puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
• [C-1-6] DEBE admitir el puntero hacia abajo para permitir que los usuarios muevan rápidamente el objeto a una posición diferente en la pantalla y, luego, apunta hacia arriba en la pantalla, que permite a los usuarios arrojar un objeto en la pantalla.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct, hicieron lo siguiente:

• [C-2-1] DEBE declarar compatibilidad con android.hardware.faketouch.
• [C-2-2] DEBE admitir un seguimiento distinto de dos o más punteros independientes. de datos.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.jazzhand, hicieron lo siguiente:

• [C-3-1] DEBE declarar compatibilidad con android.hardware.faketouch.
• [C-3-2] DEBE admitir un seguimiento distinto de 5 (seguimiento de una mano de dedos). o más entradas de puntero de forma completamente independiente.

7.2.6. Compatibilidad con controles de juegos

7.2.6.1. Asignaciones de botones

Implementaciones en dispositivos:

• [C-1-1] DEBE ser capaz de asignar eventos HID a las constantes InputEvent correspondientes, como se indica en las siguientes tablas. La implementación ascendente de Android cumple con este requisito.

Si las implementaciones de dispositivos incorporan un controlador o se envían con un controlador independiente en la caja que proporcionaría medios para ingresar todos los eventos enumerados en las siguientes tablas, sucederá lo siguiente:

• [C-2-1] SE DEBE declarar la marca de función android.hardware.gamepad.

Botón	Uso de HID2	Botón de Android
R1	0x09 0x0001.	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x090x0004.	KEYCODE_BUTTON_X (99)
A1	0x090x0005.	KEYCODE_BUTTON_Y (100)
Arriba de pad direccional1 Pad direccional abajo1	0x01 0x00393	AXIS_HAT_Y4
Pad direccional izquierdo1 Pad direccional derecho1	0x01 0x00393	AXIS_HAT_X4
Botón del hombro izquierdo1	0x090x0007.	KEYCODE_BUTTON_L1 (102)
Botón del hombro derecho1	0x09 0x0008.	KEYCODE_BUTTON_R1 (103)
Clic con la palanca izquierda1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic derecho1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Atrás1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores deben declararse dentro de un Juego pad CA (0x01 0x0005).

3 Este uso debe tener un mínimo lógico de 0, un Máximo lógico de 7, un mínimo físico de 0 y un máximo físico de 315, unidades en títulos y un tamaño de informe de 4. El valor lógico se define como el rotación en el sentido de las manecillas del reloj, lejos del eje vertical; por ejemplo, un valor lógico de 0 representa que no hay rotación y que se presiona el botón Arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados, y las teclas hacia arriba y hacia la izquierda pulsado.

4 MotionEvent

Controles analógicos1	Uso de HID	Botón de Android
Activador izquierdo	0x02 0x00C5	AXIS_LTRIGGER
Activador derecho	0x02 0x00C4	AXIS_RTRIGGER
Joystick izquierdo	0x01 0x0030 0x01 0x0031	AXIS_X EJE_Y
Joystick derecho	0x01 0x0032 0x01 0x0035.	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Control remoto

Consulta la Sección 2.3.1 para conocer los requisitos específicos de los dispositivos.

7.3 Sensores

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene un API correspondiente para desarrolladores externos, la implementación de dispositivos DEBE implementar esa API como se describe en la documentación del SDK de Android y la documentación de código abierto de Android sobre sensors

Implementaciones en dispositivos:

• [C-0-1] DEBE informar con precisión la presencia o ausencia de sensores según el android.content.pm.PackageManager clase.
• [C-0-2] DEBE mostrar una lista precisa de los sensores admitidos a través del SensorManager.getSensorList() y métodos similares.
• [C-0-3] DEBE comportarse de manera razonable con todas las otras APIs de sensores (por ejemplo, al Se mostrará true o false, según corresponda cuando las aplicaciones intenten registrarse. objetos de escucha, sin llamar a objetos de escucha de sensores cuando los sensores correspondientes no estén presente; etcétera).

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene un API correspondiente para desarrolladores externos:

• [C-1-1] SE DEBE informar todas las mediciones del sensor usando los valores relevantes del Sistema Internacional de Unidades (métrica) para cada tipo de sensor como se define en la documentación del SDK de Android.
• [C-1-2] SE DEBE informar los datos del sensor con una latencia máxima de 100. milisegundos + 2 * sample_time para el caso de una transmisión de sensores con un latencia máxima solicitada de 0 ms cuando el procesador de la aplicación está activo. Esta demora no incluye ninguna demora en el filtrado.
• [C-1-3] DEBE informar la primera muestra del sensor en un plazo de 400 milisegundos + 2 * sample_time del sensor que se activa. Es aceptable que esta muestra tienen una exactitud de 0.
• [C-1-4] Para que cualquier API indicada en la documentación del SDK de Android sea una sensor continuo, las implementaciones en dispositivos DEBEN proporcionar continuamente muestras de datos periódicas que DEBEN tener un Jitter inferior al 3%, donde el Jitter se define como la desviación estándar de la diferencia de la valores de marcas de tiempo informados entre eventos consecutivos.
• [C-1-5] DEBE asegurarse de que la transmisión de eventos del sensor NO DEBE evitar que la CPU del dispositivo entre en un estado de suspensión o se active. de un estado de suspensión.
• [C-1-6] DEBE informar la hora del evento. en nanosegundos, como se define en la documentación del SDK de Android, que representa el la hora en que ocurrió el evento y se sincronizó con el Reloj SystemClock.elapsedRealtimeNano().
• [C-SR-1] SE RECOMIENDA QUE tengan un error de sincronización de marca de tiempo. inferior a 100 milisegundos, y SE DEBE tener un error de sincronización de marca de tiempo inferior a 1 un milisegundo.
• Cuando se activan varios sensores, el consumo de energía NO DEBE superar es la suma del consumo de energía informado por cada sensor.

La lista anterior no es exhaustiva. el comportamiento documentado del SDK de Android y la documentación de código abierto de Android sensors confiables.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene un API correspondiente para desarrolladores externos:

• [C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores e informar el valor a través de Sensor.getResolution() método de API.

Algunos tipos de sensores son compuestos, lo que significa que pueden derivar de los datos proporcionados con uno o más sensores. Por ejemplo, el sensor de orientación y la de aceleración lineal).

Implementaciones en dispositivos:

• DEBERÍAN implementar estos tipos de sensores cuando incluir los requisitos previos de los sensores físicos como se describe en tipos de sensores.

Si las implementaciones de dispositivos incluyen un sensor compuesto, sucederá lo siguiente:

• [C-2-1] SE DEBE implementar el sensor como se describe en el Código abierto de Android documentación sobre sensores compuestos.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene un API correspondiente para desarrolladores externos y el sensor solo informa uno valor, entonces las implementaciones en dispositivos:

• [C-3-1] SE DEBE establecer la resolución del sensor en 1 e informar el valor. a través de Sensor.getResolution() método de API.

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor se expone a desarrolladores externos, ellos hacen lo siguiente:

• [C-4-1] NO DEBE incluir ninguna calibración fija y de fábrica. parámetros en los datos proporcionados.

Si las implementaciones de dispositivos incluyen una combinación de un acelerómetro de 3 ejes, un Un sensor de giroscopio de 3 ejes o un sensor magnetómetro:

• [C-SR-2] SE RECOMIENDA COMPLETAMENTE para garantizar que el acelerómetro, el giroscopio y tienen una posición relativa fija, de modo que si el dispositivo se transformables (p. ej., plegable), los ejes de los sensores permanecen alineados y coherentes. con el sistema de coordenadas del sensor en todos los estados de transformación.

7.3.1 Acelerómetro

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones en dispositivos incluyen un acelerómetro, ocurrirá lo siguiente:

• [C-1-1] DEBE ser capaz de informar eventos con una frecuencia de al menos 50 Hz.
• [C-1-3] DEBE cumplir con las Sistema de coordenadas de sensores Android como se detalla en las APIs de Android.
• [C-1-4] DEBE ser capaz de medir desde la caída libre hasta cuatro veces la gravity(4g) o más en cualquier eje.
• [C-1-5] DEBE tener una resolución de al menos 12 bits.
• [C-1-6] DEBE tener una desviación estándar no mayor que 0.05 m/s^, donde la desviación estándar debe calcularse por eje en las muestras recopilados durante un período de al menos 3 segundos a la tasa de muestreo más rápida.
• SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.
• DEBE tener una resolución de al menos 16 bits.
• SE DEBE calibrar mientras está en uso si las características cambian durante el ciclo de vida y compensado, y que conserven los parámetros de remuneración entre los reinicios del dispositivo.
• SE DEBE compensar la temperatura.

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

• [C-2-1] SE DEBE implementar e informar el sensor TYPE_ACCELEROMETER.
• [C-SR-4] SE RECOMIENDA MUY BIEN implementar TYPE_SIGNIFICANT_MOTION sensor compuesto.
• [C-SR-5] SE RECOMIENDA EXITOSAMENTE la implementación y el informe Sensor TYPE_ACCELEROMETER_UNCALIBRATED. Los dispositivos Android son FUERTE SE RECOMIENDA cumplir con este requisito para que puedan actualizar al en una versión futura de la plataforma en la que esto podría ser OBLIGATORIO.
• SE DEBE implementar TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR TYPE_STEP_DETECTOR y TYPE_STEP_COUNTER sensores compuestos, como se describe en el documento del SDK de Android.

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

• [C-3-1] SE DEBE implementar e informar el sensor de TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] Tienen StrongLY_RECOMMENDED implementar y reportar Sensor TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones en dispositivos incluyen un acelerómetro de 3 ejes y cualquiera de los TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR y TYPE_STEP_DETECTOR Se implementaron sensores compuestos de TYPE_STEP_COUNTER:

• [C-4-1] La suma de sus el consumo de energía DEBE ser siempre inferior a 4 mW.
• Cuando el dispositivo se encuentre en un entorno dinámico o para mantener una condición estática.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor de giroscopio de 3 ejes, hace lo siguiente:

• [C-5-1] DEBE implementar TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION sensores compuestos.
• [C-SR-7] SE RECOMIENDA ENERCMENTE implementar el Sensor compuesto de TYPE_GAME_ROTATION_VECTOR.

Si las implementaciones del dispositivo incluyen un acelerómetro de 3 ejes, un sensor de giroscopio de 3 ejes, y un sensor magnetómetro, ellos:

• [C-6-1] SE DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

7.3.2. Magnetómetro

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un magnetómetro de 3 ejes (brújula).

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

• [C-1-1] SE DEBE implementar el sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] DEBE ser capaz de informar eventos con una frecuencia de al menos 10 Hz. y DEBERÍAS informar eventos de hasta 50 Hz.
• [C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en el APIs de Android.
• [C-1-4] DEBE ser capaz de medir entre -900 μT y +900 μT en cada uno antes de la saturación.
• [C-1-5] DEBE tener un valor de desplazamiento de hierro resistente inferior a 700 μT y DEBE tener un valor inferior a 200 μT, colocando el magnetómetro lejos del campos magnéticos dinámicos (inducidos por la corriente) y estáticos (inducidos por imanes).
• [C-1-6] DEBE tener una resolución igual o mayor que 0.6 μT.
• [C-1-7] DEBE admitir la calibración en línea y la compensación del hierro resistente. el sesgo y preservar los parámetros de compensación entre los reinicios del dispositivo.
• [C-1-8] SE DEBE aplicar la compensación de hierro blando; la calibración se puede se hace mientras se usa o durante la producción del dispositivo.
• [C-1-9] DEBE tener una desviación estándar, calculada por eje en función de de muestra recopiladas durante un período de al menos 3 segundos en el método de muestreo más rápido tasa, no superior a 1.5 μT; SE DEBE tener una desviación estándar no mayor que 0.5 μT
• [C-1-10] SE DEBE implementar TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.

Si las implementaciones en dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro y un sensor de giroscopio de 3 ejes:

• [C-2-1] SE DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes o un acelerómetro, harán lo siguiente:

• PUEDES implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro y TYPE_GEOMAGNETIC_ROTATION_VECTOR, hace lo siguiente:

• [C-3-1] DEBE consumir menos de 10 mW.
• SE DEBE consumir menos de 3 mW cuando el sensor está registrado para el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un receptor GPS/GNSS.

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

• [C-1-1] DEBE admitir salidas de ubicación a una tasa de al menos 1 Hz cuando solicitado a través de LocationManager#requestLocationUpdate.
• [C-1-2] DEBE poder determinar la ubicación a cielo abierto. (señales fuertes, multitrayecto insignificante, HDOP < 2) en 10 segundos (rápido) tiempo para la primera solución), cuando se conecta a una velocidad de datos de 0.5 Mbps o superior o a Internet. Por lo general, este requisito se cumple con el uso de forma de técnica de GPS/GNSS asistido o previsto para minimizar el tiempo de bloqueo del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, Ubicación de referencia y efemérides satelitales/reloj).
  • [C-1-6] Después de realizar ese cálculo de ubicación, el dispositivo implementaciones DEBEN determinar su ubicación, a cielo abierto, dentro 5 segundos, cuando se reinician las solicitudes de ubicación, hasta una hora después el cálculo de ubicación inicial, incluso cuando la solicitud posterior sin conexión de datos o después de un reinicio.

• En condiciones de cielo abierto después de determinar la ubicación, mientras se encuentra detenido o que se mueven a menos de 1 metro por segundo al cuadrado de aceleración:

  • [C-1-3] DEBE poder determinar la ubicación dentro de los 20 metros y la velocidad. dentro de los 0.5 metros por segundo, al menos, el 95% del tiempo.
  • [C-1-4] DEBE hacer seguimiento e informar simultáneamente a través de GnssStatus.Callback al menos 8 satélites de una constelación.
  • DEBERÍAS poder realizar un seguimiento simultáneo de al menos 24 satélites, desde múltiples constelaciones (p.ej., GPS +, al menos, uno de los íconos de Glonass, BeiDou, Galileo).

• [C-SR-2] SE RECOMIENDA IMPORTANTEMENTE para seguir proporcionando GPS/GNSS normal. salidas de ubicación a través de las APIs del proveedor de ubicación del GNSS durante una llamada de emergencia llamada.

• [C-SR-3] SE RECOMIENDA ENERCMENTE que informen las mediciones GNSS de todas constelaciones rastreadas (como se informa en los mensajes GnssStatus), con la excepción de la SBAS.

• [C-SR-4] SE RECOMIENDA ENERCMENTE que informen el AGC y la frecuencia de GNSS de medición.

• [C-SR-5] SE RECOMIENDA ENERGENTEmente que informen todas las estimaciones de precisión (incluidos rumbo, velocidad y vertical) como parte de cada ubicación GPS/GNSS.

• [C-SR-6] SE RECOMIENDA ENRENDER que informen las mediciones GNSS tan pronto como los resultados de búsqueda, incluso si una ubicación calculada a partir del GPS/GNSS todavía no está informes.

• [C-SR-7] SE RECOMIENDA ENERCMENTE que informen pseudorangos GNSS y frecuencias de pseudorrango, que, en condiciones a cielo abierto después de determinar la ubicación, mientras esté quieto o en movimiento a menos de 0.2 metros por segundo al cuadrado aceleración, son suficientes para calcular la posición dentro de 20 metros, y la velocidad en un radio de 0.2 metros por segundo, al menos, el 95% del tiempo.

7.3.4. Giroscopio

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE incluir un sensor de giroscopio.

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

• [C-1-1] DEBE ser capaz de informar eventos con una frecuencia de al menos 50 Hz.
• [C-1-4] DEBE tener una resolución de 12 bits o más.
• [C-1-5] SE DEBE compensar la temperatura.
• [C-1-6] SE DEBE calibrar y compensar mientras se usa y se debe conservar la parámetros de compensación entre los reinicios del dispositivo.
• [C-1-7] DEBE tener una variación no superior a 1e-7 rad^2 / s^2 por Hz (varianza por Hz o rad^2 / s). Se permite que la varianza varíe con el tasa de muestreo, pero DEBE estar limitada por este valor. En otras palabras, si medir la varianza del giroscopio a una tasa de muestreo de 1 Hz, no DEBE ser mayor que 1e-7 rad^2/s^2.
• [C-SR-2] SE RECOMIENDA QUE el error de calibración sea inferior a 0.01 rad/s cuando el dispositivo está quieto a temperatura ambiente.
• [C-SR-3] SE RECOMIENDA ENcarecidamente que tengan una resolución de 16 bits o más.
• SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.

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

• [C-2-1] SE DEBE implementar el sensor TYPE_GYROSCOPE.
• [C-SR-4] Se recomiendan especialmente para la implementación TYPE_GYROSCOPE_UNCALIBRATED sensor.

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

• [C-3-1] SE DEBE implementar e informar el sensor de TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] Tienen StrongLY_RECOMMENDED implementar y reportar Sensor TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si las implementaciones del dispositivo incluyen un giroscopio de 3 ejes, un sensor acelerómetro y un sensor magnetómetro, ellos:

• [C-4-1] SE DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

Si las implementaciones del dispositivo incluyen un acelerómetro de 3 ejes y un giroscopio de 3 ejes sensor:

• [C-5-1] DEBE implementar TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION sensores compuestos.
• [C-SR-6] SE RECOMIENDA ENERCMENTE implementar el TYPE_GAME_ROTATION_VECTOR sensor compuesto.

7.3.5. Barómetro

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA ENERCMENTE incluir un barómetro (presión de aire ambiental sensor).

Si las implementaciones en dispositivos incluyen un barómetro, hacen lo siguiente:

• [C-1-1] SE DEBE implementar e informar el sensor de TYPE_PRESSURE.
• [C-1-2] DEBE ser capaz de transmitir eventos a 5 Hz o más.
• [C-1-3] SE DEBE compensar la temperatura.
• [C-SR-2] SE RECOMIENDA COMPLETAMENTE poder registrar las mediciones de presión en el rango de 300 hPa a 1,100 hPa.
• SE DEBE tener una precisión absoluta de 1 hPa.
• SE DEBE tener una precisión relativa de 0.12 hPa en un rango de 20 hPa (equivalente a una exactitud de ~1 m sobre el cambio de ~200 m al nivel del mar).

7.3.6. Termómetro

Si las implementaciones de dispositivos incluyen un termómetro de ambiente (sensor de temperatura), hacen lo siguiente:

• [C-1-1] DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE de los sensores de temperatura ambiente y el sensor DEBEN medir (habitación/cabina del vehículo) desde donde el usuario interactúa con el dispositivo en grados Celsius.

Si las implementaciones de dispositivos incluyen un sensor de termómetro que mide un temperatura distinta de la ambiente, como la temperatura de la CPU, hacen lo siguiente:

• [C-2-1] NO DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE. para el sensor de temperatura.

Si las implementaciones de dispositivos incluyen un sensor para controlar la temperatura cutánea, entonces:

• [C-SR-1] SON RECOMENDADAS EN FUERTE que apoyen el PowerManager.getThermalHeadroom API de gcloud.

7.3.7. Fotómetro

• Las implementaciones del dispositivo PUEDEN incluir un fotómetro (sensor de luz ambiente).

7.3.8. Sensor de proximidad

• Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad.

Si las implementaciones de dispositivos incluyen un sensor de proximidad y solo informan un La lectura binaria “cerca” o “lejana” hace lo siguiente:

• [C-1-1] DEBE medir la proximidad de un objeto en la misma dirección que el en la pantalla. Es decir, el sensor de proximidad DEBE orientarse para detectar objetos. cerca de la pantalla, ya que el principal propósito de este tipo de sensor es detectar un teléfono en uso por el usuario. Si las implementaciones en dispositivos incluyen un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API.
• [C-1-2] DEBE tener 1 bit de precisión o más.
• [C-1-3] DEBE usar 0 centímetros como la lectura cercana y 5 centímetros como la una lectura lejana.
• [C-1-4] DEBE informar un rango y resolución máximos de 5.

7.3.9. Sensores de alta fidelidad

Si las implementaciones de dispositivos incluyen un conjunto de sensores de mayor calidad, tal como se define de esta sección y ponerlos a disposición de apps de terceros, podrán hacer lo siguiente:

• [C-1-1] DEBE identificar la capacidad a través del Marca de función android.hardware.sensor.hifi_sensors.

Si las implementaciones de dispositivos declaran android.hardware.sensor.hifi_sensors, hacen lo siguiente:

• [C-2-1] DEBE tener un sensor TYPE_ACCELEROMETER con las siguientes características:

  • DEBE tener un rango de medición entre -8 g y +8 g, y es de SE RECOMIENDA IMPORTANTE tener un rango de medición de al menos -16 g y +16g.
  • DEBE tener una resolución de medición de al menos 2048 LSB/g.
  • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 400 Hz o superior. DEBES Ser compatible con SensorDirectChannel RATE_VERY_FAST
  • DEBE tener un ruido de medición que no supere los 400 μg/√ Hz.
  • SE DEBE implementar una forma de este sensor que no se active con un almacenamiento en búfer de al menos 3,000 eventos de sensores.
  • DEBE tener un consumo de energía por lotes que no sea inferior a 3 mW.
  • [C-SR-1] SE RECOMIENDA ENcarecidamente tener un ancho de banda de medición de 3 dB de 1 como mínimo, el 80% de la frecuencia de Nyquist y el espectro de ruido blanco dentro de ancho de banda.
  • SE DEBE hacer una prueba de aceleración aleatoria de menos de 30 μg √Hz a una temperatura ambiente.
  • SE RECOMIENDA tener un cambio de sesgo en comparación con la temperatura de ≤ +/- 1 mg/°C.
  • SE RECOMIENDA tener una no linealidad de la línea más adecuada de ≤ 0.5% y un cambio de sensibilidad en comparación con una temperatura de ≤ 0.03%/°
  • SE DEBE tener una sensibilidad en el eje cruzado de < 2,5 % y una variación de sensibilidad en eje cruzado < 0.2% en el rango de temperatura de funcionamiento del dispositivo.

• [C-2-2] DEBE tener un TYPE_ACCELEROMETER_UNCALIBRATED con el mismo de calidad como TYPE_ACCELEROMETER.

• [C-2-3] DEBE tener un sensor TYPE_GYROSCOPE con las siguientes características:

  • DEBE tener un rango de medición de al menos -1,000 y +1,000 dps.
  • DEBE tener una resolución de medición de al menos 16 LSB/dps.
  • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 400 Hz o superior. DEBES Ser compatible con SensorDirectChannel RATE_VERY_FAST
  • DEBE tener un ruido de medición que no supere los 0.014 °/s/√ Hz.
  • [C-SR-2] SE RECOMIENDA ENcarecidamente tener un ancho de banda de medición de 3 dB de 1 como mínimo, el 80% de la frecuencia de Nyquist y el espectro de ruido blanco dentro de ancho de banda.
  • SE RECOMIENDA hacer una prueba aleatoria de frecuencia de caminata inferior a 0.001 °/s √Hz en la habitación temperatura.
  • SE RECOMIENDA tener un cambio de sesgo respecto a la temperatura de ≤ +/- 0.05 °/ s / °C.
  • SE RECOMIENDA cambiar la sensibilidad frente a la temperatura de ≤ 0.02% / °C.
  • SE DEBE tener una no linealidad de la línea más adecuada de ≤ 0.2%.
  • SE DEBE tener una densidad de ruido igual o superior a ≤ 0.007 °/s/√ Hz.
  • SE RECOMIENDA tener un error de calibración inferior a 0.002 rad/s en rango de temperatura de 10 ~ 40 °C cuando el dispositivo está quieto.
  • DEBE tener una g-sensibilidad inferior a 0.1 °/s/g.
  • SE DEBE tener una sensibilidad en el eje cruzado de < Sensibilidad en el eje cruzado y del 4.0% variación < 0.3% en el rango de temperatura de funcionamiento del dispositivo.

• [C-2-4] DEBE tener un TYPE_GYROSCOPE_UNCALIBRATED con la misma calidad como TYPE_GYROSCOPE.

• [C-2-5] DEBE tener un sensor TYPE_GEOMAGNETIC_FIELD con las siguientes características:

  • DEBE tener un rango de medición de al menos -900 y +900 μT.
  • DEBE tener una resolución de medición de al menos 5 LSB/uT.
  • DEBE tener una frecuencia de medición mínima de 5 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 50 Hz o superior.
  • DEBE tener un ruido de medición que no supere los 0.5 uT.

• [C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con la misma calidad como TYPE_GEOMAGNETIC_FIELD y, además:

  • SE DEBE implementar una forma de este sensor que no se active con un almacenamiento en búfer capacidad de al menos 600 eventos de sensores.
  • [C-SR-3] SE RECOMIENDA ENcarecidamente tener un espectro de ruido blanco de 1 Hz a al menos 10 Hz cuando la tasa de informe sea de 50 Hz o superior.

• [C-2-7] DEBE tener un sensor TYPE_PRESSURE con las siguientes características:

  • DEBE tener un rango de medición de al menos 300 y 1,100 hPa.
  • DEBE tener una resolución de medición de al menos 80 LSB/hPa.
  • DEBE tener una frecuencia de medición mínima de 1 Hz o inferior.
  • DEBE tener una frecuencia de medición máxima de 10 Hz o superior.
  • DEBE tener un ruido de medición que no supere los 2 Pa/√Hz.
  • SE DEBE implementar una forma de este sensor que no se active con un almacenamiento en búfer capacidad de al menos 300 eventos de sensores.
  • DEBE tener un consumo de energía por lotes que no sea inferior a 2 mW.

• [C-2-8] DEBE tener un sensor TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] DEBE tener un sensor TYPE_SIGNIFICANT_MOTION con las siguientes características:

  • DEBE tener un consumo de energía no inferior a 0.5 mW cuando el dispositivo está estática y 1.5 mW cuando el dispositivo está en movimiento.

• [C-2-10] DEBE tener un sensor TYPE_STEP_DETECTOR con las siguientes características:

  • SE DEBE implementar una forma de este sensor que no se active con un almacenamiento en búfer capacidad de al menos 100 eventos de sensores.
  • DEBE tener un consumo de energía no inferior a 0.5 mW cuando el dispositivo está estática y 1.5 mW cuando el dispositivo está en movimiento.
  • DEBE tener un consumo de energía por lotes que no sea inferior a 4 mW.

• [C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER con las siguientes características:

  • DEBE tener un consumo de energía no inferior a 0.5 mW cuando el dispositivo está estática y 1.5 mW cuando el dispositivo está en movimiento.

• [C-2-12] DEBE tener un sensor TILT_DETECTOR con las siguientes características:

  • DEBE tener un consumo de energía no inferior a 0.5 mW cuando el dispositivo está estática y 1.5 mW cuando el dispositivo está en movimiento.

• [C-2-13] Marca de tiempo del mismo evento físico informada por el El acelerómetro, el giroscopio y el magnetómetro DEBEN estar dentro de los 2.5 milisegundos entre sí. La marca de tiempo del evento del mismo evento físico informado por el acelerómetro y el giroscopio DEBEN estar a 0.25 milisegundos de cada entre sí.

• [C-2-14] DEBE tener marcas de tiempo de eventos del sensor del giroscopio al mismo tiempo. base como el subsistema de la cámara y dentro de 1 milisegundos de error.

• [C-2-15] DEBE enviar muestras a las aplicaciones en un plazo de 5 milisegundos desde el momento en que los datos están disponibles en cualquiera de los sensores físicos mencionados anteriormente a la aplicación.

• [C-2-16] NO DEBE tener un consumo de energía superior a 0.5 mW cuando el dispositivo está estático y 2.0 mW cuando está en movimiento cuando se habilita cualquier combinación de los siguientes sensores:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] PUEDE tener un sensor TYPE_PROXIMITY, pero si está presente DEBE tener con una capacidad mínima de búfer de 100 eventos del sensor.

Ten en cuenta que todos los requisitos de consumo de energía de esta sección no incluyen la el consumo de energía del procesador de aplicaciones. Incluye el poder dibujada por toda la cadena del sensor, como el sensor, cualquier circuito de soporte, cualquier un sistema de procesamiento de sensores dedicado, etcétera.

Si las implementaciones de dispositivos incluyen compatibilidad directa con el sensor, sucederá lo siguiente:

• [C-3-1] SE DEBE declarar correctamente la compatibilidad con los tipos de canales directos y los nivel de tarifas de informes hasta el isDirectChannelTypeSupported y getHighestDirectReportRateLevel API de gcloud.
• [C-3-2] DEBE admitir al menos uno de los dos tipos de canal directo del sensor. para todos los sensores que declaran la compatibilidad con el canal directo del sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• SE RECOMIENDA admitir los informes de eventos a través del canal directo del sensor para principales sensor (variante sin activación) de los siguientes tipos:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensores biométricos

Para obtener más información sobre la medición de la seguridad del desbloqueo biométrico, consulte Medición de la documentación de seguridad biométrica.

Si las implementaciones en dispositivos incluyen una pantalla de bloqueo segura, sucederá lo siguiente:

• SE RECOMIENDA incluir un sensor biométrico

Los sensores biométricos se pueden clasificar en la clase 3 (anteriormente Strong), Clase 2 (anteriormente Débil) o Clase 1 (anteriormente Conveniencia) en función de sus tasas de aceptación de impostores y falsificaciones, y en la seguridad del canalización biométrica. Esta clasificación determina las capacidades sensor biométrico tiene que interactuar con la plataforma y con terceros aplicaciones. Los sensores deben cumplir con los requisitos adicionales que se detallan a continuación si desea que se la clasifique como Clase 1, Clase 2 o Clase 3. Los datos biométricos de clase 2 y clase 3 obtienen funciones adicionales, como las siguientes: como se detalla a continuación.

Si las implementaciones de dispositivos permiten que un sensor biométrico esté disponible para terceros aplicaciones mediante android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt. y android.provider.Settings.ACTION_BIOMETRIC_ENROLL, hace lo siguiente:

• [C-4-1] DEBE cumplir con los requisitos de los campos biométricos de Clase 3 o Clase 2. según se define en este documento.
• [C-4-2] DEBE reconocer y respetar cada nombre de parámetro definido como una constante. en la página Autenticadores de clase y cualquier combinación de ellos. Por el contrario, NO DEBE respetar ni reconocer las constantes de números enteros pasadas al canAuthenticate(int) y setAllowedAuthenticators(int). métodos distintos a los documentados como constantes públicas en Autenticadores y cualquier combinación de ellos.
• [C-4-3] SE DEBE implementar la función ACTION_BIOMETRIC_ENROLL en dispositivos con datos biométricos de clase 3 o clase 2. Esta acción solo DEBE presentar los puntos de entrada de inscripción para la clase 3. o datos biométricos de clase 2.

Si las implementaciones de dispositivos admiten datos biométricos pasivos, sucederá lo siguiente:

• [C-5-1] De forma predeterminada, DEBE requerir un paso de confirmación adicional. (p.ej., presionar un botón).
• [C-SR-1] SE RECOMIENDA ENcarecidamente tener un parámetro de configuración que permita a los usuarios anular la preferencia de aplicación y solicitar siempre la paso de confirmación.
• [C-SR-2] SE RECOMIENDA ENERGMENTE que se asegure la acción de confirmación para que no se falsifique la vulneración del sistema operativo o el kernel. Por ejemplo, esto significa que la acción de confirmar se basa en un botón físico. se enruta a través de un pin de entrada y salida de uso general (GPIO) de solo entrada un elemento seguro (SE) que no se puede impulsar por ningún otro medio que no sea un presionar un botón físico.
• [C-5-2] Además, DEBE implementar un flujo de autenticación implícito. (sin paso de confirmación) que corresponde a setConfirmationRequired(boolean), qué aplicaciones se pueden configurar para los flujos de acceso.

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

• [C-SR-3] SE RECOMIENDA ENRENDER que requieran solo una confirmación biométrica Por autenticación (p.ej., si están disponibles los sensores faciales y de huella dactilar en el dispositivo, onAuthenticationSucceeded deben enviarse después de que se confirme alguno de ellos).

Para que las implementaciones de dispositivos permitan el acceso a las claves del almacén de claves a de aplicaciones de terceros, hacen lo siguiente:

• [C-6-1] DEBE cumplir con los requisitos de la Clase 3 según se define en esta a continuación.
• [C-6-2] DEBE presentar solo datos biométricos de Clase 3 cuando la autenticación requiere BIOMETRIC_STRONG, o la autenticación se invoca con un CryptoObject.

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

• [C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0.002%.
• [C-1-2] DEBE divulgar que este modo puede ser menos seguro que un PIN seguro, patrón o contraseña, y enumerar claramente los riesgos de habilitarlos si el las tasas de aceptación de falsificaciones e impostores son superiores al 7% según las mediciones del Protocolos de prueba de datos biométricos de Android.
• [C-1-9] SE DEBE desafiar al usuario a la autenticación principal recomendada. (p.ej., PIN, patrón, contraseña) después de no más de veinte pruebas falsas menos de 90 segundos de retirada para la verificación biométrica, en la que ensayo falso es aquel con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un método biométrico inscrito.
• [C-SR-4] SE RECOMIENDA IMPORTANTEMENTE para reducir la cantidad total de pruebas falsas para la verificación biométrica especificada en [C-1-9] si la falsificación y el impostor Las tasas de aceptación son superiores al 7%, según los datos de Android Biometrics Protocolos de prueba.
• [C-1-3] SE DEBE limitar los intentos de verificación biométrica, cuando ensayo falso es aquel con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincida con un dato biométrico inscrito.
• [C-SR-5] SE RECOMIENDEN ENERGENTEMENTE a los intentos de límite de frecuencia de al menos 30 segundos después de cinco pruebas falsas para la verificación biométrica del cantidad máxima de pruebas falsas por [C-1-9], donde un ensayo falso es uno con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincida con un datos biométricos inscritos.
• [C-SR-6] SE RECOMIENDA ENcarecidamente tener toda la lógica de límite de frecuencia en TEE.

• [C-1-10] DEBE inhabilitar los datos biométricos una vez que se haya retirado la autenticación principal. se activa por primera vez, como se describe en [C-0-2] de la sección 9.11.

• [C-1-11] DEBE tener una tasa de aceptación de falsificaciones e impostores que no supere el 30%, con (1) una tasa de aceptación de falsificaciones e impostores para una presentación de nivel A una especie de instrumento de ataque (PAI) que no supere el 30%, y (2) una falsificación de identidad y la tasa de aceptación de impostores de la especie B de PAI de nivel B no supere el 40%, como medidas por los protocolos de prueba de datos biométricos de Android.

• [C-1-4] DEBE evitar agregar datos biométricos nuevos sin establecer primero un cadena de confianza pidiéndole al usuario que confirme el dispositivo existente o agregue uno nuevo credencial (PIN/patrón/contraseña) protegida por el TEE Android Open La implementación del proyecto fuente proporciona el mecanismo en el marco para hacer así que

• [C-1-5] SE DEBE quitar por completo todos los datos biométricos identificables de un usuario. Cuando se quita la cuenta del usuario (incluso mediante un restablecimiento de la configuración de fábrica).

• [C-1-6] DEBE respetar la marca individual de ese dato biométrico (es decir, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).

• [C-1-7] SE DEBE desafiar al usuario a la autenticación principal recomendada. (p.ej., PIN, patrón o contraseña) una vez cada 24 horas o menos. Nota: La actualización de dispositivos con Android 9 o versiones anteriores DEBE solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 72 horas o menos.

• [C-1-8] SE DEBE desafiar al usuario a la instancia principal recomendada autenticación (p. ej., PIN, patrón, contraseña) o datos biométricos de clase 3 (FUERTE) después de una de las siguientes situaciones:

  • un tiempo de espera de inactividad de 4 horas O
  • 3 intentos fallidos de autenticación biométrica.
  • Se restablecen el tiempo de espera de inactividad y el recuento de autenticación con errores después de una confirmación exitosa de las credenciales del dispositivo. Nota: Es posible que la actualización de dispositivos lanzados con Android 9 o versiones anteriores exenta de la certificación C-1-8.

• [C-SR-7] SE RECOMIENDA COMPLETAMENTE usar la lógica en el framework proporcionado por el Proyecto de código abierto de Android para aplicar las restricciones especificadas en [C-1-7] y [C-1-8] para dispositivos nuevos.

• [C-SR-8] SE RECOMIENDA ENcarecidamente tener una tasa de rechazo falso inferior a 10%, según la medición del dispositivo.

• [C-SR-9] SE RECOMIENDA ENERCMENTE tener una latencia inferior a 1 segundo, medida desde que se detectan los datos biométricos hasta que se desbloquea la pantalla, por cada datos biométricos inscritos.

Si las implementaciones en dispositivos desean tratar un sensor biométrico como de clase 2. (anteriormente Débil), hacen lo siguiente:

• [C-2-1] DEBE cumplir con todos los requisitos de la Clase 1 mencionados anteriormente.

• [C-2-2] DEBE tener una tasa de aceptación de falsificaciones e impostores que no supere el 20%, con (1) una tasa de aceptación de falsificaciones e impostores para Las especies con instrumentos de ataque de presentación (PAI) de nivel A no superiores al 20%, y (2) una tasa de aceptación de falsificaciones e impostores de las especies PAI de nivel B que no superior al 30%, según las mediciones del Protocolos de prueba de datos biométricos de Android.

• [C-2-3] DEBE realizar la coincidencia biométrica en un entorno de ejecución aislado fuera de Android de usuario o de kernel, como el entorno de ejecución confiable (TEE), o en un chip con un canal seguro al entorno de ejecución aislado o en una máquina virtual protegida que cumpla con los requisitos de la sección 9.17.
• [C-2-4] DEBE tener todos los datos identificables encriptados y criptográficamente autenticados de modo que no se puedan adquirir, leer ni modificar fuera de el entorno de ejecución aislado o un chip con un canal seguro hacia entorno de ejecución aislado, tal como se documenta en la página de implementación lineamientos en el sitio del Proyecto de código abierto de Android o una Máquina Virtual Protegida controlada por un hipervisor que cumpla con los requisitos del Artículo 9.17.
• [C-2-5] Para datos biométricos basados en cámara, mientras que para autenticación basada en datos biométricos o está en curso la inscripción:
  • DEBE operar la cámara en un modo que impida que los encuadres de la cámara se leen o modifican fuera del entorno de ejecución aislado o de 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 del Artículo 9.17.
  • Para soluciones RGB de una sola cámara, los marcos de la cámara PUEDEN legible fuera del entorno de ejecución aislado para respaldar las operaciones como la vista previa para la inscripción, pero NO DEBE ser alterable.
• [C-2-6] NO DEBE habilitar aplicaciones de terceros para distinguir entre registros biométricos individuales.
• [C-2-7] NO DEBE permitir el acceso sin encriptar a datos biométricos identificables o todos los datos derivados (como incorporaciones) al procesador de aplicaciones fuera del contexto del TEE o la máquina virtual protegida que se controla con un hipervisor y que cumple con los requisitos del Artículo 9.17. No se excluyen las actualizaciones de dispositivos lanzados en Android 9 o versiones anteriores de C-2-7.

• [C-2-8] DEBE tener una canalización de procesamiento segura que permita que un vulnerar el sistema o el kernel no puede permitir la inserción directa de datos autenticarse como usuario de forma falsa. Nota: Si ya se lanzaron implementaciones en dispositivos con la versión 9 de Android o una versión anterior y no puede cumplir con el requisito C-2-8 a través de un software del sistema actualización, PUEDEN estar exentos del requisito.

• [C-SR-10] SE RECOMIENDA COMPLETAMENTE incluir la detección de funcionamiento para todos modalidades biométricas y detección de atención para los datos biométricos faciales.

• [C-2-9] DEBE poner el sensor biométrico a disposición de terceros aplicaciones.

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

• [C-3-1] DEBE cumplir con todos los requisitos de la Clase 2 mencionada anteriormente, excepto por [C-1-7] y [C-1-8].
• [C-3-2] DEBE tener una implementación de un almacén de claves guardadas en hardware.
• [C-3-3] DEBE tener una tasa de aceptación de falsificaciones e impostores que no supere el 7%, con (1) una tasa de aceptación de falsificaciones e impostores para Las especies con instrumentos de ataque de presentación (PAI) de nivel A no superiores al 7%, y (2) una tasa de aceptación de falsificaciones e impostores de la especie PAI de nivel B que no sea superior que un 20%, según las mediciones del Protocolos de prueba de datos biométricos de Android.
• [C-3-4] SE DEBE desafiar al usuario a la instancia principal recomendada autenticación (p.ej., PIN, patrón o contraseña) una vez cada 72 horas o menos.
• [C-3-5] SE DEBE volver a generar el ID del Autenticador. para todos los datos biométricos de clase 3 compatibles con el dispositivo, si se cumplen se volvió a inscribir.
• [C-3-6] Se debe habilitar las claves de almacén de claves respaldadas con datos biométricos para terceros aplicaciones.

Si las implementaciones de dispositivos contienen un sensor de huellas dactilares ubicado debajo de la pantalla (UDFPS), hace lo siguiente:

• [C-SR-11] SE RECOMIENDEN EXITOSAMENTE para evitar el área táctil de UDFPS de interferir en la navegación con 3 botones( que algunos usuarios pueden necesitar para con fines de accesibilidad).

7.3.11. Sensor de postura

Implementaciones en dispositivos:

• PUEDE admitir el sensor de poses con 6 grados de libertad.

Si las implementaciones de dispositivos admiten el sensor de poses con 6 grados de libertad, harán lo siguiente:

• [C-1-1] DEBE implementar y, luego, informar TYPE_POSE_6DOF sensor.
• [C-1-2] DEBE ser más preciso que el vector de rotación solo.

7.3.12. Sensor de ángulo de bisagra

Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra, sucederá lo siguiente:

• [C-1-1] DEBE implementar y, luego, informar TYPE_HINGLE_ANGLE.
• [C-1-2] DEBE admitir al menos dos lecturas entre 0 y 360 grados (inclusive, es decir, incluidos 0 y 360 grados).
• [C-1-3] DEBE devolver una activación. para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Si las implementaciones de dispositivos incluyen compatibilidad con 802.1.15.4 y se exponen de Google Cloud a una aplicación de terceros:

7.4. Conectividad de datos

7.4.1 Telefonía

"Telefonía", tal como se utiliza en las APIs de Android y en este documento hace referencia específicamente con hardware relacionado con realizar llamadas de voz y enviar mensajes SMS , o establecer datos móviles a través de una red móvil (p.ej., GSM, CDMA, LTE, NR) GSM o CDMA. Un dispositivo compatible con "Telefonía" puede optar por ofrecer algunos o todos los servicios de llamadas, mensajería y datos, según corresponda para el producto.

a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no cambiarse de paquetes,se usan para que Android se considere independiente de cualquier conectividad de datos que se pueda implementar usando la misma red. En otras palabras,la funcionalidad y las APIs de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si usan una red móvil para la conectividad de datos.

• Android PUEDE usarse en dispositivos que no incluyen hardware de telefonía. Que es que Android es compatible con dispositivos que no son teléfonos.

Si las implementaciones de dispositivos incluyen telefonía GSM o CDMA, sucederá lo siguiente:

• [C-1-1] DEBE declarar la marca de función android.hardware.telephony y y otras marcas secundarias según la tecnología.
• [C-1-2] DEBE implementar compatibilidad total con la API para esa tecnología.
• SE RECOMIENDA permitir todos los tipos de servicios celulares disponibles (2G, 3G, 4G, 5G, etc.) durante llamadas de emergencia (independientemente de los tipos de red establecidos por SetAllowedNetworkTypeBitmap()).

Si las implementaciones de dispositivos no incluyen hardware de telefonía:

• [C-2-1] DEBE implementar las APIs completas como no-ops.

Si las implementaciones de dispositivos admiten eUICC o eSIMs/SIM incorporadas, incluyen lo siguiente: un mecanismo de su propiedad para poner la funcionalidad de eSIM a disposición de terceros desarrolladores, hacen lo siguiente:

• [C-3-1] DEBE declarar el android.hardware.telephony.euicc marca de función.

Si las implementaciones de dispositivos no establecen la propiedad del sistema ro.telephony.iwlan\_operation\_mode como "legacy", sucederá lo siguiente:

• [C-4-1] NO DEBE informar “NETWORK_TYPE_IWLAN” a través de NetworkRegistrationInfo#getAccessNetworkTechnology() cuando NetworkRegistrationInfo#getTransportType() se informa como “TRANSPORT_TYPE_WWAN” para la misma instancia de NetworkRegistrationInfo.

Si las implementaciones de dispositivos admiten un solo subsistema multimedia de IP (IMS) el registro para el servicio de telefonía multimedia (MMTEL) y de servicios de comunicación enriquecida (RCS) y se espera que cumplan con con los requisitos de los operadores de telefonía celular para usar un solo El registro de IMS para todo el tráfico de señalización del IMS:

• [C-5-1] DEBE declarar el android.hardware.telephony.ims. marca de función y brindan una implementación completa del API de ImsService para la API de User Capability Exchange de MMTEL y RCS.
• [C-5-2] DEBE declarar el android.hardware.telephony.ims.singlereg. marca de función y proporcionar una implementación completa de la API de SipTransport. la API de GCC indicaciones dedicadas del portador con la HAL de IRadio 1.6, y aprovisionar mediante el servidor de configuración automática (ACS) o algún otro aprovisionamiento propio con la API de configuración de IMS.

Si las implementaciones de dispositivos informan la función android.hardware.telephony, haz lo siguiente:

• [C-6-1] El SmsManager#sendTextMessage y SmsManager#sendMultipartTextMessage DEBE generar las llamadas correspondientes a CarrierMessagingService para brindar la funcionalidad de mensajería de texto. SmsManager#sendMultimediaMessage y SmsManager#downloadMultimediaMessage DEBE generar las llamadas correspondientes a CarrierMessagingService para brindar la funcionalidad de mensajería multimedia.
• [C-6-2] La aplicación designada por android.provider.Telephony.Sms#getDefaultSmsPackage SE DEBE usar Administrador de SMS APIs cuando envíes y recibas mensajes SMS y MMS. La referencia de AOSP implementación en paquetes/apps/mensajería cumple con este requisito.
• [C-6-3] La aplicación que responde a Intent#ACTION_DIAL DEBE admitir la entrada de códigos de marcador arbitrarios con el formato *#*#CODE#*#* y activar un parámetro TelephonyManager#ACTION_SECRET_CODE transmisión.
• [C-6-4] La aplicación que responde a Intent#ACTION_DIAL SE DEBE usar VoicemailContract.Voicemails#TRANSCRIPTION para mostrar a los usuarios la transcripción del buzón de voz visual si admite transcripciones del buzón de voz.
• [C-6-5] DEBE representar toda la SubscriptionInfo con un valor equivalente UUID de grupo como una única suscripción en todas las condiciones visibles para el usuario que muestren y controlar información de la tarjeta SIM. Algunos ejemplos de estas posibilidades son la configuración interfaces que coinciden Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS o EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
• [C-6-6] NO DEBES mostrar ni permitir el control de ningún SubscriptionInfo con un UUID de grupo no nulo y oportunista en cualquier indicación visible para el usuario que permitir la configuración o el control de los ajustes de la tarjeta SIM.

Si las implementaciones de dispositivos informan la función android.hardware.telephony y proporciona una barra de estado del sistema, y luego:

• [C-7-1] DEBE seleccionar una suscripción activa representativa para un determinado UUID de grupo para mostrar al usuario en cualquier opción que proporcione el estado de SIM información. Algunos ejemplos de estas posibilidades son la barra de estado de red móvil ícono de señal o tarjeta de configuración rápida.
• [C-SR-1] SE RECOMIENDA COMPLETAMENTE que la suscripción del representante sea elegido para suscripción de datos activa a menos que el dispositivo cuente con la voz durante la llamada, se RECOMIENDA ENERGMENTE que el representante es la suscripción de voz activa.

Si las implementaciones de dispositivos informan la función android.hardware.telephony, haz lo siguiente:

• [C-6-7] DEBE ser capaz de abrirse y utilizar simultáneamente la máxima cantidad de canales lógicos (20 en total) para cada UICC según el TS 102 221 de ETSI.
• [C-6-8] NO DEBE aplicar ninguno de los siguientes comportamientos a las apps de operadores activas (según lo que designó TelephonyManager#getCarrierServicePackageName) automáticamente o sin la confirmación explícita del usuario:
  • Revocar o limitar el acceso a la red
  • Revocar permisos
  • Restringir la ejecución de apps en primer o segundo plano más allá de las funciones de administración de batería existentes incluidas en el AOSP
  • Cómo inhabilitar o desinstalar la app

Si las implementaciones de dispositivos informan sobre la función android.hardware.telephony y todas activas, suscripciones no oportunistas que comparten un UUID de grupo se inhabilitan, quitado físicamente del dispositivo, o bien se marca como oportunista, entonces el dispositivo:

• [C-8-1] DEBE inhabilitar automáticamente todos los restantes activos oportunista suscripciones en el mismo grupo.

Si las implementaciones de dispositivos incluyen telefonía GSM, pero no telefonía CDMA, sucederá lo siguiente:

• [C-9-1] NO DEBE declarar PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] DEBE arrojar una IllegalArgumentException cuando se intente establecer alguna Tipos de red 3GPP2 en máscaras de bits de tipo de red preferidas o permitidas.
• [C-9-3] DEBE devolver una cadena vacía de TelephonyManager#getMeid

Si las implementaciones de dispositivos admiten eUICC con varios puertos y perfiles, tendrán las siguientes características:

• [C-10-1] DEBE declarar el android.hardware.telephony.euicc.mep marca de función.

7.4.1.1. Compatibilidad con bloqueo de números

Si las implementaciones de dispositivos informan la función android.hardware.telephony.calling, sucederá lo siguiente:

• [C-1-1] DEBE incluir asistencia para el bloqueo de números.
• [C-1-2] DEBE implementar completamente BlockedNumberContract y la API correspondiente, como se describe en la documentación del SDK.

• [C-1-3] DEBES bloquear todas las llamadas y los mensajes provenientes de un número de teléfono en "BlockedNumberProvider" sin ninguna interacción con las apps. La única excepción es cuando se quita temporalmente el bloqueo de números, según se describe en el SDK. en la documentación de Google Cloud.

• [C-1-4] DEBE escribirle al proveedor de registros de llamadas de la plataforma. para una llamada bloqueada y DEBE filtrar las llamadas con BLOCKED_TYPE del vista predeterminada del registro de llamadas en la app de Teléfono preinstalada.

• [C-1-5] NO DEBE escribirle al proveedor de telefonía. para un mensaje bloqueado.

• [C-1-6] DEBE implementar una IU de administración de números bloqueados que está abierta. con el intent que muestra TelecomManager.createManageBlockedNumbersIntent() .

• [C-1-7] NO DEBE permitir que usuarios secundarios vean o editen los números bloqueados. en el dispositivo, ya que la plataforma de Android asume que el usuario principal tiene control de los servicios de telefonía, una sola instancia, en el dispositivo. Todo IU relacionada con el bloqueo DEBE estar oculta para los usuarios secundarios y la lista de bloqueo DEBE se seguirán respetando.

• SE RECOMIENDA migrar los números bloqueados al proveedor cuando se actualice un dispositivo. a Android 7.0.

• SE DEBE proporcionar una indicación visual de usuario para mostrar las llamadas bloqueadas en la de la app de Teléfono.

7.4.1.2. API de Telecom

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

• [C-1-1] DEBE admitir las APIs de ConnectionService que se describen en el SDK.
• [C-1-2] SE DEBE mostrar una nueva llamada entrante y proporcionar la indicación visual del usuario para aceptar o rechazar la llamada entrante cuando el usuario está en una llamada en curso creado por una app de terceros que no admite la función de conservación especificada mediante CAPABILITY_SUPPORT_HOLD
• [C-1-3] DEBE tener una aplicación que implemente InCallService

• [C-SR-1] SE RECOMIENDA EXITOSAMENTE notificar al usuario que responder una llamada entrante abandonará la llamada en curso.

  La implementación de AOSP cumple con estos requisitos mediante una notificación de atención. que le indica al usuario que responder una llamada entrante provocará que se interrumpa otra llamada.

• [C-SR-2] SE RECOMIENDA IMPORTANTEMENTE precargar la app de Teléfono predeterminada que muestra una entrada de registro de llamadas y el nombre de una app de terceros en el registro de llamadas cuando la app de terceros establece la EXTRA_LOG_SELF_MANAGED_CALLS extras en su PhoneAccount a true.

• [C-SR-3] SE RECOMIENDA EXIGENTEMENTE para controlar el sonido de los auriculares Los eventos KEYCODE_MEDIA_PLAY_PAUSE y KEYCODE_HEADSETHOOK para el android.telecom APIs como se muestra a continuación:

  • Llama a Connection.onDisconnect() Cuando se detecta una pulsación breve de un evento de tecla durante una llamada en curso
  • Llama a Connection.onAnswer() Cuando se detecta una pulsación breve de un evento de tecla durante una llamada entrante
  • Llama a Connection.onReject() Cuando se detecta una presión prolongada de un evento de tecla durante una llamada entrante
  • Activa o desactiva el estado de silencio de CallAudioState.

7.4.1.3 Descarga Keepalive de NAT-T celular

Implementaciones en dispositivos:

• SE DEBE incluir compatibilidad con la descarga de keepalive de la red móvil.

Si las implementaciones de dispositivos incluyen compatibilidad con transferencia de keepalive de redes móviles y Expone la funcionalidad a apps de terceros:

• [C-1-1] DEBE ser compatible con la API de SocketKeepAlive.
• [C-1-2] DEBE admitir al menos una ranura keepalive simultánea a través de datos móviles.
• [C-1-3] DEBE admitir tantas ranuras continuas de keepalive móviles como sean compatible con la HAL de la radio móvil.
• [C-SR-1] SE RECOMIENDA ENcarecidamente que admitan al menos tres keepalive de telefonía celular ranuras por instancia de radio.

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga keepalive de datos móviles, hacen lo siguiente:

• [C-2-1] DEBE mostrar ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones en dispositivos:

• SE DEBE incluir compatibilidad con uno o más formularios de 802.11.

Si las implementaciones en dispositivos incluyen compatibilidad con 802.11 y se exponen de Google Cloud a una aplicación de terceros:

• [C-1-1] DEBE implementar la API de Android correspondiente.
• [C-1-2] SE DEBE informar la marca de función de hardware android.hardware.wifi.
• [C-1-3] SE DEBE implementar la API de multidifusión. según se describe en la documentación del SDK.
• [C-1-4] DEBE admitir DNS multicast (mDNS) y NO DEBE filtrar paquetes mDNS. (224.0.0.251 o ff02::fb). en cualquier momento de funcionamiento, incluso cuando la pantalla no esté en estado activo, a menos que se eliminen o filtren estos paquetes necesario para mantenerse dentro de los rangos de consumo de energía requeridos por las los requisitos correspondientes al mercado objetivo. En las implementaciones de dispositivos de Android Television, incluso cuando está en estado de energía en espera.
• [C-1-5] NO DEBE tratar el WifiManager.enableNetwork(). una llamada de método a la API como una indicación suficiente para cambiar el estado activo Network que se usa de forma predeterminada para el tráfico de la aplicación y se muestra de ConnectivityManager Métodos de la API, como getActiveNetwork y registerDefaultNetworkCallback. En otras palabras, PUEDEN inhabilitar solo el acceso a Internet proporcionado por cualquier o a otro proveedor de red (p.ej., datos móviles) si validan que la red Wi-Fi esté proporcionando acceso a Internet.
• [C-1-6] Se RECOMIENDA ENERGMENTE cuando ConnectivityManager.reportNetworkConnectivity() se llama al método de la API, vuelve a evaluar el acceso a Internet en el Network una vez que la evaluación determina que el Network actual ya no proporciona Acceso a Internet, cambia a cualquier otra red disponible (p.ej., móvil) datos) que proporciona acceso a Internet.
• [C-1-7] DEBE aleatorizar la dirección MAC de origen y el número de secuencia del sondeo. de solicitudes, una vez al comienzo de cada análisis, mientras que el STA desconectado.
• [C-1-8] SE DEBE usar una sola dirección MAC coherente (NO SE DEBE usar una dirección MAC aleatoria). dirección a la mitad del escaneo).
• [C-1-9] DEBE iterar el número de secuencia de la solicitud de sondeo como normal (de forma secuencial) entre las solicitudes de sondeo de un análisis.
• [C-1-10] DEBE aleatorizar el número de secuencia de la solicitud del sondeo entre el último sondeo. de un análisis y la primera solicitud de sondeo del siguiente análisis.
• [C-SR-1] SE RECOMIENDEN ENERGMENTE para aleatorizar la dirección MAC de origen que se usa para todas las comunicaciones de STA a un punto de acceso (AP) y, al mismo tiempo, se asocia asociados.
  • El dispositivo DEBE usar una dirección MAC aleatoria diferente para cada SSID. (FQDN para Passpoint) con el que se comunica.
  • El dispositivo DEBE ofrecer al usuario una opción para controlar el por SSID (FQDN para Passpoint) con aleatorización y de opciones aleatorias y DEBE establecer el modo predeterminado para conexiones Wi-Fi nuevas. parámetros de configuración se aleatorizan.
• [C-SR-2] SE RECOMIENDA EXITOSAMENTE que usen un BSSID aleatorio para cualquier AP que crear.
  • La dirección MAC DEBE aleatorizarse y conservarse según el SSID que usa el AP.
  • EL DISPOSITIVO PUEDE ofrecer al usuario la opción de inhabilitar esta función. Si se proporciona tal opción, la aleatorización DEBE estar habilitada de forma predeterminada.

Si las implementaciones de dispositivos incluyen compatibilidad con el modo de ahorro de energía de Wi-Fi como se define según el estándar IEEE 802.11:

• SE DEBE desactivar el modo de ahorro de energía de Wi-Fi cada vez que una app adquiere Bloqueo de WIFI_MODE_FULL_HIGH_PERF o de WIFI_MODE_FULL_LOW_LATENCY a través de WifiManager.createWifiLock() y WifiManager.WifiLock.acquire(). APIs y el bloqueo está activo.
• [C-3-2] La latencia promedio de ida y vuelta entre el dispositivo y un punto de acceso cuando el dispositivo esté en un bloqueo de baja latencia de Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) DEBE ser más pequeño que el latencia durante un modo de bloqueo de alto rendimiento de Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] SON RECOMENDADAS EN VEZ para minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere un bloqueo de latencia baja (WIFI_MODE_FULL_LOW_LATENCY) y entra en vigencia.

Si las implementaciones de dispositivos admiten Wi-Fi y usan Wi-Fi para buscar la ubicación, hacen lo siguiente:

• [C-2-1] DEBE proporcionar una indicación visual del usuario para habilitar/inhabilitar el valor de lectura. a través de WifiManager.isScanAlwaysAvailable método de API.

7.4.2.1. Wi-Fi directo

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con Wi-Fi directo (Wi-Fi entre pares).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi directo, sucederá lo siguiente:

• [C-1-1] DEBE implementar la API de Android correspondiente. según se describe en la documentación del SDK.
• [C-1-2] DEBE informar la función de hardware android.hardware.wifi.direct.
• [C-1-3] DEBE admitir el funcionamiento normal de Wi-Fi.
• [C-1-4] DEBE admitir operaciones de Wi-Fi y Wi-Fi directo en simultáneo.
• [C-SR-1] SE RECOMIENDEN ENERGMENTE para aleatorizar la dirección MAC de origen de todos las nuevas conexiones Wi-Fi Direct.

7.4.2.2. Configuración del vínculo directo en túnel Wi-Fi

Implementaciones en dispositivos:

• SE DEBE incluir compatibilidad con Configuración de vínculo directo en túnel (TDLS) de Wi-Fi como se describe en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad con TDLS, y el TDLS está habilitado por el API de WiFiManager, les permiten hacer lo siguiente:

• [C-1-1] DEBE declarar la compatibilidad con TDLS a través de WifiManager.isTdlsSupported.
• DEBE usar TDLS solo cuando sea posible Y beneficioso.
• SE DEBE tener una heurística y NO usar TDLS cuando su rendimiento sea es peor que pasar por el punto de acceso Wi-Fi.

7.4.2.3 Reconocimiento de Wi-Fi

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con Wi-Fi Aware.

Si las implementaciones en el dispositivo incluyen compatibilidad con el reconocimiento de Wi-Fi y exponen el a apps de terceros, les permiten hacer lo siguiente:

• [C-1-1] SE DEBE implementar las APIs de WifiAwareManager como se describe en Documentación del SDK.
• [C-1-2] DEBE declarar la marca de función android.hardware.wifi.aware.
• [C-1-3] DEBE admitir operaciones de Wi-Fi y reconocimiento de Wi-Fi al mismo tiempo.
• [C-1-4] SE DEBE aleatorizar la dirección de la interfaz de administración de reconocimiento de Wi-Fi por intervalos. no debe durar más de 30 minutos y siempre que se habilite el reconocimiento de Wi-Fi, a menos que se active la operación de rango está en curso o una ruta de acceso a los datos detectada está activa (la aleatorización no mientras la ruta de datos esté activa).

Si las implementaciones en dispositivos incluyen compatibilidad con reconocimiento de Wi-Fi y Ubicación Wi-Fi, como se describe en la Sección 7.4.2.5 y Expone estas funcionalidades a apps de terceros y, luego, hace lo siguiente:

• [C-2-1] DEBEN implementar las APIs de detección adaptada a la ubicación: setRangingEnabled, setMinDistanceMm setMaxDistanceMm y onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint para Wi-Fi

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

• [C-1-1] DEBE incluir compatibilidad con Wi-Fi Passpoint.
• [C-1-2] DEBE implementar las APIs de WifiManager relacionadas con Passpoint como que se describe en la documentación de SDK.
• [C-1-3] DEBE ser compatible con el estándar IEEE 802.11u, relacionado específicamente con descubrimiento y selección de redes, como los anuncios genéricos Google Cloud Service (GAS) y el Protocolo de consulta de red de acceso (ANQP).
• [C-1-4] SE DEBE declarar la marca de función android.hardware.wifi.passpoint.
• [C-1-5] DEBE seguir la implementación de AOSP para descubrir, hacer coincidir y asociar a las redes de Passpoint.
• [C-1-6] DEBE admitir al menos el siguiente subconjunto de provisión de dispositivos protocolos, como se define en Wi-Fi Alliance Passpoint R2: EAP-TTLS autenticación y SOAP-XML.
• [C-1-7] DEBE procesar el certificado del servidor AAA como se describe en Especificación de Hotspot 2.0 R3.
• [C-1-8] DEBE admitir el control de aprovisionamiento por parte del usuario a través del selector de Wi-Fi.
• [C-1-9] DEBE mantener la persistencia de la configuración de Passpoint en los reinicios.
• [C-SR-1] SE RECOMIENDA APTO para que cumplan con los Términos y Condiciones y aceptación de las condiciones.
• [C-SR-2] SE RECOMIENDA ENERCMENTE que respalden la función de información del lugar.

Si se proporciona un interruptor global de Passpoint que inhabilita el interruptor de control de usuario, las implementaciones hacen lo siguiente:

• [C-3-1] SE DEBE habilitar Passpoint de forma predeterminada.

7.4.2.5. Ubicación de Wi-Fi (tiempo de ida y vuelta de Wi-Fi - RTT)

Implementaciones en dispositivos:

• SE DEBE incluir compatibilidad con la Ubicación Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con la ubicación de Wi-Fi y exponen el a apps de terceros, les permiten hacer lo siguiente:

• [C-1-1] SE DEBE implementar las APIs de WifiRttManager como se describe en Documentación del SDK.
• [C-1-2] DEBE declarar la marca de función android.hardware.wifi.rtt.
• [C-1-3] DEBE aleatorizar la dirección MAC de origen para cada aumento de actividad de RTT. que se ejecuta mientras se usa la interfaz Wi-Fi en la que se ejecuta el RTT que se está ejecutando no está asociada a un punto de acceso.
• [C-1-4] DEBE tener una precisión de 2 metros a un ancho de banda de 80 MHz en el rango percentil (calculado con la función de distribución acumulativa).
• [C-SR-1] SE RECOMIENDA ENcarecidamente que informen el resultado con precisión dentro de un radio de 1.5 metros de 80 MHz en el percentil 68 (según se calcula con el Función de distribución acumulativa).

7.4.2.6. Descarga de Wi-Fi Keepalive

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con la descarga de keepalive de Wi-Fi.

Si las implementaciones en dispositivos incluyen compatibilidad con la descarga de keepalive de Wi-Fi y exponen la funcionalidad a apps de terceros, hacen lo siguiente:

• [C-1-1] DEBE admitir la API de SocketKeepAlive.
• [C-1-2] DEBE admitir al menos tres ranuras de keepalive simultáneas a través de Wi-Fi

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga keepalive de Wi-Fi, hace lo siguiente:

• [C-2-1] DEBE devolver ERROR_UNSUPPORTED.

7.4.2.7. Easy Connect para Wi-Fi (protocolo de aprovisionamiento de dispositivos)

Implementaciones en dispositivos:

• Se recomienda incluir compatibilidad con Easy Connect (DPP) de Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Easy Connect, de Google Cloud a apps de terceros, hacen lo siguiente:

• [C-1-1] DEBE tener el WifiManager#isEasyConnectSupported() que muestra true.

7.4.2.8. Validación del certificado del servidor Wi-Fi para empresas

Si el certificado del servidor Wi-Fi no está validado o el servidor Wi-Fi nombre de dominio no establecido, implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA MUY BIEN no proporcionarle al usuario la opción de agregar manualmente la red Wi-Fi empresarial en la app de Configuración.

7.4.2.9. Confianza en el primer uso (TOFU)

Si las implementaciones de dispositivos admiten confianza en el primer uso (TOFU) y permitir que el usuario defina configuraciones de WPA/WPA2/WPA3-Enterprise, entonces:

• [C-4-1] DEBE brindarle al usuario la opción de usar TOFU.

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth, sucederá lo siguiente:

• DEBE admitir Códecs de audio avanzados y códecs de audio Bluetooth (p.ej., LDAC)

Si las implementaciones de dispositivos admiten HFP, A2DP y AVRCP, harán lo siguiente:

• SE RECOMIENDA admitir al menos 5 dispositivos conectados en total.

Si las implementaciones de dispositivos declaran android.hardware.vr.high_performance funciones, les permiten hacer lo siguiente:

• [C-1-1] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE.

Android admite Bluetooth y Bluetooth de bajo consumo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth y Bluetooth De bajo consumo, hacen lo siguiente:

• [C-2-1] SE DEBE declarar las funciones relevantes de la plataforma. (android.hardware.bluetooth y android.hardware.bluetooth_le respectivamente) e implementarás las APIs de la plataforma.
• SE RECOMIENDA implementar perfiles de Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP, etc., según corresponda para el dispositivo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo (BLE), sucederá lo siguiente:

• [C-3-1] SE DEBE declarar la función de hardware android.hardware.bluetooth_le.
• [C-3-2] SE DEBE habilitar el Bluetooth basado en GATT (perfil de atributo genérico) APIs, como se describe en la documentación del SDK y android.bluetooth.
• [C-3-3] SE DEBE informar el valor correcto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar si lógica de filtrado para ScanFilter clases de API.
• [C-3-4] DEBE informar el valor correcto para BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo.

• [C-3-5] DEBE implementar un tiempo de espera de dirección privada resolvable (RPA) ya no. más de 15 minutos y rotar la dirección en el tiempo de espera para proteger la privacidad del usuario Cuando el dispositivo usa activamente BLE para escaneo o publicidad Para evitar ataques de tiempo, los intervalos de tiempo de espera también DEBEN ser aleatorios entre 5 y 15 minutos.

• SE DEBE admitir la transferencia de la lógica de filtrado al chipset de Bluetooth cuando implementes la API de ScanFilter.

• SE DEBE admitir la transferencia del escaneo por lotes al chipset Bluetooth.

• SE DEBE admitir anuncios múltiples con al menos 4 espacios.

Si las implementaciones de dispositivos admiten Bluetooth LE y se usa Bluetooth LE para el escaneo de ubicación, hace lo siguiente:

• [C-4-1] DEBE proporcionar una indicación visual del usuario para habilitar/inhabilitar el valor de lectura. a través de la API del sistema BluetoothAdapter.isBleScanAlwaysAvailable().

Si las implementaciones en los dispositivos incluyen compatibilidad con Bluetooth de bajo consumo y audífonos Perfil, como se describe en Compatibilidad con audio de audífonos con Bluetooth de bajo consumo:

• [C-5-1] DEBE devolver true por BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID).

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo, hacen lo siguiente:

• [C-6-1] SE DEBE restringir el acceso a todos los metadatos de Bluetooth (como el escaneo resultados) que podrían usarse para obtener la ubicación del dispositivo, a menos que la app solicitante pasa correctamente una android.permission.ACCESS_FINE_LOCATION la verificación de permisos según su estado actual en primer o segundo plano.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo y el manifiesto de la app no incluye una declaración del desarrollador que indique que no deriven la ubicación de Bluetooth, luego, hacen lo siguiente:

• [C-6-2] DEBE establecer la puerta de acceso a Bluetooth detrás del android.permission.ACCESS_FINE_LOCATION.

Si las implementaciones de dispositivos muestran true para la BluetoothAdapter.isLeAudioSupported() y, luego, haz lo siguiente:

• [C-7-1] DEBE ser compatible con el cliente de unidifusión.
• [C-7-2] DEBE admitir 2M PHY.
• [C-7-3] DEBE ser compatible con la publicidad de LE Extended.
• [C-7-4] DEBE admitir al menos 2 conexiones CIS en una CIG.
• [C-7-5] DEBE habilitar el cliente de unidifusión de BAP, el coordinador de conjunto de CSIP, el servidor MCP un controlador VCP y un servidor CCP simultáneamente.
• [C-SR-1] SE RECOMIENDAN IMPORTANTE para habilitar el cliente de unidifusión de HAP.

Si las implementaciones de dispositivos muestran true para la BluetoothAdapter.isLeAudioBroadcastSourceSupported() y, luego, haz lo siguiente:

• [C-8-1] DEBE admitir al menos 2 vínculos BIS en una BIG.
• [C-8-2] SE DEBE habilitar la fuente de transmisión de BAP, el asistente de emisión de BAP. al mismo tiempo.
• [C-8-3] DEBE admitir la publicidad periódica LE.

Si las implementaciones de dispositivos muestran true para la BluetoothAdapter.isLeAudioBroadcastAssistantSupported() y, luego, haz lo siguiente:

• [C-9-1] DEBE admitir PAST (transferencia de sincronización de publicidad periódica).
• [C-9-2] DEBE admitir la publicidad periódica LE.

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

• [C-10-1] DEBE tener mediciones de RSSI dentro de +/-9dB para el 95% de la medidas a 1 m de distancia de un dispositivo de referencia que transmite a ADVERTISE_TX_POWER_HIGH en un entorno de línea de visión.

• [C-10-2] DEBE incluir correcciones de Rx/Tx para reducir las desviaciones por canal. para que las mediciones de cada uno de los 3 canales, de cada una de las antenas (si se utilizan varios), deben estar dentro de un margen de +/-3 dB entre sí para el 95% de la de las mediciones.

• [C-SR-2] SE RECOMIENDA COMPLETAMENTE medir y compensar el desplazamiento de Rx a asegúrate de que la mediana de RSSI de BLE sea de -60 dBm +/-10 dB a una distancia de 1 m dispositivo de referencia transmitiendo a ADVERTISE_TX_POWER_HIGH, donde los dispositivos orientadas de modo que estén en "planos paralelos" con pantallas hacia la misma dirección IP.

• [C-SR-3] SE RECOMIENDA COMPLETAMENTE medir y compensar el desplazamiento de Tx a Asegúrate de que la mediana de RSSI de BLE sea de -60 dBm +/-10 dB cuando se realiza un escaneo a partir de una referencia dispositivo ubicado a 1 m de distancia y transmitiendo a una ADVERTISE_TX_POWER_HIGH, cuando los dispositivos están orientados de modo que están encendidos "planos paralelos" con pantallas hacia la misma dirección.

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

SE RECOMIENDA MUY BIEN seguir los pasos para configurar la medición especificados en Requisitos de calibración de presencias.

7.4.4. Comunicaciones de campo cercano

Implementaciones en dispositivos:

• SE DEBE incluir un transceptor y el hardware relacionado para la función de campo cercano Comunicaciones (NFC).
• [C-0-1] DEBE implementar android.nfc.NdefMessage y APIs de android.nfc.NdefRecord incluso si no son compatibles con NFC o declarar el atributo android.hardware.nfc, ya que las clases representan un independiente del protocolo de representación de datos.

Si las implementaciones de dispositivos incluyen hardware NFC y planean que esté disponible para en apps de terceros, hacen lo siguiente:

• [C-1-1] SE DEBE informar la función android.hardware.nfc desde el Método android.content.pm.PackageManager.hasSystemFeature().
• DEBE ser capaz de leer y escribir mensajes NDEF a través del siguiente NFC estándares como los siguientes:
• [C-1-2] DEBE ser capaz de actuar como lector/escritor de NFC Forum (tal como se define en las especificaciones técnicas del foro de NFC) NFCForum-TS-DigitalProtocol-1.0) mediante los siguientes estándares de NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de etiquetas del foro de NFC 1, 2, 3, 4, 5 (definidas por NFC Forum)

• [C-SR-1] SE RECOMIENDA ENERCMENTE ser capaz de leer y escribir NDEF al igual que los datos sin procesar a través de los siguientes estándares NFC. Ten en cuenta que si bien los estándares de NFC se indican como RECOMENDADOS EN FUERTE, Se planea cambiar la definición de compatibilidad para una versión futura DEBES. Estos estándares son opcionales en esta versión, pero serán obligatorios en versiones futuras. En los dispositivos existentes y nuevos que ejecutan esta versión de Recomendamos encarecidamente que Android cumpla con estos requisitos ahora, por lo que podrán actualizarse a versiones futuras de la plataforma.

• [C-1-13] SE DEBE sondear todas las tecnologías compatibles durante el descubrimiento de NFC .

• DEBES estar en modo de descubrimiento NFC mientras el dispositivo está activo con el la pantalla activa y la pantalla de bloqueo desbloqueada.

• DEBES poder leer el código de barras y la URL (si están codificados) de Código de barras NFC delgado productos.

Ten en cuenta que los vínculos disponibles públicamente no están disponibles para JIS, ISO ni NFC. Especificaciones del foro citadas anteriormente.

Android admite el modo de emulación de tarjeta de host NFC (HCE).

Si las implementaciones de dispositivos incluyen un chipset del controlador NFC capaz de HCE (para NfcA o NfcB) y admiten el enrutamiento de ID de aplicación (AID), hacen lo siguiente:

• [C-2-1] DEBE informar la constante de función android.hardware.nfc.hce.
• [C-2-2] DEBE ser compatible con las APIs de NFC HCE, como definidos en el SDK de Android.

Si las implementaciones del dispositivo incluyen un chipset del controlador NFC capaz de usar HCE, haz lo siguiente: para NfcF e implementar la función en aplicaciones de terceros, lograron lo siguiente:

• [C-3-1] DEBE informar la constante de función android.hardware.nfc.hcef.
• [C-3-2] SE DEBE implementar las APIs de emulación de tarjeta de NFCF. según se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad general con NFC, como se describe en este y admiten las tecnologías MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF en MIFARE Classic) en el rol de lector/escritor, hizo lo siguiente:

• [C-4-1] SE DEBE implementar las API de Android correspondientes tal como se documenta el SDK de Android.
• [C-4-2] SE DEBE informar la función com.nxp.mifare desde el android.content.pm.PackageManager.hasSystemFeature() . Ten en cuenta que esta no es una función estándar de Android y, por lo tanto, no aparecerá como una constante en la clase android.content.pm.PackageManager.

7.4.5. Protocolos de red y APIs

7.4.5.1. Capacidad de red mínima

Implementaciones en dispositivos:

• [C-0-1] DEBE incluir asistencia para una o más formas de las redes de datos. Específicamente, las implementaciones en dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos capaz de 200 Kbit/s o superior. Ejemplos de que satisfacen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet y número PAN Bluetooth.
• También se DEBE incluir compatibilidad con al menos un cable de datos inalámbrico común estándar, como 802.11 (Wi-Fi), cuando un estándar físico de red (como Ethernet) es la conexión de datos principal.
• PUEDE implementar más de una forma de conectividad de datos.

7.4.5.2. IPv6

Implementaciones en dispositivos:

• [C-0-2] DEBE incluir una pila de red IPv6 y admitir IPv6 mediante APIs administradas, como java.net.Socket y java.net.URLConnection y las APIs nativas, como AF_INET6 enchufes.
• [C-0-3] SE DEBE habilitar IPv6 de forma predeterminada.
  • DEBES asegurarte de que la comunicación IPv6 sea tan confiable como IPv4, por ejemplo:
    • [C-0-4] DEBE mantener la conectividad IPv6 en modo Descanso.
    • [C-0-5] El límite de frecuencia NO DEBE hacer que el dispositivo pierda IPv6 conectividad en cualquier red compatible con IPv6 que use ciclos de vida de RA al menos 180 segundos.
• [C-0-6] DEBE proporcionar aplicaciones de terceros con conectividad IPv6 directa a la red cuando se conecta a una red IPv6, sin ninguna forma de dirección traducción de puertos de manera local en el dispositivo. Ambas APIs administradas, como Socket#getLocalAddress o Socket#getLocalPort) y las APIs del NDK, como getsockname() o IPV6_PKTINFO, DEBEN devolver la IP y el puerto real que se usa para enviar y recibir paquetes en la visible como la IP y el puerto de origen para los servidores de Internet (web).

El nivel requerido de compatibilidad con IPv6 depende del tipo de red, como se muestra en con los siguientes requisitos.

Si las implementaciones de dispositivos admiten Wi-Fi, sucederá lo siguiente:

• [C-1-1] DEBE admitir operaciones de pila doble y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos son compatibles con Ethernet, deberán hacer lo siguiente:

• [C-2-1] DEBE admitir la operación de pila doble y solo IPv6 en Ethernet

Si las implementaciones de dispositivos admiten datos móviles, harán lo siguiente:

• [C-3-1] DEBE admitir la operación de IPv6 (solo IPv6 y posiblemente de pila doble) en móvil.

Si las implementaciones de dispositivos admiten más de un tipo de red (p.ej., Wi‐Fi y datos móviles), hacen lo siguiente:

• [C-4-1] DEBE cumplir de forma simultánea con los requisitos anteriores en cada red cuando el dispositivo está conectado simultáneamente a más de un tipo de red.

7.4.5.3 Portales cautivos

Un portal cautivo hace referencia a una red que requiere iniciar sesión para obtener acceso a Internet.

Si las implementaciones en dispositivos proporcionan una implementación completa del android.webkit.Webview API, hace lo siguiente:

• [C-1-1] DEBE proporcionar una aplicación de portal cautivo para manejar el intent ACTION_CAPTIVE_PORTAL_SIGN_IN y mostrar la página de acceso al portal cautivo enviando ese intent en llamada a la API del sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle)
• [C-1-2] DEBE realizar la detección de portales cautivos y admitir el acceso. a través de la aplicación del portal cautivo cuando el dispositivo está conectado a cualquier tipo de red, incluidas la red móvil o móvil, Wi-Fi y Ethernet. o Bluetooth.
• [C-1-3] DEBE admitir el acceso a portales cautivos con DNS de texto simple. cuando el dispositivo está configurado para usar el modo estricto de DNS privado.
• [C-1-4] DEBE usar DNS encriptado según la documentación del SDK para android.net.LinkProperties.getPrivateDnsServerName y android.net.LinkProperties.isPrivateDnsActive para todo el tráfico de red que no se comunique explícitamente con el o portal cautivo.
• [C-1-5] SE DEBE asegurarse de que, mientras el usuario esté accediendo a un dispositivo prisionero predeterminado, la red predeterminada que usan las aplicaciones (como devuelve ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, y lo usan de forma predeterminada las APIs de redes de Java, como java.net.Socket, y APIs nativas como connect()) es cualquier otra red disponible que proporcione acceso a Internet, si está disponible.

7.4.6. Configuración de sincronización

Implementaciones en dispositivos:

• [C-0-1] DEBE tener activada la sincronización automática de la instancia principal de forma predeterminada para que el método getMasterSyncAutomatically() devuelve “true”.

7.4.7. Ahorro de datos

Si las implementaciones en dispositivos incluyen una conexión de uso medido, son las siguientes:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE proporcionar el modo de Ahorro de datos.

Si las implementaciones de dispositivos proporcionan el modo de Ahorro de datos, sucederá lo siguiente:

• [C-1-1] DEBE admitir todas las APIs en ConnectivityManager según se describe en la documentación del SDK.

Si las implementaciones de dispositivos no proporcionan el modo de Ahorro de datos, sucederá lo siguiente:

• [C-2-1] SE DEBE mostrar el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NO SE DEBE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

7.4.8. Elementos seguros

Si las implementaciones en dispositivos admiten Open Mobile API elementos seguros y los ponen a disposición de apps de terceros, hacen lo siguiente:

• [C-1-1] SE DEBE enumerar los elementos seguros disponibles a través de los lectores API de android.se.omapi.SEService.getReaders().

• [C-1-2] SE DEBE declarar las marcas de función correctas a través de android.hardware.se.omapi.uicc para el dispositivo con elementos seguros basados en UICC, android.hardware.se.omapi.ese para el dispositivo con elementos seguros basados en eSE y android.hardware.se.omapi.sd para el dispositivo con elementos seguros basados en SD.

7.4.9. UWB

Si las implementaciones en dispositivos incluyen compatibilidad para 802.1.15.4 y exponer la funcionalidad a una aplicación de terceros. entonces:

• [C-1-1] DEBE implementar la API de Android correspondiente en android.uwb.
• [C-1-2] SE DEBE informar el parámetro de función de hardware android.hardware.uwb.
• [C-1-3] DEBE admitir todos los perfiles de UWB relevantes definidos en Android. para implementarlos.
• [C-1-4] DEBE proporcionar una indicación visual del usuario que le permita activar o desactivar la UWB. estado de encendido/apagado de la radio.
• [C-1-5] DEBE exigir que las apps que usan un radio UWB desplacen el permiso UWB_RANGING. (en el grupo de permisos NEARBY_DEVICE).
• [C-SR-1] SE RECOMIENDA ENcarecidamente aprobar la conformidad y pruebas de certificación definidas por las organizaciones estándar, incluidas FIRA y CCC y CSA.
• [C-1-6] SE DEBE asegurarse de que las medidas de distancia sean de +/-15 cm para un 95%. de las mediciones en el entorno de la línea de visión a 1 m de distancia en una cámara no reflectante.
• [C-1-7] DEBE asegurarse de que la mediana de las mediciones de distancia sea de 1 m. de referencia se encuentra dentro de [0.75m, 1.25m], donde la verdad fundamental La distancia se mide desde el borde superior del DUT. Se mantiene hacia arriba y se inclina 45 grados.
• [C-SR-2] SE RECOMIENDA ENERCMENTE que sigan los pasos para configurar la medición especificadas en Requisitos de calibración de presencias.

7.5 Cámaras

Si las implementaciones en dispositivos incluyen al menos una cámara, sucederá lo siguiente:

• [C-1-1] DEBE declarar la marca de función android.hardware.camera.any.
• [C-1-2] DEBE ser posible para que una aplicación asigne simultáneamente 3 mapas de bits RGBA_8888 iguales al tamaño de las imágenes producidas por la de mayor resolución del dispositivo, mientras que la cámara está abierta para la propósito de la vista previa básica y de la captura.
• [C-1-3] SE DEBE asegurarse de que la aplicación de cámara predeterminada preinstalada. controlar intents MediaStore.ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE_SECURE, o MediaStore.ACTION_VIDEO_CAPTURE, es responsable de quitar la ubicación del usuario en los metadatos de la imagen antes y la envía a la aplicación receptora cuando esta no tener ACCESS_FINE_LOCATION.

Si las implementaciones de dispositivos admiten la capacidad de salida HDR de 10 bits, sucederá lo siguiente:

• [C-2-1] DEBE admitir al menos el perfil HLG HDR para cada dispositivo de cámara. que admita una salida de 10 bits.
• [C-2-2] DEBE admitir 10 bits de salida, ya sea para la parte posterior principal o para la cámara frontal principal.
• [C-SR-1] SE RECOMIENDA ENERGENTE para admitir una salida de 10 bits para la fuente cámaras.
• [C-2-3] DEBE admitir los mismos perfiles HDR para todos Subcámaras físicas de una cámara lógica compatibles con BACKWARD_COMPATIBLE. la cámara lógica en sí.

Para dispositivos de cámara lógica compatibles con HDR de 10 bits que implementen la android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, hace lo siguiente:

• [C-3-1] DEBE admitir el cambio entre todos los dispositivos físicos retrocompatibles mediante el control CONTROL_ZOOM_RATIO de la cámara lógica.

7.5.1 Cámara posterior

Implementaciones en dispositivos:

• SE RECOMIENDA incluir una cámara posterior.

Si las implementaciones en dispositivos incluyen al menos una cámara posterior, sucederá lo siguiente:

• [C-1-1] SE DEBE informar la marca de función android.hardware.camera y android.hardware.camera.any
• [C-1-2] DEBE tener una resolución de al menos 2 megapíxeles.
• SE DEBE tener implementado un enfoque automático de hardware o uno de software. en el controlador de la cámara (transparente para el software de aplicación).
• PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
• PUEDE incluir un destello.

Si la cámara incluye flash:

• [C-2-1] la lámpara con flash NO DEBE encenderse mientras se Se registró android.hardware.Camera.PreviewCallback instancia en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un objeto Camera.Parameters. Ten en cuenta que esta restricción no se aplica de la cámara integrada en el sistema del dispositivo, pero solo a aplicaciones que usan Camera.PreviewCallback.

7.5.2. Cámara frontal

Implementaciones en dispositivos:

• PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, sucederá lo siguiente:

• [C-1-1] SE DEBE informar la marca de función android.hardware.camera.any y android.hardware.camera.front
• [C-1-2] DEBE tener una resolución de, al menos, VGA (640 x 480 píxeles).
• [C-1-3] NO DEBES usar una cámara frontal de forma predeterminada para el Camera API y NO DEBE configurar la API para tratar a la cámara frontal como la cámara posterior predeterminada, incluso si es la única cámara del dispositivo.
• [C-1-4] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con el orientación especificada por la aplicación cuando la aplicación actual tiene solicitó explícitamente que la Cámara rote la pantalla mediante una llamada al android.hardware.Camera.setDisplayOrientation() . Por el contrario, la vista previa DEBE duplicarse junto con la configuración eje horizontal cuando la aplicación actual no solicita explícitamente que se gire la pantalla de la cámara mediante una llamada al android.hardware.Camera.setDisplayOrientation() .
• [C-1-5] NO DEBE duplicar la imagen estática capturada final ni las transmisiones de video por Internet. Se devuelven a las devoluciones de llamada de la aplicación o se confirman en el almacenamiento de contenido multimedia.
• [C-1-6] SE DEBE duplicar la imagen que se muestra en la vista posterior del mismo modo. como la transmisión de imágenes de vista previa de la cámara.
• PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para cámaras posteriores, como se describe en la sección 7.5.1.

Si el usuario puede rotar las implementaciones de dispositivos (por ejemplo, automáticamente con un acelerómetro o de forma manual mediante la entrada del usuario):

• [C-2-1] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.

7.5.3 Cámara externa

Implementaciones en dispositivos:

• PUEDE incluir compatibilidad con una cámara externa que no sea necesariamente siempre conectados.

Si las implementaciones de dispositivos incluyen compatibilidad con una cámara externa, sucederá lo siguiente:

• [C-1-1] SE DEBE declarar la marca de función de la plataforma. android.hardware.camera.external y android.hardware camera.any.
• [C-1-2] DEBE admitir clase de video USB (UVC 1.0 o superior) si el adaptador La cámara se conecta a través del puerto USB del host.
• [C-1-3] DEBE pasar las pruebas del CTS de la cámara con un dispositivo de cámara externo físico. conectado. Los detalles de las pruebas del CTS de la cámara están disponibles en source.android.com.
• SE RECOMIENDA admitir compresiones de video como MJPEG para permitir la transferencia de transmisiones sin codificación de alta calidad (es decir, imágenes sin procesar o comprimidas de forma independiente) transmisiones continuas).
• PUEDE admitir varias cámaras.
• PUEDE admitir la codificación de video basada en la cámara.

Si se admite la codificación de video basada en la cámara:

• [C-2-1] Un mensaje simultáneo de transmisión MJPEG o sin codificación (QVGA o mayor resolución) DEBE ser accesible para la implementación del dispositivo.

7.5.4. Comportamiento de la API de Camera

Android incluye dos paquetes de API para acceder a la cámara, el más reciente La API de android.hardware.camera2 expone el control de la cámara de nivel inferior a la app. como flujos eficientes de picos de actividad/transmisión y controles por fotograma de exposición, ganancia, ganancias del balance de blancos, conversión de color, reducción de ruido, nitidez, y más.

El paquete de API más antiguo,android.hardware.Camera, se marca como obsoleto en Android 5.0, pero, como todavía debería estar disponible para que las apps lo usen Dispositivo Android implementaciones DEBEN garantizar la asistencia continua de la API, tal como se describe en esta sección y en el SDK de Android.

Todas las funciones comunes entre la clase android.hardware.Camera obsoleta y el paquete android.hardware.camera2 más nuevo DEBE tener un rendimiento equivalente. y calidad en ambas APIs. Por ejemplo, con una configuración equivalente, la velocidad y la precisión del enfoque automático deben ser idénticas, y la calidad de las imágenes capturadas debe ser la misma. Funciones que dependen de la semántica de las dos APIs no es necesario que tengan la misma velocidad o calidad, pero DEBERÍAN coincidir lo más posible de la forma más eficaz posible.

Las implementaciones en dispositivos DEBEN implementar los siguientes comportamientos para el relacionadas con la cámara, para todas las cámaras disponibles. Implementaciones en dispositivos:

• [C-0-1] SE DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para la vista previa. datos proporcionados a las devoluciones de llamada de la aplicación cuando una aplicación nunca ha llamado android.hardware.Camera.Parameters.setPreviewFormat(int)
• [C-0-2] DEBE tener el formato de codificación NV21 cuando una aplicación registra un android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() y a la vista previa formato es YCbCr_420_SP, los datos del byte[] pasado a onPreviewFrame(). Es decir, NV21 DEBE ser el predeterminado.
• [C-0-3] DEBE ser compatible con el formato YV12 (como se indica en el android.graphics.ImageFormat.YV12) para las vistas previas de la cámara en ambas cámaras frontal y posterior para android.hardware.Camera. (El hardware el codificador de video y la cámara pueden usar cualquier formato de píxeles nativo, pero el dispositivo la implementación DEBE admitir la conversión a YV12).
• [C-0-4] DEBE admitir los android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como salidas a través de API de android.media.ImageReader para dispositivos android.hardware.camera2 que anunciar REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities.
• [C-0-5] Aún se DEBE implementar la API de Camera completa incluidas en la documentación del SDK de Android, sin importar si el dispositivo incluye enfoque automático de hardware y otras capacidades. Por ejemplo, las cámaras que sin enfoque automático DEBE llamar a todos los dispositivos android.hardware.Camera.AutoFocusCallback de instancias (aunque no tenga relevancia con respecto a una cámara sin enfoque automático). Ten en cuenta que esto se aplica a las apps cámaras; por ejemplo, aunque la mayoría de las cámaras frontales no admiten enfoque automático, las devoluciones de llamada de la API aún deben “simularse” como se describe.
• [C-0-6] DEBE reconocer y respetar cada nombre de parámetro. definida como una constante en la android.hardware.Camera.Parameters y la clase android.hardware.camera2.CaptureRequest. Por el contrario, las implementaciones en dispositivos NO DEBEN respetar ni reconocer las constantes de cadena que se pasan al método android.hardware.Camera.setParameters() documentados como constantes en android.hardware.Camera.Parameters. Es decir, las implementaciones en dispositivos DEBEN admitir todos los parámetros estándar de la cámara si el hardware lo permite y NO DEBE admitir tipos de parámetros personalizados de la cámara. Por ejemplo, las implementaciones en dispositivos que admiten la captura de imágenes Con técnicas de imagen de alto rango dinámico (HDR) DEBE admitir el parámetro de la cámara Camera.SCENE_MODE_HDR
• [C-0-7] DEBE informar el nivel adecuado de asistencia al android.info.supportedHardwareLevel propiedad, tal como se describe en el SDK de Android, y se debe informar la marcas de funciones del framework.
• [C-0-8] también DEBE declarar sus capacidades individuales de cámara para android.hardware.camera2 mediante el Propiedad android.request.availableCapabilities y declarar las marcas de función adecuadas DEBE definir la marca de función si alguno de los dispositivos de cámara conectados admita la función.
• [C-0-9] DEBE transmitir el Camera.ACTION_NEW_PICTURE intent cada vez que se toma una nueva fotografía y el ingreso de la se ha agregado la foto a la tienda de medios.
• [C-0-10] SE DEBE transmitir la Camera.ACTION_NEW_VIDEO. cada vez que la cámara graba un video nuevo y la entrada de la se ha agregado la foto a la tienda de medios.
• [C-0-11] SE DEBE tener acceso a todas las cámaras a través de la versión obsoleta android.hardware.Camera También se puede acceder a la API a través de android.hardware.camera2 API de gcloud.
• [C-0-12] SE DEBE asegurarse de que la apariencia facial NO se haya alterado, lo que incluye alteración de la geometría, el tono de piel o el rostro suavizar la piel para cualquier android.hardware.camera2 o android.hardware.Camera API de gcloud.
• [C-SR-1] Para dispositivos con varias cámaras RGB en muy cerca y orientados en la misma dirección se recomienda encarecidamente que admitas un dispositivo de cámara lógico que muestre capacidad CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA: que constan de todas las cámaras RGB orientadas a esa dirección como dispositivos secundarios físicos.

Si las implementaciones en dispositivos proporcionan una API de cámara de propiedad a apps de terceros, hacen lo siguiente:

• [C-1-1] SE DEBE implementar una API de cámara de este tipo con android.hardware.camera2. API de gcloud.
• PUEDE proporcionar etiquetas o extensiones del proveedor a android.hardware.camera2. API de gcloud.

7.5.5 Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o posterior, estas cámaras son las siguientes:

• [C-1-1] SE DEBE orientar para que la dimensión larga de la cámara se alinee con la dimensión larga de la pantalla. Es decir, cuando el dispositivo se mantiene en posición horizontal, la orientación, las cámaras DEBEN capturar imágenes en orientación horizontal. Esta se aplica independientemente de la orientación natural del dispositivo. es decir, se aplica dispositivos principales horizontales y dispositivos principales verticales.

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

• El dispositivo implementa pantallas de geometría variable, como plegables o bisagras pantallas.
• Cuando cambia el estado de plegado o bisagra del dispositivo, este cambia entre Orientación vertical-primaria a horizontal-principal (o viceversa).

7.6 Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Implementaciones en dispositivos:

• [C-0-1] DEBE incluir un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos y DEBEN ser capaces de descargar archivos individuales de 100 MB como mínimo con la configuración predeterminada "caché" ubicación.

7.6.2. Almacenamiento compartido de la aplicación

Implementaciones en dispositivos:

• [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones (también conocidas como "almacenamiento externo compartido", "almacenamiento compartido de la aplicación" o el sistema operativo de Linux ruta de acceso "/sdcard" en la que esté montado.
• [C-0-2] DEBE configurarse con el almacenamiento compartido activado de forma predeterminada, en otros palabras "listos para usar", sin importar si el almacenamiento se implementa en un componente de almacenamiento interno o un medio de almacenamiento extraíble (por ejemplo, almacenamiento Ranura para tarjeta digital).
• [C-0-3] SE DEBE activar el almacenamiento compartido de la aplicación directamente en la ruta de acceso de Linux. sdcard o incluir un vínculo simbólico de Linux de sdcard a la activación real punto.
• [C-0-4] SE DEBE habilitar almacenamiento específico de forma predeterminada para todos aplicaciones orientadas al nivel de API 29 o superior, excepto en el siguiente caso:
  • Cuando la app solicita android:requestLegacyExternalStorage="true" en su manifiesto.
• [C-0-5] DEBE ocultar los metadatos de ubicación, como las etiquetas Exif de GPS, almacenadas en archivos multimedia cuando se accede a ellos a través de MediaStore, excepto cuando la app que realiza la llamada tiene el permiso ACCESS_MEDIA_LOCATION.

Las implementaciones en dispositivos PUEDEN cumplir con los requisitos anteriores usando cualquiera de lo siguiente:

• Almacenamiento extraíble accesible para el usuario, como una ranura de tarjeta Secure Digital (SD).
• Una parte del almacenamiento interno (no extraíble), tal como se implementa en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones en dispositivos usan almacenamiento extraíble para cumplir con los requisitos anteriores los requisitos, ellos:

• [C-1-1] SE DEBE implementar una notificación o interfaz de usuario emergente para advertir al usuario. cuando no se inserta ningún medio de almacenamiento en la ranura.
• [C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (p. ej., tarjeta SD) o programa. en la caja y otros materiales disponibles en el momento de la compra que el almacenamiento medio se debe comprar por separado.

Si las implementaciones de dispositivos usan una parte del almacenamiento no extraíble para satisfacer con los requisitos anteriores:

• SE DEBE usar la implementación de AOSP de la aplicación interna compartida y almacenamiento de los datos.
• PUEDE compartir el espacio de almacenamiento con los datos privados de la aplicación.

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB, hace lo siguiente:

• [C-3-1] DEBE proporcionar un mecanismo para acceder a los datos en la aplicación. almacenamiento compartido desde una computadora host.
• SE RECOMIENDA exponer el contenido de ambas rutas de almacenamiento de forma transparente a través de Servicio de escáner de contenido multimedia de Android y android.provider.MediaStore
• PUEDE utilizar el almacenamiento masivo USB, pero SE DEBE utilizar el Protocolo de transferencia de medios para satisfacer este requisito.

Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y compatibilidad protocolo de transferencia de medios, hacen lo siguiente:

• DEBE ser compatible con el host MTP de Android de referencia. Android File Transfer
• SE DEBE informar una clase de dispositivo USB de 0x00.
• SE DEBE informar que la interfaz USB es "MTP".

7.6.3. Almacenamiento adoptable

Si se espera que el dispositivo sea móvil, a diferencia de la televisión, implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlas accidentalmente puede causar la pérdida o corrupción de datos.

Si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimento de las baterías o otra cubierta protectora, implementaciones en dispositivos:

• [C-SR-2] RECOMENDACIÓN ENERGENTE de implementar almacenamiento adoptable.

7.7 USB

Si las implementaciones de dispositivos tienen un puerto USB, tienen las siguientes características:

• SE DEBE admitir el modo de periférico USB y el modo de host USB.
• DEBERÍA admitir la inhabilitación de la señalización de datos por USB.

7.7.1 Modo periférico USB

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo periférico:

• [C-1-1] El puerto DEBE conectarse a un host USB que tenga un puerto USB tipo A o tipo C.
• [C-1-2] SE DEBE informar el valor correcto de iSerialNumber en el estándar USB descriptor de dispositivo a través de android.os.Build.SERIAL.
• [C-1-3] DEBE detectar cargadores de 1.5 A y 3.0 A según la resistencia tipo C estándar y DEBE detectar cambios en el anuncio si admiten USB tipo C.
• [C-SR-1] El puerto DEBE usar el factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos de la plataforma para que puedan actualizarse a las versiones futuras de la plataforma.
• [C-SR-2] El puerto SE DEBE ubicar en la parte inferior del dispositivo. (según la orientación natural) o habilita la rotación de pantalla de software para todas las aplicaciones (incluida la pantalla principal), para que la pantalla se dibuje correctamente cuando que el dispositivo esté orientado con el puerto en la parte inferior. Android existente y nuevo se recomienda que los dispositivos cumplan con estos requisitos y no puedas actualizarlo a versiones futuras de la plataforma.
• [C-SR-3] SE DEBE implementar compatibilidad para generar una corriente de 1.5 A durante el pitido de HS y el tráfico, como se especifica en la especificación de la carga de batería USB, revisión 1.2. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos de la plataforma para que puedan actualizarse a las versiones futuras de la plataforma.
• [C-SR-4] SE RECOMIENDA COMPLETAMENTE no admitir software métodos de carga que modifiquen el voltaje Vbus más allá de los niveles predeterminados o alteren como tales, puede provocar problemas de interoperabilidad con el cargadores o dispositivos compatibles con los métodos estándar de USB Power Delivery. Mientras que esto se denomina "EFICIENTEMENTE RECOMENDADA". En versiones futuras de Android, puede REQUIER que todos los dispositivos tipo C admitan una interoperabilidad completa con cargadores tipo C.
• [C-SR-5] SE RECOMIENDA ENRENDIDAMENTE para admitir Power Delivery para datos y intercambio de roles de potencia cuando son compatibles con el modo de host USB y USB tipo C.
• SE RECOMIENDA admitir Power Delivery para cargas de alto voltaje y admitir Modos alternativos, como mostrar fuera de la pantalla
• SE DEBE implementar la API de Android Open Accessory (AOA) y la especificación como que se documenta en la documentación del SDK de Android.

Si las implementaciones del dispositivo incluyen un puerto USB y, además, implementa la AOA especificación, ellos:

• [C-2-1] SE DEBE declarar compatibilidad con la función de hardware. android.hardware.usb.accessory
• [C-2-2] La clase de almacenamiento masivo USB DEBE incluir la cadena "android". a las final de la interfaz de descripción iInterface cadena del almacenamiento masivo USB

7.7.2. Modo de host USB

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

• [C-1-1] SE DEBE implementar la API de host USB de Android como se documenta en la SDK de Android y DEBEN declarar la compatibilidad con la función de hardware. android.hardware.usb.host
• [C-1-2] SE DEBE implementar la compatibilidad para conectar periféricos USB estándar. En otras palabras, DEBEN:
  • Tener un puerto tipo C integrado en el dispositivo o enviar con cables que se adapten a estos componentes un puerto exclusivo a un puerto USB tipo C (dispositivo USB tipo C) estándar.
  • Tener un modelo A integrado en el dispositivo o enviarlo con cables que se adapten a los modelos integrados en el dispositivo a un puerto USB tipo A estándar.
  • Tener un puerto micro-AB en el dispositivo que SE DEBE enviar con un cable que se adapte a un puerto tipo A estándar.
• [C-1-3] NO SE DEBE enviar con un adaptador que se convierta desde USB tipo A o puertos micro-AB a un puerto tipo C (receptáculo).
• [C-SR-1] SE RECOMIENDA ENERCMENTE implementar el Clase de audio USB como se indica en la documentación del SDK de Android.
• SE DEBE admitir la carga del dispositivo periférico USB conectado mientras se encuentra en el host modo; anuncia una corriente de origen de al menos 1.5 A, como se especifica en la Parámetros de rescisión de la Revisión 1.2 de la especificación del cable USB tipo C y conector para USB tipo C o usa el rango de salida actual del puerto de carga descendente (CDP), como especificadas en el Especificaciones de la carga de la batería USB, revisión 1.2 para conectores micro-AB.
• SE DEBE implementar y admitir estándares USB tipo C.

Si las implementaciones del dispositivo incluyen un puerto USB compatible con el modo de host y la en la clase de audio, deben hacer lo siguiente:

• [C-2-1] DEBE admitir la clase USB HID.
• [C-2-2] DEBE admitir la detección y asignación de los siguientes datos HID campos especificados en las tablas de uso de USB HID y la solicitud de uso de comandos por voz a la KeyEvent constantes como se muestra a continuación:
  • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
  • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
  • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones del dispositivo incluyen un puerto USB que admite el modo de host y el framework de acceso al almacenamiento (SAF), les permite hacer lo siguiente:

• [C-3-1] SE DEBE reconocer cualquier MTP (protocolo de transferencia multimedia) conectado de manera remota. y hacer que se pueda acceder a su contenido a través de ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT. .

Si las implementaciones del dispositivo incluyen un puerto USB compatible con el modo de host y USB Tipo C:

• [C-4-1] DEBE implementar la funcionalidad de puerto de rol dual según lo definido por el USB Especificación tipo C (sección 4.5.1.3.3). Para doble Puertos de rol, en dispositivos que incluyen un conector de audio de 3.5 mm, el receptor USB detección (modo de host) PUEDE estar desactivada de forma predeterminada, pero DEBE ser posible usuario la habilite.
• [C-SR-2] SE RECOMIENDA ENRENDER para admitir DisplayPort, SE DEBE admitir USB las tarifas de datos de SuperSpeed, y se RECOMIENDA ENERGENTE para admitir Power Delivery para intercambiar datos y roles.
• [C-SR-3] SE RECOMIENDA ENRENDER QUE NO sea compatible con el modo de accesorio del adaptador de audio como descritos en el Apéndice A de las Revisión de especificaciones del cable USB tipo C y conector 1.2.
• SE DEBE implementar el modelo Try.* que sea más adecuado para el y el factor de forma del dispositivo. Por ejemplo, un dispositivo de mano DEBE implementar el Modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

Si las implementaciones en dispositivos incluyen un micrófono, sucederá lo siguiente:

• [C-1-1] DEBE informar la constante de función android.hardware.microphone.
• [C-1-2] DEBE cumplir con los requisitos de grabación de audio en artículo 5.4.
• [C-1-3] DEBE cumplir con los requisitos de latencia de audio en artículo 5.6.
• [C-SR-1] SE RECOMIENDA COMPLETAMENTE para admitir la grabación casi ultrasónica como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos omiten un micrófono, sucederán lo siguiente:

• [C-2-1] NO DEBE informar la constante de función android.hardware.microphone.
• [C-2-2] SE DEBE implementar la API de grabación de audio al menos como no-ops, según Artículo 7.

7.8.2. Salida de audio

Si las implementaciones en el dispositivo incluyen una bocina o una salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 4 conductores de 3,5 mm o Puerto USB en modo host con clase de audio USB:

• [C-1-1] DEBE informar la constante de función android.hardware.audio.output.
• [C-1-2] DEBE cumplir con los requisitos de reproducción de audio en artículo 5.5.
• [C-1-3] DEBE cumplir con los requisitos de latencia de audio en artículo 5.6.
• [C-SR-1] SE RECOMIENDA COMPLETAMENTE para admitir la reproducción casi ultrasónica como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos no incluyen un puerto de salida de audio o bocina, sucederá lo siguiente:

• [C-2-1] NO DEBE informar la función android.hardware.audio.output.
• [C-2-2] SE DEBE implementar, al menos, las API relacionadas con la Salida de audio como no-ops.

A los efectos de esta sección, se usará un “puerto de salida” es un interfaz física como un conector de audio de 3.5 mm, un puerto HDMI o un puerto en modo host USB con clase de audio USB. Compatibilidad con salida de audio a través de protocolos de radio, como Bluetooth, Una red Wi-Fi o móvil no califica para incluir un "puerto de salida".

7.8.2.1. Puertos de audio analógicos

Para ser compatibles con el auriculares y otros accesorios de audio usando el conector de audio de 3.5 mm en todo el ecosistema de Android, incluyen uno o más puertos de audio analógicos:

• [C-SR-1] SE RECOMIENDA ENERCMENTE incluir al menos uno de los para que sean un conector de audio de 3,5 mm de 4 conductores.

Si las implementaciones de dispositivos tienen un conector de audio de 4 conductores de 3.5 mm, sucede lo siguiente:

• [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares. con un micrófono.
• [C-1-2] DEBE admitir conectores de audio TRRS con el orden de pines CTIA.
• [C-1-3] DEBE admitir la detección y la asignación a los códigos de teclas del siguiente a tres rangos de impedancia equivalente entre el micrófono y el suelo. conductores en el enchufe de audio:
  • 70 ohm o menos: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DEBE activar ACTION_HEADSET_PLUG al insertar un enchufe, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
• [C-1-5] DEBE ser capaz de conducir al menos 150 mV ± 10% del voltaje de salida en una impedancia de la bocina de 32 ohm.
• [C-1-6] DEBE tener una compensación de voltaje del micrófono entre 1.8 V y 2.9 V.
• [C-1-7] DEBE detectar y asignar al código de clave para lo siguiente rango de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR-2] SE RECOMIENDA ENERGENTE para admitir enchufes de audio con OMTP Fijar orden.
• [C-SR-3] SE RECOMIENDA COMPLETAMENTE para admitir la grabación de audio estéreo auriculares con micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 4 conductores de 3,5 mm y admiten un micrófono y transmitir el android.intent.action.HEADSET_PLUG con el de valor adicional configurado en 1, hacen lo siguiente:

• [C-2-1] DEBE admitir la detección del micrófono en el audio conectado. accesorio.

7.8.2.2. Puertos de audio digitales

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

7.8.3. Casi ultrasónica

El audio casi ultrasónico está en la banda de entre 18.5 kHz y 20 kHz.

Implementaciones en dispositivos:

• DEBE informar correctamente la compatibilidad de de audio casi ultrasónica mediante AudioManager.getProperty API de la siguiente manera:

Si es PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es “verdadero”, el Fuentes de audio VOICE_RECOGNITION y UNPROCESSED:

• [C-1-1] La potencia de respuesta media del micrófono en la banda de 18.5 kHz a 20 kHz DEBE no estar más de 15 dB por debajo de la respuesta a 2 kHz.
• [C-1-2] La relación señal-ruido no ponderada del micrófono superior a 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS DEBE ser no menor que 50 dB.

Si es PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es “verdadero”:

• [C-2-1] La respuesta media de la bocina en 18.5 kHz a 20 kHz no DEBE ser inferior a 40 dB por debajo de la respuesta a 2 kHz.

7.8.4. Integridad de la señal

Implementaciones en dispositivos:

• SE DEBE proporcionar una ruta de acceso de señal de audio sin fallas para ambas entradas. de salida en dispositivos portátiles, como se define sin fallas medida durante una prueba de un minuto por ruta. Cómo realizar pruebas con OboeTester “Automated Glitch Test”.

La prueba requiere una llave de bucle invertido de audio. usarse directamente en un conector de 3.5 mm o en combinación con un adaptador de USB-C a 3.5 mm. Se DEBEN probar todos los puertos de salida de audio.

Actualmente, OboeTester admite rutas de AAudio, por lo que Las siguientes combinaciones SE DEBEN probar con AAudio para detectar fallas:

Modo rendimiento	Uso compartido	Tasa de muestreo de salida	En Chans	Oportunidades de salida
BAJO_LATENCIA	EXCLUSIVO	SIN ESPECIFICAR	1	2
BAJO_LATENCIA	EXCLUSIVO	SIN ESPECIFICAR	2	1
BAJO_LATENCIA	COMPARTIDO	SIN ESPECIFICAR	1	2
BAJO_LATENCIA	COMPARTIDO	SIN ESPECIFICAR	2	1
NINGUNO	COMPARTIDO	48000	1	2
NINGUNO	COMPARTIDO	48000	2	1
NINGUNO	COMPARTIDO	44100	1	2
NINGUNO	COMPARTIDO	44100	2	1
NINGUNO	COMPARTIDO	16000	1	2
NINGUNO	COMPARTIDO	16000	2	1

Una transmisión confiable DEBE cumplir con los siguientes criterios de Señal al ruido relación de aspecto (SNR) y distorsión armónica total (THD) para el seno de 2,000 Hz.

Transductor	THD	SNR
bocina principal integrada, medida con un micrófono de referencia externo	< 3%	50 dB o superior
micrófono principal integrado, medido con una bocina de referencia externa	< 3%	50 dB o superior
conectores analógicos de 3.5 mm integrados, probados con un adaptador de bucle invertido	< 1%	60 dB o superior
Adaptadores USB incluidos con el teléfono, probados con un adaptador de bucle invertido.	< 1%	60 dB o superior

7.9 Realidad virtual

Android incluye API e instalaciones para crear "realidad virtual" (RV) aplicaciones, incluidas las experiencias de RV móvil de alta calidad. Dispositivo implementaciones DEBEN implementar adecuadamente estas APIs y estos comportamientos, como se detalla en esta sección.

7.9.1 Modo de realidad virtual

Android incluye compatibilidad con Modo RV, una función que controla la renderización estereoscópica de notificaciones e inhabilita monoculares del sistema de IU, mientras que una aplicación de RV tiene el foco del usuario.

7.9.2. Modo de realidad virtual: Alto rendimiento

Si las implementaciones de dispositivos admiten el modo RV, sucederá lo siguiente:

• [C-1-1] DEBE tener al menos 2 núcleos físicos.
• [C-1-2] SE DEBE declarar la función android.hardware.vr.high_performance.
• [C-1-3] DEBE admitir el modo de rendimiento sostenido.
• [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
• [C-1-5] DEBE admitir android.hardware.vulkan.level 0.
• SE DEBE admitir android.hardware.vulkan.level 1 o versiones posteriores.
• [C-1-6] DEBE implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync: EGL_IMG_context_priority: EGL_EXT_protected_content: EGL_EXT_image_gl_colorspace y expón las extensiones en la lista de extensiones EGL disponibles.
• [C-1-8] DEBE implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, y expón las extensiones en la lista de extensiones de GL disponibles.
• [C-SR-1] SE RECOMIENDA EXIENTEMENTE implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, y expón las extensiones en la lista de extensiones de GL disponibles.
• [C-SR-2] SE RECOMIENDA ENcarecidamente que sean compatibles con Vulkan 1.1.
• [C-SR-3] SE RECOMIENDA EXIENTEMENTE implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, y exponlo en la lista de extensiones de Vulkan disponibles.
• [C-SR-4] SE RECOMIENDA INTENSIFICAMENTE para exponer al menos una familia de colas de Vulkan en la que flags contienen VK_QUEUE_GRAPHICS_BIT y VK_QUEUE_COMPUTE_BIT, y queueCount es 2 como mínimo.
• [C-1-7] La GPU y la pantalla DEBEN sincronizar el acceso a la red búfer frontal, de modo que la renderización de ojos alternos del contenido de RV a 60 FPS con dos los contextos de renderización se mostrarán sin artefactos de seccionamiento visibles.
• [C-1-9] DEBE implementar asistencia para AHardwareBuffer marcas AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT como se describe en el NDK.
• [C-1-10] SE DEBE implementar compatibilidad con AHardwareBuffer con cualquier combinación de las marcas de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para, al menos, los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
• [C-SR-5] SE RECOMIENDA COMPLETAMENTE para admitir la asignación de AHardwareBuffer con más de una capa, y marcas y formatos especificados en C-1-10.
• [C-1-11] DEBE admitir la decodificación H.264 de al menos 3840 × 2160 a 30 fps. comprimido en un promedio de 40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-10 Mbps o 2 instancias de 1920 x 1080 a 60 fps-20 Mbps).
• [C-1-12] DEBE ser compatible con HEVC y VP9, DEBE ser capaz de decodificar al menos 1920 x 1080 a 30 fps comprimidos a un promedio de 10 Mbps y DEBERÍA capaz de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-5 Mbps).
• [C-1-13] DEBE ser compatible con la API de HardwarePropertiesManager.getDeviceTemperatures. y devuelve valores exactos para la temperatura cutánea.
• [C-1-14] DEBE tener una pantalla incorporada y su resolución DEBE ser al menos 1920 × 1080.
• [C-SR-6] SE RECOMIENDA ENcarecidamente que tengan una resolución de pantalla de al menos 2,560 × 1,440.
• [C-1-15] La pantalla DEBE actualizar al menos 60 Hz en modo RV.
• [C-1-17] La pantalla DEBE admitir un modo de persistencia baja con ≤ 5 milisegundos La persistencia, que se define como la cantidad de tiempo para en la que un píxel emite luz.
• [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE sección 7.4.3.
• [C-1-19] SE DEBE admitir e informar correctamente. Tipo de canal directo para todos los siguientes tipos de sensores predeterminados:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] SE RECOMIENDA ENERGMENTE que respalden el TYPE_HARDWARE_BUFFER tipo de canal directo para todos los tipos de canales directos mencionados anteriormente.
• [C-1-21] DEBE cumplir con los requisitos del giroscopio, el acelerómetro y el magnetómetro requisitos para android.hardware.hifi_sensors, como se especifica en sección 7.3.9.
• [C-SR-8] SE RECOMIENDA ENRENDIDAMENTE que respalden el android.hardware.sensor.hifi_sensors.
• [C-1-22] DEBE tener movimiento de extremo a extremo para una latencia de fotón no superior a 28 milisegundos.
• [C-SR-9] SE RECOMIENDA COMPLEMENTE tener un movimiento de extremo a extremo para una latencia de fotón. no superior a 20 milisegundos.
• [C-1-23] DEBE tener la proporción del primer fotograma, que es la proporción entre los brillo de los píxeles en el primer fotograma después de una transición de negro a blanco y el brillo de los píxeles blancos en estado estable, de al menos 85%.
• [C-SR-10] SE RECOMIENDA ENcarecidamente que tengan una proporción del primer fotograma de al menos un 90%.
• PUEDE proporcionar un núcleo exclusivo para el primer plano y PUEDE admitir la API de Process.getExclusiveCores para que se devuelva la cantidad de núcleos de CPU que son exclusivas de la parte superior en primer plano y mantener la integridad de su aplicación.

Si se admite el núcleo exclusivo, entonces el núcleo:

• [C-2-1] No DEBE permitir que se ejecute ningún otro proceso del espacio de usuario en él. (excepto los controladores de dispositivo que usa la aplicación), pero PUEDE permitir cierto kernel que los procesos se ejecuten según sea necesario.

7.10. Tecnología háptica

7.11. Clase de rendimiento del contenido multimedia

La clase de rendimiento del contenido multimedia de la implementación del dispositivo se puede obtener de la API de android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS Requisitos de la clase de rendimiento multimedia se definen para cada versión de Android, comenzando por R (versión 30). El valor especial de 0 indica que el dispositivo no es de un clase de rendimiento del medio.

Si las implementaciones de dispositivos muestran un valor distinto de cero en android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hicieron lo siguiente:

• [C-1-1] DEBE mostrar al menos un valor de android.os.Build.VERSION_CODES.R.

• [C-1-2] DEBE ser una implementación de dispositivo de mano.

• [C-1-3] DEBE cumplir con todos los requisitos de la "Clase de rendimiento de medios" descritos en la sección 2.2.7.

En otras palabras, la clase de rendimiento multimedia en Android T solo se define para portátiles en las versiones T, S o R.

Consulta la sección 2.2.7 para obtener información sobre atributos específicos del dispositivo y los requisitos de cumplimiento.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y consumo de energía son fundamentales para la experiencia del usuario e influir en las suposiciones de referencia que tendrían los desarrolladores al desarrollar un .

8.1. Coherencia de la experiencia del usuario

Se puede brindar una interfaz de usuario fluida al usuario final si hay requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta coherentes para aplicaciones y juegos. Las implementaciones en dispositivos, según el tipo de dispositivo, PUEDE tener requisitos medibles para la latencia de la interfaz de usuario y las tareas cambios, como se describe en la sección 2.

8.2. Rendimiento del acceso a la E/S de archivos

Proporciona un modelo de referencia común para lograr un rendimiento coherente de acceso a los archivos en la el almacenamiento de datos privados de la aplicación (/data partición) permite a los desarrolladores de apps establecer una expectativa adecuada que ayude a su diseño de software. Dispositivo según el tipo de dispositivo, PUEDEN tener ciertos requisitos que se describe en la sección 2 para la siguiente lectura y de escritura:

• Rendimiento de la escritura secuencial. Se mide escribiendo un archivo de 256 MB usando Búfer de escritura de 10 MB.
• Rendimiento de escritura aleatoria. Se mide escribiendo un archivo de 256 MB con un tamaño de 4 KB. búfer de escritura.
• Rendimiento de la lectura secuencial. Se mide leyendo un archivo de 256 MB con Búfer de escritura de 10 MB.
• Rendimiento de lectura aleatoria. Se mide leyendo un archivo de 256 MB usando 4 KB. búfer de escritura.

8.3. Modos de ahorro de energía

Si las implementaciones en dispositivos incluyen funciones para mejorar la administración de energía del dispositivo incluidas en AOSP (p.ej., App Standby Bucket, Descanso) o extender las funciones para aplicar restricciones más fuertes que el intervalo RESTRINGIDO de App Standby, tienen las siguientes características:

• [C-1-1] NO DEBE desviarse de la implementación de AOSP para la activación. el mantenimiento, los algoritmos de activación y el uso de la configuración global del sistema o DeviceConfig de los modos de ahorro de energía App Standby y Descanso.
• [C-1-2] NO DEBE desviarse de la implementación de AOSP para el uso de o DeviceConfig para administrar la limitación de los trabajos, las alarmas y red para las apps de cada intervalo para App Standby.
• [C-1-3] NO DEBE desviarse de la implementación de AOSP para el número de Intervalos de App Standby que se usa para App Standby.
• [C-1-4] DEBE implementar Intervalos de App Standby y Descanso, como se describe en Administración de energía.
• [C-1-5] DEBE devolver true por PowerManager.isPowerSaveMode() cuando el dispositivo esté en modo de ahorro de energía.
• [C-1-6] DEBE proporcionar la indicación visual del usuario para mostrar todas las apps exentas desde los modos de ahorro de energía App Standby y Descanso o cualquier optimización de la batería y DEBE implementar ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intención de solicitar al usuario que permita que una aplicación ignore la batería optimizaciones.
• [C-SR-1] SE RECOMIENDA ENRENDIDAMENTE para proporcionar al usuario la indicación visual necesaria para habilitar y inhabilitar la función de ahorro de batería.
• [C-SR-2] SE RECOMIENDA ENERGÍAMENTE para proporcionar al usuario la posibilidad de mostrar todo apps que están exentas de los modos de ahorro de energía App Standby y Descanso.

Si las implementaciones de dispositivos extienden las funciones de administración de energía que se incluyen en AOSP, y esa extensión aplica restricciones más estrictas que las el intervalo poco frecuente de App Standby consulta la sección 3.5.1.

Además de los modos de ahorro de energía, MAYO POSIBILIDAD de implementaciones en dispositivos Android implementar uno o todos los 4 estados de poder de sueño, según lo definido por la política de la interfaz de configuración y energía (ACPI).

Si las implementaciones del dispositivo implementan los estados de energía de S4, tal como se define en la ACPI, les permiten hacer lo siguiente:

• [C-1-1] DEBE ingresar a este estado únicamente después de que el usuario haya realizado una acción explícita. para dejar el dispositivo en estado inactivo (p.ej., al cerrar una tapa que se del dispositivo o apagar un vehículo o un televisor) y antes de la El usuario reactiva el dispositivo (p.ej., abriendo la tapa o girando el vehículo o la televisión).

Si las implementaciones del dispositivo implementan los estados de energía de S3, tal como se define en la ACPI, les permiten hacer lo siguiente:

• [C-2-1] DEBE cumplir con C-1-1 anterior o DEBE pasar al estado S3 solo cuando un tercero las aplicaciones no necesitan los recursos del sistema (p.ej., la pantalla o la CPU).

  Por el contrario, DEBE salir del estado de S3 cuando las aplicaciones de terceros necesitan del sistema, como se describe en este SDK.

  Por ejemplo, aunque las aplicaciones de terceros solicitan conservar la pantalla a través de FLAG_KEEP_SCREEN_ON o mantener la CPU en ejecución durante PARTIAL_WAKE_LOCK, el dispositivo NO DEBE pasar al estado S3, a menos que, como se describe, en C-1-1, el usuario ha realizado una acción explícita para colocar el dispositivo en una inactivo. Por el contrario, cuando una tarea que las apps de terceros implementar mediante JobScheduler o Firebase Cloud Messaging entregado a apps de terceros, el dispositivo DEBE salir del estado S3, a menos que el El usuario puso el dispositivo en estado inactivo. Estos no son exhaustivos ejemplos y el AOSP implementa muchos indicadores de activación de este estado.

8.4. Contabilidad del consumo de energía

Una contabilización y un informe más precisos del consumo de energía proporcionan la desarrolladores de apps los incentivos y las herramientas para optimizar el uso de energía el patrón de la aplicación.

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE proporcionar un perfil de energía por componente que define el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería causado con el paso del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
• [C-SR-2] SE RECOMIENDA COMPLETAMENTE informar todos los valores de consumo de energía en miliamperios horas (mAh).
• [C-SR-3] SE RECOMIENDA ENRENDIDAMENTE para informar el consumo de energía de la CPU por cada UID del proceso. El Proyecto de código abierto de Android cumple con los requisitos mediante la Implementación del módulo de kernel uid_cputime.
• [C-SR-4] SE RECOMIENDA ENRENDIDAMENTE que este uso de energía esté disponible a través de la adb shell dumpsys batterystats de shell al desarrollador de la app.
• SE DEBE atribuir al componente de hardware si no se puede atribuir el uso de energía de un componente de hardware a una aplicación.

8.5. Rendimiento coherente

El rendimiento puede fluctuar drásticamente en las apps de alto rendimiento que se ejecutan durante mucho tiempo ya sea debido a la ejecución de otras apps en segundo plano o a la limitación de la CPU debido a los límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo es capaz, la aplicación en primer plano puede solicitar que el optimizará la asignación de recursos para abordar las fluctuaciones.

Implementaciones en dispositivos:

• [C-0-1] SE DEBE informar con precisión la compatibilidad del Modo de rendimiento sostenido. mediante la PowerManager.isSustainedPerformanceModeSupported() método de API.

• SE DEBE admitir el Modo de rendimiento sostenido.

Si las implementaciones de dispositivos informan compatibilidad con el Modo de rendimiento sostenido, deben hacer lo siguiente:

• [C-1-1] DEBE proporcionar a la aplicación en primer plano un nivel consistente de el rendimiento durante al menos 30 minutos, cuando la app lo solicite.
• [C-1-2] DEBE respetar el Window.setSustainedPerformanceMode() API y otras APIs relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, sucederán lo siguiente:

• SE DEBE proporcionar al menos un núcleo exclusivo que se pueda reservar para la parte superior. aplicación en primer plano.

Si las implementaciones en dispositivos permiten reservar un núcleo exclusivo para los aplicación en primer plano, hacen lo siguiente:

• [C-2-1] DEBE informar a través del Process.getExclusiveCores() Método de API. Los números de ID de los núcleos exclusivos que se pueden reservar. por la aplicación superior en primer plano.
• [C-2-2] No DEBE permitir ningún proceso de espacio del usuario excepto los controladores del dispositivo. usada por la aplicación para ejecutarse en núcleos exclusivos, pero PUEDE permitir que algunos para que los procesos de kernel se ejecuten según sea necesario.

Si las implementaciones en dispositivos no admiten un núcleo exclusivo, sucederá lo siguiente:

• [C-3-1] DEBE devolver una lista vacía a través del Process.getExclusiveCores() método de API.

9. Compatibilidad del modelo de seguridad

Implementaciones en dispositivos:

• [C-0-1] DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, como se define en Documento de referencia de Seguridad y permisos en las APIs de la documentación para desarrolladores de Android.

• [C-0-2] DEBE admitir la instalación de pruebas autofirmadas aplicaciones sin la necesidad de permisos o certificados adicionales de ningún terceros o autoridades.

Si las implementaciones de dispositivos declaran el android.hardware.security.model.compatible funciones, les permiten hacer lo siguiente:

• [C-1-1] DEBE admitir los requisitos que se enumeran en las siguientes subsecciones.

9.1 Permisos

Implementaciones en dispositivos:

• [C-0-1] DEBE admitir el modelo de permisos de Android y el Modelo de roles de Android según se define en la documentación para desarrolladores de Android. En concreto, DEBE hacer cumplir cada permiso y rol definidos como se describe en el documentación del SDK; los permisos y los roles no se pueden omitir, modificar o ignoradas.

• PUEDE agregar permisos adicionales, siempre que las nuevas cadenas de ID del permiso no están en el espacio de nombres android.\*.

• [C-0-2] Permisos con protectionLevel de PROTECTION_FLAG_PRIVILEGED Solo DEBE otorgarse a las apps preinstaladas en las rutas de acceso con privilegios del imagen del sistema (así como APEX) y se debe dentro del subconjunto de los permisos explícitamente incluidos en la lista de entidades permitidas de cada app. La implementación del AOSP cumple con este requisito, ya que lee y respeta el permisos incluidos en la lista de entidades permitidas para cada app desde los archivos etc/permissions/ y usa la ruta system/priv-app como con privilegios mínimos.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Aplicaciones con targetSdkVersion > 22 las solicitan en el tiempo de ejecución.

Implementaciones en dispositivos:

• [C-0-3] DEBE mostrar una interfaz dedicada para que el usuario decida. si otorga los permisos de tiempo de ejecución solicitados y también una interfaz para que el usuario administre permisos de tiempo de ejecución.

• [C-0-5] NO DEBE otorgar ningún permiso de tiempo de ejecución a las aplicaciones, a menos que ocurra lo siguiente:

  • Se instalan en el momento del envío del dispositivo.

  • El consentimiento del usuario se puede obtener antes de que la aplicación usa el permiso,

    O

  • Los permisos de tiempo de ejecución se otorgan por la política de otorgamiento de permisos predeterminada o por tener un rol en la plataforma.

• [C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo para aplicaciones del sistema que registren un agente de recuperación protegido correctamente. R El agente de recuperación correctamente protegido se define como un agente de software en el dispositivo que se sincroniza con un almacenamiento remoto fuera del dispositivo, que está equipado con hardware más seguro con una protección equivalente o más fuerte que la descritos en Servicio Google Cloud Key Vault para evitar ataques de fuerza bruta en el factor de conocimiento de la pantalla de bloqueo.

Implementaciones en dispositivos:

• [C-0-7] DEBE cumplir con las propiedades del permiso de ubicación de Android cuando una app solicita los datos de ubicación o actividad física mediante la API de Android estándar o mecanismo de propiedad exclusiva. Estos datos incluyen, entre otros, los siguientes:

  • Ubicación del dispositivo (p.ej., latitud y longitud) como se describe en artículo 9.8.8.
  • Información que puede usarse para determinar o estimar la capacidad ubicación (p.ej., SSID, BSSID, ID de celular o la ubicación de la red a la que está conectado el dispositivo).
  • Indica la actividad física del usuario o la clasificación de la actividad física.

Más concretamente, las implementaciones en dispositivos:

• [C-0-8] SE DEBE obtener el consentimiento del usuario para permitir que una aplicación acceda al ubicación o datos de actividad física.
• [C-0-9] SE DEBE otorgar un permiso de tiempo de ejecución SOLO a la app que lo contiene. permiso suficiente, como se describe en el SDK. Por ejemplo: TelephonyManager#getServiceState requiere android.permission.ACCESS_FINE_LOCATION).

Las únicas excepciones a las propiedades de permiso de ubicación de Android anteriores son para aplicaciones que no accedan a la ubicación para obtener o identificar la ubicación del usuario específicamente:

• Cuando las apps tienen el permiso RADIO_SCAN_WITHOUT_LOCATION
• Para la configuración del dispositivo, en donde las apps del sistema contienen los el permiso NETWORK_SETTINGS o NETWORK_SETUP_WIZARD.

Los permisos se pueden marcar como una restricción que altera su comportamiento.

• [C-0-10] Los permisos marcados con la marca hardRestricted NO DEBEN otorgada a una app, a menos que se cumplan las siguientes condiciones:

  • Hay un archivo APK de la app en la partición del sistema.
  • El usuario asigna un rol asociado con el hardRestricted. permisos de una app.
  • El instalador otorga el hardRestricted a una app.
  • A una app se le otorga la hardRestricted en una versión anterior de Android.

• [C-0-11] Las apps que tienen un permiso softRestricted DEBEN limitarse solo y NO DEBE obtener acceso completo hasta que se incluya en la lista de entidades permitidas, como se describe en SDK, en el que se define el acceso completo y limitado para cada softRestricted permiso (por ejemplo, READ_EXTERNAL_STORAGE).

• [C-0-12] NO DEBE proporcionar ninguna función o API personalizada para evadir la restricciones de permisos definidas en setPermissionPolicy. y setPermissionGrantState. APIs

• [C-0-13] SE DEBE usar las APIs de AppOpsManager para registrar y hacer seguimiento de cada cada acceso programático a los datos protegidos por permisos peligrosos de Actividades y servicios de Android

• [C-0-14] Solo DEBE asignar roles a las aplicaciones con funcionalidades que cumplen con los requisitos del rol.

• [C-0-15] No DEBE definir roles que sean duplicados o funcionalidades de superconjunto. de roles definidos por la plataforma.

Si los dispositivos informan android.software.managed_users, hará lo siguiente:

• [C-1-1] NO DEBE tener los siguientes permisos otorgados de manera silenciosa por el administrador:
  • Ubicación (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Cámara (CÁMARA)
  • Micrófono (RECORD_AUDIO)
  • Sensor corporal (BODY_SENSORS)
  • Actividad física (ACTIVITY_RECOGNITION)

Si las implementaciones de dispositivos proporcionan una indicación visual al usuario para elegir qué apps pueden se superpone con otras aplicaciones con una actividad que controla la ACTION_MANAGE_OVERLAY_PERMISSION , ellos:

• [C-2-1] SE DEBE asegurarse de que todas las actividades con filtros de intents para el ACTION_MANAGE_OVERLAY_PERMISSION tengan la misma pantalla de IU, independientemente de la app iniciadora o cualquier la información que proporciona.

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

• [C-3-1] SE DEBE mostrar una renuncia de responsabilidad durante la configuración de dispositivos completamente administrados. (configuración del propietario del dispositivo) que indique que el administrador de TI podrá hacer lo siguiente: Permite que las aplicaciones controlen la configuración del teléfono, incluidos el micrófono, la cámara y ubicación, con opciones para que el usuario continúe o salga de la configuración, A MENOS que el administrador inhabilitó el control de los permisos del dispositivo.

Si las implementaciones del dispositivo preinstalan cualquier paquete que contenga cualquiera de los roles de System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence o System Visual Intelligence, los paquetes:

• [C-4-1] DEBE cumplir con todos los requisitos descritos para las implementaciones en dispositivos en secciones “9.8.6 Captura de contenido” “9.8.6 Datos ambientales y a nivel del SO y 9.8.15 de la API de Sandboxed”.

9.2 UID y aislamiento de procesos

Implementaciones en dispositivos:

• [C-0-1] DEBE ser compatible con la aplicación para Android. modelo de zona de pruebas, en el que cada aplicación se ejecuta como un UID único de estilo Unix y en un proceso independiente.
• [C-0-2] DEBE admitir la ejecución de varias aplicaciones. como el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas correctamente. y construirse, como se define en el Referencia de seguridad y permisos.

9.3 Permisos del sistema de archivos

Implementaciones en dispositivos:

• [C-0-1] DEBE admitir el acceso a archivos de Android. de permisos, tal como se define en el Referencia de seguridad y permisos.

Entornos de ejecución alternativos

Las implementaciones en dispositivos DEBEN mantener la coherencia de la seguridad y de permisos, incluso si incluyen entornos de ejecución que ejecutan aplicaciones que usan algún otro software o tecnología distinto del comando Dalvik Executable Formato o código nativo En otras palabras:

• [C-0-1] Los tiempos de ejecución alternativos DEBEN ser aplicaciones de Android, y cumplir con el modelo de seguridad estándar de Android, como se describe en otro lugar en la sección 9.

• [C-0-2] A los entornos de ejecución alternativos NO DEBEN tener acceso a los recursos protegida por permisos no solicitados en el AndroidManifest.xml del tiempo de ejecución archivo a través de la <uses-permission> de atención.

• [C-0-3] Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones usen Funciones protegidas por permisos de Android restringidos a aplicaciones del sistema.

• [C-0-4] Los tiempos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android y las aplicaciones instaladas con un tiempo de ejecución alternativo NO DEBEN reutilizar la zona de pruebas de cualquier otra aplicación instalada en el dispositivo, excepto mediante los mecanismos estándar de Android de ID de usuario compartido y certificado de firma.

• [C-0-5] Los tiempos de ejecución alternativos NO DEBEN iniciarse, otorgarse ni otorgarse el acceso a las zonas de pruebas correspondientes a otras aplicaciones de Android.

• [C-0-6] Los entornos de ejecución alternativos NO DEBEN iniciarse, otorgarse ni otorgarse a otras aplicaciones, cualquier privilegio del superusuario (raíz) o de cualquier otro ID del usuario.

• [C-0-7] Cuando los archivos .apk de entornos de ejecución alternativos se incluyen en el de las implementaciones de dispositivos, DEBE firmarse con una clave desde la clave utilizada para firmar otras aplicaciones incluidas con el dispositivo de Google Cloud.

• [C-0-8] Al instalar aplicaciones, se DEBEN obtener tiempos de ejecución alternativos el consentimiento del usuario para los permisos de Android que utiliza la aplicación.

• [C-0-9] Cuando una aplicación necesita usar un recurso de dispositivo para que tienen un permiso de Android correspondiente (como Cámara, GPS, etc.), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.

• [C-0-10] Cuando el entorno de ejecución no registra la aplicación capacidades de esta manera, el entorno de ejecución DEBE que retiene el propio entorno de ejecución cuando instala cualquier aplicación que lo use.

• Los entornos de ejecución alternativos DEBEN instalar las apps a través de PackageManager en zonas de pruebas independientes de Android (IDs de usuario de Linux, etc.).

• Los tiempos de ejecución alternativos PUEDEN proporcionar una única zona de pruebas de Android compartida por todos aplicaciones usando el entorno de ejecución alternativo.

9.5 Compatibilidad multiusuario

Android incluye compatibilidad para varios usuarios. y admite el aislamiento completo de usuarios y clonar perfiles de usuario con aislamiento parcial(es decir, un solo perfil de usuario adicional de tipo android.os.usertype.profile.CLONE).

• PUEDEN POSIBLES implementaciones en dispositivos, pero NO DEBEN habilitar la función multiusuario si usan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones en dispositivos admiten compatibilidad para varios usuarios, sucederá lo siguiente:

• [C-1-2] SE DEBE, para cada usuario, implementar una política coherente con el modelo de seguridad de la plataforma de Android, tal como se define en Documento de referencia de Seguridad y permisos en las APIs.
• [C-1-3] DEBE tener almacenamiento de aplicación compartido separado y aislado (también conocido como /sdcard) para cada instancia de usuario.
• [C-1-4] DEBEN asegurarse de que las aplicaciones que son propiedad de un usuario determinado no puede enumerar, leer ni escribir en los archivos que pertenecen a otro usuario incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
• [C-1-5] SE DEBE encriptar el contenido de la tarjeta SD cuando el modo multiusuario está habilitado. usando una clave almacenada únicamente en medios no extraíbles al que solo puede acceder el sistema si de dispositivos usan medios extraíbles para las APIs de almacenamiento externo. Como esto hará que el contenido multimedia no sea legible para una PC host, las implementaciones del dispositivo deberá cambiar a MTP o un sistema similar para proporcionarles a las PC host el acceso a los datos del usuario actual.

Si las implementaciones en dispositivos son compatibles con varios usuarios, entonces, para todos los usuarios, excepto los creados específicamente para ejecutar instancias dobles de la misma app:

• [C-2-1] DEBE tener almacenamiento de aplicación compartido separado y aislado (también conocidos como /sdcard) para cada instancia de usuario.
• [C-2-2] DEBE asegurarse de que las aplicaciones que pertenezcan a y que se ejecuten en nombre de un usuario determinado no pueden enumerar, leer ni escribir en los archivos que por cualquier otro usuario, incluso si los datos de ambos están almacenados en la misma volumen o sistema de archivos.

Las implementaciones de dispositivos PUEDEN crear un único perfil de usuario adicional de tipo android.os.usertype.profile.CLONE en relación con el usuario principal (y solo en relación con el usuario principal) con el fin de ejecutar instancias dobles de la misma app. Estas instancias duales comparten almacenamiento parcialmente aislado, se presentan al usuario final en el selector al mismo tiempo y aparecer en la misma vista de recientes. Por ejemplo, podría usarse para permitir que el usuario instale dos instancias de una sola app en un dispositivo con SIM dual.

Si las implementaciones de dispositivos crean el perfil de usuario adicional mencionado anteriormente, entonces:

• [C-3-1] Solo DEBE brindar acceso al almacenamiento o a los datos accesible para el perfil de usuario principal o que pertenezca directamente a este perfil de usuario adicional.
• [C-3-2] NO DEBE tener esto como un perfil de trabajo.
• [C-3-3] DEBE tener directorios de datos de app privados aislados del elemento superior. cuenta de usuario.
• [C-3-4] NO DEBE permitir que se cree el perfil de usuario adicional si sea un propietario del dispositivo aprovisionado (consulta la sección 3.9.1) o permite que un propietario de dispositivo se aprovisione sin quitar primero el perfil de usuario adicional.

9.6 Advertencia de SMS premium

Android admite advertencias a los usuarios mensaje SMS premium. SMS premium mensajes son mensajes de texto enviados a un servicio registrado con un operador que puede incurrir en un cargo al usuario.

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

• [C-1-1] DEBE advertir a los usuarios antes de enviar un mensaje SMS a los números Se identifican a través de expresiones regulares definidas en /data/misc/sms/codes.xml. en el dispositivo. El Proyecto de código abierto de Android ascendente brinda una implementación que cumpla con este requisito.

9.7 Funciones de seguridad

Las implementaciones en dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad kernel y la plataforma, como se describe a continuación.

La zona de pruebas de Android incluye funciones que usan Security-Enhanced Linux (SELinux), sistema de control de acceso obligatorio (MAC), zona de pruebas seccomp y otros las funciones de seguridad del kernel de Linux. Implementaciones en dispositivos:

• [C-0-1] DEBE mantener la compatibilidad con las aplicaciones existentes, aun cuando SELinux o cualquier otra función de seguridad se implemente debajo del en un framework de nube.
• [C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta el incumplimiento y se lo bloquea correctamente la función de seguridad se implementa debajo del framework de Android, pero PUEDE tener una interfaz de usuario visible cuando se produce una violación de la seguridad desbloqueada y resulta en un exploit exitoso.
• [C-0-3] NO DEBE implementar SELinux ni ninguna otra función de seguridad. a continuación del framework de Android que el usuario o el desarrollador de la app pueden configurar.
• [C-0-4] NO DEBE permitir una aplicación que pueda afectar a otra aplicación a través de una API (como una API de administración de dispositivos) para configurar una política que interrumpe la compatibilidad.
• [C-0-5] DEBE dividir el framework de medios en varios procesos para que es posible otorgar acceso de manera más restringida a cada proceso según descritos en el sitio del Proyecto de código abierto de Android.
• [C-0-6] SE DEBE implementar un mecanismo de zona de pruebas de aplicaciones de kernel. que permite filtrar llamadas al sistema usando una política configurable programas multiproceso. El Proyecto de código abierto de Android ascendente cumple con mediante la habilitación de seccomp-BPF con threadgroup (TSYNC), como se describe en la sección Configuración de kernel de source.android.com.

Las funciones de integridad del kernel y de autoprotección son fundamentales para Android seguridad. Implementaciones en dispositivos:

• [C-0-7] DEBE implementar mecanismos de protección contra el desbordamiento del búfer de la pila del kernel. Algunos ejemplos de estos mecanismos son CC_STACKPROTECTOR_REGULAR y CONFIG_CC_STACKPROTECTOR_STRONG
• [C-0-8] DEBEN implementar protecciones estrictas de memoria de kernel donde se puedan ejecutar código es de solo lectura, los datos de solo lectura no se pueden ejecutar ni escribir los datos que admiten escritura no se pueden ejecutar (p.ej., CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DEBE implementar el tamaño de objeto estático y dinámico. comprobación de límites de copias entre el espacio del usuario y el espacio de kernel (p. ej., CONFIG_HARDENED_USERCOPY) en dispositivos que originalmente se enviaban con el nivel de API. 28 o una versión posterior
• [C-0-10] NO DEBE ejecutar la memoria del espacio del usuario cuando se ejecuta en el modo de kernel (por ejemplo, PXN de hardware, o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos originalmente se envió con nivel de API 28 o superior.
• [C-0-11] NO DEBE leer ni escribir la memoria del espacio del usuario en la fuera de las APIs normales de acceso a usercopy (p.ej., PAN de hardware o se emulan a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN). en dispositivos que originalmente se entregaban con el nivel de API 28 o superior.
• [C-0-12] SE DEBE implementar el aislamiento de la tabla de la página del kernel si el hardware es vulnerable a CVE-2017-5754 en todos los dispositivos que originalmente se enviaron con un nivel de API 28 o superior (p.ej., CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] DEBE implementar el endurecimiento de la predicción de ramas si el hardware se vulnerable a CVE-2017-5715 en todos los dispositivos que originalmente se enviaron con un nivel de API 28 o versiones posteriores (p. ej., CONFIG_HARDEN_BRANCH_PREDICTOR)

• [C-SR-1] SE RECOMIENDA IMPORTANTE para mantener los datos del kernel que se escribe solo durante la inicialización y se marca como de solo lectura después inicial (p.ej., __ro_after_init).

• [C-SR-2] SE RECOMIENDA COMPLETAMENTE para aleatorizar el diseño del código del kernel y memoria y para evitar exposiciones que comprometan la aleatorización (p.ej., CONFIG_RANDOMIZE_BASE con la entropía del bootloader mediante el /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

• [C-SR-3] SE RECOMIENDA COMPLETAMENTE para habilitar la integridad del flujo de control (CFI) en el kernel para proporcionar protección adicional contra ataques de reutilización de código (p.ej., CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] SE RECOMIENDA COMPLETAMENTE no inhabilitar la integridad de flujo de control (CFI). Shadow Call Stack (SCS) o limpieza de desbordamiento de enteros (IntSan) en componentes que lo tienen habilitado.

• [C-SR-5] SE RECOMIENDA ENERGENTE para habilitar CFI, SCS e IntSan para cualquier componentes adicionales del espacio de usuario sensibles a la seguridad, como se explica en CFI y San San.

• [C-SR-6] SE RECOMIENDA COMPLETAMENTE para habilitar la inicialización de pila en el kernel para evitar el uso de variables locales no inicializadas (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Además, las implementaciones en dispositivos NO DEBEN suponer el valor que usa el compilador para inicializamos los locales.

• [C-SR-7] SE RECOMIENDAN IMPORTANTE para habilitar la inicialización de montón en el kernel. para evitar el uso de asignaciones de montón no inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) y NO DEBEN suponer el valor utilizado por el kernel para inicializar esas asignaciones.

Si las implementaciones en dispositivos usan un kernel de Linux que sea capaz de admitir SELinux:

• [C-1-1] DEBE implementar SELinux.
• [C-1-2] DEBE configurar SELinux en el modo de aplicación global.
• [C-1-3] SE DEBE configurar todos los dominios en modo de aplicación forzosa. No hay modo permisivo incluidos los dominios específicos de un dispositivo o proveedor.
• [C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas de “Neverallow” presentes. en la carpeta del sistema o la directiva proporcionada en la carpeta de código abierto de Android ascendente El Proyecto (AOSP) y la política DEBEN compilarse con todas las reglas "Neverallow" presentes tanto para dominios SELinux del AOSP como para dominios específicos de dispositivos o proveedores.
• [C-1-5] DEBE ejecutar aplicaciones de terceros orientadas al nivel de API 28 o superior. en zonas de pruebas de SELinux por aplicación con restricciones de SELinux por app en cada directorio de datos privados de tu aplicación.
• SE DEBE conservar la política SELinux predeterminada proporcionada en la política de SELinux del Proyecto de código abierto de Android ascendente y solo agregarlo más a esta para su propia configuración específica del dispositivo.

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

• [C-2-1] DEBE usar un sistema de control de acceso obligatorio que sea equivalente a SELinux.

Si las implementaciones en dispositivos usan dispositivos de E/S compatibles con DMA, sucederá lo siguiente:

• [C-SR-9] SE RECOMIENDA EXIGENTEMENTE para aislar cada dispositivo de E/S con capacidad de DMA con un IOMMU (p.ej., el ARM SMMU).

Android contiene varias funciones de defensa en profundidad que son esenciales para el dispositivo. seguridad. Además, Android se centra en reducir las clases clave de errores comunes. que contribuyen a las fallas en la calidad y seguridad.

Para reducir los errores de memoria, las implementaciones en dispositivos hacen lo siguiente:

• [C-SR-10] SE RECOMIENDA ENRENDER que se prueben con un error de memoria del espacio del usuario herramientas de detección como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8+ o ASan para otros tipos de dispositivos.
• [C-SR-11] SE RECOMIENDA ENRENDER que se prueben con un error de memoria del kernel de detección, como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para Dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 o CONFIG_KASAN_GENERIC para otros tipos de dispositivos).
• [C-SR-12] SE RECOMIENDA ENcarecidamente usar herramientas de detección de errores de memoria en producción, como MTE, GWP-ASan y KFENCE.

Si las implementaciones de dispositivos usan un TEE basado en TrustZone de Arm, sucederá lo siguiente:

• [C-SR-13] SE RECOMIENDA MUY BIEN usar un protocolo estándar para la memoria entre Android y el TEE, como el framework de firmware Arm para Armv8-A (FF-A).
• [C-SR-14] SE RECOMIENDA EXITOSAMENTE que restrinjan las aplicaciones de confianza solo a acceder a la memoria que se compartió explícitamente con ellos a través de lo anterior protocolo. Si el dispositivo es compatible con el nivel de excepción Arm S-EL2, este debe aplicar de manera forzosa con el administrador de particiones seguro. De lo contrario, debería ser impuesta por el SO de TEE.

9.8 Privacidad

9.8.1 Historial de uso

Android almacena el historial de elecciones del usuario y administra dicho historial UsageStatsManager.

Implementaciones en dispositivos:

• [C-0-1] DEBE mantener un período razonable de retención de dicho historial del usuario.
• [C-SR-1] SE RECOMIENDA IMPORTANTEMENTE mantener el período de retención de 14 días como configurado de forma predeterminada en la implementación del AOSP.

Android almacena los eventos del sistema con el método StatsLog. identificadores, y administra dicho historial a través de StatsManager y la API del sistema IncidentManager.

Implementaciones en dispositivos:

• [C-0-2] Solo DEBE incluir los campos marcados con DEST_AUTOMATIC en el informe de incidentes creado por la clase IncidentManager de la API del sistema.
• [C-0-3] No DEBES usar los identificadores de eventos del sistema para registrar ningún otro evento. que la que se describe en la StatsLog Documentos del SDK. Si se registran eventos del sistema adicionales, PUEDEN usar un identificador atómico diferente en el rango entre 100,000 y 200,000.

9.8.2. Grabando

Implementaciones en dispositivos:

• [C-0-1] NO DEBE precargar ni distribuir componentes de software desde el primer momento que enviar información privada del usuario (por ejemplo, pulsaciones de teclas, texto que aparece en pantalla, informe de errores) fuera del dispositivo sin el consentimiento del usuario o borrar las notificaciones continuas.
• [C-0-2] DEBE mostrar una advertencia del usuario y obtener el consentimiento explícito del usuario para permitir que se capture la información sensible que aparece en la pantalla del usuarioy que incluya el mismo mensaje que AOSP siempre que cada vez que una sesión recopile la pantalla transmisión o grabación de pantalla está habilitado iniciado mediante MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), o APIs propias de Google. NO DEBE proporcionar a los usuarios la opción para inhabilitar la visualización futura del consentimiento del usuario.
• [C-0-3] DEBE tener una notificación continua para el usuario durante la transmisión de pantalla o la grabación de pantalla esté habilitada. AOSP cumple con este requisito, ya que muestra un el ícono de notificación continua en la barra de estado.

Si las implementaciones de dispositivos incluyen funcionalidades en el sistema que captura el contenido que aparece en la pantalla o graba la transmisión de audio que se reproduzcan en un dispositivo que no sea mediante ContentCaptureService de la API del sistema otros medios de propiedad descritos en En el artículo 9.8.6 Datos ambientales y a nivel del SO, se aplica lo siguiente:

• [C-1-1] DEBE tener una notificación continua al usuario siempre que esta esté habilitada y se esté capturando o grabando de manera activa.

Si las implementaciones de dispositivos incluyen un componente habilitado listo para usar que es capaz de grabar audio ambiental o grabar el audio reproducido en el dispositivo para inferir información útil sobre el contexto del usuario:

• [C-2-1] NO DEBE almacenar en el almacenamiento persistente en el dispositivo ni transmitir fuera de la el audio sin procesar grabado o cualquier formato que se pueda volver a convertir el audio original o un facsímil, excepto con el consentimiento explícito del usuario.

Un "indicador de micrófono" hace referencia a una vista en la pantalla, que está siempre visible. al usuario y no se puede ocultar, lo que los usuarios entienden como un micrófono está en use(mediante texto, color, ícono o alguna combinación únicos).

Un "indicador de cámara" hace referencia a una vista en la pantalla, que es constantemente visible para al usuario y no se puede ocultar, ya que la cámara entiende que esta se está usando. (mediante texto, color, ícono o alguna combinación únicos).

Después de que se muestra el primer segundo, un indicador puede cambiar visualmente, como cada vez más pequeño y no es necesario que se muestre como se presentó y y comprende.

El indicador del micrófono puede combinarse con una cámara que se muestra activamente. indicador, siempre que el texto, los iconos o los colores le indiquen al usuario que comenzó el uso del micrófono.

El indicador de la cámara puede combinarse con un micrófono que se muestra activamente. siempre que el texto, los iconos o los colores le indiquen al usuario que el comenzó el uso de la cámara.

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

• [C-SR-1] SE RECOMIENDA MUY BIEN que muestren el indicador del micrófono cuando una app accede a datos de audio desde el micrófono, pero no cuando el micrófono está a las que solo acceden HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o aplicaciones que tienen las funciones mencionadas en la sección 9.1 Permisos con identificador de CDD [C-3-X]. .
• [C-SR-2] SE RECOMIENDA INTENSIÓN para mostrar la lista de mensajes recientes y activos. apps que usan el micrófono como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier atribución mensajes asociados.
• [C-SR-3] SE RECOMIENDA ENRENDER no ocultar el indicador del micrófono de del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

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

• [C-SR-4] SE RECOMIENDA MUY BIEN mostrar el indicador de la cámara cuando se inicia una app. acceder a los datos de la cámara en vivo, pero no cuando solo se accede a la cámara apps que tienen las funciones mencionadas en el Artículo 9.1 Permisos con CDD identificador [C-3-X].
• [C-SR-5] SE RECOMIENDA MUY BIEN que se muestren apps recientes y activas usando cámara como se devuelve en PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución asociados.
• [C-SR-6] SE RECOMIENDA ENERCMENTE no ocultar el indicador de la cámara en el sistema Aplicaciones que tienen interfaces de usuario visibles o interacción directa con el usuario.

9.8.3 Conectividad

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB, hacen lo siguiente:

• [C-1-1] DEBE presentar una interfaz de usuario en la que se solicite el consentimiento del usuario antes de lo que permite el acceso al contenido del almacenamiento compartido a través del puerto USB.

9.8.4. Tráfico de red

Implementaciones en dispositivos:

• [C-0-1] DEBE preinstalar los mismos certificados raíz para el servidor de confianza Almacenamiento de la autoridad certificadora (AC) como proporcionado en el Proyecto de código abierto de Android ascendente.
• [C-0-2] SE DEBE enviar con un almacén de AC raíz de usuario vacío.
• [C-0-3] SE DEBE mostrar una advertencia al usuario que indique el tráfico de red. puede supervisarse cuando se agrega una AC raíz de usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones de los dispositivos:

• [C-1-1] DEBE mostrar una advertencia al usuario en la que se indique lo siguiente:
  • Es posible que ese tráfico de red esté supervisado.
  • El tráfico de red se enruta a través de la VPN específica una aplicación que proporciona la VPN.

Si las implementaciones de dispositivos tienen un mecanismo, habilitado de forma predeterminada desde el primer momento, ese enruta el tráfico de datos de red a través de un servidor proxy o una puerta de enlace de VPN (por ejemplo, precarga un servicio de VPN con android.permission.CONTROL_VPN otorgado), hacen lo siguiente:

• [C-2-1] SE DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo. a menos que esa VPN esté habilitada por el controlador de Device Policy a través del DevicePolicyManager.setAlwaysOnVpnPackage() , en cuyo caso el usuario no necesita dar un consentimiento aparte, pero Solo DEBE ser notificado.

Si las implementaciones de dispositivos implementan una indicación visual del usuario para activar el "VPN siempre activada" función de una app de VPN de terceros, hacen lo siguiente:

• [C-3-1] SE DEBE inhabilitar esta opción de usuario para las apps que no son compatibles. servicio de VPN siempre activada en el archivo AndroidManifest.xml mediante la configuración de SERVICE_META_DATA_SUPPORTS_ALWAYS_ON a false.

9.8.5 Identificadores de dispositivos

Implementaciones en dispositivos:

• [C-0-1] SE DEBE impedir el acceso al número de serie del dispositivo y, dónde correspondiente, IMEI/MEID, número de serie de SIM e International Mobile Identidad del suscriptor (IMSI) de una app, a menos que cumpla con una de las siguientes requisitos:
  • es una app de operador firmada y verificada por los fabricantes de dispositivos.
  • se le otorgó el permiso READ_PRIVILEGED_PHONE_STATE.
  • Tenga privilegios de operador, tal como se define en los Privilegios de proveedor de UICC.
  • es un propietario de dispositivo o perfil al que se le otorgó el READ_PHONE_STATE.
  • (Solo para el número de serie de SIM o ICCID) tiene el requisito de reglamentaciones locales. que la aplicación detecte cambios en la identidad del suscriptor.

9.8.6 Captura de contenido y búsqueda de aplicacionesDatos ambientales y a nivel del SO

Android, a través de las API del sistema ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query o por otro de propiedad exclusiva, admite un mecanismo para el uso de dispositivos para capturar las siguientes interacciones de datos de aplicaciones entre las aplicaciones el usuario datos sensibles:

• Texto y gráficos que se renderizan en la pantalla, incluidos, sin limitaciones, notificaciones y datos de asistencia mediante AssistStructure API de gcloud.
• Datos multimedia, como audio o video, que el dispositivo graba o reproduce
• Eventos de entrada (p. ej., tecla, mouse, gesto, voz, video y accesibilidad)

• Cualquier mensaje de texto u otros datos que se envíen a través del TextClassifier API al TextClassifier del sistema, es decir, al servicio del sistema para comprender el significado del texto, así como la generación de acciones futuras previstas según el texto.
• Datos indexados por la implementación de AppSearch de la plataforma, incluidos, pero no limitados a texto, gráficos, datos multimedia y otros datos similares.

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

• [C-1-1] SE DEBE encriptar todos esos datos cuando estén almacenados en el dispositivo. Esta PUEDE llevarse a cabo mediante la encriptación basada en archivos de Android o cualquier de los cifrados enumerados como API nivel 26 o versiones posteriores descritos en Cipher SDK.
• [C-1-2] NO DEBE hacer una copia de seguridad de los datos sin procesar ni encriptados con Métodos de copia de seguridad de Android o cualquier otro up.
• [C-1-3] Solo se DEBE enviar todos esos datos. y el registro de la dispositivo con un mecanismo que preserva la privacidad, excepto con el consentimiento explícito del usuario cada vez que compartidos. El mecanismo que preserva la privacidad se definen como “aquellos que solo permiten el análisis en conjunto y evitan la coincidencia de eventos registrados o resultados derivados con usuarios individuales”, hasta evitar que los datos por usuario sean introspectivos (p.ej., implementados usando una tecnología de privacidad diferencial, como RAPPOR).
• [C-1-4] NO DEBE asociar dichos datos con ninguna identidad de usuario (como como Account) en el dispositivo, excepto con el consentimiento explícito del usuario cada vez que se actualicen los datos asociados.
• [C-1-5] NO DEBE compartir estos datos con otros componentes del SO que no deben cumplir con los requisitos que se describen en la sección actual (9.8.6 Captura de contenido Nivel de SO y ambiente datos), excepto que se cuente con el consentimiento explícito del usuario cada tiempo en el que se comparten. A menos que dicha funcionalidad sea compilada como una API del SDK de Android (AmbientContext, HotwordDetectionService).
• [C-1-6] DEBE brindar al usuario la autorización para borrar los datos que el ContentCaptureService implementación o patentado significa que recopila si cuando los datos se almacenan de cualquier forma en el dispositivo. Si los el usuario elige borrar los datos, DEBE eliminar todo el historial con datos valiosos y útiles.
• [C-1-7] DEBE brindar una indicación al usuario para rechazar los datos recopilados, lo cual a través de AppSearch o medios de propiedad para evitar que se muestren en la plataforma de Android p.ej., de Google.
• [C-SR-1] SE RECOMIENDA ENERGMENTE NO solicitar el permiso de INTERNET.
• [C-SR-2] SE RECOMIENDA ENcarecidamente acceder a Internet solo a través de APIs estructuradas respaldadas por implementaciones de código abierto disponibles públicamente.

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema ContentCaptureService, AppSearchManager.index o cualquier servicio de propiedad que captura los datos como se describió anteriormente, hace lo siguiente:

• [C-2-1] NO DEBE permitir que los usuarios reemplacen los servicios con un una aplicación o servicio instalable por el usuario y DEBE permitir únicamente el y preinstalados para captar esos datos.
• [C-2-2] NO DEBE permitir ninguna aplicación que no sean los servicios preinstalados un mecanismo de control para captar esos datos.
• [C-2-3] DEBE proporcionar al usuario la posibilidad de inhabilitar los servicios.
• [C-2-4] NO DEBES omitir la prestación del usuario para administrar los permisos de Android que que poseen los servicios y siguen los permisos de Android modelo de AA, tal como se describe en la Sección 9.1. Permiso.

• [C-SR-3] SE RECOMIENDA ENERGENTE para mantener los servicios separados de otros componentes del sistema(p.ej., no vincular el servicio o compartir IDs de procesos) excepto por lo siguiente:

  • Telefonía, Contactos, IU del sistema y Contenido multimedia

9.8.7 Acceso al portapapeles

Implementaciones en dispositivos:

• [C-0-1] NO DEBE devolver datos recortados del portapapeles (p.ej., a través del ClipboardManager a menos que el proveedor de es el IME predeterminado o es la app que actualmente está enfocada.

• [C-0-2] DEBE borrar los datos del portapapeles como máximo 60 minutos después de su última vez colocarse en un portapapeles o leer desde un portapapeles.

9.8.8. Ubicación

La ubicación incluye información en la clase de ubicación de Android( como Latitude, longitud y altitud), así como los identificadores que pueden convertirse en ubicaciones. La ubicación puede ser tan precisa como el DGPS (sistema de posicionamiento global diferencial) o aproximada como ubicaciones a nivel de país (como la ubicación del código de país; MCC, dispositivos móviles) código de país).

A continuación, se incluye una lista de los tipos de ubicaciones que derivan directamente o se puede convertir en la ubicación de un usuario. Esta no es una pero debe usarse como ejemplo sobre qué puede permitir se derivarán indirectamente de:

• GPS/GNSS/DGPS/PPP
  • Solución de posicionamiento global o Sistema de navegación global por satélite o Solución de posicionamiento diferencial global
  • También se incluyen las mediciones GNSS sin procesar y el estado de GNSS
    • La ubicación precisa puede derivar de las mediciones GNSS sin procesar
• Tecnologías inalámbricas con identificadores únicos, como los siguientes:
  • Puntos de acceso Wi-Fi (MAC, BSSID, Nombre o SSID)
  • Bluetooth/BLE (MAC, BSSID, nombre o SSID)
  • UWB (MAC, BSSID, nombre o SSID)
  • ID de la torre de telefonía celular (3G, 4G, 5G, etc.), incluidos todos los futuros módems móviles tecnologías con identificadores únicos)

Como punto de referencia principal, consulta las APIs de Android que requieren ACCESS_FINE_Location o ACCESS_COARSE_Location.

Implementaciones en dispositivos:

• [C-0-1] NO DEBE activar/desactivar la configuración de ubicación del dispositivo ni la conexión Wi-Fi/Bluetooth. de análisis de datos sin el consentimiento explícito del usuario ni su iniciación.
• [C-0-2] DEBE brindar al usuario la opción de acceder a contenido relacionado información, como las solicitudes de ubicación recientes, los permisos a nivel de la aplicación y el uso de la búsqueda de Wi-Fi/Bluetooth para determinar la ubicación.
• [C-0-3] DEBE asegurarse de que la aplicación use la API de Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] es una emergencia iniciada por el usuario. (p.ej., llame al 911 o envíe un mensaje de texto al 911). Sin embargo, para la industria automotriz, un vehículo podría iniciar una sesión de emergencia sin interacción activa del usuario en el caso Se detecta una falla o un accidente (p.ej., para cumplir con los requisitos de llamadas electrónicas).
• [C-0-4] DEBE preservar la capacidad de la API de Emergency Location Bypass para omitir la configuración de ubicación del dispositivo sin cambiar la configuración.
• [C-0-5] SE DEBE programar una notificación que le recuerde al usuario que, luego de usar una aplicación, que el fondo haya accedido a su ubicación [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instaladas

Las aplicaciones para Android que se orientan al nivel de API 30 o superior no pueden ver los detalles de otras aplicaciones apps instaladas de forma predeterminada (consulta Visibilidad de paquetes en la app de Android documentación del SDK).

Implementaciones en dispositivos:

• [C-0-1] NO SE DEBE exponer a ningún detalle de app que se oriente al nivel de API 30 o superior. acerca de cualquier otra aplicación instalada, a menos que la aplicación ya pueda ver los detalles sobre la otra app instalada mediante las APIs administradas. Esto incluye, no se limita a los detalles que exponen las APIs personalizadas que agrega el dispositivo. o se puede acceder a ella a través del sistema de archivos.
• [C-0-2] NO DEBES otorgar a ninguna app acceso de lectura o escritura a archivos en ningún otro directorio dedicado y específico de la app dentro del almacenamiento externo. Las únicas excepciones son las siguientes:
  • Es la autoridad del proveedor de almacenamiento externo (p.ej., apps como DocumentsUI).
  • Download Provider, que usa la autoridad del proveedor de "descargas" para descargar archivos en el almacenamiento de apps.
  • aplicaciones del Protocolo de transferencia de medios (MTP) firmadas por la plataforma que usan el el permiso con privilegios ACCESS_MTP para permitir la transferencia de archivos a otro dispositivo.
  • Apps que instalan otras apps y que tienen permiso INSTALL_PACKAGES solo puede acceder a directorios “OBB” con el propósito de administrar Archivos de expansión APK.

9.8.10 Informe de errores de conectividad

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

• [C-1-1] DEBE admitir la generación de informes de errores de conectividad a través de BUGREPORT_MODE_TELEPHONY con BugreportManager
• [C-1-2] SE DEBE obtener el consentimiento del usuario cada vez que BUGREPORT_MODE_TELEPHONY sea usarse para generar un informe y NO DEBE solicitar al usuario que dé su consentimiento para todos futuras solicitudes de la aplicación.
• [C-1-3] NO DEBE devolver el informe generado a la aplicación solicitante sin el consentimiento explícito del usuario.
• [C-1-4] Los informes generados con BUGREPORT_MODE_TELEPHONY DEBEN contener al menos la siguiente información:
  • Volcado de TelephonyDebugService
  • Volcado de TelephonyRegistry
  • Volcado de WifiService
  • Volcado de ConnectivityService
  • Un volcado de la instancia de CarrierService del paquete que realiza la llamada (si está vinculada)
  • Búfer de registro de radio
  • Volcado de SubscriptionManagerService
• [C-1-5] NO DEBE incluir lo siguiente en los informes generados:
  • Cualquier tipo de información que no esté directamente relacionada con la conectividad la depuración.
  • Cualquier tipo de registros de tráfico de aplicaciones instalados por el usuario o perfiles detallados de aplicaciones o paquetes instalados por el usuario (los UID están bien, los nombres de los paquetes son no).
• PUEDE incluir información adicional que no esté asociada con ningún usuario con tu identidad. (p.ej., registros del proveedor).

Si las implementaciones de dispositivos incluyen información adicional (p.ej., los registros del proveedor) en informes de errores y que la información tiene privacidad/seguridad/batería/almacenamiento/memoria impacto, ellos:

• [C-SR-1] SE RECOMIENDA ENcarecidamente que tengan establecida la configuración de desarrollador de forma predeterminada inhabilitado. Para cumplir con esto, la implementación de referencia de AOSP proporciona Enable verbose vendor logging. en la configuración del desarrollador para incluir registros adicionales de proveedores específicos del dispositivo en los informes de errores.

9.8.11 Uso compartido de BLOB de datos

Android, a través de BlobStoreManager permite que las apps aporten BLOB de datos al sistema para que se compartan con un conjunto de apps.

Si las implementaciones de dispositivos admiten BLOB de datos compartidos como se describe en el Documentación del SDK, hace lo siguiente:

• [C-1-1] NO DEBE compartir BLOB de datos que pertenezcan a las aplicaciones más allá de lo que previstos para permitir (es decir, el alcance del acceso predeterminado y las demás opciones modos que pueden especificarse BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), o BlobStoreManager.session#allowPublicAccess() NO DEBE modificarse). La implementación de referencias de AOSP cumple con estos y los requisitos de cumplimiento.
• [C-1-2] NO DEBE enviar los hashes seguros fuera del dispositivo ni compartirlos con otras aplicaciones. de BLOB de datos (que se usan para controlar el acceso).

9.8.12. Reconocimiento de música

Android, a través de la API del sistema MusicRecognitionManager, admite un mecanismo para implementaciones en dispositivos para solicitar el reconocimiento de música a partir de una grabación de audio delegar el reconocimiento de música a una aplicación con privilegios que implemente el API de MusicRecognitionService.

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema MusicRecognitionManager o cualquier servicio de propiedad que transmita datos de audio como descritos anteriormente, hacen lo siguiente:

• [C-1-1] DEBE exigir que el llamador de MusicRecognitionManager conserve el Permiso MANAGE_MUSIC_RECOGNITION
• [C-1-2] SE DEBE exigir que un único reconocimiento de música preinstalado de proyectos implementa MusicRecognitionService.
• [C-1-3] NO DEBE permitir que los usuarios reemplacen MusicRecognitionManagerService. o MusicRecognitionService con una aplicación o servicio que el usuario puede instalar.
• [C-1-4] SE DEBE asegurarse de que cuando MusicRecognitionManagerService acceda al grabación de audio y lo reenvía a la aplicación que implementa el MusicRecognitionService, se realiza un seguimiento del acceso al audio mediante invocaciones de AppOpsManager.noteOp / startOp.

Si las implementaciones de MusicRecognitionManagerService o MusicRecognitionService almacena cualquier dato de audio capturado:

• [C-2-1] NO DEBE almacenar en el disco ninguna huella digital ni audio sin procesar, o en la memoria durante más de 14 días.
• [C-2-2] NO DEBE compartir dichos datos fuera del MusicRecognitionService, excepto con el consentimiento explícito del usuario cada vez que se comparte.

9.8.13 SensorPrivacyManager

Si las implementaciones de dispositivos proporcionan al usuario una indicación visual de software para desactivar la entrada de la cámara o del micrófono para la implementación del dispositivo:

• [C-1-1] DEBE mostrar el valor “true” de manera exacta. de las campañas admiteSensorToggle() método de API.
• [C-1-2] DEBE, cuando una aplicación intenta acceder a un micrófono o una cámara bloqueados: al usuario con una indicación visual que no se puede descartar y que indica que el sensor está bloqueado y requiere una opción para continuar bloquear o desbloquear según la implementación del AOSP que cumple un requisito de seguridad.
• [C-1-3] Solo se DEBE pasar datos de la cámara y de audio en blanco (o falsos) a las apps. y no informar un código de error debido a que el usuario no enciende la cámara ni el micrófono a través de la opción de usuario presentada según [C-1-2] arriba.

9.9 Encriptación del almacenamiento de datos

Todos los dispositivos DEBEN cumplir con los requisitos de la sección 9.9.1. Los dispositivos que se lanzaron en un nivel de API anterior al de este documento son quedan exentas de los requisitos de los artículos 9.9.2 y 9.9.3. sino que DEBE cumplir con los requisitos de la sección 9.9 de la guía de compatibilidad de Android Documento de definición que corresponde al nivel de API en el que se inició el dispositivo.

9.9.1 Inicio directo

Implementaciones en dispositivos:

• [C-0-1] DEBE implementar las APIs del modo de inicio directo incluso si no admiten la encriptación de almacenamiento.

• [C-0-2] El ACTION_LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED Aun así, los intents DEBEN transmitirse para indicar a las aplicaciones que reconocen el arranque directo. Las ubicaciones de almacenamiento cifrado por dispositivo (DE) y encriptado por credenciales (CE) son las siguientes: disponibles para el usuario.

9.9.2. Requisitos de encriptación

Implementaciones en dispositivos:

• [C-0-1] DEBE encriptar la aplicación como privada. (partición /data), así como la partición de almacenamiento compartido de la aplicación (partición /sdcard) si es una parte permanente del dispositivo no extraíble.
• [C-0-2] SE DEBE habilitar la encriptación de almacenamiento de datos de forma predeterminada en ese momento. el usuario completó la experiencia de configuración lista para usar.

• [C-0-3] DEBE cumplir con la encriptación de almacenamiento de datos anterior mediante la implementación de uno de los siguientes dos métodos de encriptación:

  • Encriptación basada en archivos (FBE) y Encriptación de metadatos como se describe en la sección 9.9.3.1.
  • Encriptación a nivel de bloqueo por usuario, como se describe en la sección 9.9.3.2.

9.9.3 Métodos de encriptación

Si las implementaciones de dispositivos están encriptadas, suceden lo siguiente:

• [C-1-1] DEBE iniciarse sin solicitar al usuario las credenciales y permitir que las apps compatibles con el inicio directo accedan al almacenamiento de dispositivo encriptado (DE) después de que se emite el mensaje ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] Solo DEBE permitir el acceso al almacenamiento de Credential Encrypted (CE) después de el usuario desbloqueó el dispositivo proporcionando sus credenciales (p. ej., contraseña, PIN, patrón o huella dactilar) y el ACTION_USER_UNLOCKED se transmite este mensaje.
• [C-1-13] NO DEBE ofrecer ningún método para desbloquear el almacenamiento protegido por CE. sin las credenciales proporcionadas por el usuario, una clave de custodia registrada o Reanuda la implementación de reinicio que cumpla con los requisitos del artículo 9.9.4.
• [C-1-4] DEBE usar el inicio verificado.

9.9.3.1 Encriptación basada en archivos con encriptación de metadatos

Si las implementaciones de dispositivos usan encriptación basada en archivos con encriptación de metadatos, hace lo siguiente:

• [C-1-5] DEBE encriptar el contenido del archivo y los metadatos del sistema de archivos usando AES-256-XTS o Adiantum. AES-256-XTS hace referencia al estándar de encriptación avanzada con una longitud de clave de cifrado de 256 bits, operada en modo XTS la longitud total del es de 512 bits. Adiantum hace referencia a Adiantum-XChaCha12-AES, como se especifica en https://github.com/google/adiantum Los metadatos del sistema de archivos son datos los tamaños, la propiedad, los modos y los atributos extendidos (xattrs).
• [C-1-6] SE DEBE encriptar los nombres de los archivos con AES-256-CBC-CTS, AES-256-HCTR2, o Adiantum.
• [C-1-12] Si el dispositivo tiene un Estándar de encriptación avanzada (AES) instrucciones (como las extensiones de criptografía de ARMv8 en dispositivos basados en ARM, o AES-NI en dispositivos basados en x86) y, luego, las opciones anteriores basadas en AES para el nombre del archivo contenido de los archivos y se DEBE usar la encriptación de metadatos del sistema de archivos, no Adiantum.
• [C-1-13] DEBE usar una clave criptográficamente segura y no reversible de derivación (p.ej., HKDF-SHA512) para derivar cualquier subclave necesaria (p.ej., claves por archivo) de las claves CE y DE. "Criptografía sólida y irreversible" significa que la función de derivación de claves tiene una seguridad de al menos 256 bits y se comporta como una función pseudoaleatoria familia sobre sus entradas.
• [C-1-14] NO DEBE usar las mismas claves o subclaves de encriptación basada en archivos (FBE). para diferentes propósitos criptográficos (p.ej., para la encriptación y la clave derivación o para dos algoritmos de encriptación diferentes).
• [C-1-15] DEBE asegurarse de que todos los bloques no eliminados del contenido del archivo encriptado en el almacenamiento persistente se encriptaron usando combinaciones de claves de encriptación y vector de inicialización (IV) que dependen tanto del archivo como del desplazamiento dentro el archivo. Además, todas esas combinaciones DEBEN ser distintas, excepto cuando la encriptación se realiza mediante hardware de encriptación en línea que solo admite Longitud de IV de 32 bits.
• [C-1-16] SE DEBE asegurarse de que todos los nombres de archivo encriptados no eliminados en directorios diferentes se encriptaron usando distintas combinaciones de la clave de encriptación y el vector de inicialización (IV).

• [C-1-17] DEBEN asegurarse de que todos los metadatos del sistema de archivos encriptados se bloqueen en el almacenamiento persistente se encriptaron con distintas combinaciones de claves de encriptación y el vector de inicialización (IV).

• Claves que protegen las áreas de almacenamiento CE y DE, y los metadatos del sistema de archivos:

  • [C-1-7] DEBE vincularse criptográficamente a un almacén de claves guardado en hardware. Este almacén de claves DEBE estar vinculado al inicio verificado y al hardware del dispositivo. raíz de confianza.
  • [C-1-8] Las claves CE DEBEN estar vinculadas a las credenciales de la pantalla de bloqueo de un usuario.
  • [C-1-9] Las claves CE DEBEN estar vinculadas a una contraseña predeterminada cuando el usuario credenciales de pantalla de bloqueo no especificadas.
  • [C-1-10] DEBE ser único y distinto, en otras palabras, ningún CE o DE del usuario coincida con las teclas CE o DE de cualquier otro usuario.
  • [C-1-11] DEBE usar los algoritmos de cifrado, las longitudes de clave y modos.
  • [C-1-12] SE DEBE borrar de manera segura durante el desbloqueo y bloqueo del bootloader. como se describe aquí.

• DEBES crear apps esenciales preinstaladas (p.ej., Alarma, Teléfono, Messenger) Compatible con el inicio directo.

El proyecto ascendente de código abierto de Android proporciona una implementación preferida de Encriptación basada en archivos basada en el kernel de Linux “fscrypt” función de encriptación, y de encriptación de metadatos basada en el kernel de Linux “dm-default-key” .

9.9.3.2. Encriptación a nivel de bloqueo por usuario

Si las implementaciones de dispositivos usan encriptación a nivel de bloque por usuario, sucederá lo siguiente:

• [C-1-1] SE DEBE habilitar la asistencia multiusuario como se describe en la sección 9.5.
• [C-1-2] DEBE proporcionar particiones por usuario, ya sea usando particiones sin procesar o volúmenes lógicos.
• [C-1-3] DEBE usar claves de encriptación únicas y distintas por usuario para la encriptación de los dispositivos de almacenamiento en bloques subyacentes.

• [C-1-4] SE DEBE usar AES-256-XTS para la encriptación a nivel de bloque del usuario o particiones.

• Estas son las claves que protegen los dispositivos encriptados por usuario a nivel de bloque:

  • [C-1-5] DEBE vincularse de forma criptográfica a un almacén de claves guardado en hardware. Este almacén de claves DEBE estar vinculado al inicio verificado y al hardware del dispositivo. raíz de confianza.
  • [C-1-6] SE DEBE vincular a la pantalla de bloqueo del usuario correspondiente. credenciales.

La encriptación a nivel de bloque por usuario se puede implementar con el kernel de Linux. “dm-crypt” en particiones por usuario.

9.9.4 Reanudar en el reinicio

La opción Reanudar en el reinicio permite desbloquear el almacenamiento CE de todas las apps, incluidas las siguientes. que aún no admiten el inicio directo, después de un reinicio inalámbrico. Esta permite que los usuarios reciban notificaciones de apps instaladas después de reiniciar.

La implementación de Reanudación en el reinicio debe continuar asegurando que cuando una caiga en las manos de un atacante, es muy difícil que ese que el atacante recupere los datos encriptados con CE del usuario, incluso si el dispositivo está encendido el almacenamiento de CE se desbloquea y el usuario desbloquea el dispositivo después de recibir una OTA. Para la resistencia ante ataques de usuarios con información privilegiada, también asumimos que el atacante obtiene acceso transmitir claves de firma criptográficas.

Más precisamente:

• [C-0-1] El almacenamiento CE NO DEBE ser legible incluso para el atacante que físicamente el dispositivo y, luego, presenta estas capacidades y limitaciones:

  • Se puede usar la clave de firma de cualquier proveedor o empresa para firmar mensajes nuevos.
  • Puede hacer que el dispositivo reciba una actualización inalámbrica.
  • Puede modificar el funcionamiento de cualquier hardware (AP, flash, etc.), excepto en los siguientes casos: se detallan a continuación, pero dicha modificación implica un retraso de al menos una y un reinicio que destruye el contenido de la RAM.
  • No se puede modificar el funcionamiento del hardware resistente a alteraciones (p. ej., Titan M).
  • No se puede leer la RAM del dispositivo activo.
  • No se puede obtener la credencial del usuario (PIN, patrón o contraseña). de lo contrario, ingresarán los datos.

A modo de ejemplo, la implementación de un dispositivo que implementa y cumple con todas de las descripciones que se encuentran aquí cumplirá con los estándares [C-0-1].

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan la transparencia en el estado de la la integridad del dispositivo. Implementaciones en dispositivos:

• [C-0-1] SE DEBE informar correctamente a través del método de la API del sistema. PersistentDataBlockManager.getFlashLockState() si su bootloader permite la escritura en la memoria flash de la imagen del sistema.

• [C-0-2] DEBE admitir el inicio verificado para la integridad del dispositivo.

Si las implementaciones en dispositivos ya se lanzaron sin compatibilidad con el inicio verificado en una versión anterior de Android y no puedo agregar compatibilidad con esto con una actualización de software del sistema, PUEDEN estar exentas de la un requisito de seguridad.

El inicio verificado es una función que garantiza la integridad del dispositivo software. Si las implementaciones en dispositivos admiten la función, sucederá lo siguiente:

• [C-1-1] SE DEBE declarar la marca de función de la plataforma. android.software.verified_boot
• [C-1-2] SE DEBE verificar cada secuencia de inicio.
• [C-1-3] DEBE iniciar la verificación desde una clave de hardware inmutable que es raíz de confianza y llegar hasta la partición del sistema.
• [C-1-4] SE DEBE implementar cada etapa de verificación para comprobar la integridad y la autenticidad de todos los bytes en la siguiente etapa, antes de ejecutar el código en a la siguiente etapa.
• [C-1-5] DEBE usar algoritmos de verificación tan sólidos como los actuales recomendaciones del NIST para los algoritmos de hash (SHA-256) y la clave pública (RSA-2048).
• [C-1-6] NO DEBE permitir que se complete el inicio cuando falla la verificación del sistema. a menos que el usuario dé su consentimiento para intentar iniciarse de todas formas, en cuyo caso, los datos de No DEBE usar bloques de almacenamiento no verificados.
• [C-1-7] NO DEBE permitir que se modifiquen las particiones verificadas en el dispositivo a menos que el usuario haya desbloqueado explícitamente el bootloader.
• [C-SR-1] Si hay varios chips discretos en el dispositivo (p.ej., radio, un procesador de imágenes especializado), el proceso de inicio de cada uno de esos chips RECOMIENDA verificar cada etapa durante el inicio.
• [C-1-8] SE DEBE usar el almacenamiento de manipulación evidente: para guardar si está desbloqueado. El almacenamiento a prueba de sabotajes significa que el bootloader puede detectar si se manipuló el almacenamiento desde Android.
• [C-1-9] DEBE solicitar permiso al usuario mientras usa el dispositivo. requerir confirmación física antes de permitir una transición desde el bootloader del modo bloqueado al modo desbloqueado del bootloader.
• [C-1-10] DEBE implementar la protección contra reversión para las particiones que usa Android. (p.ej., inicio, particiones del sistema) y usar el almacenamiento de manipulación evidente metadatos que se usan para determinar la versión mínima permitida del SO.
• [C-1-11] SE DEBE borrar de forma segura todos los datos del usuario durante el desbloqueo del bootloader y de bloqueo según '9.12. Eliminación de datos" (incluida la partición userdata y cualquier espacio NVRAM).
• [C-SR-2] SE RECOMIENDA COMPLETAMENTE verificar todos los archivos APK de la app con privilegios mediante una cadena de confianza con permisos de administrador en particiones protegidas por el inicio verificado.
• [C-SR-3] SE RECOMIENDA COMPLETAMENTE verificar cualquier artefacto ejecutable cargado por una aplicación con privilegios fuera de su archivo APK (como código cargado dinámicamente o (código compilado) antes de ejecutarlas, o SE RECOMIENDA SÓLIDAMENTE no ejecutarlas en absoluto.
• SE DEBE implementar la protección contra reversión para cualquier componente con (p.ej., módem o cámara), y DEBERÍAS usar el almacenamiento a prueba de manipulaciones almacenar los metadatos utilizados para determinar la versión mínima permitida.

Si ya se lanzaron implementaciones en dispositivos sin admitir C-1-8 a través de C-1-11 en una versión anterior de Android y no puede agregar compatibilidad con estos requisitos con una actualización de software del sistema, PUEDEN estar exentos del y los requisitos de cumplimiento.

El Proyecto de código abierto de Android ascendente ofrece una implementación preferida de esta función en la external/avb/ que se puede integrar en el bootloader que se usa para cargar Android

Implementaciones en dispositivos

Si las implementaciones en dispositivos pueden verificar el archivo contenido por página, entonces:

• [C-0-3] C-2-1] verificando de forma criptográfica el contenido de un archivo frente a un clave de confianza sin leer todo el archivo.

• [C-0-4 C-2-2] NO DEBE permitir el de lectura de un archivo protegido para tener éxito cuando el contenido de lectura no verificar con una clave de confianza no se verifica por [C-2-1] anterior.

Si ya se iniciaron implementaciones de dispositivos sin la capacidad de verificarlas de archivos con una clave de confianza de una versión anterior de Android y no se puede agregar asistencia para esta función con una actualización de software del sistema, PUEDEN estar exentas del requisito. El proyecto ascendente de código abierto de Android proporciona una implementación preferida de esta función según la función fs-verity del kernel de Linux.

Implementaciones en dispositivos:

• [C-SR-4] SE RECOMIENDA ENERGMENTE que sea compatible con la API de Confirmación de protección de Android.

Si las implementaciones de dispositivos admiten la Confirmación de protección de Android API:

• [C-3-1] DEBE informar true para el ConfirmationPrompt.isSupported(). API de gcloud.

• [C-3-2] SE DEBE asegurarse de que el código que se ejecuta en el SO Android, incluido su malicioso o de otro tipo, no puede generar una respuesta positiva sin la interacción del usuario.

• [C-3-3] SE DEBE asegurarse de que el usuario haya podido revisar y aprobar el mensaje solicitado aun cuando el SO Android, incluido su kernel, se comprometa.

9.11. Claves y credenciales

El sistema Android Keystore que permite a los desarrolladores de apps almacenar claves criptográficas en un contenedor y usarlas operaciones criptográficas a través de la API de KeyChain o la API de Keystore. Implementaciones en dispositivos:

• [C-0-1] DEBE permitir que se importen o generen al menos 8,192 claves.
• [C-0-2] La autenticación de la pantalla de bloqueo DEBE implementar un intervalo de tiempo. entre intentos fallidos. Con n como recuento de intentos fallidos, el tiempo el intervalo DEBE ser de, al menos, 30 segundos durante 9 < n < Para n > 29, el el valor del intervalo de tiempo DEBE ser de, al menos, 30*2^floor((n-30)/10)) segundos o al menos 24 horas, lo que sea menor.
• No se DEBE limitar la cantidad de claves que se pueden generar.

Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, hace lo siguiente:

• [C-1-1] SE DEBE hacer una copia de seguridad de la implementación del almacén de claves con una entorno de ejecución.
• [C-1-2] DEBE tener implementaciones de RSA, AES, ECDSA, ECDH (si IKeyMintDevice es compatible), 3DES, y los algoritmos criptográficos HMAC y los hashes de la familia MD5, SHA1 y SHA-2 para admitir correctamente la infraestructura en un área aislada de forma segura del código que se ejecuta kernel y versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos por qué código del espacio del usuario o kernel puede acceder al estado interno del entorno aislado, incluida la DMA. El código abierto de Android ascendente (AOSP) cumple con este requisito por medio de la Trusty, pero otra solución basada en ARM TrustZone o una versión segura revisada por terceros implementación de un aislamiento adecuado basado en un hipervisor son alternativas opciones de estado.
• [C-1-3] DEBE realizar la autenticación de la pantalla bloqueada en la de ejecución y, solo cuando sea exitoso, permite el acceso claves que se usarán. Las credenciales de la pantalla de bloqueo DEBEN almacenarse en un que permite que solo el entorno de ejecución aislado realice la pantalla de bloqueo autenticación. El Proyecto de código abierto de Android ascendente ofrece la Capa de abstracción de hardware (HAL) del recepcionista y Trusty, que pueden usarse para cumplir con este requisito.
• [C-1-4] DEBE admitir la certificación de claves donde se encuentre la clave de firma de la certificación protegida con hardware seguro, y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse en una cantidad lo suficientemente grande de para evitar que las claves se usen como identificadores de dispositivos. Ida solo para cumplir con este requisito es compartir la misma clave de certificación, a menos que se producen al menos 100,000 unidades de un SKU determinado. Si hay más de 100,000 unidades de un SKU, PUEDE usarse una clave diferente para cada 100,000 unidades.

Ten en cuenta que, si la implementación de un dispositivo ya se lanzó en una versión anterior de Android versión, este dispositivo está exento del requisito de tener un almacén de claves. está respaldado por un entorno de ejecución aislado y admite la certificación de claves. a menos que declare la función android.hardware.fingerprint que requiera un de código abierto respaldado por un entorno de ejecución aislado.

• [C-1-5] DEBE permitir que el usuario elija el tiempo de espera de suspensión para la transición de desbloqueado al estado bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos. Dispositivos automotores que bloquean la pantalla cuando la consola central está apagado o el usuario está encendido, NO PUEDE tener el tiempo de espera de suspensión configuración.
• [C-1-6] DEBE admitir una de las siguientes opciones:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice versión 1 o
  • IKeyMintDevice versión 2.
• [C-SR-1] se RECOMIENDA ENRENDER para ser compatible con la versión 1 de IKeyMintDevice.

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

La implementación del AOSP sigue un modelo de autenticación por niveles, en el que un La autenticación principal basada en la fábrica del conocimiento puede contar con el respaldo datos biométricos sólidos secundarios o por modalidades terciarias más débiles.

Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA ENERGMENTE establecer solo una de las siguientes opciones como autenticación principal método:

  • Un PIN numérico
  • Una contraseña alfanumérica

  • Un patrón de deslizamiento en una cuadrícula de exactamente 3 x 3 puntos.

    Ten en cuenta que los métodos de autenticación anteriores se conocen como métodos de autenticación principales de este documento.

Si las implementaciones de dispositivos agregan o modifican la autenticación principal recomendada y usan un nuevo método de autenticación como una forma segura de bloquear la pantalla, el nuevo método de autenticación:

• [C-2-1] DEBE ser el método de autenticación del usuario como se describe en Solicitud de Autenticación del Usuario para el Uso de la Clave.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo si se basa en un secreto conocido y usas una nueva autenticación método que se tratará como una forma segura de bloquear la pantalla:

• [C-3-1] La entropía de la menor longitud permitida de entradas DEBE ser superior a 10 bits.
• [C-3-2] La entropía máxima de todas las entradas posibles DEBE ser mayor que 18 bits.
• [C-3-3] El nuevo método de autenticación NO DEBE reemplazar ninguno de los métodos de autenticación principales recomendados (es decir, PIN, patrón y contraseña) se implementan y proporcionan en el AOSP.
• [C-3-4] El nuevo método de autenticación DEBE inhabilitarse cuando el La aplicación del controlador de política de dispositivo (DPC) estableció la contraseña política de requisitos de privacidad a través de la DevicePolicyManager.setRequiredPasswordComplexity() con una complejidad más restrictiva constante que PASSWORD_COMPLEXITY_NONE o mediante DevicePolicyManager.setPasswordQuality() con una constante más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Los nuevos métodos de autenticación DEBEN recurrir al métodos de autenticación principales recomendados (es decir, PIN, patrón, contraseña) una vez cada 72 horas o menos O revelar claramente a la usuario que no se creará una copia de seguridad de algunos datos para preservar la privacidad de sus datos.

Si las implementaciones de dispositivos agregan o modifican la autenticación principal recomendada métodos para desbloquear la pantalla de bloqueo y usar un nuevo método de autenticación que basados en datos biométricos se tratarán como una forma segura de bloquear la pantalla, el nuevo método:

• [C-4-1] DEBE cumplir con todos los requisitos descritos en la sección 7.3.10 para la clase 1 (anteriormente, Conveniencia).
• [C-4-2] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales basados en un secreto conocido.
• [C-4-3] DEBE inhabilitarse y solo permitir la instancia principal recomendada autenticación para desbloquear la pantalla cuando el controlador de política de dispositivo (DPC) la aplicación configuró la política de función de protección de teclado llamando al método DevicePolicyManager.setKeyguardDisabledFeatures() , con cualquiera de los marcadores biométricos asociados (es decir, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Si los métodos de autenticación biométrica no cumplen con los requisitos para la Clase 3 (anteriormente Strong), como se describe en sección 7.3.10:

• [C-5-1] Los métodos DEBEN inhabilitarse si el controlador de política de dispositivo (DPC) aplicación estableció la política de calidad de requisitos de contraseña mediante la clase DevicePolicyManager.setRequiredPasswordComplexity() con un bucket de complejidad más restrictivo que PASSWORD_COMPLEXITY_LOW o con DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK
• [C-5-2] Se DEBE cuestionar al usuario para obtener la instancia principal recomendada autenticación (p. ej., PIN, patrón, contraseña) como se describe en [C-1-7] y [C-1-8] en la sección 7.3.10.
• [C-5-3] Los métodos NO DEBEN tratarse como una pantalla de bloqueo segura y DEBEN cumplir con los requisitos que comienzan con C-8 en la siguiente sección.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo y un nuevo método de autenticación basado en un token físico o la ubicación:

• [C-6-1] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales basados en un secreto conocido los requisitos que se deben tratar como una pantalla de bloqueo segura.
• [C-6-2] El nuevo método DEBE inhabilitarse y solo permitir uno de los métodos de autenticación principales recomendados para desbloquear la pantalla cuando la La aplicación del controlador de política de dispositivo (DPC) estableció la política con los siguientes valores:
  • El DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) método
  • El DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_NONE
  • El DevicePolicyManager.setRequiredPasswordComplexity() con un bucket de complejidad más restrictivo que PASSWORD_COMPLEXITY_NONE
• [C-6-3] Se DEBE cuestionar al usuario por uno de los eventos principales recomendados. métodos de autenticación (p.ej., PIN, patrón, contraseña) al menos una vez cada 4 horas o menos. Cuando un token físico cumple con los requisitos para las implementaciones de TrustAgent en C-X, restricciones de tiempo de espera definidas en C-9-5.
• [C-6-4] El nuevo método NO DEBE tratarse como una pantalla de bloqueo segura y DEBE seguir las restricciones que se enumeran en C-8 a continuación.

Si las implementaciones en dispositivos tienen una pantalla de bloqueo segura e incluyen una o más agente de confianza, que implementa la API del sistema TrustAgentService:

• [C-7-1] DEBE tener una indicación clara en el menú de configuración y en la cerradura. pantalla cuando el bloqueo del dispositivo se aplaza o los agentes de confianza pueden desbloquearlo. Por ejemplo, AOSP cumple con este requisito al mostrar una descripción de texto para el parámetro de configuración "Bloqueo automático" y "El botón de encendido se bloquea al instante" en la el menú de configuración y un ícono distinguible en la pantalla de bloqueo.
• [C-7-2] DEBE respetar e implementar completamente todas las APIs de agente de confianza en la DevicePolicyManager, como KEYGUARD_DISABLE_TRUST_AGENTS constante.
• [C-7-3] NO DEBE implementar por completo TrustAgentService.addEscrowToken(). en un dispositivo que se usa como dispositivo personal principal (p.ej., portátil), pero PUEDE implementar completamente la función en el dispositivo implementaciones que se suelen compartir (p.ej., Android Television o Automotive).
• [C-7-4] DEBE encriptar todos los tokens almacenados agregados por TrustAgentService.addEscrowToken()
• [C-7-5] NO DEBES almacenar la clave de encriptación ni el token de custodia en el en el mismo dispositivo en el que se usa la clave. Por ejemplo, se permite una llave almacenada en un teléfono para desbloquear una cuenta de usuario en una TV. En el caso de los dispositivos de la industria automotriz, no se permite almacenar el token de custodia en cualquier parte del vehículo.
• [C-7-6] DEBE informar al usuario sobre las implicaciones de seguridad antes habilitar el token de custodia para desencriptar el almacenamiento de datos.
• [C-7-7] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales.
• [C-7-8] Se DEBE cuestionar al usuario por uno de los métodos de autenticación principales recomendados (p. ej., PIN, patrón, contraseña) al menos una vez cada 72 horas o menos, a menos que se trate de la seguridad del usuario (p. ej., la distracción del conductor). es motivo de preocupación.
• [C-7-9] Se DEBE cuestionar al usuario por uno de los eventos principales recomendados. de autenticación (p. ej., PIN, patrón, contraseña) como se describe en [C-1-7] y [C-1-8] en la sección 7.3.10, a menos que se preocupa la seguridad del usuario (p.ej., la distracción del conductor).
• [C-7-10] NO DEBE tratarse como una pantalla de bloqueo segura y DEBE seguir la que se enumeran en C-8 a continuación.
• [C-7-11] NO DEBE permitir TrustAgents en los dispositivos personales principales (p. ej., de mano) para desbloquear el dispositivo, y solo podrá usarlos para mantener un dispositivo ya desbloqueado en ese estado durante un máximo de un máximo de 4 horas. La implementación predeterminada de TrustManagerService en AOSP cumple con este requisito.
• [C-7-12] DEBE usar una versión criptográfica segura (p. ej., UKEY2) canal de comunicación para pasar el token de custodia desde el con el dispositivo de destino.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo que no sea segura, como se describió anteriormente, y usar un nuevo método de autenticación para desbloquear la protección de seguridad:

• [C-8-1] El nuevo método DEBE inhabilitarse cuando el controlador de política de dispositivo (DPC) estableció la política de calidad de la contraseña mediante el DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_NONE o a través de la DevicePolicyManager.setRequiredPasswordComplexity() con una complejidad más restrictiva constante que "PASSWORD_COMPLEXITY_NONE"
• [C-8-2] NO DEBEN restablecer el temporizador de vencimiento de la contraseña establecido por DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] NO DEBEN exponer una API para que la usen aplicaciones de terceros para cambiar el estado del bloqueo.

Si las implementaciones en los dispositivos permiten que las aplicaciones creen pantallas virtuales y no admiten eventos de entrada asociados, VirtualDeviceManager: hacen lo siguiente:

• [C-9-1] DEBE bloquear estas pantallas virtuales secundarias cuando el la pantalla predeterminada esté bloqueada y desbloquear estas pantallas virtuales secundarias cuando la pantalla predeterminada del dispositivo esté desbloqueada.

Si las implementaciones en dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y admiten entradas asociadas eventos, como mediante VirtualDeviceManager, hacen lo siguiente:

• [C-10-1] DEBE admitir estados de bloqueo separados por dispositivo virtual.
• [C-10-2] SE DEBE desconectar todos los dispositivos virtuales tras el tiempo de espera de inactividad.
• [C-10-3] DEBE tener un tiempo de espera de inactividad.
• [C-10-4] DEBE bloquear todas las pantallas cuando el usuario inicia una bloqueo, lo que incluye mediante el bloqueo del usuario requerido para dispositivos de mano (consulta Artículo 2.2.5[9.11/H-1-2])
• [C-10-5] DEBE tener instancias de dispositivos virtuales independientes por usuario.
• [C-10-6] SE DEBE inhabilitar la creación de eventos de entrada asociados a través de VirtualDeviceManager cuando lo indique DevicePolicyManager.setNearbyAppStreamingPolicy
• [C-10-7] SE DEBE usar un portapapeles independiente solo para cada dispositivo virtual (o inhabilitar el portapapeles para los dispositivos virtuales)
• [C-10-11] DEBE inhabilitar la IU de autenticación en dispositivos virtuales, lo que incluye entrada de factor de conocimiento y instrucción biométrica
• [C-10-12] DEBE restringir los intents iniciados desde un dispositivo virtual para mostrarlos. solo en el mismo dispositivo virtual
• [C-10-13] No DEBE usar un estado de bloqueo del dispositivo virtual como autenticación de usuario. autorización con el sistema Android Keystore. Consulta KeyGenParameterSpec.Builder.setUserAuthentication*

Cuando las implementaciones en dispositivos permiten que el usuario transfiera el dominio de conocimiento de autenticación de un dispositivo de origen a uno de destino como en la configuración inicial del dispositivo de destino, deben hacer lo siguiente:

• [C-11-1] DEBE encriptar el factor de conocimiento con garantías de protección similares a los descritos en el Servicio Google Cloud Key Vault el informe de seguridad de Google Cloud cuando se transfieren factor de conocimiento desde el dispositivo de origen hasta el dispositivo de destino, de modo que el factor de conocimiento no se puede desencriptar ni usar de forma remota para desbloquear con cualquiera de los dos dispositivos.
• [C-11-2] SE DEBE, en el dispositivo de origen , pedirle al usuario que confirme factor de conocimiento del dispositivo de origen antes de transferir el factor de conocimiento con el dispositivo de destino.
• [C-11-3] DEBE, en un dispositivo de destino que carece de una autenticación principal establecida factor de conocimiento, pide al usuario que confirme un factor de conocimiento transferido en el dispositivo de destino antes de establecer ese factor de conocimiento como el principal el factor de conocimiento de autenticación para el dispositivo de destino y antes de disponible cualquier dato transferido desde un dispositivo de origen.

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

• [C-12-1] Solo DEBE llamar a grantTrust() con la marca cuando se conecta a un dispositivo físico próximo con una pantalla de bloqueo propia y cuando el usuario autenticaron su identidad con la pantalla de bloqueo. Los dispositivos cercanos pueden usar mecanismos de detección de transporte o en la muñeca después de que un usuario se desbloquea por única vez para satisfacer el requisito de autenticación de usuarios.
• [C-12-2] DEBE poner la implementación del dispositivo en el TrustState.TRUSTABLE cuando la pantalla está apagada (por ejemplo, al presionar un botón o mostrar se agotó el tiempo de espera) y el TrustAgent no revocó la confianza. El AOSP satisface este requisito.
• [C-12-3] Solo DEBE mover el dispositivo de TrustState.TRUSTABLE a TrustState.TRUSTED si el TrustAgent aún otorga confianza según los requisitos de C-12-1.
• [C-12-4] DEBE llamar a TrustManagerService.revokeTrust().
  • Después de un máximo de 24 horas desde que se otorga la confianza
  • Después de un período de inactividad de 8 horas
  • Si las implementaciones no usan una plataforma segura y rango preciso como se define en [C-12-5], cuando la conexión subyacente con el dispositivo físico próximo.
• [C-12-5] Las implementaciones que dependen de un rango seguro y preciso para cumplir con requisitos de [C-12-4] DEBEN usar una de las siguientes soluciones:
  • Implementaciones con UWB:
    • DEBE cumplir con los requisitos de conformidad, certificación, precisión y requisitos de calibración para UWB que se describe en 7.4.9.
    • SE DEBE usar uno de los modos de seguridad P-STS que se indican en 7.4.9
  • Implementaciones con Wi-Fi Neighborhood Awareness Networking (NAN):
    • DEBE cumplir con los requisitos de precisión de 2.2.1 [7.4.2.5/H-SR-1], usa el ancho de banda de 160 MHz (o una opción más alta) y sigue los pasos para configurar la medición especificados en Calibración de presencias.
    • DEBE usar Secure LTF como se define en IEEE 802.11az

Si las implementaciones en dispositivos permiten que las aplicaciones creen pantallas virtuales secundarias y admiten entradas asociadas eventos, como a través de VirtualDeviceManager. y las pantallas no están marcadas con VIRTUAL_DISPLAY_FLAG_SECURE, hacen lo siguiente:

• [C-13-8] DEBE bloquear las actividades con el atributo android:canDisplayOnRemoteDevices o los metadatos android.activity.can_display_on_remote_devices configurados como falsos para que no se inicien en la consola virtual. dispositivo.
• [C-13-9] DEBE bloquear las actividades. que no habilitan explícitamente la transmisión y que indican que muestran contenido sensible, incluso a través de SurfaceView#setSecure, FLAG_SECURE o SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS que se inició en el dispositivo virtual.
• [C-13-10] SE DEBE inhabilitar la instalación de aplicaciones iniciadas desde dispositivos virtuales.

Si las implementaciones del dispositivo admiten estados de energía separados de la pantalla mediante DeviceStateManager Y admiten estados de bloqueo de pantalla separados mediante KeyguardDisplayManager, hizo lo siguiente:

• [C-SR-2] SE RECOMIENDA EXIGENTEMENTE que utilicen una reunión para obtener las credenciales. definidos en la sección 9.11.1 o una reunión de Biometric definida como mínimo Las especificaciones de clase 1 definidas en la sección 7.3.10 para permitir desbloqueando desde la pantalla predeterminada del dispositivo.
• [C-SR-3] SE RECOMIENDA IMPORTANTE para limitar el desbloqueo de la pantalla por separado a través de un tiempo de espera de visualización definido.
• [C-SR-4] SE RECOMIENDA EXITOSAMENTE para permitir que el usuario bloquee todas las pantallas de manera global a través del bloqueo desde el dispositivo de mano principal.

9.11.2. StrongBox

El sistema Android Keystore te permite a los desarrolladores de apps almacenar claves criptográficas en un procesador seguro dedicado, como y el entorno de ejecución aislado descrito anteriormente. Este de un procesador seguro y dedicado se denomina “StrongBox”. Requisitos C-1-3 hasta C-1-11, definen los requisitos que debe cumplir un dispositivo para que califican como StrongBox.

Implementaciones en dispositivos que tienen un procesador seguro dedicado:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE ser compatible con StrongBox. StrongBox se convierta en un requisito en una versión futura.

Si las implementaciones de dispositivos admiten StrongBox, hacen lo siguiente:

• [C-1-1] DEBE declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DEBE proporcionar hardware seguro y dedicado que se use para respaldar almacén de claves y autenticación de usuario segura. La plataforma de seguridad dedicada el hardware se puede usar para otros fines también.

• [C-1-3] DEBE tener una CPU discreta que no comparta caché, DRAM ni coprocesadores u otros recursos principales con el procesador de aplicaciones (AP).

• [C-1-4] DEBE asegurarse de que ningún periférico compartido con el AP no pueda alterar procesamiento de StrongBox de ninguna manera ni obtener información de StrongBox. El AP PUEDE inhabilitar o bloquear el acceso a StrongBox.

• [C-1-5] DEBE tener un reloj interno con una precisión razonable (+-10%). inmune a la manipulación por parte de AP.

• [C-1-6] DEBE tener un generador de números aleatorios reales que produzca un resultado impredecible y distribuido de manera uniforme.

• [C-1-7] DEBE tener resistencia a la manipulación, incluida resistencia contra penetración física y fallas.

• [C-1-8] DEBE tener resistencia en el canal lateral, incluida la resistencia contra fuga de información a través de energía, sincronización, radiación electromagnética y térmica de la radiación.

• [C-1-9] DEBE tener almacenamiento seguro que garantice la confidencialidad, integridad, autenticidad, coherencia y actualidad de los contenidos. El almacenamiento NO SE DEBE poder leer ni modificar, excepto según lo permitido por las APIs de StrongBox.

• Para validar el cumplimiento con [C-1-3] a [C-1-9], el dispositivo implementaciones:

  • [C-1-10] DEBE incluir el hardware que está certificado en el Perfil de protección IC seguro BSI-CC-PP-0084-2014 o evaluado por un laboratorio de pruebas acreditado a nivel nacional que incorpora Evaluación de vulnerabilidades de alto potencial de ataque según la Aplicación de criterios comunes del potencial de ataque a Tarjetas inteligentes.
  • [C-1-11] DEBE incluir el firmware que evalúa un laboratorio de pruebas acreditado nacionalmente una evaluación de vulnerabilidades potenciales de acuerdo con Aplicación de criterios comunes del potencial de ataque a las tarjetas inteligentes.
  • [C-SR-2] SE RECOMIENDA ENERCMENTE incluir el hardware que se se evalúa con un objetivo de seguridad, un nivel de garantía de la evaluación (EAL) 5, aumentado por AVA_VAN.5. Es probable que la certificación EAL 5 en una versión futura.
  • [C-SR-3] SE RECOMIENDEN ENERGMENTE para proporcionar resistencia ante ataques de usuarios con información privilegiada. (IAR), lo que significa que un usuario con acceso a la firma de firmware no pueden producir firmware que provoque la fuga de StrongBox de Secrets, para evadir los requisitos de seguridad funcional u habilitar el acceso a datos sensibles de los usuarios. La forma recomendada de implementar IAR permite las actualizaciones de firmware solo cuando la contraseña del usuario principal se proporciona a través de la HAL de IAuthSecret.

9.11.3 Credencial de identidad

El sistema de credenciales de identidad se define y logra implementando todos APIs en la android.security.identity.* . Estas APIs permiten a los desarrolladores de apps almacenar y recuperar identidades de usuarios documentos. Implementaciones en dispositivos:

• [C-SR-1] SE RECOMIENDA EXITOSAMENTE para implementar la Credencial de identidad Sistema

Si las implementaciones de dispositivos implementan Identity Credential System, ocurrirá lo siguiente:

• [C-1-1] DEBE mostrar un valor no nulo para IdentityCredentialStore#getInstance(). .

• [C-1-2] DEBE implementar el Sistema de credenciales de identidad (p.ej., android.security.identity.*) con código que se comunica con un profesional aplicación en un área aislada de forma segura del código que se ejecuta en kernel y versiones posteriores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos por qué código del espacio del usuario o kernel puede acceder al estado interno del entorno aislado, incluida la DMA.

• [C-1-3] Las operaciones criptográficas necesarias para implementar Identity El sistema de credenciales (p.ej., las APIs de android.security.identity.*) DEBE tener se realiza por completo en la aplicación de confianza y en el material de la clave privada DEBE Nunca abandonen el entorno de ejecución aislado, a menos que sea específicamente necesario. debido a las APIs de nivel superior (p.ej., createEphemeralKeyPair() método).

• [C-1-4] La aplicación de confianza DEBE implementarse de tal manera que las propiedades de seguridad no se ven afectadas (p.ej., no se divulgan los datos de las credenciales a menos que se cumplan las condiciones de control de acceso, no se podrán producir MAC datos arbitrarios) incluso si Android tiene un comportamiento incorrecto o se ve comprometido.

El Proyecto de código abierto de Android ascendente proporciona una referencia implementación de una aplicación confiable (libeic) que puede usarse para implementar el sistema de credenciales de identidad.

9.12. Eliminación de Datos

Todas las implementaciones en dispositivos:

• [C-0-1] DEBE proporcionarles a los usuarios un mecanismo para restablecer la configuración de fábrica.
• [C-0-2] SE DEBE borrar todos los datos del sistema de archivos userdata cuando se realiza una "Restablecer configuración de fábrica".
• [C-0-3] SE DEBE eliminar los datos de tal manera que satisfagan las necesidades estándares de la industria, como NIST SP800-88, cuando se realiza Restablecer".
• [C-0-4] SE DEBE activar el “restablecimiento de la configuración de fábrica” anterior. proceso cuando el DevicePolicyManager.wipeData() La app del controlador de política de dispositivo del usuario principal llama a la API.
• PUEDE proporcionar una opción de limpieza de datos rápida que lleve a cabo solo una eliminación lógica de datos.

9.13 Modo de inicio seguro

Android ofrece un modo de inicio seguro, que permite a los usuarios iniciar en un modo en el que solo se permite ejecutar apps del sistema preinstaladas, y todas las apps de terceros las apps están inhabilitadas. Este modo, conocido como "modo de inicio seguro", proporciona al usuario la capacidad para desinstalar aplicaciones potencialmente dañinas de terceros.

Las implementaciones en dispositivos son las siguientes:

• [C-SR-1] SE RECOMIENDA COMPLETAMENTE implementar el modo de inicio seguro.

Si las implementaciones de dispositivos implementan el modo de inicio seguro, harán lo siguiente:

• [C-1-1] DEBE brindarle al usuario la opción de ingresar al modo de inicio seguro de una manera que sea ininterrumpida por parte de terceros, aplicaciones instaladas en el dispositivo, excepto cuando la aplicación de terceros es una Device Policy Controller y estableció el UserManager.DISALLOW_SAFE_BOOT marca como true.

• [C-1-2] DEBE permitir que el usuario desinstala las apps de terceros en modo seguro.

• SE DEBE ofrecerles al usuario la opción de ingresar al modo de inicio seguro desde el de inicio con un flujo de trabajo diferente del de un inicio normal.

9.14. Aislamiento de sistemas para vehículos

Se espera que los dispositivos Android Automotive intercambien datos con vehículos subsistemas mediante la HAL del vehículo para enviar y recibir mensajes a través de redes de vehículos como CAN bus.

El intercambio de datos puede protegerse implementando funciones de seguridad debajo del Capas del framework de Android para evitar la interacción maliciosa o involuntaria con estos subsistemas.

9,15 Planes de suscripción

"Planes de suscripción" consulte los detalles del plan de relación de facturación proporcionados por un operador de telefonía celular mediante SubscriptionManager.setSubscriptionPlans()

Todas las implementaciones en dispositivos:

• [C-0-1] DEBE devolver los planes de suscripción solo a la app del operador de telefonía celular que las proporcionó originalmente.
• [C-0-2] NO DEBE crear una copia de seguridad de los planes de suscripción ni subirlos de forma remota.
• [C-0-3] Solo DEBE permitir anulaciones, como SubscriptionManager.setSubscriptionOverrideCongested(), desde la app del operador de telefonía celular que actualmente proporciona planes de suscripción válidos.

9.16. Migración de datos de aplicaciones

Si las implementaciones en dispositivos incluyen una capacidad para migrar datos de un dispositivo a en otro dispositivo y no limites los datos de la aplicación que copia que configura el desarrollador de la aplicación en el manifiesto a través de android:fullBackupContent el atributo de imagen, permiten hacer lo siguiente:

• [C-1-1] NO DEBE iniciar transferencias de datos de aplicación desde dispositivos en los que el usuario no configuró una autenticación principal como descritos en 9.11.1 Pantalla de Bloqueo y Autenticación.
• [C-1-2] SE DEBE confirmar de forma segura la autenticación principal en la fuente dispositivo y confirma con la intención del usuario de copiar los datos en la fuente antes de que se transfieran los datos.
• [C-1-3] DEBE usar la certificación de llave de seguridad para garantizar que tanto la fuente dispositivo y el dispositivo de destino en la migración de un dispositivo a otro se dispositivos Android legítimos y tienen un bootloader bloqueado.
• [C-1-4] Solo DEBE migrar los datos de la aplicación a la misma aplicación en el dispositivo de destino con el mismo nombre de paquete Y certificado de firma.
• [C-1-5] DEBE mostrar una indicación de que el dispositivo de origen tiene datos. que se migran con una migración de datos de un dispositivo a otro en el menú de configuración. Un usuario NO se debería poder quitar esta indicación.

9.17. Android Virtualization Framework

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework (android.system.virtualmachine.*), el host de Android hará lo siguiente:

• [C-1-1] DEBE admitir todas las APIs definidas por el android.system.virtualmachine.
• [C-1-2] NO DEBE modificar el modelo de permisos ni SELinux de Android para el administración de máquinas virtuales protegidas (pVM).

• [C-1-4] Solo se DEBE permitir el código firmado por la plataforma las aplicaciones con privilegiosNO DEBEN permite que el código no confiable (p.ej., aplicaciones de terceros) cree y ejecutar una máquina virtual protegida pVM Nota: Esto podría cambiar en versiones futuras de Android.

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

• [C-2-1] DEBE ser capaz de ejecutar todos los sistemas operativos disponibles en el APEX de virtualización en una máquina virtual protegida pVM
• [C-2-2] NO DEBE permitir una máquina virtual protegida pVM para ejecutar un sistema operativo que no esté firmado por el implementador de dispositivos ni por el proveedor del SO.
• [C-2-3] NO DEBE permitir una máquina virtual protegida pVM para ejecutar datos como código (p.ej., SELinux nuncaallow execmem).

• [C-2-5] SE DEBE implementar la Máquina virtual protegida pVM mecanismos de defensa en profundidad (p.ej., SELinux para pVMs) incluso para sistemas operativos que no son microdroid.
• [C-2-6] DEBE asegurarse de que la pVM falla el firmware se niega al inicio si no puede verificarse. no se pueden verificar las imágenes iniciales que ejecutará la VM. La verificación DEBE realizarse dentro de la VM.
• [C-2-7] DEBE asegurarse de que la pVM falla el firmware se niega al inicio si se ve comprometida la integridad de instance.img.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework (android.system.virtualmachine.*), el hipervisor hace lo siguiente:

• [C-3-1] SE DEBE asegurarse de que las páginas de memoria se que son propiedad de una VM (ya sea una pVM o una VM host) son accesibles solo para las propia o el hipervisor, no a través de otras máquinas virtuales, estén protegidas o no. NO DEBE permitir que ninguna pVM tenga acceso a una página. pertenece a otra (es decir, otra pVM o hipervisor), a menos que la página la comparta explícitamente propietario. Esto incluye la VM del host. Esto se aplica a los accesos a CPU y DMA.
• [C-3-2] SE DEBE limpiar una página luego de que la utiliza una pVM y antes de que se devuelva al host (p.ej., se destruye la pVM).
• [C-3-3SR-1] SE RECOMIENDA RECOMENDADAMENTE para garantizar SE DEBES garantizar que el firmware de la pVM se cargue y se ejecute antes de que se cargue cualquier código en una pVM.
• [C-3-4] SE DEBE asegurarse de que cada VM derive un secreto por VM que{la cadena de certificados de inicio (BCC) y el identificador de dispositivo compuesto (CDI) proporcionados a una instancia de pVM solo puedan derivarse a través de esa instancia de VM en particular y que los cambios se realicen al restablecimiento de la configuración de fábrica y de manera inalámbrica.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework, luego, en todas las áreas:

• [C-4-1] NO DEBE proporcionar funcionalidad a una pVM que permita omitir la El modelo de seguridad de Android

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework, sucede lo siguiente:

• [C-5-1] DEBE ser capaz de admitir la compilación aislada , pero puede inhabilitar la función de compilación aislada en el envío del dispositivo de una actualización del tiempo de ejecución de ART.

Si el dispositivo implementa compatibilidad con las APIs de Android Virtualization Framework, haz lo siguiente para Key Management:

• [C-SR-26-2] SE RECOMIENDA ENERGMENTE usar DICE como el mecanismo de derivación de secretos por VM. DEBE REALIZAR DICE correctamente, es decir, proporcionar los valores correctos. .

10. Pruebas de compatibilidad de software

Las implementaciones en dispositivos DEBEN superar todas las pruebas que se describen en esta sección. Sin embargo, ten en cuenta que ningún paquete de prueba de software es completamente completo. Por este motivo, se RECOMIENDA ENRENDER a los implementadores de dispositivos que hagan lo siguiente: la cantidad mínima de cambios posible a la referencia y los que se prefieran de Android disponible a partir del Proyecto de código abierto de Android. Esto minimizará el riesgo de introducir errores que creen incompatibilidades. que requieran reelaboración y posibles actualizaciones de los dispositivos.

10.1 Conjunto de pruebas de compatibilidad (CTS)

Implementaciones en dispositivos:

• [C-0-1] DEBE aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponibles en el Proyecto de código abierto de Android, con el envío software en el dispositivo.

• [C-0-2] SE DEBE garantizar la compatibilidad en casos de ambigüedad en el CTS y para cualquier o reimplementaciones de partes del código fuente de referencia.

El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, el CTS puede contener errores. El control de versiones del CTS será independiente de este una definición de compatibilidad y varias revisiones del CTS pueden publicarse Android 14.

Implementaciones en dispositivos:

• [C-0-3] DEBE aprobar la última versión disponible del CTS en el momento en que se active el software.

• SE DEBE usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible.

10.2. Verificador del CTS

El verificador del CTS está incluido con el Conjunto de pruebas de compatibilidad. está diseñado para ser ejecutado por un operador humano a fin de probar una funcionalidad que no se puede a través de un sistema automatizado, como el correcto funcionamiento de una cámara y sensores.

Implementaciones en dispositivos:

• [C-0-1] DEBE ejecutar correctamente todos los casos aplicables en el verificador del CTS.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluidos algunos hardware que es opcional.

Implementaciones en dispositivos:

• [C-0-2] DEBE superar todas las pruebas de hardware que posee. por ejemplo, Si un dispositivo posee un acelerómetro, DEBE ejecutar correctamente el Caso de prueba del acelerómetro en el verificador del CTS.

Casos de prueba de funciones que se indican como opcionales en esta definición de compatibilidad PUEDE omitirse o omitirse el documento.

• [C-0-2] Todos los dispositivos y las compilaciones DEBEN ejecutar correctamente el verificador del CTS, como se indica más arriba. Sin embargo, dado que muchas compilaciones son muy similares, no se espera que los implementadores ejecuten de manera explícita el verificador del CTS en las compilaciones que difieren solo de maneras triviales. En concreto, las implementaciones en dispositivos se diferencian de una implementación que aprobó el verificador del CTS solo por el de configuraciones regionales, marcas, etc. incluidas, PUEDE omitir la prueba del verificador del CTS.

11. Software actualizable

• [C-0-1] Las implementaciones en dispositivos DEBEN incluir un mecanismo para reemplazar el la totalidad del software del sistema. No es necesario que el mecanismo realice operaciones actualizaciones, es decir, es posible que debas reiniciar el dispositivo. Se puede utilizar cualquier método, siempre que pueda reemplazar toda la preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques cumplirá con este requisito:

  • "Conexión inalámbrica (OTA)" descargas con la actualización sin conexión mediante el reinicio.
  • "Conectado" actualizaciones mediante USB desde una PC host.
  • "Sin conexión" las actualizaciones mediante un reinicio y las actualizaciones desde un archivo en almacenamiento extraíble.

• [C-0-2] El mecanismo de actualización utilizado DEBE admitir actualizaciones sin limpiar al usuario. de datos no estructurados. Es decir, el mecanismo de actualización DEBE preservar los datos privados de la aplicación y y los datos compartidos de la aplicación. Ten en cuenta que el software upstream de Android incluye un de actualización que cumpla con este requisito.

• [C-0-3] Se DEBE firmar toda la actualización y el mecanismo de actualización integrado en el dispositivo DEBE verificar la actualización y la firma con una clave pública almacenada en el dispositivo.

• [C-SR-1] Se RECOMIENDA EL mecanismo de firma para generar un hash de la actualización. con SHA-256 y validar el hash con la clave pública mediante ECDSA NIST P-256.

Si las implementaciones en dispositivos incluyen compatibilidad con una red de datos no medidos, como el perfil 802.11 o PAN (red de área personal) de Bluetooth, luego, hacen lo siguiente:

• [C-1-1] DEBE admitir descargas OTA con actualización sin conexión a través del reinicio.

Las implementaciones en dispositivos DEBEN verificar que la imagen del sistema sea idéntica a la binaria con el resultado esperado después de una actualización inalámbrica. La OTA basada en bloques en el Proyecto de código abierto de Android ascendente, agregado desde que 5.1 cumple con este requisito.

Además, las implementaciones en dispositivos DEBEN admitir las actualizaciones del sistema A/B. AOSP implementa esta función mediante la HAL de control de inicio.

Si se encuentra un error en la implementación de un dispositivo después de haberse publicado dentro de la vida útil razonable del producto, que se determina en consulta con el equipo de compatibilidad de Android para afectar la compatibilidad aplicaciones, y luego:

• [C-2-1] El implementador de dispositivos DEBE corregir el error a través de un software actualizaciones disponibles que pueden aplicarse según el mecanismo que se acaba de describir.

Android incluye funciones que permiten que la app de Propietario del dispositivo (si está presente) la instalación de actualizaciones del sistema. Si el subsistema de actualización del sistema En el caso de dispositivos, informan android.software.device_admin. Luego, hacen lo siguiente:

• [C-3-1] SE DEBE implementar el comportamiento descrito en SystemUpdatePolicy. clase.

12. Registro de cambios del documento

Para obtener un resumen de los cambios en la definición de compatibilidad de esta versión, consulta lo siguiente:

• Registro de cambios del documento

13. Comunícate con nosotros

Puedes unirte foro de compatibilidad de Android y pedir aclaraciones o plantear problemas que no se consideran relevantes en el documento cubrir.