Definición de compatibilidad de Android (vista previa)

1. Introducción

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

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 15, 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 EXIGENTEMENTE 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 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 De 4 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

Nota: Los requisitos que no se aplican a las tablets Android están marcados con un *.

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 mide al menos 2.2" en el límite más 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.

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

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

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

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

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

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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [7.4.3/H] SE DEBE incluir compatibilidad con Bluetooth y Bluetooth de bajo consumo

Implementaciones de dispositivos portátiles que admiten Bluetooth de bajo consumo:

  • [7.4.3/H-SR-1] SE RECOMIENDA COMPLETAMENTE asistencia Extensión de la longitud del paquete de datos de Bluetooth LE.

Finaliza los nuevos requisitos

Si los dispositivos admiten el protocolo Wi-Fi 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 declaran FEATURE_BLUETOOTH_LE, hacen lo siguiente:

  • [7.4.3/H-1-3] SE DEBE medir y compensar la recepción de Rx. para garantizar que la mediana de RSSI de BLE sea de -50 dBm +/-15 dB a 1 m de distancia dispositivo de referencia transmitiendo a las ADVERTISE_TX_POWER_HIGH.
  • [7.4.3/H-1-4] DEBE medir y compensar la transacción. desfase para garantizar que la mediana de RSSI de BLE sea de -50 dBm +/-15 dB al escanearse desde un dispositivo de referencia posicionado a una distancia de 1 m y transmitiendo a una distancia ADVERTISE_TX_POWER_HIGH

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: hacen 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 incluidas en la biblioteca 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de mano incluyen un puerto USB asistencia con un controlador que funcione en modo periférico, hace lo siguiente:

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

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si Para Implementaciones en dispositivos de mano que declaren android.hardware.audio.output y android.hardware.microphone, hacen lo siguiente: Consulta los requisitos de RTL y TTL en la sección 5.6

  • [5.6/H-1-1] DEBE tener un ida y vuelta promedio continuo. una latencia de 300 milisegundos, o menos de 5 mediciones, con una desviación absoluta media menor que 30 ms, más de 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.

Finaliza los nuevos requisitos

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 una función 7.10 de uso general con un accionador de resonancia lineal:

  • [7.10/H] SE DEBE posicionar la ubicación del accionador cerca de la ubicación donde normalmente se sostiene o toca el dispositivo con las manos.

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

Si las implementaciones en dispositivos de mano tienen un 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:

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
  • [5.2/H-0-3] AV1

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
  • [5.3/H-0-6] AV1

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 RESPONSABLES RECOMMENDED para precargar una aplicación de correo electrónico que pueda procesar ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE 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 en la API de Cloud.
  • [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] SE DEBE permitir el permiso 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 hace 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 en dispositivos que incluyen la tecla de navegación de la función Recientes, como detalladas en la sección 7.2.3 modifican la interfaz, cumplen con lo siguiente:

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

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:

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.

  • [3.8.16/H-1-6] Implementaciones en dispositivos DEBE representar con precisión la asignación del usuario de la siguiente manera:

    • Si el dispositivo estableció config_supportsMultiWindow=true y la app declara los metadatos. META_DATA_PANEL_ACTIVITY en la ControlsProviderService incluida el ComponentName de un actividad válida (según lo define la API), la aplicación DEBE incorporar dicha en esta indicación visual.
    • Si la app no declara los metadatos META_DATA_PANEL_ACTIVITY, ocurrirá lo siguiente: entonces DEBE renderizar los campos especificados tal como lo proporciona el ControlsProviderService al igual que cualquier campo especificado que proporcione el Control de las APIs.
  • [3.8.16/H-1-7] Si la app declara los metadatos, haz lo siguiente: META_DATA_PANEL_ACTIVITY: DEBE pasar el valor de la configuración definida en [3.8.16/H-1-5] con EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS cuando se inicia la actividad incorporada.

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

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 copiado en el portapapeles (por ejemplo, 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:

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

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

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:

Implementaciones en dispositivos de mano:

  • [8.5/H-0-1] DEBE proporcionar Una indicación visual del usuario para ver todas las apps con servicios activos en primer plano o tareas iniciadas por el usuario, incluida la duración de cada uno de estos servicios ya que comenzó como se describe en el documento del SDK.

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

2.2.5. Modelo de seguridad

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 proporcionan un mecanismo accesible para el usuario revocar el acceso a dichas aplicaciones en respuesta a la android.settings.ACTION_USAGE_ACCESS_SETTINGS .

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Las implementaciones del dispositivo DEBEN declarar la compatibilidad con android.software.credentials y:

  • [9/H-0-2] DEBE respetar el intent android.settings.CREDENTIAL_PROVIDER. para permitir la selección de un proveedor preferido para el Administrador de credenciales. Este proveedor se habilitará para autocompletar y también será la ubicación predeterminada para guardar credenciales nuevas se ingresa a través del Administrador de credenciales.

  • [9/H-0-3] DEBE admitir al menos 2 proveedores de credenciales simultáneos. y proporciona una indicación visual de usuario en la app de Configuración para habilitar o inhabilitar proveedores.

Finaliza los nuevos requisitos

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

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

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, SHA-1 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [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 DEBEN compartirse en una cantidad lo suficientemente grande de dispositivos para evitar que se usen claves evitado se usen como recursos permanentes identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la 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 usar esa clave para cada 100,000 unidades.

Finaliza los nuevos requisitos

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 de dispositivos tienen una pantalla de bloqueo segura e incluyen uno o más agentes de confianza, que implementan la API del sistema de TrustAgentService, harán lo siguiente:

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

Si las implementaciones 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.

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

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

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 y detección de consultas siempre activa, sin micrófono ni cámara de acceso.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Configuración restringida

La configuración restringida proporciona al usuario advertencias visibles y solicita la confirmación del usuario para otorgar permisos para cada aplicación:

  • Se instala después de descargarse a través de una aplicación. (por ejemplo, una aplicación de mensajería o un navegador) que no sean una “tienda de aplicaciones” aplicación identificada por PackageManager como PACKAGE_DOWNLOADED_FILE
  • Se instala desde un archivo local. (por ejemplo, se transfirió la aplicación) identificado por PackageManager como PACKAGE_SOURCE_LOCAL_FILE

Para cualquiera de los Permisos Aplicados y sus identificadores asociados se enumeran a continuación:

  • Alarmas y recordatorios: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Acceso a todos los archivos: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Mostrar sobre otras apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Instalar apps desconocidas: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Administrar contenido multimedia: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Modificar configuración del sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Pantalla en pantalla: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Activar pantalla: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Notificaciones de pantalla completa: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • Control de Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Accesibilidad: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Objeto de escucha de notificaciones: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Acceso a datos de uso: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Administrador del dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
  • No interrumpir: Manifest.permission.MANAGE_NOTIFICATIONS

Estas aplicaciones tienen la etiqueta de “Aplicaciones Cubiertas” de los requisitos que se indican en esta sección.

Implementaciones en dispositivos:

  • [9.8/H-0-1] SE DEBE implementar la configuración restringida como se describió anteriormente para lo siguiente:

    • Permisos especiales
      • Accesibilidad (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
      • Objeto de escucha de notificaciones (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
      • Apps de administración del dispositivo (Manifest.permission.BIND_DEVICE_ADMIN)
      • Mostrar sobre otras apps (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
      • Acceso a datos de uso (AppOpsManager.OPSTR_GET_USAGE_STATS)
    • Roles (apps predeterminadas)
      • Teléfono (RoleManager.ROLE_DIALER)
      • SMS (RoleManager.ROLE_SMS)
    • Permisos de tiempo de ejecución
      • Tiempo de ejecución de SMS (Manifest.permission_group.SMS)
  • [9.8/H-0-2] SE DEBE habilitar la configuración restringida como predeterminada y se SE RECOMIENDA no tener ninguna indicación visual, lo que le permita a un usuario para inhabilitar la configuración restringida en todas las apps.

  • [9.8/H-0-3] SE DEBE asegurarse de que se obtenga la confirmación del usuario para cada Aplicación cubierta antes de que se pueda otorgar cualquiera de los Permisos aplicados.

  • [9.8/H-0-4] Solo DEBE permitir la confirmación del usuario para habilitar la configuración restringida. que se debe obtener de la página AppInfo de la Aplicación cubierta con la API de EnhancedConfirmationManager.

  • [9.8/H-0-5] SE RECOMIENDA IMPORTANTEMENTE integrarse y llamar EnhancedConfirmationManager para todos los permisos especiales, para determinar de forma dinámica si se trata de un parámetro de configuración restringido.

    • Alarmas y recordatorios: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • Acceso a todos los archivos: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
    • Mostrar sobre otras apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
    • Instalar apps desconocidas: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
    • Administrar contenido multimedia: AppOpsManager.OPSTR_MANAGE_MEDIA
    • Modificar configuración del sistema: AppOpsManager.OPSTR_WRITE_SETTINGS
    • Pantalla en pantalla: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
    • Activar pantalla: AppOpsManager.OPSTR_TURN_SCREEN_ON
    • Notificaciones de pantalla completa: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
    • Control de Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
    • Accesibilidad: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
    • Objeto de escucha de notificaciones: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
    • Acceso a datos de uso: AppOpsManager.OPSTR_GET_USAGE_STATS
    • Administrador del dispositivo: Manifest.permission.BIND_DEVICE_ADMIN
    • No interrumpir: Manifest.permission.MANAGE_NOTIFICATIONS

Finaliza los nuevos requisitos

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 el 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 (excluye las reproducciones de audio) transmitirse fuera del servicio de detección de palabras clave en cada resultado de palabra clave.
  • [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-1-15] SE DEBE asegurarse de que las transmisiones de audio proporcionadas en la palabra clave exitosa los resultados se transmiten unidireccionalmente desde el servicio de detección de palabras clave al servicio de interacción por voz.

  • [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 eventos de activación de hardware, lo que ocurra primero.

Si las implementaciones de dispositivos incluyen una aplicación que usa la API del sistema HotwordDetectionService o un mecanismo similar para la detección de palabras clave sin 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 admiten la API del sistema VisualQueryDetectionService o algún otro mecanismo para la detección de consultas sin una indicación de acceso a la cámara o al micrófono:

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

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.
  • [9.8.2/H-4-3] 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.
  • [9.8.2/H-4-4] SE DEBE mostrar la lista de Recientes y Activos. apps que usan el micrófono como se muestra en PermissionManager.getIndicatorAppOpUsageData(), junto con los mensajes de atribución 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.
  • [9.8.2/H-5-3] 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si las implementaciones en dispositivos admiten la función, sucederá lo siguiente:

  • [9.10/H-1-1] SE DEBE verificar todas las particiones de solo lectura. se activa durante la secuencia de inicio de Android, y el resumen de VBMeta incluye todas estas particiones verificadas en su cálculo.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Implementaciones en dispositivos de mano (* no aplicable a 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 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]* 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).

Finaliza los nuevos requisitos

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.U. para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Finaliza los nuevos requisitos

  • [5.1/H-1-1] SE DEBE anunciar la cantidad máxima de decodificadores de video de hardware. sesiones que se pueden ejecutar simultáneamente en cualquier combinación de códecs a través del CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints().

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-2] DEBE admitir 6 instancias de decodificador de video de hardware de 8 bits (SDR). sesiones (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs en ejecución De forma simultánea, 3 sesiones a una resolución de 1080p a 30 fps y 3 sesiones a 4K de resolución a 30 fps, a menos que sea AV1. En todas las sesiones, NO DEBE haber más de 1 fotograma por segundo. Los códecs de AV1 solo se requieren para admitir una resolución de 1080p, pero de todos modos son compatibles con 6 instancias a 1080p30 FPS.

Finaliza los nuevos requisitos

  • [5.1/H-1-3] SE DEBE anunciar la cantidad máxima de codificadores de video de hardware. sesiones que se pueden ejecutar simultáneamente en cualquier combinación de códecs a través del CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints().

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-4] DEBE admitir 6 instancias de codificador de video de hardware de 8 bits (SDR). sesiones (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs en ejecución De forma simultánea, 4 sesiones a una resolución de 1080p a 30 fps y 2 sesiones a 4K de resolución a 30 fps, a menos que sea AV1. En todas las sesiones, NO DEBE haber más de 1 fotograma por segundo. Los códecs AV1 solo se requieren para admitir una resolución de 1080p, pero aún necesario para admitir 6 instancias a 1080p30 fps.

Finaliza los nuevos requisitos

  • [5.1/H-1-5] DEBE anunciar la cantidad máxima de codificador de video de hardware y de codificador-decodificador que se pueden ejecutar simultáneamente en cualquier combinación de códecs a través del CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints().

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-6] DEBE admitir 6 instancias de decodificador de video de hardware de 8 bits (SDR). y sesiones de codificador de video de hardware (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs que se ejecutan simultáneamente con 3 sesiones a 4K a 30 fps (a menos que sea AV1), de las cuales 2, como máximo, son sesiones de codificador y 3 sesiones con resolución de 1080p. En todas las sesiones, NO DEBE haber más de 1 fotograma por segundo. Los códecs AV1 solo se requieren para admitir una resolución de 1080p, pero aún necesario para admitir 6 instancias a 1080p30 fps.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-19] DEBE admitir 3 instancias de decodificador de video de hardware de 10 bits (HDR). y sesiones de codificador de video de hardware (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códec que se ejecuta simultáneamente a una resolución de 4K a 30 fps (salvo AV1) de los cuales, como máximo, 1 es una sesión de codificador, que podría configurarse en RGBA_1010102 a través de una superficie GL. Para todas las sesiones, NO DEBE haber más de 1 fotograma descartado por por segundo. Generación de metadatos de HDR por parte del codificador no es necesario si se codifica desde la superficie de GL. Las sesiones de códecs AV1 solo se requiere para admitir una resolución de 1080p, incluso cuando este requisito requiere para 4K.

Finaliza los nuevos requisitos

  • [5.1/H-1-7] DEBE tener una latencia de inicialización de códec de 40 ms o menos para un Sesión de codificación de video de 1080p o menor para todos los codificadores de video de hardware cuando bajo carga. La carga aquí se define como una resolución simultánea de solo video de 1080p a 720p de transcodificación con códecs de video de hardware y la resolución de 1080p inicialización de la grabación de audio y video. Para el códec de Dolby Vision, el códec la latencia de inicialización DEBE ser de 50 ms o menos.
  • [5.1/H-1-8] DEBE tener una latencia de inicialización de códec de 30 ms o menos para un Sesión de codificación de audio de 128 Kbps o menor para todos los codificadores de audio cuando bajo carga. La carga aquí se define como una resolución simultánea de solo video de 1080p a 720p de transcodificación con códecs de video de hardware y la resolución de 1080p inicialización de la grabación de audio y video.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-9] DEBE admitir 2 instancias de decodificador de video de hardware seguro sesiones (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs en ejecución a una resolución de 4K a 30 fps al mismo tiempo (a menos que sea AV1) para 8 bits (SDR) y Contenido HDR de 10 bits. En todas las sesiones, NO DEBE haber más de 1 fotograma por segundo. Las sesiones de códecs AV1 solo se requieren para admitir una resolución de 1080p incluso cuando este requisito requiere 4K.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-10] DEBE admitir 3 instancias de decodificador de video de hardware no seguro. sesiones junto con 1 instancia de sesión de decodificador de video de hardware seguro (4 instancias en total) (AVC, HEVC, VP9, AV1 o posteriores) en cualquier combinación de códecs Se ejecuta simultáneamente con 3 sesiones a una resolución 4K a 30 fps (salvo AV1). que incluye una sesión de decodificador segura y 1 sesión de nn-secure a 1080p resolución a 30 FPS, en la que un máximo de 2 sesiones pueden estar en HDR de 10 bits. En todas las sesiones, NO DEBE haber más de 1 fotograma por segundo. Las sesiones de códecs AV1 solo se requieren para admitir una resolución de 1080p incluso cuando este requisito requiere 4K.

Finaliza los nuevos requisitos

  • [5.1/H-1-11] DEBE admitir un decodificador seguro para cada AVC de hardware, HEVC, un decodificador VP9 o AV1 en el dispositivo.
  • [5.1/H-1-12] DEBE tener una latencia de inicialización de códec de 40 ms o menos durante un Sesión de decodificación de video de 1080p o menor para todos los decodificadores de video por hardware cuando están bajo carga. La carga aquí se define como una resolución simultánea de 1080p a 720p sesión de transcodificación de solo video con códecs de video de hardware junto con el Inicialización de la reproducción de audio y video en 1080p Para el códec de Dolby Vision, el códec la latencia de inicialización DEBE ser de 50 ms o menos.
  • [5.1/H-1-13] DEBE tener una latencia de inicialización de códec de 30 ms o menos para un Sesión de decodificación de audio de 128 Kbps o menor para todos los decodificadores de audio cuando bajo carga. La carga aquí se define como una resolución simultánea de solo video de 1080p a 720p de transcodificación con códecs de video de hardware y la resolución de 1080p inicialización de la reproducción de audio y video.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-14] DEBE ser compatible con el decodificador de hardware de AV1 principal 10, nivel 4.1. y grano de película con efecto de grano de película sobre la composición de la GPU.

Finaliza los nuevos requisitos

  • [5.1/H-1-15] DEBE tener al menos 1 decodificador de video por hardware compatible con 4K60.
  • [5.1/H-1-16] DEBE tener al menos 1 codificador de video de hardware compatible con 4K60.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-21] DEBE admitir FEATURE_DynamicColorAspect para todos los videos de hardware. decodificadores (AVC, HEVC, VP9, AV1 o posteriores). Nota: Esto significa que las aplicaciones pueden actualizar los aspectos de color del contenido de video durante la sesión de decodificación Los decodificadores que admiten contenido de 10 y 8 bits DEBEN ser compatibles de forma dinámica para cambiar entre contenido de 8 y 10 bits en modo superficie. Decodificadores compatibles La función de transferencia de HDR DEBE admitir el cambio dinámico entre SDR y HDR contenido.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-22] DEBE ser compatible con la codificación, la decodificación, la edición de GPU y la visualización de video. contenido en relación de aspecto vertical independientemente de los metadatos de rotación del resolución compatible de cámara más grande o 4K, lo que sea menor. Nota: Este incluye perfiles HDR si el códec admite HDR. Los códecs de AV1 solo se requieren para admite una resolución de 1080p. Este requisito es solo para códecs de hardware, GPU y la DPU.

Finaliza los nuevos requisitos

  • [5.3/H-1-1] NO DEBE reducir más de 1 fotograma en 10 segundos (es decir, menos de 0.167% de caída de fotogramas) para una sesión de video en 4K a 60 fps con carga.
  • [5.3/H-1-2] NO DEBE reducir más de 1 fotograma en 10 segundos durante un video. Cambio de resolución en una sesión de video de 60 FPS bajo carga para una sesión en 4K
  • [5.6/H-1-1] DEBE tener una latencia de toque a tono de 80 milisegundos o menos con la prueba de toque a tono del verificador del CTS.
  • [5.6/H-1-2] DEBE tener una latencia de audio de ida y vuelta de 80 milisegundos o menos en al menos una ruta de datos admitida.
  • [5.6/H-1-3] DEBE admitir audio de 24 bits o más para salida estéreo de más de 3.5 mm de audio a través de conectores de audio, si están presentes, y a través de audio USB si es compatible con todos los datos para configuraciones de transmisión y latencia baja. Para la latencia baja predeterminada, la app debe usar AAudio en la devolución de llamada de baja latencia . Para la configuración de transmisión, se debe usar Java AudioTrack la aplicación. En las configuraciones de transmisión y latencia baja, la HAL el receptor de salida debe aceptar AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT o AUDIO_FORMAT_PCM_FLOAT para el formato de salida objetivo.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.6/H-1-4] DEBE admitir dispositivos de audio USB de más o menos de 4 canales. (Los controladores de DJ usan esta opción para obtener vistas previas de las canciones).

Finaliza los nuevos requisitos

  • [5.6/H-1-5] DEBE admitir dispositivos MIDI compatibles con la clase y declarar marca de función MIDI.
  • [5.6/H-1-9] DEBE admitir una combinación de al menos 12 canales. Esto implica que para abrir un audioTrack con una máscara de canal 7.1.4 y permite espacializar o mezclar todos los canales en estéreo.
  • [5.6/H-SR] SE RECOMIENDA COMPLETAMENTE admitir la combinación de 24 canales con compatibilidad mínima con las máscaras de canal 9.1.6 y 22.2.
  • [5.7/H-1-2] DEBE admitir MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL con el debajo de las capacidades de desencriptación de contenido.
Tamaño mínimo de la muestra 4 MiB
Cantidad mínima de submuestras: H264 o HEVC 32
Cantidad mínima de submuestras: VP9 9
Cantidad mínima de submuestras: AV1 288
Tamaño mínimo del búfer de la submuestra 1 MiB
Tamaño mínimo de búfer criptográfico genérico 500 KiB
Cantidad mínima de sesiones simultáneas 30
Cantidad mínima de claves por sesión 20
Cantidad total mínima de claves (todas las sesiones) 80
Número total mínimo de claves DRM (todas sesiones) 6
Tamaño del mensaje 16 KiB
Fotogramas desencriptados por segundo 60 FPS
  • [5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes de hardware compatible con AVIF Perfil de Baseline.
  • [5.1/H-1-18] DEBE ser compatible con el codificador AV1 que puede codificar hasta 480p de resolución a 30 fps y 1 Mbps.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [5.1/H-1-20] DEBE admitir Feature_HdrEditing para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo en 4K o la resolución más grande compatible con la cámara, lo que sea menor.

Finaliza los nuevos requisitos

  • [5.12/H-SR] Se recomiendan especialmente para respaldar la Feature_HdrEditing para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
  • [5.12/H-1-2] DEBE admitir el formato de color RGBA_1010102 para todos los hardware AV1 y codificadores HEVC presentes en el dispositivo.
  • [5.12/H-1-3] DEBE anunciar la compatibilidad con la extensión EXT_YUV_target a de texturas YUV, tanto en 8 y 10 bits.
  • [7.1.4/H-1-1] DEBE tener al menos 6 superposiciones de hardware en el procesamiento de Display. (DPU), con al menos 2 de ellas capaces de mostrar contenido de video de 10 bits.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS e incluyen con un codificador AVC o HEVC de hardware:

Finaliza los nuevos requisitos

2.2.7.2. Cámara

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [7.5/H-1-1] DEBE tener una cámara posterior principal con una resolución de al menos 12 megapíxeles que admita la captura de video con 4k a 30 fps, 1080p a 60 fps y 720p a 60 fps La cámara posterior principal es la cámara posterior con el ID de cámara más bajo.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [7.5/H-1-18] DEBE admitir JPEG_R para la parte posterior principal y cámaras frontales principales.
  • [7.5/H-1-19] DEBE admitir CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION para HLG10 de 1080p vista previa con tamaño máximo de JPEG con relación de aspecto de 16:9 y vista previa de 720p HLG10 con combinaciones de transmisión JPEG de tamaño máximo de 16:9 para el principal y la cámara posterior.
  • [7.5/H-1-20] DEBE generar JPEG_R de forma predeterminada para la instancia principal. Cámara frontal principal y posterior en la app nativa de la cámara

Finaliza los nuevos requisitos

2.2.7.3 Hardware

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.U durante android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Finaliza los nuevos requisitos

  • [7.1.1.1/H-2-1] DEBE tener una resolución de pantalla de al menos 1080p.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [7.1.1.3/H-2-1] DEBE tener una densidad de pantalla de al menos 400 dpi si el ancho de la pantalla del dispositivo es < 600 dp

Finaliza los nuevos requisitos

  • [7.1.1.3/H-3-1] DEBE tener una pantalla HDR que admita al menos 1,000 nits. promedio.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Finaliza los nuevos requisitos

2.2.7.4. Rendimiento

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.U durante android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de mano devuelven android.os.Build.VERSION_CODES.V para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

2.2.7.5 Gráficos

Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.V. para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, hizo lo siguiente:

Finaliza los nuevos requisitos

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, y/o TV en vivo para usuarios que están sentados a unos tres metros de distancia (una 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, hacen 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 en implementaciones de dispositivos.

Implementaciones de dispositivos de televisión:

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

2.3.2. Multimedia

Las implementaciones de dispositivos de televisión DEBEN admitir 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
  • [5.2/T-0-3] AV1

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:

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] SE DEBE configurar el modo de salida HDMI en el resolución más alta para el formato de píxeles elegido que funcione con 50 Hz o 60 Hz frecuencia de actualización de la pantalla externa, según la frecuencia de actualización del video para la región en la que se vende el dispositivo.
  • [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 MUY BIEN 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Implementaciones de dispositivos de televisión:

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

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

El framework de entrada de televisión de Android (TIF) simplifica el la entrega de contenido en vivo a dispositivos Android Television. El TIF proporciona un API para crear módulos de entrada que controlen dispositivos de Android Television.

Implementaciones de dispositivos de televisión:

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

El framework de Android Television Tuner (TF) unifica el manejo de contenido en vivo desde Tuner con la transmisión de contenido desde IP en dispositivos Android Television. El framework de Turner proporciona una API estándar para crear servicios de entrada que usen Android Television Tuner.

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

  • [3/T-1-1] DEBE ser compatible con todas las APIs de Tuner Framework de modo que un que usa estas APIs se puede instalar y usar en el dispositivo.

Finaliza los nuevos requisitos

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:

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, SHA-1 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [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 DEBEN compartirse en una cantidad lo suficientemente grande de dispositivos para evitar que se usen claves evitado se usen como recursos permanentes identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la 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 usar esa clave para cada 100,000 unidades.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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.
    • [6.1/T-0-5] El daemon rastreado de perfetto DEBE estar habilitada de forma predeterminada (propiedad del sistema persist.traced.enable).

Finaliza los nuevos requisitos

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 en dispositivos de reloj incluyen compatibilidad con Vulkan, ocurrirá lo siguiente:

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, hacen 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] SE 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.

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

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

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), hacen lo siguiente:

  • [7.1.1.1/A-1-1] DEBE tener una pantalla independiente de de, al menos, 6 pulgadas de diámetro físico para cada zona de ocupación para la pantalla principal. Esto debe etiquetarse como CarOccupantZoneManager.DISPLAY_TYPE_MAIN para cada zona de ocupación.
  • [7.1.1.1/A-1-2] DEBE tener un diseño de tamaño de pantalla. de, al menos, 750 dp x 480 dp para cada pantalla principal.

Finaliza los nuevos requisitos

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

Implementaciones en dispositivos de Automotive:

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [7.2.3/A-0-1] DEBE proporcionar la Página principal y las funciones Atrás y PUEDE proporcionar Atrás y el Función recientes.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), hacen lo siguiente:

  • [7.3/A-1-1] DEBE establecer la NIGHT_MODE marcan el valor de forma coherente con el modo diurno/nocturno del panel todas las pantallas, incluidas las del asiento trasero.

Finaliza los nuevos requisitos

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 dps 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 de dispositivos Automotive incluyen un giroscopio con menos de 3 ejes, sucederá lo siguiente:

  • [7.3.4/A-4-1] SE DEBE implementar y, luego, informar 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, usando 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)

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [7.4.3/A-SR-1] SE RECOMIENDA EXCELENTEMENTE que brinden asistencia Perfil de acceso a mensajes (MAP) si el dispositivo tiene la zona de ocupación del conductor.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), hacen lo siguiente:

  • [7.4.3/A-1-1] DEBE ser independiente y NO interferir. con la de otros usuarios experiencia Bluetooth.

Finaliza los nuevos requisitos

Implementaciones en dispositivos de Automotive:

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

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

  • [7.4/A-1-1] SE DEBE declarar la compatibilidad con FEATURE_BROADCAST_RADIO.

Una cámara posterior significa una cámara orientada al mundo que puede ubicarse en cualquier sobre el vehículo y que mire hacia el exterior de su cabina. es decir, imágenes en el costado más lejano de la carrocería del vehículo, como la cámara posterior.

Una cámara frontal significa una cámara orientada al usuario que puede ubicarse en cualquier colocarse sobre el vehículo y que esté orientado hacia el interior de su cabina; eso es todo imágenes al usuario, como para videoconferencias y aplicaciones similares.

Implementaciones en dispositivos de Automotive:

  • [7.5/A-SR-1] SE RECOMIENDA MUY BIEN incluir una o más plataformas cámaras.
  • PUEDE incluir una o más cámaras para el usuario.
  • [7.5/A-SR-2] SE RECOMIENDA EXIGENTEMENTE para admitir transmisiones simultáneas de varias cámaras.

Si las implementaciones en dispositivos de Automotive incluyen al menos una cámara que tiene mirando al mundo entonces, para una cámara de este tipo, deben:

  • [7.5/A-1-1] SE DEBE orientar para que la dimensión larga de la cámara se alinee. con el plano X-Y de los ejes de sensores de la industria automotriz de Android.
  • [7.5/A-SR-3] SE RECOMIENDA ES IMPORTANTE que tengan un enfoque fijo o EDOF. (Profundidad de campo extendida).
  • [7.5/A-1-2] DEBE tener la cámara enfocada en el mundo principal. cámara con el ID de cámara más bajo.

Si las implementaciones en dispositivos de Automotive incluyen al menos una cámara que tiene para el usuario, para este tipo de cámara:

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

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

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

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

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

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

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

Si las implementaciones en dispositivos de Automotive incluyen una o más cámaras que no se puede acceder a través de Extended View System Service y android.hardware.Camera o la API de android.hardware.Camera2, para esa cámara, deben hacer lo siguiente:

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

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

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

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 (/data partición).

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), hacen lo siguiente:

  • [7.6.1/A-1-1] DEBE tener, en una sola instancia AAOS, al menos 4 GB por cada usuario simultáneo de Android de almacenamiento no volátil Está disponible para los datos privados de la aplicación (partición /data).

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

    • 280 dpi o menos en pantallas pequeñas o normales
    • ldpi o inferior en pantallas extragrandes
    • mdpi o inferior en pantallas grandes
  • [7.6.1/A-2-2] La memoria disponible para el kernel y el espacio del usuario DEBE ser de, al menos, 944 MB. por pantalla principal si se usa alguna de las siguientes densidades:

    • xhdpi o superior en pantallas pequeñas o normales
    • hdpi o más alta en pantallas grandes
    • mdpi o superior en pantallas extragrandes
  • [7.6.1/A-2-3] La memoria disponible para el kernel y el espacio del usuario DEBE tener al menos 1,280 MB. por pantalla principal si se usa alguna de las siguientes densidades:

    • 400 dpi o más en pantallas pequeñas o normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extragrandes
  • [7.6.1/A-2-4] La memoria disponible para el kernel y el espacio de usuario DEBE tener al menos 1,824 MB. por pantalla principal si se usa alguna de las siguientes densidades:

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

Ten en cuenta que la “memoria disponible para el kernel y el espacio 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 incluidas en la biblioteca en implementaciones del dispositivo.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), hacen lo siguiente:

  • [7.8.2/A-1-1] DEBE tener un dispositivo de salida de audio para cada para varios sistemas de usuario simultáneos.
  • [7.8.2/A-1-2] DEBE tener una zona de audio del controlador que cubra bocina de cabina global. La zona de pasajeros delantero puede compartir el audio del conductor. o puede tener su propia salida de audio.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitado), hacen lo siguiente:

  • [5.5.3/A-1-1] DEBE definir curvas de volumen idénticas para Todas las transmisiones de salida de audio asignadas al mismo grupo de volúmenes como se define en archivo de configuración del audio del auto.

Finaliza los nuevos requisitos

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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Si las implementaciones de dispositivos de Automotive admiten multiusuarios simultáneos (donde varios usuarios de Android pueden interactuar con el dispositivo al mismo tiempo, cada uno usando su propia pantalla cuando config_multiuserVisibleBackgroundUsers está habilitada), para los usuarios secundarios completos que no son el usuario actual en primer plano pero tienen acceso de IU a la pantalla, hacen lo siguiente:

Finaliza los nuevos requisitos

Implementaciones en dispositivos de Automotive:

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

Implementaciones en dispositivos de Automotive:

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

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:

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

  • [9.8.2/A-1-1] SE DEBE mostrar el indicador del micrófono cuando accede a datos de audio desde el micrófono, pero no cuando solo pueden acceder al micrófono HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o aplicaciones que tienen los roles que se mencionaron en artículo 9.1 con el identificador de CDD [C-4-X].
  • [9.8.2/A-1-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.
  • [9.8.2/A-1-3] DEBE proporcionar una indicación visual del usuario para activar o desactivar la el micrófono en la app de Configuración.

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 aplicaciones que tienen los roles, tal como se define en Sección 9.1 Permisos con el identificador de CDD [C-4-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.
  • [9.8.2/A-2-3] DEBE proporcionar una indicación visual del usuario para activar o desactivar la cámara en la app de Configuración.
  • [9.8.2/A-2-4] SE DEBEN mostrar apps recientes y activas usando la cámara como se muestra. desde PermissionManager.getIndicatorAppOpUsageData(), junto con cualquier mensajes de atribución asociados.

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, SHA-1 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [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 DEBEN compartirse en una cantidad lo suficientemente grande de dispositivos para evitar que se usen claves evitado se usen como recursos permanentes identificadores de dispositivos. Una forma de cumplir con este requisito es compartir la 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 usar esa clave para cada 100,000 unidades.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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.
    • [6.1/A-0-5] El daemon rastreado de perfetto DEBE estar habilitada de forma predeterminada (propiedad del sistema persist.traced.enable).

Finaliza los nuevos requisitos

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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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.

Finaliza los nuevos requisitos

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 de cualquier API documentada expuesta por el SDK de Android o cualquier API decorada con la "@SystemApi" en el flujo de trabajo 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

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 haya 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 interfaz de software 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 versiones, 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 15.
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 15, este campo DEBE tener el valor entero 15_INT.
VERSION.SDK&lowbar;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 15, este campo DEBE tener el valor entero 15&lowbar;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 la 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&lowbar; 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.
Compatibilidad&lowbar;32&lowbar;BIT&lowbar;ABIS 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&lowbar;64&lowbar;BIT&lowbar; 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 la barra&low 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 la CPU&lowbar; 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:15/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 la 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.
SOC&lowbar;MANUFACTURER 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 comenzar 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&lowbar;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 terminar 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&lowbar;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 debe coincidir con la expresión regular ^[a-zA-Z0-9._-]+ y DEBE tienen uno de los valores correspondientes a las tres funciones 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 ("").
SEGURIDAD&lowbar;PATCH 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&lowbar;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 la 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, que las aplicaciones de terceros anularán. 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 "Selector" usuario 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:

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

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

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

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:

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:

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

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

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

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

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

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:

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:

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.

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

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() en la API de Cloud.
  • [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() en la API de Cloud.
  • 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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

  • [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 núcleo. 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 mediante 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 15 para la implementación de la android.webkit.WebView en la API de Cloud.
  • [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:
  • [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. 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:

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

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 proporcionadas mediante las APIs de insignias de notificación que se describen en el SDK como Notification.Builder.setNumber() y la Notification.Builder.setBadgeIconType() en la API de Cloud.

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:

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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

3.8.3.4. Protección de notificaciones sensibles

La información sensible de las notificaciones incluye contenido como contraseñas de un solo uso, códigos de confirmación únicos y códigos de restablecimiento o autenticación similares que pueden aparecer en notificaciones para los usuarios.

Si las implementaciones en los dispositivos permiten que las apps de terceros notificar a los usuarios sobre eventos importantes hace lo siguiente:

  • [C-1-1] DEBE ocultar la información confidencial de notificaciones para que no se transmita a objetos de escucha de notificaciones, a menos que el servicio de escucha sea uno de los siguientes:

    • Apps firmadas por el sistema con un uid < 10,000
    • IU del sistema
    • Una caracola
    • Aplicación de dispositivo complementaria designada (definida por CompanionDeviceManager)
    • Rol SYSTEM_AUTOMOTIVE_PROJECTION
    • Rol SYSTEM_NOTIFICATION_INTELLIGENCE
    • Rol de HOME

La implementación de AOSP de NotificationAssistantServices ejemplifica y cumple estos requisitos. Consulta android.ext.services.notification para ver un ejemplo.

Finaliza los nuevos requisitos

3.8.4. APIs 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, puede ser 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 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 un "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] DEBE admitir el “Material”. de la familia de temas y NO DEBEN alterar 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 sección "Predeterminado del dispositivo" de la familia de temas 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.

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

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 emojis familiares diversos, 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 en 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() en la API de Cloud.
  • [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() en la API de Cloud.
  • [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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones en dispositivos incluyen más de un software compatible mostrar áreas y ponerlas a disposición de las aplicaciones, hacen lo siguiente:

  • [C-4-1] DEBE admitir el modo multiventana.

Si las implementaciones de dispositivos admiten modos multiventana, harán lo siguiente:

  • [C-5-1] DEBE implementar la versión correcta de las extensiones del administrador de ventanas nivel de API, como se describe en Extensiones de WindowManager.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Android incluye funciones que permiten reconocer la seguridad aplicaciones habilitan aplicaciones del controlador de política de dispositivo 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 APIs de Device Policy Manager.

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.

Finaliza los nuevos requisitos

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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

3.9.1.2. Aprovisionamiento de perfiles administrados

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

  • [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.
  • [C-1-10] SE DEBE asegurarse de que los datos de la captura de pantalla estén guardados en el perfil de trabajo. cuando se toma una captura de pantalla con una topActivity Ventana que tiene enfoque (el último con el que interactuó el usuario entre todas las actividades) y pertenece una app de perfil de trabajo
  • [C-1-11] NO DEBE capturar otro contenido en pantalla (barra del sistema, notificaciones o cualquier contenido del perfil personal), excepto por el perfil de trabajo ventanas/ventanas de aplicaciones al guardar una captura de pantalla en el perfil de trabajo (para garantizar que el los datos del perfil no se guardan en el perfil de trabajo).

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

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.9.5 Marco de trabajo de resolución de políticas de dispositivos

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

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

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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

3.12. Framework de entrada de TV

El framework de entrada de televisión (TIF) de Android simplifica el la entrega de contenido en vivo a dispositivos Android Television. El TIF proporciona un API para crear módulos de entrada que controlen 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.

Finaliza los nuevos requisitos

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. 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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-3] DEBE proporcionar las indicaciones visuales del usuario para que seleccione o confirme un de que el dispositivo complementario esté presente y esté en funcionamiento, que DEBEN usar el mismo mensaje que se implementó en AOSP sin agregar ni modificación.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

3.19. Configuración del idioma

Implementaciones en dispositivos:

  • [C-0-1] NO DEBE proporcionar ninguna indicación visual para seleccionar un género específico tratamiento lingüístico para idiomas que no son compatibles con un género específico traducciones. Consulta los recursos gramaticales. para obtener más información.

Finaliza los nuevos requisitos

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 en la API de Cloud.

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 en la API de Cloud.

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
  • [C-0-4] AVIF
    • Los dispositivos deben admitir BITRATE_MODE_CQ y el perfil de Baseline.

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) y 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: hacen 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.
VP9 Consulta la sección 5.3 para obtener más información.
AV1 Consulta los artículos 5.2 y 5.3 para obtener más detalles
  • MPEG-4 (.mp4)
  • Matroska (.mkv, solo 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 incluye compatibilidad con 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 en la API de Cloud.

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 de dispositivos admiten cualquier codificador de video y lo ponen a disposición en apps de terceros y configura el
MediaFormat.KEY_BITRATE_MODE a BITRATE_MODE_VBR para que el codificador opere en el modo de tasa de bits variable y, luego, siempre y cuando no afecte el precio mínimo de calidad. la tasa de bits codificada :

  • NO DEBERÍA eso, más de una ventana variable, más del 15% sobre la tasa de bits entre intraframe (I-frame) en intervalos de tiempo.
  • NO DEBEN ser más de 100% sobre la tasa de bits en una ventana deslizante de 1 segundo.

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

  • [C-SR-2] SE RECOMIENDA ENERGMENTE a NO superará el 15% de la tasa de bits objetivo en una ventana variable de 1 segundo.

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) con el perfil de Baseline nivel 45. La resolución SQCIF es opcional.

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] DEBE admitir el perfil principal de nivel 3 hasta el Resolución de 512 x 512
  • [C-SR-1] SE RECOMIENDA ENERGMENTE para respaldar el el perfil SD de 720 x 480 y las 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.2.6. AV1

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

  • [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.
  • [C-1-2] SE DEBE publicar los datos de rendimiento (es decir, informar los datos de rendimiento a través del getSupportedFrameRatesFor() o getSupportedPerformancePoints() APIs para las resoluciones compatibles en la siguiente tabla.

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

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

  • [C-2-1] DEBE admitir un perfil de codificación HD1080p inclusive desde el a continuación:
SD HD: 720p HD: 1080 p UHD
Resolución de video 720 × 480 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps
Tasa de bits del video 5 Mbps 8 Mbps 16 Mbps 50 Mbps

5.3 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 y 384 Kbps) y el nivel 45 (QCIF y resoluciones SQCIF a 30 fps y 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 del HDR necesario 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, sucederá 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: hace lo siguiente:

  • [C-1-1] DEBE incluir un extractor compatible con Dolby Vision.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-2] DEBE mostrar correctamente el contenido de Dolby Vision. cualquiera en el dispositivo o en una pantalla externa conectada a través de un puerto de salida de video estándar (p.ej., HDMI).

Finaliza los nuevos requisitos

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

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

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

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

  • [C-2-1] SE DEBE poder decodificar al menos perfiles de decodificación de video HD 720p desde la siguiente tabla cuando la altura informada por Display.getSupportedModes() es igual o superior a 720p.
  • [C-2-2] SE DEBE poder decodificar al menos perfiles de decodificación de video HD de 1080p. de la tabla que aparece a continuación cuando la altura informada por Display.getSupportedModes() es igual o superior a 1080p.
SD HD: 720p HD: 1080 p UHD
Resolución de video 720 × 480 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps
Tasa de bits del video 5 Mbps 8 Mbps 16 Mbps 50 Mbps

Si las implementaciones de dispositivos admiten el perfil HDR a través de las APIs de contenido multimedia, entonces hace lo siguiente:

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

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

  • 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 mayor que 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 junto al 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:

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-4] DEBE admitir efectos de audio con de punto flotante, cuando el efecto los resultados se devuelven a la canalización de audio del framework. Esto se refiere a insert o efectos auxiliares, como el ecualizador. El comportamiento equivalente es muy Se recomienda cuando el audio del framework no puede ver los resultados del efecto. canalización (como efectos posteriores al procesamiento o descargada).

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-5] DEBEN asegurarse de que los efectos de audio admitan varios canales de hasta el recuento de canales del mezclador, también conocido como FCC_LIMIT, Cuando los resultados del efecto se devuelven a la canalización de audio del framework. Esta hace referencia a los típicos efectos de inserción o auxiliar, pero excluye los efectos especiales como como los efectos de mezclar descendente, upmix y espacialización que cambian el recuento de canales. Se recomienda un comportamiento equivalente cuando los efectos no son visibles para el de audio de framework, como procesamiento posterior o descarga efectos).

Finaliza los nuevos requisitos

  • 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 (MAD): Es el promedio del valor absoluto de la desviaciones de la media para un conjunto de valores.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • La latencia de tocar para tono (TTL), según la medición del verificador del CTS, es la hora entre el momento en que se presiona la pantalla y el momento en que se genera un tono como resultado de eso se escucha en la bocina. Esto se promedia sobre 5 mediciones usando el API de audio nativo de AAudio para salida.

  • La latencia de ida y vuelta (RTL), según la medición del verificador del CTS, es la media Latencia continua en más de 5 mediciones, medida en una ruta de bucle invertido que envía la salida a la entrada con la API de audio nativa de AAudio. Las rutas de bucle invertido son las siguientes:

    • Bocina/micrófono: Bocina integrada a micrófono integrado.
    • Analógico: conector analógico de 3.5 mm y adaptador de bucle invertido.
    • USB: adaptador USB a 3.5 mm y un adaptador de bucle invertido o un dispositivo de audio USB. y de bucle invertido.
  • FEATURE_AUDIO_PRO. La función android.hardware.audio.pro es declarado.

  • MPC Clase de rendimiento del contenido multimedia

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • latencia de seguimiento de cabeza. La hora toma del movimiento de la cabeza capturado por la unidad de medición inercial (IMU). a los transductores de auriculares detección del cambio en el sonido causado por este movimiento.

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-4] Latencias de ida y vuelta calculadas en función de la entrada y el resultado Las marcas de tiempo que devuelve AAudioStream_getTimestamp DEBEN tener un máximo de 200 ms la latencia medida de ida y vuelta para AAUDIO_PERFORMANCE_MODE_NONE y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY para bocinas, con cable y de forma inalámbrica auriculares.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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 la bocina la ruta de acceso a los datos.

  • [C-SR-2] La latencia de la función de tocar para tono es de 80 milisegundos o menos.

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

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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:

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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.

Finaliza los nuevos requisitos

Si las implementaciones de dispositivos incluyen android.hardware.microphone, DEBE cumplir con estos requisitos de audio de entrada:

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

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

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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] Limitar el error en las marcas de tiempo de entrada, como lo muestra AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

En la siguiente tabla, se definen los requisitos de RTL para dispositivos de mano. implementaciones definidas en la sección 2.2.1 que declaran android.hardware.audio.output y android.hardware.microphone.

Dispositivo y declaraciones RTL (ms) MAD (ms) Rutas de bucle invertido
Dispositivo manual 250 30 bocina/micrófono, analógico de 3.5 mm (si es compatible), USB (si es compatible)
>= MPC_T (14) 80 15 al menos, una ruta
FEATURE_AUDIO_LOW_LATENCY 50 10 al menos, una ruta
FEATURE_AUDIO_PRO 25 5 al menos, una ruta
FEATURE_AUDIO_PRO 20 5 analógico (si es compatible)
FEATURE_AUDIO_PRO 25 5 USB (si no es compatible con el formato analógico)

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

En la siguiente tabla, se definen los requisitos de TTL para dispositivos de mano implementaciones definidas en la sección 2.2.1 que declaran android.hardware.audio.output y android.hardware.microphone.

Dispositivo y declaraciones TTL (ms)
Dispositivo manual 250
>= MPC_T (14) 80
MPC_S (13) 100
FEATURE_AUDIO_PRO 80

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones en dispositivos admiten spatial audio con seguimiento de cabeza y declara el PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY marca, ellos:

  • [C-4-1] DEBE mostrar una latencia de seguimiento de cabeza máxima para la actualización de audio de 300 ms.

Finaliza los nuevos requisitos

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:

  • [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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-2] DEBE tener el audio de ida y vuelta continuo. de latencia, llega a la latencia requisitos para FEATURE_AUDIO_PRO según se define en la sección 5.6 Latencia de audio de 25 milisegundos o menos durante al menos uno compatible ruta de acceso.

Finaliza los nuevos requisitos

  • [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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-5] DEBE cumplir con latencias y audio USB requisitos de latencia con el Audio nativo de AAudio API y AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Finaliza los nuevos requisitos

  • [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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [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 lograr los siguientes resultados:

    • voicemark.90 >= 32 voces
    • latenciamark.fixed.little <= 15 ms
    • latemark.dynamic.little <= 50 ms
  • SE DEBE minimizar la imprecisión y la desviación del reloj de audio en relación con la hora estándar.

  • SE RECOMIENDA minimizar el desvío del reloj de audio 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 DEBE minimizar el jitter en los tiempos de entrada de devolución de llamada de finalización del búfer de audio, ya que esto afecta el porcentaje utilizable del ancho de banda total de la CPU por parte de la devolución de llamada.

  • SE DEBE proporcionar cero fallas de audio en condiciones de uso normal con la latencia informada.

  • SE DEBE proporcionar una diferencia de latencia entre canales de cero.

  • DEBES minimizar la latencia media de MIDI en todos los transportes.

  • SE RECOMIENDA minimizar la variabilidad de la latencia MIDI bajo carga (jitter) en todos los transportes.

  • DEBERÍAS proporcionar marcas de tiempo MIDI precisas en todos los transportes.

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

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones de dispositivos cumplen con todos los requisitos anteriores, sucederá lo siguiente:

Finaliza los nuevos requisitos

Si las implementaciones de los dispositivos incluyen un conector de audio de 4 conductores de 3.5 mm, sucede lo siguiente:

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Finaliza los nuevos requisitos

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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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.

Finaliza los nuevos requisitos

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, hacen 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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

Finaliza los nuevos requisitos

  • [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, unitstats, huella digital, graphicsstats, netstats, notificación, procstats) registrada con el comando dumpsys.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [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
    • InputDeviceUsageReported
    • Cambio de estado del trabajo
    • TecladoConfigurado
    • TecladoSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • Cambio de estado de pantalla
    • Estado de sincronización cambiado
    • SystemElapsedRealtime
    • Uso del panel táctil
    • 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

Finaliza los nuevos requisitos

  • [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 PERFECTTO perfeccionado para que escriba como salida un 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:

  • 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 funcionar bien en 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.

Implementaciones en dispositivos:

  • [C-0-1] DEBE, de forma predeterminada, representar aplicaciones de terceros solo en Pantallas compatibles con Android

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

  • tamaño diagonal físico. La distancia en pulgadas entre dos opuestos esquinas de la parte iluminada de la pantalla.
  • densidad. Es la cantidad de píxeles que abarca una línea intervalo horizontal o vertical de 1”, expresado en píxeles por pulgada (ppp o DPI). Donde se enumeran los valores ppi y dpi, los DPI horizontales y verticales deben estar dentro del rango indicado.
  • 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 ser 854/480 = 1.779 o aproximadamente "16:9".
  • píxel independiente de la densidad (dp). Una unidad de píxeles virtuales normalizados a una densidad de pantalla de 160. Para algo de densidad d, y la cantidad de píxeles p, la cantidad de píxeles independientes de la densidad dp, es calculada de la siguiente manera: 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 con capacidad de Configuración de tamaño de UI_MODE_TYPE_NORMAL y usar pantallas físicas con esquinas redondeadas para renderizarlas, hacen lo siguiente:

  • [C-1-1] DEBE asegurarse de que al menos uno de los siguientes requisitos para cada pantalla:

    • El radio de las esquinas redondeadas es menor o igual que 38 dp.
    • Cuando se ancla un cuadro de 18 dp por 18 dp en cada esquina de la lógica al menos un píxel de cada cuadro será visible en la pantalla.
  • SE RECOMIENDA incluir la indicación visual del usuario para cambiar al modo de visualización con los esquinas rectangulares.

Si las implementaciones en dispositivos solo pueden configurar el teclado NO_KEYS, y quieres informar la compatibilidad con el modo de IU UI_MODE_TYPE_NORMAL configuración, hacen lo siguiente:

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

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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones en dispositivos incluyen una o más áreas de visualización compatibles con Android plegables o que incluyen una bisagra plegable entre varias áreas del panel de visualización compatibles con Android y ponerlas a disposición de aplicaciones, les permiten hacer lo siguiente:

  • [C-4-1] SE DEBE implementar la versión correcta de las extensiones del administrador de ventanas Nivel de API, como se describe en Extensiones de WindowManager.

Finaliza los nuevos requisitos

7.1.1.2. Relación de aspecto de la pantalla

Esta sección se borró en Android 14.

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] SE DEBE informar una de las densidades del framework de Android que se indican. en DisplayMetrics a través de la API de DENSITY_DEVICE_STABLE que debe ser estático para cada pantalla física. Sin embargo, PUEDE QUE informar un DisplayMetrics.density diferente 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.

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

Si las implementaciones en dispositivos proporcionan una indicación visual cambiar el tamaño de visualización del dispositivo:

  • [C-1-1] NO DEBE escalar la pantalla más de 1.5 veces. DENSITY_DEVICE_STABLE 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] NO DEBE ajustar la escala de la pantalla. inferior a 0.85 veces el 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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-SR-1] SE RECOMIENDA ENcarecidamente que sean compatibles con OpenGL ES 3.1.

Finaliza los nuevos requisitos

  • 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-master-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 es compatible con 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-master-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, sucede 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 completamente las APIs de Vulkan 1.1 para cada una de las APIs enumeradas 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 establece 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.
  • [C-SR-5] SE RECOMIENDA ENERGENTE para apoyar a VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory y VK_EXT_global_priority.
  • [C-SR-6] SE RECOMIENDA ENcarecidamente usar SkiaVk con HWUI.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

Si las implementaciones en dispositivos incluyen compatibilidad con Vulkan, sucede lo siguiente:

  • [C-SR-8] SE RECOMIENDA ENERGMENTE no modificar el cargador de Vulkan.
  • [C-1-14] NO DEBE enumerar las extensiones de dispositivos Vulkan del tipo "KHR", "GOOGLE" o "ANDROID" a menos que estas extensiones se incluyan en el Marca de función android.software.vulkan.deqp.level.

Finaliza los nuevos requisitos

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 se describen aquí, hace 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.

  • [C-SR-7] SE RECOMIENDA MUY BIEN realizar la VK_KHR_external_fence_fd de la aplicación estén disponibles para apps de terceros y habilitarás exportar la carga útil de valla e importarla desde el archivo POSIX descriptores de producto como se describe aquí.

7.1.4.3 RenderScript

Implementaciones en dispositivos:

  • [C-0-1] DEBE ser compatible con 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 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(), hacen lo siguiente:

  • [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 la 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 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:

7.2.1. Teclado

Si las implementaciones en dispositivos admiten Editor de método de entrada (IME) permite hacer lo siguiente:

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:

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 para cada 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 un elemento 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, hace 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 .
  • [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 documento de 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 del ciclo de vida y compensan, y preservan los parámetros de compensación entre los reinicios del dispositivo.
  • SE DEBE compensar la temperatura.

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

  • [C-2-1] SE DEBE implementar e informar el sensor TYPE_ACCELEROMETER.
  • [C-SR-4] SE RECOMIENDA 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. las salidas de ubicación mediante las APIs del proveedor de ubicación de GNSS durante un teléfono 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:

Si las implementaciones de dispositivos incluyen un sensor para controlar la temperatura cutánea, entonces:

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 binario “cerca” o "lejos" leer, ellos:

  • [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, hace 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 en la API de Cloud.
  • [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.
  • 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.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-4-4] DEBE permitir que las aplicaciones agreguen contenido personalizado a BiometricPrompt con los formatos de visualización de contenido de PromptContentView. La pantalla de contenido Estos formatos NO DEBEN extenderse para permitir imágenes, vínculos, contenido interactivo, o cualquier otro tipo de contenido multimedia que aún no forme parte de BiometricPrompt en la API de Cloud. Ajustes estilísticos que no alteran, ocultan ni truncan de contenido (como cambio de posición, relleno, márgenes y tipografía).

Finaliza los nuevos requisitos

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-7-1] DEBE hacerlo cuando un dato biométrico está bloqueado (es decir, cuando está inhabilitado) hasta que el usuario lo desbloquee con la autenticación principal) o el bloqueo por tiempo limitado (es decir, los datos biométricos se inhabilitan temporalmente hasta que el usuario espera un momento (intervalo) debido a demasiados intentos fallidos, bloquea también todos los demás datos biométricos de una clase biométrica inferior. En el caso del bloqueo por tiempo limitado, El tiempo de retirada para la verificación biométrica DEBE ser el tiempo de retirada máximo. de todos los datos biométricos en el bloqueo por tiempo limitado.

  • [C-SR-12] SON RECOMENDADAS EN VEZ cuando hay datos biométricos en bloqueo (es decir, el método biométrico está inhabilitado hasta que el usuario desbloquee el dispositivo con la autenticación principal). bloqueo por tiempo limitado (es decir, los datos biométricos se inhabilitan temporalmente hasta que usuario espera durante un intervalo) debido a demasiados intentos fallidos, además de bloquea todos los demás datos biométricos de la misma clase. En el caso de el bloqueo por tiempo limitado, el tiempo de retirada para la verificación biométrica es ESPECÍFICO SE RECOMIENDA ser el tiempo de retirada máximo de todos los datos biométricos en un período bloqueo.

  • [C-7-2] SE DEBE desafiar al usuario a la autenticación principal recomendada (p. ej., PIN, patrón, contraseña) para restablecer el contador de bloqueos de datos se bloqueen. PUEDE permitirse los datos biométricos de clase 3 para restablecer el bloqueo para obtener datos biométricos bloqueados de la misma clase o una inferior. Clase 2 o NO DEBE permitirse los datos biométricos de clase 1 para completar un restablecimiento de bloqueo de datos 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 o 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 el índice de aceptación de impostores de la especie B de PAI de nivel B no superior al 40%, como medida con 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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [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) o cuando se recomienda la autenticación principal (p.ej., PIN, patrón o contraseña).

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-7] SE DEBE desafiar al usuario a la autenticación principal recomendada. (como 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 solicita al usuario la autenticación principal recomendada (como PIN, patrón o contraseña) una vez cada 72 horas o menos.

Finaliza los nuevos requisitos

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-8] SE DEBE desafiar al usuario a la instancia principal recomendada autenticación (como PIN, patrón o 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: Actualización de dispositivos con la versión 9 de Android o anteriores PUEDEN estar exentas del requisito C-1-8.

Finaliza los nuevos requisitos

  • [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 de menos del 10%, según las mediciones 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.
  • [C-1-12] DEBE tener una tasa de aceptación de falsificaciones e impostores que no supere el 40%. por especie de instrumento de ataque de presentación (PAI), según las mediciones del Protocolos de prueba de datos biométricos de Android.
  • [C-SR-13] SE RECOMIENDA ENcarecidamente no falsificar y el porcentaje de aceptación de impostores no debe superar el 30 %. por especie de instrumento de ataque de presentación (PAI), según las mediciones del Protocolos de prueba de datos biométricos de Android.
  • [C-SR-8] SE RECOMIENDA ENcarecidamente tener una tasa de rechazo falso de menos del 10%, según las mediciones del dispositivo.

Cómo iniciar los nuevos requisitos para 15 (AOSP experimental)

  • [C-1-15] DEBE permitir que los usuarios quiten uno o varios datos biométricos inscripciones.

Finaliza los nuevos requisitos

  • [C-SR-14] SE RECOMIENDA EXIENTEMENTE que divulguen la clase biométrica de la biométrico y los riesgos correspondientes de habilitarlo.

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

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-SR-15] SE RECOMIENDA ENERCMENTE tener una falsificación y un impostor una tasa de aceptación no superior al 20% por especie de instrumento de ataque de presentación (PAI), 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), 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 en una máquina virtual protegida controlado por un hipervisor que cumpla con los requisitos de la Sección 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 política Máquina virtual controlada por un hipervisor que cumple con los requisitos de la Sección 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 de la máquina virtual protegida que controla por un hipervisor que cumpla con los requisitos de la Sección 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 (como 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.
  • [C-SR-16] SE RECOMIENDA ENERCMENTE tener una falsificación y un impostor una tasa de aceptación no superior a 7% por especie con instrumento de ataque de presentación (PAI), según las mediciones del Protocolos de prueba de datos biométricos de Android. Si las implementaciones de dispositivos contienen un sensor de huellas dactilares ubicado debajo de la pantalla (UDFPS), hacen 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:

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:

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

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

7.4. Conectividad de datos

7.4.1 Telefonía

"Telefonía" según lo que usan las APIs de Android. En este documento, se hace referencia específicamente con hardware relacionado con realizar llamadas de voz y enviar mensajes SMS Estableciendo datos móviles a través de un celular (p.ej., GSM, CDMA, LTE, NR)GSM o CDMA en cada red. Un dispositivo compatible con "Telefonía" puedes ofrecer algunos o todos los servicios de llamadas, mensajería y datos, según sean adecuados para el producto.

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

Si las implementaciones de dispositivos no establecen la propiedad del sistema ro.telephony.iwlan\_operation\_mode como "legacy", sucederá lo siguiente:

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:

Si las implementaciones de dispositivos informan la función android.hardware.telephony, haz lo siguiente:

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:

Si las implementaciones de dispositivos admiten eUICC con varios puertos y perfiles, tendrán las siguientes características:

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ómo iniciar los nuevos requisitos para 15 (AOSP experimental)

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

  • [C-1-4] DEBE admitir mDNS y NO filtrar paquetes de mDNS. (224.0.0.251 o ff02::fb) en cualquier momento de operación, incluso cuando la la pantalla no esté activa, a menos que no se mantenga presionado el bloqueo de multidifusión los paquetes se filtran por APF. Los paquetes no están obligados a satisfacer ninguna Operaciones de mDNS actualmente solicitadas por las aplicaciones a través de NsdManager APIs Sin embargo, PUEDE que el dispositivo filtre paquetes de mDNS si es necesario. para mantenerse dentro de los rangos de consumo de energía requeridos por los requisitos reglamentarios que se aplican al mercado objetivo.

Finaliza los nuevos requisitos

  • [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() yWifiManager.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, hace 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.

Implementaciones en dispositivos:

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:

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:

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

7.4.2.7. Easy Connect para Wi-Fi (protocolo de aprovisionamiento de dispositivos)

Implementaciones en dispositivos:

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

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:

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:

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 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: hacen 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 redes móviles o móviles, Wi-Fi, Ethernet o Bluetooth.
  • [C-1-3] DEBE admitir el acceso a portales cautivos con DNS de texto simple. cuando el dispositivo está configurado para usar el modo estricto de DNS privado.
  • [C-1-4] 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 las 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:

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

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:

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 se mide desde el borde superior del DUT.
  • [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

Una cámara posterior es una cámara orientada al mundo que captura escenas en el lado más alejado. del dispositivo, como una cámara tradicional. en dispositivos de mano, es decir, ubicado en el lateral del dispositivo opuesto a la pantalla.

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

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

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

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

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” según 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 en la API de Cloud.
  • [C-0-12] 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 en la API de Cloud.
  • [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:

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).
  • Implementaciones de dispositivos que el usuario no puede rotar, de modo como los dispositivos de la industria automotriz.

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:

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