Definición de compatibilidad con Android 12

1. Introducción

Este documento enumera los requisitos que se deben cumplir para que los dispositivos sean compatibles con Android 12.

El uso de “DEBE”, “NO DEBE”, “REQUERIDO”, “DEBE”, “NO DEBE”, “DEBE”, “NO DEBE”, “RECOMENDADO”, “PUEDE” y “OPCIONAL” es según el IETF. estándar definido en RFC2119 .

Tal como se utiliza en este documento, un "implementador de dispositivo" o "implementador" es una persona u organización que desarrolla una solución de hardware/software que ejecuta Android 12. Una "implementación de dispositivo" o "implementación" es la solución de hardware/software así desarrollada.

Para ser considerada compatible con Android 12, las implementaciones de dispositivos DEBEN cumplir con los requisitos presentados en esta Definición de compatibilidad, incluido cualquier documento incorporado mediante referencia.

Cuando esta definición o las pruebas de software descritas en la sección 10 no dicen nada, son ambiguas o están incompletas, es responsabilidad del implementador del dispositivo garantizar la compatibilidad con las implementaciones existentes.

Por esta razón, el Proyecto de Código Abierto de Android es a la vez la implementación de referencia y preferida de Android. Se RECOMIENDA ENCARECIDAMENTE a los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente "ascendente" disponible en el Proyecto de código abierto de Android. Si bien hipotéticamente algunos componentes pueden reemplazarse con implementaciones alternativas, se RECOMIENDA ENCARECIDAMENTE no seguir esta práctica, ya que pasar las pruebas de software será sustancialmente más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluido y más allá del Compatibility Test Suite. Finalmente, tenga en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

Muchos de los recursos vinculados en este documento se derivan directa o indirectamente del SDK de Android y serán funcionalmente idénticos a la información contenida en la documentación de ese SDK. En cualquier caso en el que esta Definición de compatibilidad o el Conjunto de pruebas de compatibilidad no estén de acuerdo con la documentación del SDK, la documentación del SDK se considera autorizada. Cualquier detalle técnico proporcionado en los recursos vinculados a lo largo de este documento se considera por inclusión parte de esta Definición de compatibilidad.

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

La Sección 2 contiene todos los requisitos que se aplican a un tipo de dispositivo específico. Cada subsección de la Sección 2 está dedicada a un tipo de dispositivo específico.

Todos los demás requisitos, que se aplican universalmente a cualquier implementación de dispositivo Android, se enumeran en las secciones posteriores a la Sección 2 . Estos requisitos se denominan "Requisitos básicos" en este documento.

1.1.2. ID de requisito

El ID de requisito se asigna a los requisitos MUST.

  • La identificación se asigna únicamente para los requisitos MUST.
  • Los requisitos MUY RECOMENDADOS están marcados como [SR] pero no se asigna una ID.
  • La ID consta de: ID de tipo de dispositivo - ID de condición - ID de requisito (por ejemplo, C-0-1).

Cada ID se define de la siguiente manera:

  • ID de tipo de dispositivo (ver más en 2. Tipos de dispositivos )
    • C: Core (Requisitos que se aplican a todas las implementaciones de dispositivos Android)
    • H: dispositivo portátil Android
    • T: dispositivo de televisión Android
    • R: Implementación de Android Automotive
    • W: implementación de Android Watch
    • Pestaña: Implementación de tableta Android
  • ID de condición
    • Cuando el requisito es incondicional, este ID se establece en 0.
    • Cuando el requisito es condicional, se asigna 1 para la primera condición y el número aumenta en 1 dentro de la misma sección y el mismo tipo de dispositivo.
  • ID de requisito
    • Este ID comienza desde 1 y aumenta en 1 dentro de la misma sección y la misma condición.

1.1.3. ID de requisito en la Sección 2

Los ID de requisitos de la Sección 2 tienen dos partes. El primero corresponde a un ID de sección como se describe anteriormente. La segunda parte identifica el factor de forma y el requisito específico del factor de forma.

ID de sección seguido por el ID de requisito descrito anteriormente.

  • El ID de la Sección 2 consta de: ID de sección/ID de tipo de dispositivo - ID de condición - ID de requisito (por ejemplo, 7.4.3/A-0-1).

2. Tipos de dispositivos

El Proyecto de código abierto de Android proporciona una pila de software que se puede utilizar para una variedad de tipos de dispositivos y factores de forma. Para respaldar la seguridad en los dispositivos, se espera que la pila de software, incluido cualquier sistema operativo de reemplazo o una implementación de kernel alternativa, se ejecute en un entorno seguro como se describe en la sección 9 y en otras partes de este CDD. Hay algunos tipos de dispositivos que tienen un ecosistema de distribución de aplicaciones relativamente mejor establecido.

Esta sección describe esos tipos de dispositivos y los requisitos y recomendaciones adicionales aplicables a cada tipo de dispositivo.

Todas las implementaciones de dispositivos Android que no se ajusten a ninguno de los tipos de dispositivos descritos DEBEN cumplir todos los requisitos de las otras secciones de esta Definición de compatibilidad.

2.1 Configuraciones del dispositivo

Para conocer las principales diferencias en la configuración de hardware por tipo de dispositivo, consulte los requisitos específicos del dispositivo que aparecen a continuación en esta sección.

2.2. Requisitos de mano

Un dispositivo portátil Android se refiere a una implementación de dispositivo Android que normalmente se usa sosteniéndolo en la mano, como un reproductor de mp3, un teléfono o una tableta.

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

  • Contar con una fuente de energía que proporcione movilidad, como una batería.
  • Tener un tamaño de pantalla diagonal física en el rango de 3,3 pulgadas (o 2,5 pulgadas para implementaciones de dispositivos que se enviaron con el nivel API 29 o anterior) a 8 pulgadas.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos portátiles Android.

Nota: Los requisitos que no se aplican a los dispositivos Tablet Android están marcados con un *.

2.2.1. Hardware

Implementaciones de dispositivos portátiles:

  • [ 7.1 .1.1/H-0-1] DEBE tener al menos una pantalla compatible con Android que cumpla con todos los requisitos descritos en este documento.
  • [ 7.1 .1.3/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE para brindar a los usuarios la posibilidad de cambiar el tamaño de la pantalla (densidad de la pantalla).

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

Si las implementaciones de dispositivos portátiles admiten la rotación de pantalla del software,:

  • [ 7.1 .1.1/H-1-1]* DEBE hacer que la pantalla lógica que esté disponible para aplicaciones de terceros tenga al menos 2 pulgadas en los bordes cortos y 2,7 ​​pulgadas en los bordes largos. Los dispositivos que se enviaron con el nivel 29 de API de Android o anterior PUEDEN estar exentos de este requisito.

Si las implementaciones de dispositivos portátiles no admiten la rotación de pantalla del software, estas:

  • [ 7.1 .1.1/H-2-1]* DEBE hacer que la pantalla lógica que esté disponible para aplicaciones de terceros tenga al menos 2,7 pulgadas en los bordes cortos. Los dispositivos que se enviaron con el nivel 29 de API de Android o anterior PUEDEN estar exentos de este requisito.

Si las implementaciones de dispositivos portátiles afirman ser compatibles con pantallas de alto rango dinámico a través de Configuration.isScreenHdr() ,:

  • [ 7.1 .4.5/H-1-1] DEBE anunciar soporte para las extensiones 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 de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles declaran soporte a través de una propiedad del sistema graphics.gpu.profiler.support ,:

Implementaciones de dispositivos portátiles:

  • [ 7.1 .5/H-0-1] DEBE incluir soporte para el modo de compatibilidad de aplicaciones heredadas tal como lo implementa el código fuente abierto de Android. Es decir, las implementaciones de dispositivos NO DEBEN alterar los desencadenantes o umbrales en los que se activa el modo de compatibilidad, y NO DEBEN alterar el comportamiento del modo de compatibilidad en sí.
  • [ 7.2 .1/H-0-1] DEBE incluir soporte para aplicaciones de editor de métodos de entrada (IME) de terceros.
  • [ 7.2 .3/H-0-3] DEBE proporcionar la función Inicio en todas las pantallas compatibles con Android que proporcionan la pantalla de inicio.
  • [ 7.2 .3/H-0-4] DEBE proporcionar la función Atrás en todas las pantallas compatibles con Android y la función Recientes en al menos una de las pantallas compatibles con Android.
  • [ 7.2 .3/H-0-2] DEBE enviar tanto el evento de pulsación normal como el de pulsación larga de la función Atrás ( KEYCODE_BACK ) a la aplicación de primer plano. Estos eventos NO DEBEN ser consumidos por el sistema y PUEDEN activarse desde fuera del dispositivo Android (por ejemplo, un teclado de hardware externo conectado al dispositivo Android).
  • [ 7.2 .4/H-0-1] DEBE admitir la entrada de pantalla táctil.
  • [ 7.2 .4/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE iniciar la aplicación de asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService, o una actividad que maneja ACTION_ASSIST al mantener presionada KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no maneja esos eventos de larga duración.
  • [ 7.3 .1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos portátiles incluyen un acelerómetro de 3 ejes, estos:

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

Si las implementaciones de dispositivos portátiles incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través del indicador de función android.hardware.location.gps , estas:

  • [ 7.3 .3/H-2-1] DEBE informar las mediciones GNSS tan pronto como se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.
  • [ 7.3 .3/H-2-2 ] DEBEN informar los pseudodistancias y velocidades de pseudodistancia GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras están estacionarios o en movimiento con menos de 0,2 metros por segundo al cuadrado de aceleración, sean suficientes para calcular posición dentro de los 20 metros y velocidad dentro de los 0,2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos portátiles incluyen un giroscopio de 3 ejes, estos:

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

Implementaciones de dispositivos portátiles que pueden realizar una llamada de voz e indicar cualquier valor distinto de PHONE_TYPE_NONE en getPhoneType :

  • [ 7.3 .8/H] DEBE incluir un sensor de proximidad.

Implementaciones de dispositivos portátiles:

  • [ 7.3 .11/H-SR-1] Se RECOMIENDAN para soportar el sensor de pose con 6 grados de libertad.
  • [ 7.4 .3/H] DEBE incluir soporte para Bluetooth y Bluetooth LE.

Si las implementaciones de dispositivos portátiles incluyen una conexión medida,:

  • [ 7.4 .7/H-1-1] DEBE proporcionar el modo de ahorro de datos.

Si las implementaciones de dispositivos portátiles incluyen un dispositivo de cámara lógico que enumera las capacidades que utilizan CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA ,:

  • [ 7.5 .4/H-1-1] DEBE tener un campo de visión normal (FOV) de forma predeterminada y DEBE estar entre 50 y 95 grados.

Implementaciones de dispositivos portátiles:

  • [ 7.6 .1/H-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").
  • [ 7.6 .1/H-0-2] DEBE devolver "verdadero" para ActivityManager.isLowRamDevice() cuando hay menos de 1 GB de memoria disponible para el kernel y el espacio de usuario.

Si las implementaciones de dispositivos portátiles declaran admitir solo 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 al menos 416 MB si la pantalla predeterminada utiliza resoluciones de framebuffer 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 utiliza resoluciones de framebuffer 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 utiliza resoluciones de framebuffer de hasta FHD (por ejemplo, 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 utiliza resoluciones de framebuffer hasta QHD (por ejemplo, QWXGA).

Si las implementaciones de dispositivos portátiles declaran compatibilidad con cualquier ABI de 64 bits (con o sin ABI de 32 bits):

  • [ 7.6 .1/H-5-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 816 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta qHD (por ejemplo, FWVGA).

  • [ 7.6 .1/H-6-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta HD+ (por ejemplo, HD, WSVGA).

  • [ 7.6 .1/H-7-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si la pantalla predeterminada utiliza resoluciones de framebuffer de hasta FHD (por ejemplo, WSXGA+).

  • [ 7.6 .1/H-8-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1824 MB si la pantalla predeterminada utiliza resoluciones de framebuffer hasta QHD (por ejemplo, QWXGA).

Tenga en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior se refiere al espacio de memoria proporcionado además de cualquier memoria ya dedicada a componentes de hardware como radio, video, etc. que no están bajo el control del kernel en las implementaciones del dispositivo.

Si las implementaciones de dispositivos portátiles incluyen menos o igual a 1 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [ 7.6 .1/H-9-1] DEBE declarar el indicador 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 los datos privados de la aplicación (también conocida como partición "/data").

Si las implementaciones de dispositivos portátiles incluyen más de 1 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [ 7.6 .1/H-10-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").
  • DEBE declarar el indicador de función android.hardware.ram.normal .

Si las implementaciones de dispositivos portátiles incluyen 2 GB o más y menos de 4 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [7.6.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir solo espacio de usuario de 32 bits (tanto aplicaciones como código del sistema)

Si las implementaciones de dispositivos portátiles incluyen menos de 2 GB de memoria disponible para el kernel y el espacio de usuario,:

  • [7.6.1/H-1-1] DEBE admitir solo ABI de 32 bits.

Implementaciones de dispositivos portátiles:

  • [ 7.6 .2/H-0-1] NO DEBE proporcionar un almacenamiento compartido de aplicaciones de menos de 1 GiB.
  • [ 7.7 .1/H] DEBE incluir un puerto USB que admita el modo periférico.

Si las implementaciones de dispositivos portátiles incluyen un puerto USB que admite el modo periférico,:

  • [ 7.7 .1/H-1-1] DEBE implementar la API del accesorio abierto de Android (AOA).

Si las implementaciones de dispositivos portátiles incluyen un puerto USB que admite el modo host:

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

Implementaciones de dispositivos portátiles:

  • [ 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 de dispositivos portátiles son capaces de cumplir con todos los requisitos de rendimiento para admitir el modo VR e incluyen soporte para él,:

  • [ 7.9 .1/H-1-1] DEBE declarar el indicador de función android.hardware.vr.high_performance .
  • [ 7.9 .1/H-1-2] DEBE incluir una aplicación que implemente android.service.vr.VrListenerService que las aplicaciones de realidad virtual puedan habilitar a través de android.app.Activity#setVrModeEnabled .

Si las implementaciones de dispositivos portátiles incluyen uno o más puertos USB-C en modo host e implementan (clase de audio USB), además de los requisitos de la sección 7.7.2 ,:

  • [ 7.8 .2.2/H-1-1] DEBE proporcionar el siguiente mapeo de software de códigos HID:
Función Mapeos Contexto Comportamiento
A Página de uso de HID : 0x0C
Uso de HID : 0x0CD
Clave del núcleo : KEY_PLAYPAUSE
Clave de Android : KEYCODE_MEDIA_PLAY_PAUSE
Reproducción multimedia Entrada : pulsación corta
Salida : Reproducir o pausar
Entrada : pulsación larga
Salida : iniciar comando de voz
Envía : android.speech.action.VOICE_SEARCH_HANDS_FREE si el dispositivo está bloqueado o su pantalla está apagada. Envía android.speech.RecognizerIntent.ACTION_WEB_SEARCH de lo contrario
Llamada entrante Entrada : pulsación corta
Salida : Aceptar llamada
Entrada : pulsación larga
Salida : Rechazar llamada
llamada en curso Entrada : pulsación corta
Salida : Finalizar llamada
Entrada : pulsación larga
Salida : Silenciar o reactivar el 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 multimedia, llamada en curso Entrada : Pulsación corta o larga
Salida : aumenta el volumen del sistema o de los auriculares.
C Página de uso de HID : 0x0C
Uso de HID : 0x0EA
Clave del núcleo : KEY_VOLUMEDOWN
Clave de Android : VOLUME_DOWN
Reproducción multimedia, llamada en curso Entrada : Pulsación corta o larga
Salida : Disminuye el volumen del sistema o de los auriculares.
D Página de uso de HID : 0x0C
Uso de HID : 0x0CF
Clave del núcleo : KEY_VOICECOMMAND
Clave de Android : KEYCODE_VOICE_ASSIST
Todo. Puede activarse en cualquier caso. Entrada : Pulsación corta o larga
Salida : iniciar comando de voz
  • [ 7.8 .2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG al insertar un enchufe, pero solo después de que las interfaces de audio USB y los puntos finales se hayan enumerado correctamente para identificar el tipo de terminal conectado.

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

  • [ 7.8 .2.2/H-2-1] DEBE transmitir el Intent ACTION_HEADSET_PLUG con el "micrófono" adicional establecido en 0.

Cuando se detecta el terminal de audio USB tipo 0x0402,:

  • [ 7.8 .2.2/H-3-1] DEBE transmitir el Intent ACTION_HEADSET_PLUG con el "micrófono" adicional configurado en 1.

Cuando se llama a API AudioManager.getDevices() mientras el periférico USB está conectado:

  • [ 7.8 .2.2/H-4-1] DEBE enumerar un dispositivo de 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 enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y la función isSink() si el campo de tipo de terminal de audio USB es 0x0402.

  • [ 7.8 .2.2/H-4-3] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y la función isSource() si el campo de tipo de terminal de audio USB es 0x0402.

  • [ 7.8 .2.2/H-4-4] DEBE enumerar un dispositivo de 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 enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y la función isSource() si el campo de tipo de terminal de audio USB es 0x604.

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

  • [ 7.8 .2.2/H-4-7] DEBE enumerar un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y la función isSource() si el campo de tipo de terminal de audio USB es 0x400.

  • [ 7.8 .2.2/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE al conectar un periférico de audio USB-C, para realizar una enumeración de descriptores USB, identificar tipos de terminales y transmitir Intent ACTION_HEADSET_PLUG en menos de 1000 milisegundos.

Si las implementaciones de dispositivos portátiles declaran android.hardware.audio.output y android.hardware.microphone ,:

  • [5.6(#56_audio-latency)/H-1-1] DEBE tener una latencia media continua de ida y vuelta de 800 milisegundos o menos en 5 mediciones, con una desviación media absoluta inferior a 100 ms, en al menos una ruta admitida.

Si las implementaciones de dispositivos portátiles incluyen al menos un actuador háptico, estos:

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

Si las implementaciones de dispositivos portátiles incluyen al menos un actuador resonante lineal,:

  • [ 7.10 /H]* DEBE mover el actuador háptico en el eje X de orientación vertical.

Si las implementaciones de dispositivos portátiles tienen un actuador háptico que es un actuador resonante lineal (LRA) del eje X,:

  • [ 7.10 /H]* DEBE tener la frecuencia de resonancia del LRA del eje X por debajo de 200 Hz.

Si las implementaciones de dispositivos portátiles siguen el mapeo de constantes hápticas,:

2.2.2. Multimedia

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación y decodificación de audio y ponerlos a disposición de aplicaciones de terceros:

  • [ 5.1 /H-0-1] RAM-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 de bajo retardo mejorado)

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:

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

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:

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

2.2.3. Software

Implementaciones de dispositivos portátiles:

  • [ 3.2.3.1 /H-0-1] DEBE tener una aplicación que maneje las intenciones ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT , ACTION_OPEN_DOCUMENT_TREE y ACTION_CREATE_DOCUMENT como se describe en los documentos del SDK, y proporcione al usuario la posibilidad de acceder a los datos del proveedor de documentos mediante la API DocumentsProvider .
  • [ 3.2.3.1 /H-0-2]* DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .
  • [ 3.2.3.1 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar una aplicación de correo electrónico que pueda manejar ACTION_SENDTO o ACTION_SEND o ACTION_SEND_MULTIPLE intentos para enviar un correo electrónico.
  • [ 3.4 .1/H-0-1] DEBE proporcionar una implementación completa de la API android.webkit.Webview .
  • [ 3.4 .2/H-0-1] DEBE incluir una aplicación de navegador independiente para la navegación web del usuario general.
  • [ 3.8.1 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un iniciador predeterminado que admita la fijación de accesos directos, widgets y funciones de widgets en la aplicación.
  • [ 3.8 .1/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE implementar un iniciador predeterminado que proporcione acceso rápido a los accesos directos adicionales proporcionados por aplicaciones de terceros a través de la API ShortcutManager .
  • [ 3.8 .1/H-SR-3] Se RECOMIENDA ENCARECIDAMENTE incluir una aplicación de inicio predeterminada que muestre insignias para los íconos de las aplicaciones.
  • [ 3.8 .2/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE para admitir widgets de aplicaciones de terceros.
  • [ 3.8 .3/H-0-1] DEBE permitir que aplicaciones de terceros notifiquen a los usuarios sobre eventos notables a través de las clases API Notification y NotificationManager .
  • [ 3.8 .3/H-0-2] DEBE admitir notificaciones enriquecidas.
  • [ 3.8 .3/H-0-3] DEBE admitir notificaciones de aviso.
  • [ 3.8 .3/H-0-4] DEBE incluir un tono de notificación, que brinde al usuario la capacidad de controlar directamente (por ejemplo, responder, posponer, descartar, bloquear) las notificaciones a través de las posibilidades del usuario, como los botones de acción o el panel de control, según se implemente. en la AOSP.
  • [ 3.8 .3/H-0-5] DEBE mostrar las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el tono de notificación.
  • [ 3.8 .3/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar la primera opción proporcionada a través de RemoteInput.Builder setChoices() en el tono de notificación sin interacción adicional del usuario.
  • [ 3.8 .3/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE mostrar todas las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el tono de notificación cuando el usuario expande todas las notificaciones en el tono de notificación.
  • [ 3.8 .3.1/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar acciones para las cuales Notification.Action.Builder.setContextual está configurado como true en línea con las respuestas mostradas por Notification.Remoteinput.Builder.setChoices .
  • [ 3.8.4 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para manejar la acción de Asistencia .

Si las implementaciones de dispositivos portátiles admiten la acción de asistencia, estas:

  • [ 3.8.4 /H-SR-2] Se RECOMIENDA ENCARECIDAMENTE utilizar una pulsación prolongada de la tecla HOME como 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 asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que maneje la intención ACTION_ASSIST .

Si las implementaciones de dispositivos portátiles admiten conversation notifications y las agrupan en una sección separada de las alertas y las notificaciones silenciosas que no son de conversación,:

  • [ 3.8 .4/H-1-1]* DEBE mostrar las notificaciones de conversación antes que las notificaciones que no son de conversación, con la excepción de las notificaciones de servicio en primer plano en curso y las notificaciones de importancia: alta .

Si las implementaciones de dispositivos portátiles Android admiten una pantalla de bloqueo,:

  • [ 3.8 .10/H-1-1] DEBE mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación de medios.

Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura,:

Si las implementaciones de dispositivos portátiles incluyen soporte para ControlsProviderService y Control API y permiten que aplicaciones de terceros publiquen controles de dispositivos , entonces:

  • [ 3.8 .16/H-1-1] DEBE declarar el indicador de función android.software.controls y establecerlo en true .
  • [ 3.8 .16/H-1-2] DEBE proporcionar al usuario la posibilidad de agregar, editar, seleccionar y operar los controles del dispositivo favorito del usuario desde los controles registrados por las aplicaciones de terceros a través de ControlsProviderService y las API Control . .
  • [ 3.8 .16/H-1-3] DEBE proporcionar acceso a esta posibilidad de usuario dentro de tres interacciones desde un iniciador predeterminado.
  • [ 3.8 .16/H-1-4] DEBE representar con precisión en esta prestación de usuario el nombre y el icono de cada aplicación de terceros que proporciona controles a través de la API ControlsProviderService , así como cualquier campo especificado proporcionado por las API Control .

Por el contrario, si las implementaciones de dispositivos portátiles no implementan dichos controles,:

Implementaciones de dispositivos portátiles:

  • [ 3.10 /H-0-1] DEBE admitir servicios de accesibilidad de terceros.
  • [ 3.10 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE-1 precargar servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad Switch Access y TalkBack (para idiomas admitidos por el motor de texto a voz preinstalado) tal como se proporcionan en el proyecto de código abierto talkback .
  • [ 3.11 /H-0-1] DEBE admitir la instalación de motores TTS de terceros.
  • [ 3.11 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor TTS que admita los idiomas disponibles en el dispositivo.
  • [ 3.13 /H-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un componente de interfaz de usuario de Configuración rápida.

Si las implementaciones de dispositivos portátiles Android declaran compatibilidad con FEATURE_BLUETOOTH o FEATURE_WIFI ,:

  • [ 3.16 /H-1-1] DEBE admitir la función de emparejamiento 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 para la función Inicio no DEBE tener más de 32 dp de altura desde la parte inferior de la pantalla.

Si las implementaciones de dispositivos portátiles proporcionan una función de navegación como un gesto desde cualquier lugar 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 gesto DEBE tener 24 dp de ancho de forma predeterminada.

Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura y tienen 2 GB o más de memoria disponible para el kernel y el espacio de usuario,:

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

Si las implementaciones de dispositivos portátiles Android declaran la compatibilidad con la cámara a través de android.hardware.camera.any :

2.2.4. Rendimiento y potencia

  • [ 8.1 /H-0-1] Latencia de fotogramas consistente . La latencia de fotogramas inconsistente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia de 5 fotogramas por segundo, y DEBEN ser inferiores a 1 fotograma por segundo.
  • [ 8.1 /H-0-2] Latencia de la interfaz de usuario . Las implementaciones de dispositivos DEBEN garantizar una experiencia de usuario de baja latencia al desplazarse por una lista de 10.000 entradas de lista según lo definido por Android Compatibility Test Suite (CTS) en menos de 36 segundos.
  • [ 8.1 /H-0-3] Cambio de tarea . Cuando se han iniciado varias aplicaciones, volver a iniciar una aplicación que ya se está ejecutando después de haberla iniciado DEBE tardar menos de 1 segundo.

Implementaciones de dispositivos portátiles:

  • [ 8.2 /H-0-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 5 MB/s.
  • [ 8.2 /H-0-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 0,5 MB/s.
  • [ 8.2 /H-0-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 15 MB/s.
  • [ 8.2 /H-0-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 3,5 MB/s.

Si las implementaciones de dispositivos portátiles incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o amplían las funciones que se incluyen en AOSP, estas:

  • [ 8.3 /H-1-1] DEBE proporcionar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.
  • [ 8.3 /H-1-2] DEBE proporcionar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles incluyen una pantalla o salida de video,:

2.2.5. Modelo de seguridad

Implementaciones de dispositivos portátiles:

  • [ 9.1 /H-0-1] DEBE permitir que aplicaciones de terceros accedan a las estadísticas de uso a través del permiso android.permission.PACKAGE_USAGE_STATS y proporcionar un mecanismo accesible para el usuario para otorgar o revocar el acceso a dichas aplicaciones en respuesta a android.settings.ACTION_USAGE_ACCESS_SETTINGS intención.

Implementaciones de dispositivos portátiles:

  • [ 9.11 /H-0-2] DEBE realizar 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 algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de las familias MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos admitidos del sistema Android Keystore en un área segura. aislado del código que se ejecuta en el kernel y superiores. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [ 9.11 /H-0-4] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislada y solo cuando tenga éxito, permita que se utilicen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El proyecto de código abierto de Android proporciona la capa de abstracción de hardware Gatekeeper (HAL) y Trusty, que se pueden utilizar para satisfacer este requisito.
  • [ 9.11 /H-0-5] DEBE admitir la atestación de clave donde la clave de firma de la atestación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad suficiente de dispositivos para evitar que se utilicen como identificadores de dispositivos. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.
  • [9/H-0-1] DEBE declarar la característica 'android.hardware.security.model.compatible'.

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Cuando las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura,:

  • [ 9.11 /H-1-1] DEBE permitir al usuario elegir el tiempo de espera más corto, es decir, un tiempo de transición del estado desbloqueado al estado bloqueado, de 15 segundos o menos.
  • [ 9.11 /H-1-2] DEBE brindar al usuario la posibilidad de ocultar notificaciones y deshabilitar todas las formas de autenticación, excepto la autenticación primaria descrita en 9.11.1 Pantalla de bloqueo seguro . El AOSP cumple con el requisito como modo de bloqueo.

Si las implementaciones de dispositivos portátiles incluyen varios usuarios y no declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /H-2-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

Si las implementaciones de dispositivos portátiles incluyen varios usuarios y declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /H-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir o deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

Android, a través de la API del sistema, VoiceInteractionService admite un mecanismo para la detección segura de palabras activas siempre activas sin indicación de acceso al micrófono.

Si las implementaciones de dispositivos portátiles admiten System API HotwordDetectionService u otro mecanismo para la detección de palabras activas sin indicación de acceso al micrófono,:

  • [9.8/H-1-1] DEBE asegurarse de que el servicio de detección de palabras activas solo pueda transmitir datos al Sistema o ContentCaptureService
  • [9.8/H-1-2] DEBE asegurarse de que el servicio de detección de palabras activas solo pueda transmitir datos de audio del micrófono o datos derivados de él al servidor del sistema a través de la API HotwordDetectionService , o a ContentCaptureService a través de la API ContentCaptureManager .
  • [9.8/H-1-3] NO DEBE suministrar audio de micrófono que dure más de 30 segundos para una solicitud individual activada por hardware al servicio de detección de palabras activas.
  • [9.8/H-1-4] NO DEBE proporcionar audio de micrófono almacenado en búfer de más de 8 segundos para una solicitud individual al servicio de detección de palabras activas.
  • [9.8/H-1-5] NO DEBE suministrar audio de micrófono almacenado en buffer de más de 30 segundos al servicio de interacción de voz o entidad similar.
  • [9.8/H-1-6] NO DEBE permitir que se transmitan más de 100 bytes de datos fuera del servicio de detección de palabras activas en cada resultado exitoso de palabra activa.
  • [9.8/H-1-7] NO DEBE permitir que se transmitan más de 5 bits de datos fuera del servicio de detección de palabras activas en cada resultado negativo de palabra activa.
  • [9.8/H-1-8] DEBE permitir únicamente la transmisión de datos fuera del servicio de detección de palabras activas en una solicitud de validación de palabras activas del servidor del sistema.
  • [9.8/H-1-9] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección de palabras activas.
  • [9.8/H-1-10] NO DEBE aparecer en la interfaz de usuario datos cuantitativos sobre el uso del micrófono por parte del servicio de detección de palabras activas.
  • [9.8/H-1-11] DEBE registrar la cantidad de bytes incluidos en cada transmisión desde el servicio de detección de palabras activas para permitir la inspeccionabilidad por parte de los investigadores de seguridad.
  • [9.8/H-1-12] DEBE admitir un modo de depuración que registre el contenido sin procesar de cada transmisión desde el servicio de detección de palabras activas para permitir la inspeccionabilidad por parte de los investigadores de seguridad.
  • [9.8/H-1-13] DEBE reiniciar el proceso que aloja el servicio de detección de palabras activas al menos una vez cada hora o cada 30 eventos de activación de hardware, lo que ocurra primero.
  • [9.8/H-1-14] DEBE mostrar el indicador del micrófono, como se describe en la sección 9.8.2 , cuando se transmite un resultado exitoso de una palabra activa al servicio de interacción de voz o entidad similar.
  • [9.8/H-SR-1] Se RECOMIENDA ENCARECIDAMENTE notificar a los usuarios antes de configurar una aplicación como proveedor del servicio de detección de palabras activas.
  • [9.8/H-SR-2] Se RECOMIENDA ENCARECIDAMENTE no permitir la transmisión de datos no estructurados fuera del servicio de detección de palabras activas.

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

  • [9.8/H-2-1] DEBE proporcionar un aviso explícito al usuario para cada frase de palabra activa admitida.
  • [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 activas.
  • [9.8/H-2-3] NO DEBE transmitir desde el servicio de detección de palabras clave, datos de audio, datos que puedan usarse para reconstruir (total o parcialmente) el audio, o contenidos de audio no relacionados con la palabra clave en sí, excepto ContentCaptureService .

Si las implementaciones de dispositivos portátiles declaran android.hardware.microphone ,:

  • [ 9.8.2 /H-4-1] DEBE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede HotwordDetectionService , SOURCE_HOTWORD , ContentCaptureService o aplicaciones que desempeñan los roles mencionados en la sección 9.1 con identificador CDD [C-4-X]. .
  • [ 9.8.2 /H-4-2] DEBE mostrar la lista de aplicaciones recientes y activas que usan el micrófono según lo devuelto por PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.
  • [ 9.8.2 /H-4-3] No DEBE ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
  • [ 9.8.2 /H-4-4] DEBE mostrar la lista de aplicaciones recientes y activas que usan el micrófono según lo devuelto por PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.

Si las implementaciones de dispositivos portátiles declaran android.hardware.camera.any ,:

  • [ 9.8.2 /H-5-1] DEBE mostrar el indicador de la cámara cuando una aplicación accede a los datos de la cámara en vivo, pero no cuando solo acceden a la cámara las aplicaciones que desempeñan las funciones mencionadas en la sección 9.1 con el identificador CDD. [C-4-X].
  • [ 9.8.2 /H-5-2] DEBE mostrar las aplicaciones recientes y activas que usan la cámara tal como se devuelven desde PermissionManager.getIndicatorAppOpUsageData() , junto con cualquier mensaje de atribución asociado con ellas.
  • [ 9.8.2 /H-5-3] No DEBE ocultar el indicador de la cámara para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

2.2.6. Compatibilidad de opciones y herramientas de desarrollador

Implementaciones de dispositivos portátiles (* No aplicable para tableta):

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

Implementaciones de dispositivos portátiles (* No aplicable para tableta):

  • perfecto
    • [ 6.1 /H-0-2]* DEBE exponer un binario /system/bin/perfetto al usuario del shell cuyo cmdline cumpla con la documentación de perfetto .
    • [ 6.1 /H-0-3]* El binario perfetto DEBE aceptar como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [ 6.1 /H-0-4]* El binario perfetto DEBE escribir como salida una traza 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 binario perfetto, al menos las fuentes de datos descritas en la documentación de perfetto .
    • [ 6.1 /H-0-6]* El demonio rastreado de perfetto DEBE estar habilitado de forma predeterminada (propiedad del sistema persist.traced.enable ).

2.2.7. Clase de rendimiento de medios portátiles

Consulte la Sección 7.11 para conocer la definición de clase de rendimiento del medio.

2.2.7.1. Medios de comunicación

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • DEBE cumplir con los requisitos de medios enumerados en la sección 2.2.7.1 de CDD de Android 11

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.S para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • [5.1/H-1-1] DEBE anunciar el número máximo de sesiones de decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() .
  • [5.1/H-1-2] DEBE admitir 6 instancias de sesiones de decodificador de video de hardware (AVC, HEVC, VP9* o posterior) en cualquier combinación de códec que se ejecute simultáneamente a una resolución de 720p a 30 fps. *Solo se requieren 2 instancias si el códec VP9 está presente.
  • [5.1/H-1-3] DEBE anunciar el número máximo de sesiones de codificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() .
  • [5.1/H-1-4] DEBE admitir 6 instancias de sesiones de codificador de video de hardware (AVC, HEVC, VP9* o posterior) en cualquier combinación de códec que se ejecute simultáneamente con una resolución de 720p a 30 fps. *Solo se requieren 2 instancias si el códec VP9 está presente.
  • [5.1/H-1-5] DEBE anunciar el número máximo de sesiones de codificador y decodificador de video de hardware que se pueden ejecutar simultáneamente en cualquier combinación de códec a través de los métodos CodecCapabilities.getMaxSupportedInstances() y VideoCapabilities.getSupportedPerformancePoints() .
  • [5.1/H-1-6] DEBE admitir 6 instancias de sesiones de decodificador de video de hardware y codificador de video de hardware (AVC, HEVC, VP9* o posterior) en cualquier combinación de códec que se ejecute simultáneamente a una resolución de 720p a 30 fps. *Solo se requieren 2 instancias si el códec VP9 está presente.
  • [5.1/H-1-7] DEBE tener una latencia de inicialización de códec de 50 ms o menos para una sesión de codificación de video de 1080p o menor para todos los codificadores de video de hardware (que no sean el códec Dolby Vision) cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de video de 1080p a 720p únicamente utilizando códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p.
  • [5.1/H-1-8] DEBE tener una latencia de inicialización de códec de 40 ms o menos para una sesión de codificación de audio con una velocidad de bits de 128 kbps o inferior para todos los codificadores de audio cuando están bajo carga. La carga aquí se define como una sesión simultánea de transcodificación de video de 1080p a 720p únicamente utilizando códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p.
  • [5.3/H-1-1] NO DEBE perder más de 2 fotogramas en 10 segundos (es decir, menos del 0,333 por ciento de pérdida de fotogramas) para una sesión de vídeo de 1080p a 60 fps bajo carga. La carga se define como una sesión simultánea de transcodificación de vídeo de 1080p a 720p únicamente utilizando códecs de vídeo de hardware, así como una reproducción de audio AAC de 128 kbps.
  • [5.3/H-1-2] NO DEBE perder más de 2 cuadros en 10 segundos durante un cambio de resolución de video en una sesión de video de 60 fps bajo carga. La carga se define como una sesión simultánea de transcodificación de vídeo de 1080p a 720p únicamente utilizando códecs de vídeo de hardware, así como una reproducción de audio AAC de 128 kbps.
  • [5.6/H-1-1] DEBE tener una latencia de pulsación para tono de menos de 100 milisegundos utilizando la prueba de pulsación para tono de OboeTester o la prueba de pulsación para tono de CTS Verifier.

2.2.7.2. Cámara

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • DEBE cumplir con los requisitos de la cámara enumerados en la sección 2.2.7.2 del CDD de Android 11

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.S para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • [7.5/H-1-1] DEBE tener una cámara principal trasera con una resolución de al menos 12 megapíxeles que admita captura de video a 4k@30fps. La cámara trasera principal es la cámara trasera con el ID de cámara más bajo.
  • [7.5/H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 5 megapíxeles y admitir captura de video a 1080p@30fps. La cámara frontal principal es la cámara frontal con el ID de cámara más bajo.
  • [7.5/H-1-3] DEBE admitir la propiedad android.info.supportedHardwareLevel como FULL o mejor para ambas cámaras principales.
  • [7.5/H-1-4] DEBE admitir CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME para ambas cámaras principales.
  • [7.5/H-1-5] DEBE tener una latencia de captura JPEG de la cámara 2 < 1000 ms para una resolución de 1080p según lo medido por la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000K) para ambas cámaras principales.
  • [7.5/H-1-6] DEBE tener una latencia de inicio de la cámara 2 (cámara abierta al primer fotograma de vista previa) < 600 ms, según lo medido por la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000 K) para ambas cámaras principales.
  • [7.5/H-1-8] DEBE admitir CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW y android.graphics.ImageFormat.RAW_SENSOR para la cámara trasera principal.

2.2.7.3. Hardware

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • DEBE cumplir con los requisitos de hardware enumerados en la sección 2.2.7.3 del CDD de Android 11

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.S para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • [7.1.1.1/H-2-1] DEBE tener una resolución de pantalla de al menos 1080p.
  • [7.1.1.3/H-2-1] DEBE tener una densidad de pantalla de al menos 400 ppp.
  • [7.6.1/H-2-1] DEBE tener al menos 6 GB de memoria física.

2.2.7.4. Actuación

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • DEBE cumplir con los requisitos de rendimiento enumerados en la sección 2.2.7.4 del CDD de Android 11

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.S para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , entonces:

  • [8.2/H-2-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 125 MB/s.
  • [8.2/H-2-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 10 MB/s.
  • [8.2/H-2-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 250 MB/s.
  • [8.2/H-2-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 40 MB/s.

2.3. Requisitos de televisión

Un dispositivo Android Television se refiere a una implementación de dispositivo Android que es una interfaz de entretenimiento para consumir medios digitales, películas, juegos, aplicaciones y/o TV en vivo para usuarios sentados a unos diez pies de distancia (un usuario “reclinado” o “usuario de 10 pies”). interfaz").

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

  • Han proporcionado un mecanismo para controlar de forma remota la interfaz de usuario representada en la pantalla que podría estar 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 visualización.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos Android Television.

2.3.1. Hardware

Implementaciones de dispositivos de televisión:

  • [ 7.2 .2/T-0-1] DEBE admitir D-pad .
  • [ 7.2 .3/T-0-1] DEBE proporcionar las funciones Inicio y Atrás.
  • [ 7.2 .3/T-0-2] DEBE enviar tanto el evento de pulsación normal como el de pulsación larga de la función Atrás ( KEYCODE_BACK ) a la aplicación de primer plano.
  • [ 7.2 .6.1/T-0-1] DEBE incluir soporte para controladores de juegos y declarar el indicador de función android.hardware.gamepad .
  • [ 7.2.7 /T] DEBE proporcionar un control remoto desde el cual los usuarios puedan acceder a la navegación no táctil y a las entradas de las teclas de navegación principales .

Si las implementaciones de dispositivos de televisión incluyen un giroscopio de 3 ejes, estos:

  • [ 7.3 .4/T-1-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.
  • [ 7.3.4 /T-1-2] DEBE ser capaz de medir cambios de orientación de hasta 1000 grados por segundo.

Implementaciones de dispositivos de televisión:

  • [ 7.4 .3/T-0-1] DEBE admitir Bluetooth y Bluetooth LE.
  • [ 7.6 .1/T-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los 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 que admite el modo host,:

  • [ 7.5 .3/T-1-1] DEBE incluir soporte para una cámara externa que se conecta a través de este puerto USB pero que no necesariamente está siempre conectada.

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 cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes

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 utiliza cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes

Tenga en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior se refiere al espacio de memoria proporcionado además de cualquier memoria ya dedicada a componentes de hardware como radio, video, etc. que no están bajo el control del kernel en las implementaciones del dispositivo.

Implementaciones de dispositivos de televisión:

  • [ 7.8 .1/T] 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 los siguientes formatos de codificación y decodificación de audio 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 de bajo retardo mejorado)

Las implementaciones de dispositivos de televisión DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:

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

Implementaciones de dispositivos de televisión:

  • [ 5.2 .2/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir la codificación H.264 de vídeos con resolución de 720p y 1080p a 30 fotogramas por segundo.

Las implementaciones de dispositivos de televisión DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación MPEG-2, como se detalla en la Sección 5.3.1, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.1 /T-1-1] HD 1080p a 29,97 cuadros por segundo con perfil principal de alto nivel.
  • [ 5.3.1 /T-1-2] HD 1080i a 59,94 cuadros por segundo con perfil principal de alto nivel. DEBEN desentrelazar el vídeo MPEG-2 entrelazado y ponerlo 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 la Sección 5.3.4, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 5.3.4 /T-1-1] HD 1080p a 60 cuadros por segundo con Baseline Profile
  • [ 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 cuadros por segundo con High Profile Level 4.2

Las implementaciones de dispositivos de televisión con decodificadores de hardware H.265 DEBEN admitir la decodificación H.265, como se detalla en la Sección 5.3.5, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 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 H.265 y el perfil de decodificación UHD,:

  • [ 5.3.5 /T-2-1] DEBE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil Main10 Nivel 5 Main Tier

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación VP8, como se detalla en la Sección 5.3.6, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

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

Las implementaciones de dispositivos de televisión con decodificadores de hardware VP9 DEBEN admitir la decodificación VP9, ​​como se detalla en la Sección 5.3.7, a velocidades de cuadros de video estándar y resoluciones de hasta e incluyendo:

  • [ 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 VP9 admiten la decodificación VP9 y el perfil de decodificación UHD,:

  • [ 5.3.7 /T-2-1] DEBE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil 0 (profundidad de color de 8 bits).
  • [ 5.3.7 /T-2-1] Se RECOMIENDA ENCARECIDAMENTE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil 2 (profundidad de color de 10 bits).

Implementaciones de dispositivos de televisión:

  • [ 5.5 /T-0-1] DEBE incluir soporte para el volumen maestro del sistema y la atenuación del volumen de salida de audio digital en las salidas admitidas, excepto para la salida de paso de audio comprimido (donde no se realiza ninguna decodificación de audio en el dispositivo).

Si las implementaciones de dispositivos de televisión no tienen una pantalla incorporada, pero admiten una pantalla externa conectada a través de HDMI,:

  • [ 5.8 /T-0-1] DEBE configurar el modo de salida HDMI para seleccionar la resolución máxima que puede admitirse con una frecuencia de actualización de 50 Hz o 60 Hz.
  • [ 5.8 /T-SR-1] Se RECOMIENDA ENCARECIDAMENTE proporcionar un selector de frecuencia de actualización HDMI configurable por el usuario.
  • [ 5.8 ] DEBE configurar la frecuencia de actualización del modo de salida HDMI en 50 Hz o 60 Hz, dependiendo de la frecuencia de actualización de video para la región en la que se vende el dispositivo.

Si las implementaciones de dispositivos de televisión no tienen una pantalla incorporada, pero admiten una pantalla externa conectada a través de HDMI,:

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

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

  • [ 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] DEBE declarar las funciones android.software.leanback y android.hardware.type.television .
  • [ 3.2.3.1 /T-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .
  • [ 3.4 .1/T-0-1] DEBE proporcionar una implementación completa de la API android.webkit.Webview .

Si las implementaciones de dispositivos Android Television admiten una pantalla de bloqueo,:

  • [ 3.8 .10/T-1-1] DEBE mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación de medios.

Implementaciones de dispositivos de televisión:

  • [ 3.8 .14/T-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir el modo de ventana múltiple de imagen en imagen (PIP).
  • [ 3.10 /T-0-1] DEBE admitir servicios de accesibilidad de terceros.
  • [ 3.10 /T-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad Switch Access y TalkBack (para idiomas admitidos por el motor de texto a voz preinstalado) según lo dispuesto en el proyecto de código abierto talkback .

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

  • [ 3.11 /T-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor TTS que admita los idiomas disponibles en el dispositivo.
  • [ 3.11 /T-1-1] DEBE admitir la instalación de motores TTS de terceros.

Implementaciones de dispositivos de televisión:

  • [ 3.12 /T-0-1] DEBE admitir el marco de entrada de TV.

2.3.4. Rendimiento y potencia

  • [ 8.1 /T-0-1] Latencia de fotogramas consistente . La latencia de fotogramas inconsistente o un retraso en la renderización de fotogramas NO DEBEN ocurrir con más frecuencia de 5 fotogramas por segundo, y DEBEN ser inferiores a 1 fotograma por segundo.
  • [ 8.2 /T-0-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 5 MB/s.
  • [ 8.2 /T-0-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 0,5 MB/s.
  • [ 8.2 /T-0-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 15 MB/s.
  • [ 8.2 /T-0-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 3,5 MB/s.

Si las implementaciones de dispositivos de televisión incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o amplían las funciones que se incluyen en AOSP, estas:

  • [ 8.3 /T-1-1] DEBE proporcionar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.

Si las implementaciones de dispositivos de televisión no tienen batería:

Si las implementaciones de dispositivos de televisión tienen batería:

  • [ 8.3 /T-1-3] DEBE proporcionar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.

Implementaciones de dispositivos de televisión:

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

2.3.5. Modelo de seguridad

Implementaciones de dispositivos de televisión:

  • [ 9.11 /T-0-1] DEBE realizar 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 algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de las familias MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos admitidos del sistema Android Keystore en un área que esté aislada de forma segura. del código que se ejecuta en el kernel y superior. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [ 9.11 /T-0-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislada y solo cuando tenga éxito, permita que se utilicen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El proyecto de código abierto de Android proporciona la capa de abstracción de hardware Gatekeeper (HAL) y Trusty, que se pueden utilizar para satisfacer este requisito.
  • [ 9.11 /T-0-4] DEBE admitir la atestación de clave donde la clave de firma de atestación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad suficiente de dispositivos para evitar que se utilicen como identificadores de dispositivos. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.
  • [9/T-0-1] DEBE declarar la característica 'android.hardware.security.model.compatible'.

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Si las implementaciones de dispositivos de televisión admiten una pantalla de bloqueo segura,:

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

Si las implementaciones de dispositivos de televisión incluyen varios usuarios y no declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /T-2-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

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

  • [ 9.5 /T-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir/deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

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

  • [ 9.8.2 /T-4-1] DEBE mostrar el indicador del micrófono cuando una aplicación accede a datos de audio desde el micrófono, pero no cuando al micrófono solo accede HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o aplicaciones que desempeñan los roles mencionados en Sección 9.1 Permisos con identificador CDD C-3-X].
  • [ 9.8.2 /T-4-2] No DEBE ocultar el indicador del micrófono para aplicaciones del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.

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

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

2.3.6. Compatibilidad de opciones y herramientas de desarrollador

Implementaciones de dispositivos de televisión:

2.4. Requisitos del reloj

Un dispositivo Android Watch se refiere a una implementación de dispositivo Android destinada a usarse en el cuerpo, tal vez en la muñeca.

Las implementaciones de dispositivos Android se clasifican como Watch si cumplen con todos los criterios siguientes:

  • Tener una pantalla con una longitud diagonal física en el rango de 1,1 a 2,5 pulgadas.
  • Disponer de un mecanismo para llevar en el cuerpo.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos Android Watch.

2.4.1. Hardware

Ver implementaciones de dispositivos:

  • [ 7.1 .1.1/W-0-1] DEBE tener una pantalla con un tamaño diagonal físico en el rango de 1,1 a 2,5 pulgadas.

  • [ 7.2 .3/W-0-1] DEBE tener la función Inicio disponible para el usuario y la función Atrás excepto cuando está en UI_MODE_TYPE_WATCH .

  • [ 7.2 .4/W-0-1] DEBE admitir la entrada de pantalla táctil.

  • [ 7.3 .1/W-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos Watch incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través del indicador de función android.hardware.location.gps , estas:

  • [ 7.3 .3/W-1-1] DEBE informar las mediciones GNSS tan pronto como se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.
  • [ 7.3 .3/W-1-2 ] DEBE informar los pseudodistancias y velocidades de pseudodistancia GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras está estacionario o en movimiento con menos de 0,2 metros por segundo al cuadrado de aceleración, sean suficientes para calcular posición dentro de los 20 metros y velocidad dentro de los 0,2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones del dispositivo Watch incluyen un giroscopio de 3 ejes,:

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

Ver implementaciones de dispositivos:

  • [ 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 conocida como partición "/data").

  • [ 7.6 .1/W-0-2] DEBE tener al menos 416 MB de memoria disponible para el kernel y el espacio de 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

Ver implementaciones de dispositivos:

  • [ 3 /W-0-1] DEBE declarar la característica android.hardware.type.watch .
  • [ 3 /W-0-2] DEBE admitir uiMode = UI_MODE_TYPE_WATCH .
  • [ 3.2.3.1 /W-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .

Ver implementaciones de dispositivos:

  • [ 3.8 .4/W-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para manejar la acción de asistencia .

Observe las implementaciones de dispositivos que declaran el indicador de función android.hardware.audio.output :

  • [ 3.10 /W-1-1] DEBE admitir servicios de accesibilidad de terceros.
  • [ 3.10 /W-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad Switch Access y TalkBack (para idiomas admitidos por el motor de texto a voz preinstalado) según lo dispuesto en el proyecto de código abierto talkback .

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

  • [ 3.11 /W-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un motor TTS que admita los idiomas disponibles en el dispositivo.

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

2.4.4. Rendimiento y potencia

Si las implementaciones de dispositivos Watch incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o amplían las funciones que se incluyen en AOSP, estas:

  • [ 8.3 /W-SR-1] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze.
  • [ 8.3 /W-SR-2] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.

Ver implementaciones de dispositivos:

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

2.4.5. Modelo de seguridad

Ver implementaciones de dispositivos:

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

Si las implementaciones de dispositivos Watch incluyen varios usuarios y no declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /W-1-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

Si las implementaciones de dispositivos Watch incluyen varios usuarios y declaran la marca de función android.hardware.telephony , estos:

  • [ 9.5 /W-2-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir o deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

2.5. Requisitos automotrices

La implementación de Android Automotive se refiere a la unidad principal de un vehículo que ejecuta Android como sistema operativo para parte o la totalidad del sistema y/o la funcionalidad de infoentretenimiento.

Las implementaciones de dispositivos Android se clasifican como automotrices si declaran la característica android.hardware.type.automotive o cumplen con todos los criterios siguientes.

  • Están integrados como parte de un vehículo automotor o se pueden conectar a él.
  • Están utilizando una pantalla en la fila del asiento del conductor como pantalla principal.

Los requisitos adicionales en el resto de esta sección son específicos de las implementaciones de dispositivos Android Automotive.

2.5.1. Hardware

Implementaciones de dispositivos automotrices:

  • [ 7.1 .1.1/A-0-1] DEBE tener una pantalla de al menos 6 pulgadas de tamaño diagonal físico.
  • [ 7.1 .1.1/A-0-2] DEBE tener un diseño de tamaño de pantalla de al menos 750 dp x 480 dp.

  • [ 7.2 .3/A-0-1] DEBE proporcionar la función Inicio y PUEDE proporcionar funciones Atrás y Recientes.

  • [ 7.2 .3/A-0-2] DEBE enviar tanto el evento de pulsación normal como el de pulsación larga de la función Atrás ( KEYCODE_BACK ) a la aplicación de primer plano.

  • [ 7.3 /A-0-1] DEBE implementar e informar GEAR_SELECTION , NIGHT_MODE , PERF_VEHICLE_SPEED y PARKING_BRAKE_ON .

  • [ 7.3 /A-0-2] El valor del indicador NIGHT_MODE DEBE ser consistente con el modo día/noche del tablero y DEBE basarse en la entrada del sensor de luz ambiental. El sensor de luz ambiental subyacente PUEDE ser el mismo que el fotómetro .

  • [ 7.3 /A-0-3] DEBE proporcionar el campo de información adicional del sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor proporcionado.

  • [ 7.3 /A-0-1] PUEDE ubicación por estima fusionando GPS/GNSS con sensores adicionales. Si se considera la ubicación , se RECOMIENDA ENCARECIDAMENTE implementar e informar los tipos de sensores correspondientes y/o las identificaciones de propiedad del vehículo utilizadas.

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

Si las implementaciones de dispositivos automotrices son compatibles con OpenGL ES 3.1,:

  • [ 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 Vulkan y exportar todos los símbolos.

Si las implementaciones de dispositivos automotrices incluyen un acelerómetro de 3 ejes,:

Si las implementaciones de dispositivos automotrices incluyen un giroscopio de 3 ejes,:

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

Si las implementaciones de dispositivos automotrices incluyen un receptor GPS/GNSS, pero no incluyen conectividad de datos basada en red celular,:

  • [ 7.3 .3/A-3-1] DEBE determinar la ubicación la primera vez que se enciende el receptor GPS/GNSS o después de más de 4 días dentro de 60 segundos.
  • [ 7.3 .3/A-3-2] DEBE cumplir con los criterios de tiempo para la primera localización como se describe 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, solicitudes que no son la primera vez o después de más de 4 días). El requisito 7.3.3/C-1-2 normalmente se cumple en vehículos sin conectividad de datos basada en red celular, mediante el uso de predicciones de órbita GNSS calculadas en el receptor, o utilizando la última ubicación conocida del vehículo junto con la capacidad de estimar al menos al menos 60 segundos con una precisión de posición que satisfaga 7.3.3/C-1-3 , o una combinación de ambos.

Implementaciones de dispositivos automotrices:

  • [ 7.4 .3/A-0-1] DEBE admitir Bluetooth y DEBE admitir Bluetooth LE.
  • [ 7.4 .3/A-0-2] Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles de Bluetooth:
    • Llamadas telefónicas a través del perfil manos libres (HFP).
    • Reproducción de medios a través del perfil de distribución de audio (A2DP).
    • Control de reproducción multimedia a través del perfil de control remoto (AVRCP).
    • Compartir contactos mediante el perfil de acceso a la agenda telefónica (PBAP).
  • [ 7.4 .3/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE admitir el perfil de acceso a mensajes (MAP).

  • [ 7.4.5 /A] DEBE incluir soporte para conectividad de datos basada en redes celulares.

  • [ 7.4.5 /A] PUEDE usar la constante API del sistema NetworkCapabilities#NET_CAPABILITY_OEM_PAID para redes que deberían estar disponibles para las aplicaciones del sistema.

Una cámara de visión exterior es una cámara que captura escenas fuera de la implementación del dispositivo, como una cámara para tablero.

Implementaciones de dispositivos automotrices:

  • DEBE incluir una o más cámaras de visión exterior.

Si las implementaciones de dispositivos automotrices incluyen una cámara de visión exterior, para dicha cámara:

  • [ 7.5 /A-1-1] NO DEBEN tener cámaras de visión exterior accesibles a través de las API de cámara de Android , a menos que cumplan con los requisitos básicos de la cámara.
  • [ 7.5 /A-SR-1] Se RECOMIENDA ENCARECIDAMENTE no rotar ni reflejar horizontalmente la vista previa de la cámara.
  • [ 7.5 .5/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE orientarlas de manera que la dimensión larga de la cámara se alinee con el horizonte.
  • [ 7.5 /A-SR-2] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de al menos 1,3 megapíxeles.
  • DEBE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
  • DEBE admitir el marco de sincronización de Android .
  • PUEDE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara.

Implementaciones de dispositivos automotrices:

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

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

Si las implementaciones de dispositivos automotrices proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble,:

  • [ 7.6 .1/A-SR-1] Se RECOMIENDAN ENCARECIDAMENTE para reducir la sobrecarga de E/S en las operaciones realizadas en el almacenamiento externo, por ejemplo, mediante el uso SDCardFS .

Si las implementaciones de dispositivos automotrices son de 32 bits:

  • [ 7.6 .1/A-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 512 MB si se utiliza cualquiera de las siguientes densidades:

    • 280 ppp o menos en pantallas pequeñas/normales
    • ldpi o inferior en pantallas extra grandes
    • mdpi o inferior en pantallas grandes
  • [ 7.6 .1/A-1-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 608 MB si se utiliza cualquiera de las siguientes densidades:

    • xhdpi o superior en pantallas pequeñas/normales
    • hdpi o superior en pantallas grandes
    • mdpi o superior en pantallas extra grandes
  • [ 7.6 .1/A-1-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si se utiliza cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes
  • [ 7.6 .1/A-1-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1344 MB si se utiliza cualquiera de las siguientes densidades:

    • 560 ppp o más en pantallas pequeñas/normales
    • 400 ppp o más en pantallas grandes
    • xhdpi o superior en pantallas extra grandes

Si las implementaciones de dispositivos automotrices son de 64 bits:

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

    • 280 ppp o menos en pantallas pequeñas/normales
    • ldpi o inferior en pantallas extra grandes
    • mdpi o inferior en pantallas grandes
  • [ 7.6 .1/A-2-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si se utiliza cualquiera de las siguientes densidades:

    • xhdpi o superior en pantallas pequeñas/normales
    • hdpi o superior en pantallas grandes
    • mdpi o superior en pantallas extra grandes
  • [ 7.6 .1/A-2-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se utiliza cualquiera de las siguientes densidades:

    • 400 ppp o más en pantallas pequeñas/normales
    • xhdpi o superior en pantallas grandes
    • tvdpi o superior en pantallas extra grandes
  • [ 7.6 .1/A-2-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1824 MB si se utiliza cualquiera de las siguientes densidades:

    • 560 ppp o más en pantallas pequeñas/normales
    • 400 ppp o más en pantallas grandes
    • xhdpi o superior en pantallas extra grandes

Tenga en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior se refiere al espacio de memoria proporcionado además de cualquier memoria ya dedicada a componentes de hardware como radio, video, etc. que no están bajo el control del kernel en las implementaciones del dispositivo.

Implementaciones de dispositivos automotrices:

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

Implementaciones de dispositivos automotrices:

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

Implementaciones de dispositivos automotrices:

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

2.5.2. Multimedia

Las implementaciones de dispositivos automotrices DEBEN admitir los siguientes formatos de codificación y decodificación de audio 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 de bajo retardo mejorado)

Las implementaciones de dispositivos automotrices DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de aplicaciones de terceros:

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

Las implementaciones de dispositivos automotrices DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de aplicaciones de terceros:

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

Se RECOMIENDA ENCARECIDAMENTE que las implementaciones de dispositivos automotrices admitan la siguiente decodificación de video:

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

2.5.3. Software

Implementaciones de dispositivos automotrices:

  • [ 3 /A-0-1] DEBE declarar la característica android.hardware.type.automotive .

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

  • [ 3 /A-0-3] DEBE admitir todas las API públicas en el espacio de nombres android.car.* .

Si las implementaciones de dispositivos automotrices proporcionan una API patentada mediante android.car.CarPropertyManager con android.car.VehiclePropertyIds ,:

  • [ 3 /A-1-1] NO DEBE otorgar privilegios especiales al uso de estas propiedades por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros utilicen estas propiedades.
  • [ 3 /A-1-2] NO DEBE replicar una propiedad del vehículo que ya existe en el SDK .

Implementaciones de dispositivos automotrices:

  • [ 3.2 .1/A-0-1] DEBE admitir y hacer cumplir todas las constantes de permisos según lo documentado en la página de referencia de permisos automotrices .

  • [ 3.2.3.1 /A-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .

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

  • [ 3.8 .3/A-0-1] DEBE mostrar notificaciones que utilicen la API Notification.CarExtender cuando las soliciten aplicaciones de terceros.

  • [ 3.8 .4/A-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para manejar la acción de asistencia .

Si las implementaciones de dispositivos automotrices incluyen un botón de pulsar para hablar,:

  • [ 3.8 .4/A-1-1] DEBE utilizar una pulsación breve del botón pulsar para hablar como interacción designada para iniciar la aplicación de asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService .

Implementaciones de dispositivos automotrices:

  • [ 3.8.3.1 /A-0-1] DEBE representar correctamente los recursos como se describe en la documentación Notifications on Automotive OS .
  • [ 3.8.3.1 /A-0-2] DEBE mostrar PLAY y MUTE para las acciones de notificación en lugar de las proporcionadas a través de Notification.Builder.addAction()
  • [ 3.8.3.1 /A] DEBE restringir el uso de tareas de administración enriquecidas, como controles por canal de notificación. PUEDE utilizar la disponibilidad de UI por aplicación para reducir los controles.

Si las implementaciones de dispositivos automotrices admiten propiedades HAL de usuario, estas:

Implementaciones de dispositivos automotrices:

Si las implementaciones de dispositivos automotrices incluyen una aplicación de inicio predeterminada, estas:

Implementaciones de dispositivos automotrices:

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

2.5.4. Rendimiento y potencia

Implementaciones de dispositivos automotrices:

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

2.5.5. Modelo de seguridad

Si las implementaciones de dispositivos automotrices admiten varios usuarios, estos:

Implementaciones de dispositivos automotrices:

  • [ 9.11 /A-0-1] DEBE realizar 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 algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de las familias MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos admitidos del sistema Android Keystore en un área que esté aislada de forma segura. del código que se ejecuta en el kernel y superior. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [ 9.11 /A-0-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislada y solo cuando tenga éxito, permita que se utilicen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El proyecto de código abierto de Android proporciona la capa de abstracción de hardware Gatekeeper (HAL) y Trusty, que se pueden utilizar para satisfacer este requisito.
  • [ 9.11 /A-0-4] DEBE admitir la atestación de clave donde la clave de firma de la atestación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una cantidad suficiente de dispositivos para evitar que se utilicen como identificadores de dispositivos. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.
  • [9/A-0-1] DEBE declarar la característica 'android.hardware.security.model.compatible'.

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

Implementaciones de dispositivos automotrices:

  • [ 9.14 /A-0-1] DEBE controlar los mensajes de los subsistemas del vehículo del marco Android, por ejemplo, enumerando los tipos de mensajes permitidos y las fuentes de mensajes.
  • [ 9.14 /A-0-2] DEBE vigilar los ataques de denegación de servicio desde el marco de Android o aplicaciones de terceros. Esto protege contra software malicioso que inunda la red del vehículo con tráfico, lo que puede provocar un mal funcionamiento de los subsistemas del vehículo.

2.5.6. Compatibilidad de opciones y herramientas de desarrollador

Implementaciones de dispositivos automotrices:

2.6. Requisitos de la tableta

Un dispositivo tableta Android se refiere a una implementación de dispositivo Android que normalmente cumple con todos los criterios siguientes:

  • Se utiliza sosteniéndolo con ambas manos.
  • No tiene configuración tipo clamshell o convertible.
  • Las implementaciones de teclado físico utilizadas con el dispositivo se conectan mediante una conexión estándar (por ejemplo, USB, Bluetooth).
  • Tiene una fuente de energía que proporciona movilidad, como una batería.
  • Tiene un tamaño de pantalla mayor a 7” y menor a 18”, medida en diagonal.

Las implementaciones de dispositivos de tableta tienen requisitos similares a los de las implementaciones de dispositivos portátiles. Las excepciones se indican con un * en esa sección y se anotan como referencia en esta sección.

2.6.1. Hardware

Giroscopio

Si las implementaciones de dispositivos Tablet incluyen un giroscopio de 3 ejes,:

  • [ 7.3 .4/Tab-1-1] DEBE ser capaz de medir cambios de orientación de hasta 1000 grados por segundo.

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

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

Modo periférico USB (Sección 7.7.1)

Si las implementaciones de dispositivos de tableta incluyen un puerto USB que admite el modo periférico:

  • [ 7.7.1 /Tab] PUEDE implementar la API del accesorio abierto de Android (AOA).

Modo de realidad virtual (Sección 7.9.1)

Realidad virtual de alto rendimiento (Sección 7.9.2)

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

2.6.2. Modelo de seguridad

Claves y Credenciales (Sección 9.11)

Consulte la Sección [ 9.11 ].

Si las implementaciones de dispositivos Tablet incluyen varios usuarios y no declaran el indicador de función android.hardware.telephony , estos:

  • [ 9.5 /T-1-1] DEBE admitir perfiles restringidos, una característica que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las aplicaciones que están disponibles en esos entornos.

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

  • [ 9.5 /T-2-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para permitir/deshabilitar el acceso de otros usuarios a las llamadas de voz y SMS.

2.6.2. Software

  • [ 3.2.3.1 /Tab-0-1] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicación enumeradas aquí .

3.software

3.1. Compatibilidad de API administrada

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

Implementaciones de dispositivos:

  • [C-0-1] DEBE proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android o cualquier API decorada con el marcador "@SystemApi" en el código fuente de Android.

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

  • [C-0-3] NO DEBE omitir ninguna API administrada, alterar las interfaces o firmas de la API, desviarse del comportamiento documentado ni incluir operaciones no operativas, excepto donde lo permita específicamente esta Definición de compatibilidad.

  • [C-0-4] DEBE mantener las API presentes y comportarse de manera razonable, incluso cuando se omiten algunas funciones de hardware para las cuales Android incluye API. Consulte la sección 7 para conocer los requisitos específicos para este escenario.

  • [C-0-5] NO DEBE permitir que aplicaciones de terceros utilicen interfaces que no sean SDK, que se definen como métodos y campos en los paquetes de lenguaje Java que se encuentran en la ruta de clase de inicio en AOSP y que no forman parte del SDK público. Esto incluye las API decoradas con la anotación @hide pero no con @SystemAPI , como se describe en los documentos del SDK y los miembros de clase privados y de paquete privado.

  • [C-0-6] DEBE enviarse con todas y cada una de las interfaces que no sean SDK en las mismas listas restringidas proporcionadas a través de los indicadores de lista provisional y de lista de denegación en la ruta prebuilts/runtime/appcompat/hiddenapi-flags.csv para la rama de nivel de API adecuada en la AOSP.

  • [C-0-7] DEBE admitir el mecanismo de actualización dinámica de configuración firmada para eliminar interfaces que no son SDK de una lista restringida mediante la incorporación de configuración firmada en cualquier APK, utilizando las claves públicas existentes presentes en AOSP.

    Sin embargo ellos:

    • MAYO, si una API oculta está ausente o se implementa de manera diferente en la implementación del dispositivo, mueva la API oculta a la lista de rechazados u omítala de todas las listas restringidas.
    • MAYO, si aún no existe una API oculta en el AOSP, agregue la API oculta a cualquiera de las listas restringidas.

3.1.1. Extensiones de Android

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

Implementaciones de dispositivos Android:

  • [C-0-1] DEBE precargar la implementación AOSP tanto de la biblioteca compartida ExtShared como de los servicios ExtServices con versiones mayores o iguales a las versiones mínimas permitidas por cada nivel de API. Por ejemplo, las implementaciones de dispositivos Android 7.0 que ejecutan el nivel API 24 DEBEN incluir al menos la versión 1.

  • [C-0-2] DEBE devolver únicamente un número de versión de extensión válido que haya sido definido por el AOSP.

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

3.1.2. Biblioteca de Android

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

  • [C-0-1] NO DEBE colocar la biblioteca org.apache.http.legacy en bootclasspath.
  • [C-0-2] DEBE agregar la biblioteca org.apache.http.legacy al classpath de la aplicación solo cuando la aplicación satisface una de las siguientes condiciones:
    • Apunta al nivel API 28 o inferior.
    • Declara en su manifiesto que necesita la biblioteca configurando el atributo android:name de <uses-library> en org.apache.http.legacy .

La implementación de AOSP cumple con estos requisitos.

3.2. Compatibilidad de API suave

Además de las API administradas de la sección 3.1 , Android también incluye una importante API "suave" solo en tiempo de ejecución, en forma de intenciones, permisos y aspectos similares de las aplicaciones de Android que no se pueden aplicar en el momento de la compilación de la aplicación.

3.2.1. Permisos

  • [C-0-1] Los implementadores de dispositivos DEBEN admitir y hacer cumplir todas las constantes de permisos según lo documentado en la página de referencia de permisos . Tenga en cuenta que la sección 9 enumera requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de construcción

Las API de Android incluyen una serie de constantes en la clase android.os.Build cuyo objetivo es describir el dispositivo actual.

  • [C-0-1] Para proporcionar valores coherentes y significativos en todas las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que DEBEN ajustarse las implementaciones de dispositivos.
Parámetro Detalles
VERSIÓN.LIBERACIÓN La versión del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en Cadenas de versión permitidas para Android 12 .
VERSIÓN.SDK La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 12, este campo DEBE tener el valor entero 12_INT.
VERSIÓN.SDK_INT La versión del sistema Android que se ejecuta actualmente, en un formato accesible al código de aplicación de terceros. Para Android 12, este campo DEBE tener el valor entero 12_INT.
VERSIÓN.INCREMENTAL Un valor elegido por el implementador del dispositivo que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO DEBE reutilizarse para diferentes compilaciones disponibles para los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de fuente se utilizó para generar la compilación. El valor de este campo DEBE poder codificarse como ASCII imprimible de 7 bits y coincidir con la expresión regular “^[^ :\/~]+$”.
JUNTA Un valor elegido por el implementador del dispositivo que identifica el hardware interno específico utilizado por el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
MARCA Un valor que refleja la marca asociada con el dispositivo tal como la conocen los usuarios finales. DEBE estar en formato legible por humanos y DEBE representar al fabricante del dispositivo o la marca de la empresa bajo la cual se comercializa el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad API nativa .
SOPORTE_32_BIT_ABIS El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad API nativa .
SOPORTE_64_BIT_ABIS El nombre del segundo conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad API nativa .
CPU_ABI El nombre del conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad API nativa .
CPU_ABI2 El nombre del segundo conjunto de instrucciones (tipo de CPU + convención ABI) del código nativo. Ver sección 3.3. Compatibilidad API nativa .
DISPOSITIVO Un valor elegido por el implementador del dispositivo que contiene el nombre del desarrollo o el nombre del código que identifica la configuración de las características del hardware y el diseño industrial del dispositivo. El valor de este campo DEBE poder codificarse 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 la vida útil del producto.
HUELLA DACTILAR Una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla:

$(MARCA)/$(PRODUCTO)/
$(DISPOSITIVO):$(VERSIÓN.LIBERACIÓN)/$(ID)/$(VERSIÓN.INCREMENTAL):$(TIPO)/$(TAGS)

Por ejemplo:

cima/miproducto/
mi dispositivo: 12/LMYXX/3359: userdebug/test-keys

La huella digital NO DEBE incluir espacios en blanco. El valor de este campo DEBE poder codificarse como ASCII de 7 bits.

HARDWARE El nombre del hardware (de la línea de comando del kernel o /proc). DEBE ser razonablemente legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ANFITRIÓN Una cadena que identifica de forma única el host en el que se creó la compilación, en formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
IDENTIFICACIÓN Un identificador elegido por el implementador del dispositivo para hacer referencia a una versión específica, en formato legible por humanos. Este campo puede ser el mismo que android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE El nombre comercial del fabricante de equipos originales (OEM) del producto. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
SOC_MANUFACTURADOR El nombre comercial del fabricante del sistema primario en chip (SOC) utilizado en el producto. Los dispositivos con el mismo fabricante de SOC deben utilizar el mismo valor constante. Pregunte al fabricante del SOC cuál es la constante correcta a utilizar. El valor de este campo DEBE poder codificarse como ASCII de 7 bits, DEBE coincidir con la expresión regular “^([0-9A-Za-z ]+)”, NO DEBE comenzar ni terminar con espacios en blanco y NO DEBE ser igual a “ desconocido". Este campo NO DEBE cambiar durante la vida útil del producto.
SOC_MODEL El nombre del modelo del sistema primario en un chip (SOC) utilizado en el producto. Los dispositivos con el mismo modelo de SOC deben utilizar el mismo valor constante. Pregunte al fabricante del SOC cuál es la constante correcta a utilizar. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^([0-9A-Za-z ._/+-]+)$”, NO DEBE comenzar ni terminar con espacios en blanco, y DEBE NO ser igual a “desconocido”. Este campo NO DEBE cambiar durante la vida útil del producto.
MODELO Un valor elegido por el implementador del dispositivo que contiene el nombre del dispositivo tal como lo conoce el usuario final. Este DEBE ser el mismo nombre con el que se comercializa y vende el dispositivo a los usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
PRODUCTO Un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre en código del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente está destinado a ser visto por usuarios finales. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este producto NO DEBE cambiar durante la vida útil del producto.
ODM_SKU Un valor opcional elegido por el implementador del dispositivo que contiene SKU (Unidad de mantenimiento de stock) utilizado para rastrear configuraciones específicas del dispositivo, por ejemplo, cualquier periférico incluido con el dispositivo cuando se vende. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “[0-9A-Za-z.,_-])"
DE SERIE DEBE devolver "DESCONOCIDO".
ETIQUETAS Una lista de etiquetas separadas por comas elegidas por el implementador del dispositivo que distingue aún más la compilación. Las etiquetas DEBEN poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+” y DEBEN tener uno de los valores correspondientes a las tres configuraciones de firma típicas de la plataforma Android: lanzamiento- claves, claves de desarrollo y claves de prueba.
TIEMPO Un valor que representa la marca de tiempo de cuando ocurrió la compilación.
TIPO Un valor elegido por el implementador del dispositivo que especifica la configuración de tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: usuario, usuariodebug o eng.
USUARIO Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
PARCHE_SEGURIDAD Un valor que indica el nivel del parche de seguridad de una compilación. DEBE significar que la compilación no es de ninguna manera vulnerable a ninguno de los problemas descritos en el Boletín de Seguridad Pública de Android designado. DEBE tener el formato [AAAA-MM-DD] y coincidir con una cadena definida documentada en el Boletín de seguridad pública de Android o en el Aviso de seguridad de Android , por ejemplo, "2015-11-01".
SO_BASE Un valor que representa el parámetro FINGERPRINT de la compilación que, por lo demás, es idéntico 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 dicha compilación no existe, informar una cadena vacía ("").
CARGADOR DE ARRANQUE Un valor elegido por el implementador del dispositivo que identifica la versión específica del gestor de arranque interno utilizada en el dispositivo, en formato legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
obtenerVersiónRadio() DEBE (ser o devolver) un valor elegido por el implementador del dispositivo que identifique la versión interna específica de radio/módem utilizada en el dispositivo, en formato legible por humanos. Si un dispositivo no tiene ninguna radio/módem interno, DEBE devolver NULL. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.
obtener serie() DEBE (ser o devolver) un número de serie de hardware, que DEBE estar disponible y ser único en todos los dispositivos con el mismo MODELO y FABRICANTE. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.

3.2.3. Compatibilidad de intenciones

3.2.3.1. Intenciones de aplicación comunes

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

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones, para todos los patrones de filtro de intenciones públicas definidos por las siguientes intenciones de aplicaciones enumeradas aquí y proporcionar cumplimiento, es decir, cumplir con las expectativas del desarrollador para estas intenciones de aplicación comunes como se describe en el SDK.

Consulte la Sección 2 para conocer las intenciones de aplicación obligatorias para cada tipo de dispositivo.

3.2.3.2. Resolución de intención
  • [C-0-1] Como Android es una plataforma extensible, las implementaciones de dispositivos DEBEN permitir que cada patrón de intención al que se hace referencia en la sección 3.2.3.1 , excepto la Configuración, sea anulado por aplicaciones de terceros. La implementación de código abierto de Android permite esto de forma predeterminada.

  • [C-0-2] Los implementadores de dispositivos NO DEBEN otorgar privilegios especiales al uso de estos patrones de intención por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros se vinculen y asuman el control de estos patrones. Esta prohibición incluye específicamente, entre otras, la desactivación de la interfaz de usuario "Selector" que permite al usuario seleccionar entre múltiples aplicaciones que manejan el mismo patrón de intención.

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

  • Sin embargo, las implementaciones de dispositivos PUEDEN proporcionar actividades predeterminadas para patrones de URI específicos (por ejemplo, http://play.google.com) cuando la actividad predeterminada proporciona un atributo más específico para el URI de datos. Por ejemplo, un patrón de filtro de intención que especifica el URI de datos "http://www.android.com" es más específico que el patrón de intención principal del navegador para "http://".

Android también incluye un mecanismo para que las aplicaciones de terceros declaren un comportamiento de vinculación de aplicaciones predeterminado autorizado para ciertos tipos de intenciones de URI web. Cuando dichas declaraciones autorizadas se definen en los patrones de filtro de intención de una aplicación, las implementaciones del dispositivo:

  • [C-0-4] DEBE intentar validar cualquier filtro de intención realizando los pasos de validación definidos en la especificación de Enlaces de activos digitales implementada por el Administrador de paquetes en el Proyecto de código abierto de Android ascendente.
  • [C-0-5] DEBE intentar la validación de los filtros de intención durante la instalación de la aplicación y configurar todos los filtros de intención de URI validados correctamente como controladores de aplicaciones predeterminados para sus URI.
  • PUEDE establecer filtros de intención de URI específicos como controladores de aplicaciones predeterminados para sus URI, si se verifican correctamente pero otros filtros de URI candidatos no superan la verificación. Si la implementación de un dispositivo hace esto, DEBE proporcionar al usuario anulaciones de patrones por URI apropiadas en el menú de configuración.
  • DEBE proporcionar al usuario controles de enlaces de aplicaciones por aplicación en Configuración de la siguiente manera:
    • [C-0-6] El usuario DEBE poder anular de manera integral el comportamiento predeterminado de los enlaces de aplicaciones para que una aplicación esté: siempre abierta, siempre preguntando o nunca abierta, lo que debe aplicarse a todos los filtros de intención de URI candidatos por igual.
    • [C-0-7] El usuario DEBE poder ver una lista de los filtros de intención de URI candidatos.
    • La implementación del dispositivo PUEDE proporcionar al usuario la capacidad de anular filtros de intención de URI candidatos específicos que se verificaron con éxito, por filtro por intención.
    • [C-0-8] La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intención de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros de intención de URI candidatos tengan éxito en la verificación mientras que otros pueden fallar.
3.2.3.3. Espacios de nombres de intención
  • [C-0-1] Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier intención nueva o patrón de intención de transmisión utilizando una ACCIÓN, CATEGORÍA u 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 respete cualquier intención nueva o patrón de intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete que pertenece a otra organización.
  • [C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni ampliar ninguno de los patrones de intención enumerados en la sección 3.2.3.1 .
  • Las implementaciones de dispositivos PUEDEN incluir patrones de intención que utilizan espacios de nombres asociados clara y obviamente con su propia organización. Esta prohibición es análoga a la especificada para las clases de lenguaje Java en la sección 3.6 .
3.2.3.4. Intenciones de transmisión

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

Implementaciones de dispositivos:

  • [C-0-1] DEBE transmitir las intenciones de transmisión pública enumeradas aquí en respuesta a los eventos apropiados del sistema, como se describe en la documentación del SDK. Tenga en cuenta que este requisito no entra en conflicto con la sección 3.5, ya que la limitación para aplicaciones en segundo plano también se describe en la documentación del SDK. Además, ciertos intentos de transmisión están condicionados a la compatibilidad con el hardware; si el dispositivo admite el hardware necesario, DEBEN transmitir los intentos y proporcionar el comportamiento en línea con la documentación del SDK.
3.2.3.5. Intenciones de aplicación condicional

Android incluye configuraciones que brindan a los usuarios una manera fácil de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla de inicio o SMS.

Cuando tenga sentido, las implementaciones de dispositivos DEBEN proporcionar un menú de configuración similar y ser compatibles con el patrón de filtro de intención y los métodos API que se describen en la documentación del SDK como se muestra a continuación.

Si las implementaciones de dispositivos informan android.software.home_screen ,:

  • [C-1-1] DEBE respetar la intención de android.settings.HOME_SETTINGS de mostrar un menú de configuración de aplicación predeterminado para la pantalla de inicio.

Si las implementaciones de dispositivos informan android.hardware.telephony ,:

Si las implementaciones de dispositivos informan android.hardware.nfc.hce ,:

  • [C-3-1] DEBE respetar la intención de android.settings.NFC_PAYMENT_SETTINGS de mostrar un menú de configuración de aplicación predeterminado para pagos sin contacto.
  • [C-3-2] DEBE respetar la intención de android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT de mostrar una actividad que abre un cuadro de diálogo para solicitar al usuario que cambie el servicio de emulación de tarjetas predeterminado para una determinada categoría, como se describe en el SDK.

Si las implementaciones de dispositivos informan android.hardware.nfc ,:

Si las implementaciones de dispositivos informan android.hardware.bluetooth ,:

Si las implementaciones de dispositivos admiten la función DND,:

  • [C-6-1] DEBE implementar una actividad que responda a la intención ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS , que para implementaciones con UI_MODE_TYPE_NORMAL DEBE ser una actividad en la que el usuario pueda otorgar o denegar a la aplicación el acceso a las configuraciones de la política DND.

Si las implementaciones del dispositivo permiten a los usuarios utilizar métodos de entrada de terceros en el dispositivo, ellos:

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

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, estos:

  • [C-8-1] DEBE respetar la intención de android.settings.ACCESSIBILITY_SETTINGS de proporcionar un mecanismo accesible al usuario para habilitar y deshabilitar los servicios de accesibilidad de terceros junto con los servicios de accesibilidad precargados.

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Easy Connect y exponen la funcionalidad a aplicaciones de terceros, estos:

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos,:

Si las implementaciones de dispositivos no proporcionan el modo de ahorro de datos,:

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

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

Si las implementaciones de dispositivos declaran el indicador de función android.software.autofill ,:

Si las implementaciones de dispositivos incluyen una aplicación preinstalada o desean permitir que aplicaciones de terceros accedan a las estadísticas de uso, estas:

  • Se RECOMIENDA ENCARECIDAMENTE que [C-SR-2] proporcione un mecanismo accesible para el usuario para otorgar o revocar el acceso a las estadísticas de uso en respuesta a la intención android.settings.ACTION_USAGE_ACCESS_SETTINGS para aplicaciones que declaran el permiso android.permission.PACKAGE_USAGE_STATS .

Si las implementaciones de dispositivos tienen la intención de impedir que cualquier aplicación, incluidas las aplicaciones preinstaladas, acceda a las estadísticas de uso, estas:

  • [C-15-1] DEBE aún tener una actividad que maneje el patrón de intención android.settings.ACTION_USAGE_ACCESS_SETTINGS pero DEBE implementarla como no operativa, es decir, para tener un comportamiento equivalente a cuando se rechaza el acceso del usuario.

Si las implementaciones de dispositivos muestran enlaces a las actividades especificadas por AutofillService_passwordsActivity en Configuración o enlaces a contraseñas de usuarios a través de un mecanismo similar,:

  • [C-16-1] DEBE mostrar dichos enlaces para todos los servicios de autocompletar instalados.

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

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

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE respetar las intenciones android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA y android.speech.tts.engine.GET_SAMPLE_TEXT tienen una actividad para proporcionar cumplimiento a estas intenciones como descrito en el SDK aquí .

Android incluye soporte para salvapantallas interactivos, anteriormente conocidos como Dreams. Los protectores de pantalla permiten a los usuarios interactuar con aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o acoplado a una base de escritorio. Implementaciones de dispositivos:

  • DEBE incluir soporte para protectores de pantalla y proporcionar una opción de configuración para que los usuarios configuren protectores de pantalla en respuesta a la intención de android.settings.DREAM_SETTINGS .

3.2.4. Actividades en pantallas secundarias/múltiples

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

  • [C-1-1] DEBE configurar el indicador de función android.software.activities_on_secondary_displays .
  • [C-1-2] DEBE garantizar la compatibilidad de API similar a una actividad que se ejecuta en la pantalla principal.
  • [C-1-3] DEBE aterrizar la nueva actividad en la misma pantalla que la actividad que la inició, cuando la nueva actividad se inicia sin especificar una pantalla de destino a través de la API ActivityOptions.setLaunchDisplayId() .
  • [C-1-4] DEBE destruir todas las actividades cuando se elimina una pantalla con el indicador Display.FLAG_PRIVATE .
  • [C-1-5] DEBE ocultar de forma segura el contenido en todas las pantallas cuando el dispositivo está bloqueado con una pantalla de bloqueo segura, a menos que la aplicación opte por mostrarse en la parte superior de la pantalla de bloqueo usando la API Activity#setShowWhenLocked() .
  • DEBE tener android.content.res.Configuration que corresponda a esa pantalla para poder mostrarse, funcionar correctamente y mantener la compatibilidad si se inicia una actividad en la pantalla secundaria.

Si las implementaciones del dispositivo permiten iniciar actividades normales de Android en pantallas secundarias y una pantalla secundaria tiene el indicador android.view.Display.FLAG_PRIVATE :

  • [C-3-1] Solo el propietario de esa pantalla, el sistema y las actividades que ya están en esa pantalla DEBEN poder iniciarla. Todos pueden iniciar sesión en una pantalla que tenga el indicador android.view.Display.FLAG_PUBLIC .

3.3. Compatibilidad API nativa

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

  • [C-SR-1] RECOMIENDA ENCARECIDAMENTE utilizar las implementaciones de las bibliotecas que se enumeran a continuación del proyecto de código abierto de Android.

3.3.1. Interfaces binarias de aplicaciones

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

Implementaciones de dispositivos:

  • [C-0-1] DEBE ser compatible con una o más ABI NDK de Android definidas.
  • [C-0-2] DEBE incluir soporte para el código que se ejecuta en el entorno administrado para llamar al código nativo, utilizando la semántica estándar de la interfaz nativa de Java (JNI).
  • [C-0-3] DEBE ser compatible con el código fuente (es decir, compatible con el encabezado) y con el sistema binario (para ABI) con cada biblioteca requerida en la lista siguiente.
  • [C-0-5] DEBE informar con precisión la interfaz binaria de aplicación (ABI) nativa admitida por el dispositivo, a través de los parámetros android.os.Build.SUPPORTED_ABIS , android.os.Build.SUPPORTED_32_BIT_ABIS y android.os.Build.SUPPORTED_64_BIT_ABIS , cada una de las cuales es una lista separada por comas de ABI ordenadas del más al menos preferido.
  • [C-0-6] DEBE informar, a través de los parámetros anteriores, un subconjunto de la siguiente lista de ABI y NO DEBE informar ninguna ABI que no esté en la lista.

  • [C-0-7] DEBE hacer que todas las siguientes bibliotecas, que proporcionan API nativas, estén disponibles para aplicaciones que incluyen código nativo:

    • libaaudio.so (soporte de audio nativo de AAudio)
    • libamidi.so (soporte MIDI nativo, si se reclama la función android.software.midi como se describe en la Sección 5.9)
    • libandroid.so (soporte de actividad nativo de Android)
    • libc (biblioteca C)
    • libcamera2ndk.so
    • libdl (enlazador dinámico)
    • libEGL.so (gestión de superficie nativa 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 (soporte de API de medios nativos)
    • libm (biblioteca de matemáticas)
    • libneuralnetworks.so (API de redes neuronales)
    • libOpenMAXAL.so (soporte para OpenMAX AL 1.0.1)
    • libOpenSLES.so (soporte de audio OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (soporte mínimo para C++)
    • libvulkan.so (Vulkan)
    • libz (compresión Zlib)
    • interfaz JNI
  • [C-0-8] NO DEBE agregar ni eliminar las funciones públicas para las bibliotecas nativas enumeradas anteriormente.

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

  • [C-0-10] NO DEBE exponer ninguna otra biblioteca nativa, implementada y proporcionada en AOSP como bibliotecas del sistema, a aplicaciones de terceros orientadas al nivel API 24 o superior, ya que están reservadas.

  • [C-0-11] DEBE exportar todos los símbolos de función de OpenGL ES 3.1 y Android Extension Pack , tal como se define en el NDK, a través de la biblioteca libGLESv3.so . Tenga en cuenta que si bien todos los símbolos DEBEN estar presentes, la sección 7.1.4.1 describe con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.

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

  • DEBE construirse utilizando el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android.

Tenga en cuenta que las versiones futuras de Android pueden incorporar compatibilidad con ABI adicionales.

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

Si las implementaciones de dispositivos informan que son compatibles con la ABI armeabi , estas:

  • [C-3-1] También DEBE admitir armeabi-v7a e informar su compatibilidad, ya que armeabi solo es compatible con aplicaciones anteriores.

Si las implementaciones de dispositivos informan que admiten la ABI armeabi-v7a , para las aplicaciones que usan esta ABI:

  • [C-2-1] DEBE incluir las siguientes líneas en /proc/cpuinfo y NO DEBE alterar los valores en el mismo dispositivo, incluso cuando otros ABI los leen.

    • Features: , seguido de una lista de las funciones opcionales de la CPU ARMv7 admitidas por el dispositivo.
    • CPU architecture: , seguido de un número entero que describe la arquitectura ARM más compatible del dispositivo (por ejemplo, "8" para dispositivos ARMv8).
  • [C-2-2] DEBE mantener siempre disponibles las siguientes operaciones, incluso en el caso de que la ABI esté implementada en una arquitectura ARMv8, ya sea mediante soporte nativo de CPU o mediante emulación de software:

    • Instrucciones SWP y SWPB.
    • Operaciones de barrera CP15ISB, CP15DSB y CP15DMB.
  • [C-2-3] DEBE incluir soporte para la extensión Advanced SIMD (también conocida como NEON).

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

Si las implementaciones de dispositivos proporcionan una implementación completa de la API android.webkit.Webview , estas:

  • [C-1-1] DEBE informar android.software.webview .
  • [C-1-2] DEBE utilizar la compilación del Proyecto Chromium del Proyecto de código abierto de Android en la rama de Android 12 para la implementación de la API android.webkit.WebView .
  • [C-1-3] La cadena del agente de usuario reportada por WebView DEBE tener este formato:

    Mozilla/5.0 (Linux; Android $(VERSIÓN); [$(MODELO)] [Compilación/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, como Gecko) Versión/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • El valor de la cadena $(VERSION) DEBE ser el mismo que el valor de android.os.Build.VERSION.RELEASE.
    • La cadena $(MODEL) PUEDE estar vacía, pero si no está vacía DEBE tener el mismo valor que android.os.Build.MODEL.
    • "Build/$(BUILD)" PUEDE omitirse, pero si está presente, la cadena $(BUILD) 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 Mobile en la cadena del agente de usuario.
  • El componente WebView DEBE incluir soporte para tantas funciones HTML5 como sea posible y, si es compatible, la función DEBE ajustarse a la especificación HTML5 .

  • [C-1-4] DEBE representar el contenido proporcionado o el contenido de la URL remota en un proceso que sea distinto de la aplicación que crea una instancia de WebView. Específicamente, el proceso de renderizado separado DEBE tener privilegios inferiores, ejecutarse como una ID de usuario separada, no tener acceso al directorio de datos de la aplicación, no tener acceso directo a la red y solo tener acceso a los servicios mínimos requeridos del sistema a través de Binder. La implementación AOSP de WebView cumple con este requisito.

Tenga en cuenta que si las implementaciones de dispositivos son de 32 bits o declaran el indicador de función android.hardware.ram.low , están exentas de C-1-3.

3.4.2. Compatibilidad del navegador

Si las implementaciones de dispositivos incluyen una aplicación de navegador independiente para la navegación web general, estas:

  • [C-1-1] DEBE admitir cada una de estas API asociadas con HTML5:
  • [C-1-2] DEBE admitir la API de almacenamiento web HTML5/W3C y DEBE admitir la API IndexedDB HTML5/W3C. Tenga en cuenta que a medida que los organismos de estándares de desarrollo web están haciendo la transición para favorecer IndexedDB sobre el almacenamiento web, se espera que IndexedDB se convierta en un componente requerido en una versión futura de Android.
  • PUEDE enviar una cadena de agente de usuario personalizada en la aplicación de navegador independiente.
  • DEBE implementar soporte para la mayor cantidad de HTML5 posible en la aplicación de navegador independiente (ya sea basada en la aplicación de navegador WebKit anterior o en un reemplazo de terceros).

Sin embargo, si las implementaciones de dispositivos no incluyen una aplicación de navegador independiente, estas:

  • [C-2-1] DEBE seguir siendo compatible con los patrones de intención pública como se describe en la sección 3.2.3.1 .

3.5. Compatibilidad de comportamiento de API

Implementaciones de dispositivos:

  • [C-0-9] DEBE garantizar que se aplique la compatibilidad de comportamiento de API para todas las aplicaciones instaladas, a menos que estén restringidas como se describe en la Sección 3.5.1 .
  • [C-0-10] NO DEBE implementar el enfoque de lista blanca que garantiza la compatibilidad del comportamiento de API solo para aplicaciones seleccionadas por los implementadores de dispositivos.

Los comportamientos de cada uno de los tipos de API (administrada, software, nativa y web) deben ser coherentes con la implementación preferida del proyecto de código abierto de Android ascendente. Algunas áreas específicas de compatibilidad son:

  • [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento o la semántica de una intención estándar.
  • [C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida o la semántica del ciclo de vida de un tipo particular de componente del sistema (como Servicio, Actividad, Proveedor de contenido, etc.).
  • [C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
  • Los dispositivos NO DEBEN alterar las limitaciones impuestas a las aplicaciones en segundo plano. Más específicamente, para aplicaciones en segundo plano:
    • [C-0-4] DEBEN dejar de ejecutar devoluciones de llamada registradas por la aplicación para recibir resultados de GnssMeasurement y GnssNavigationMessage .
    • [C-0-5] DEBEN limitar la frecuencia de las actualizaciones que se proporcionan a la aplicación a través de la clase API LocationManager o el método WifiManager.startScan() .
    • [C-0-6] si la aplicación tiene como objetivo el nivel API 25 o superior, NO DEBEN permitir registrar receptores de transmisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la aplicación, a menos que la intención de transmisión requiera una "signature" o "signatureOrSystem" permiso protectionLevel o están en la lista de exenciones .
    • [C-0-7] si la aplicación tiene como objetivo el nivel API 25 o superior, DEBEN detener los servicios en segundo plano de la aplicación, como si la aplicación hubiera llamado al método stopSelf() de los servicios, a menos que la aplicación se coloque en una lista de permitidos temporal. para manejar una tarea que es visible para el usuario.
    • [C-0-8] si la aplicación tiene como objetivo el nivel API 25 o superior, DEBEN liberar los wakelocks que contiene la aplicación.
  • [C-0-11] Los dispositivos DEBEN devolver los siguientes proveedores de seguridad como los primeros siete valores de matriz del método Security.getProviders() , en el orden dado y con los nombres dados (según lo devuelto por Provider.getName() ) y clases , a menos que la aplicación haya modificado la lista mediante insertProviderAt() o removeProvider() . Los dispositivos PUEDEN 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. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. antes de Cristo - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. ArmoníaJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

La lista anterior no es exhaustiva. El Compatibility Test Suite (CTS) prueba partes importantes de la plataforma para determinar la compatibilidad del comportamiento, pero no todas. Es responsabilidad del implementador garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android. Por esta razón, los implementadores de dispositivos DEBEN utilizar el código fuente disponible a través del Proyecto de código abierto de Android siempre que sea posible, en lugar de volver a implementar partes importantes del sistema.

3.5.1. Restricción de aplicación

Si las implementaciones de dispositivos implementan un mecanismo propietario para restringir aplicaciones y ese mecanismo es más restrictivo que el Restricted App Standby Bucket , ellos:

  • [C-1-1] DEBE proporcionar al usuario posibilidades donde el usuario pueda ver la lista de aplicaciones restringidas.
  • [C-1-2] DEBE proporcionar al usuario la posibilidad de activar o desactivar las restricciones en cada aplicación.
  • [C-1-3] NO DEBE aplicar restricciones automáticamente sin evidencia de un comportamiento deficiente de la salud del sistema, pero PUEDE aplicar las restricciones a las aplicaciones al detectar un comportamiento deficiente de la salud del sistema, como wakelocks atascados, servicios de larga duración y otros criterios. Los criterios PUEDEN ser determinados por los implementadores del dispositivo, pero DEBEN estar relacionados con el impacto de la aplicación en el estado del sistema. Otros criterios que no estén puramente relacionados con el estado del sistema, como la falta de popularidad de la aplicación en el mercado, NO DEBEN utilizarse como criterios.
  • [C-1-4] NO DEBE aplicar automáticamente restricciones de aplicaciones cuando un usuario ha desactivado las restricciones de aplicaciones manualmente, y PUEDE sugerir al usuario que aplique restricciones de aplicaciones.
  • [C-1-5] DEBE informar a los usuarios si las restricciones de aplicación se aplican a una aplicación automáticamente. Dicha información DEBE proporcionarse dentro de las 24 horas siguientes a la aplicación de las restricciones.
  • [C-1-6] DEBE devolver true para ActivityManager.isBackgroundRestricted() cuando la aplicación restringida llama a esta API.
  • [C-1-7] NO DEBE restringir la aplicación de primer plano superior que el usuario utiliza explícitamente.
  • [C-1-8] DEBE suspender las restricciones en una aplicación que se convierte en la aplicación de primer plano cuando el usuario comienza a usar explícitamente la aplicación que solía estar restringida.
  • [C-1-9] DEBE informar todos los eventos de restricción de aplicaciones a través de UsageStats .
  • [C-1-10] NO DEBE permitir que una aplicación se coloque automáticamente en el depósito RESTRINGIDO dentro de las 2 horas posteriores al uso más reciente por parte de un usuario.

Si las implementaciones de dispositivos amplían las restricciones de las aplicaciones implementadas en AOSP, estas:

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

3.5.2. Hibernación de aplicaciones

Si las implementaciones de dispositivos incluyen la hibernación de aplicaciones incluida en AOSP o amplían la función incluida en AOSP, entonces:

  • [C-1-1] DEBE cumplir con todos los requisitos de la sección 3.5.1 excepto [C-1-6] y [C-1-3].
  • [C-1-2] Solo DEBE aplicar la restricción en la aplicación para un usuario cuando hay evidencia de que el usuario no ha utilizado la aplicación durante algún período de tiempo. Se RECOMIENDA ENCARECIDAMENTE que esta duración sea de un mes o más. El uso DEBE definirse mediante la interacción explícita del usuario a través de la API UsageStats#getLastTimeVisible() o cualquier cosa que pueda causar que una aplicación abandone el estado de detención forzada, incluidos enlaces de servicios, enlaces de proveedores de contenido, transmisiones explícitas, etc., que serán rastreados. mediante una nueva API UsageStats#getLastTimeAnyComponentUsed().
  • [C-1-3] Solo DEBE aplicar restricciones que afecten a todos los usuarios del dispositivo cuando haya evidencia de que el paquete no ha sido utilizado por NINGÚN usuario durante algún período de tiempo. Se RECOMIENDA ENCARECIDAMENTE 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 intentos de actividad, enlaces de servicios, solicitudes de proveedores de contenido o transmisiones explícitas.

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

3.6. Espacios de nombres API

Android sigue las convenciones de espacio de nombres de paquetes y clases definidas por el lenguaje de programación Java. Para garantizar la compatibilidad con aplicaciones de terceros, los implementadores de dispositivos NO DEBEN realizar modificaciones prohibidas (ver a continuación) en estos espacios de nombres de paquetes:

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

Es decir, ellos:

  • [C-0-1] NO DEBE modificar las API expuestas públicamente en la plataforma Android cambiando ningún método o firma de clase, ni eliminando clases o campos de clase.
  • [C-0-2] NO DEBE agregar ningún elemento expuesto públicamente (como clases o interfaces, o campos o métodos a clases o interfaces existentes) o API de prueba o sistema a las API en los espacios de nombres anteriores. Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide" como se usa en el código fuente de Android.

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

  • [C-0-3] NO DEBE afectar el comportamiento indicado ni la firma en lenguaje Java de ninguna API expuesta públicamente.
  • [C-0-4] NO DEBE publicitarse ni exponerse de otro modo a los desarrolladores.

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

  • [C-0-5] NO DEBE estar en un espacio de nombres que sea propiedad de otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar API al espacio de nombres com.google.* o similar: solo Google puede hacerlo. De manera similar, Google NO DEBE agregar API a los espacios de nombres de otras empresas.
  • [C-0-6] DEBE estar empaquetado en una biblioteca compartida de Android para que solo las aplicaciones que las usan explícitamente (a través del mecanismo <uses-library>) se vean afectadas por el mayor uso de memoria de dichas API.

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

  • [C-1-1] NO DEBE estar en una biblioteca del NDK o en una biblioteca propiedad de otra organización como se describe aquí .

Si un implementador de dispositivo propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando nuevas funciones útiles a una API existente o agregando una nueva API), el implementador DEBE visitar source.android.com y comenzar el proceso para contribuir con cambios y código, según la información de ese sitio.

Tenga en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar API en el lenguaje de programación Java; Esta sección simplemente tiene como objetivo reforzar esas convenciones y hacerlas vinculantes mediante su inclusión en esta Definición de compatibilidad.

3.7. Compatibilidad en tiempo de ejecución

Implementaciones de dispositivos:

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

  • [C-0-2] DEBE configurar los tiempos de ejecución de Dalvik para asignar memoria de acuerdo con la plataforma Android ascendente y como se especifica en la siguiente tabla. (Consulte la sección 7.1.1 para conocer las definiciones de tamaño y densidad de pantalla).

  • DEBE utilizar Android RunTime (ART), la implementación ascendente de referencia del formato ejecutable Dalvik y el sistema de gestión de paquetes de la implementación de referencia.

  • DEBE ejecutar pruebas difusas en varios modos de ejecución y arquitecturas de destino para garantizar la estabilidad del tiempo de ejecución. Consulte JFuzz y DexFuzz en el sitio web del Proyecto de código abierto de Android.

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

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

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Lanzador (pantalla de inicio)

Android incluye una aplicación de inicio (pantalla de inicio) y soporte para aplicaciones de terceros para reemplazar el iniciador del dispositivo (pantalla de inicio).

Si las implementaciones del dispositivo permiten que aplicaciones de terceros reemplacen la pantalla de inicio del dispositivo, estas:

  • [C-1-1] DEBE declarar la característica de la plataforma android.software.home_screen .
  • [C-1-2] DEBE devolver el objeto AdaptiveIconDrawable cuando la aplicación de terceros usa la etiqueta <adaptive-icon> para proporcionar su ícono y se llama a los métodos PackageManager para recuperar íconos.

Si las implementaciones de dispositivos incluyen un iniciador predeterminado que admite la fijación de accesos directos en la aplicación,:

Por el contrario, si las implementaciones de dispositivos no admiten la fijación de accesos directos en la aplicación, estas:

Si las implementaciones de dispositivos implementan un iniciador predeterminado que brinda acceso rápido a los accesos directos adicionales proporcionados por aplicaciones de terceros a través de la API ShortcutManager ,:

  • [C-4-1] DEBE admitir todas las funciones de acceso directo documentadas (por ejemplo, accesos directos estáticos y dinámicos, accesos directos de fijación) e implementar completamente las API de la clase API ShortcutManager .

Si las implementaciones de dispositivos incluyen una aplicación de inicio predeterminada que muestra insignias para los íconos de las aplicaciones, estas:

  • [C-5-1] DEBE respetar el método API NotificationChannel.setShowBadge() . En otras palabras, muestre una prestación visual asociada con el ícono de la aplicación si el valor está establecido como true y no muestre ningún esquema de insignias del ícono de la aplicación cuando todos los canales de notificación de la aplicación hayan establecido el valor como false .
  • PUEDE anular las insignias de íconos de aplicaciones con su esquema de insignias patentado cuando las aplicaciones de terceros indiquen compatibilidad con el esquema de insignias patentadas mediante el uso de API patentadas, pero DEBE usar los recursos y valores proporcionados a través de las API de insignias de notificación descritas en el SDK , como la API Notification.Builder.setNumber() y Notification.Builder.setBadgeIconType() .

3.8.2. widgets

Android admite widgets de aplicaciones de terceros al definir un tipo de componente y la API y el ciclo de vida correspondientes que permiten a las aplicaciones exponer un "AppWidget" al usuario final.

Si las implementaciones de dispositivos admiten widgets de aplicaciones de terceros, estos:

  • [C-1-1] DEBE declarar compatibilidad con la función de plataforma android.software.app_widgets .
  • [C-1-2] DEBE incluir soporte integrado para AppWidgets y exponer las posibilidades de la interfaz de usuario para agregar, configurar, ver y eliminar AppWidgets directamente dentro del Iniciador.
  • [C-1-3] DEBE ser capaz de representar widgets de 4 x 4 en el tamaño de cuadrícula estándar. Consulte las pautas de diseño de widgets de aplicaciones en la documentación del SDK de Android para obtener más detalles.
  • PUEDE admitir widgets de aplicaciones en la pantalla de bloqueo.

Si las implementaciones de dispositivos admiten widgets de aplicaciones de terceros y fijación de accesos directos en la aplicación,:

3.8.3. Notificaciones

Android incluye API Notification y NotificationManager que permiten a los desarrolladores de aplicaciones de terceros notificar a los usuarios sobre eventos notables y atraer la atención de los usuarios utilizando los componentes de hardware (p. ej., sonido, vibración y luz) y funciones de software (p. ej., pantalla de notificación, barra del sistema) del dispositivo. .

3.8.3.1. Presentación de Notificaciones

Si las implementaciones de dispositivos permiten que aplicaciones de terceros notifiquen a los usuarios sobre eventos importantes , estas:

  • [C-1-1] DEBE admitir notificaciones que utilizan funciones de hardware, como se describe en la documentación del SDK, y en la medida de lo posible con el hardware de implementación del dispositivo. Por ejemplo, si la implementación de un dispositivo incluye un vibrador, DEBE implementar correctamente las API de vibración. Si la implementación de un dispositivo carece de hardware, las API correspondientes DEBEN implementarse como no operativas. Este comportamiento se detalla más en la sección 7 .
  • [C-1-2] DEBEN representar correctamente todos los recursos (iconos, archivos de animación, etc.) proporcionados en las API o en la guía de estilo de iconos de la barra de estado/sistema, aunque PUEDEN proporcionar una experiencia de usuario alternativa para las notificaciones. proporcionado por la implementación de código abierto de Android de referencia.
  • [C-1-3] DEBE respetar e implementar adecuadamente los comportamientos descritos para que las API actualicen, eliminen y agrupen notificaciones.
  • [C-1-4] DEBE proporcionar el comportamiento completo de la API NotificationChannel documentada en el SDK.
  • [C-1-5] DEBE proporcionar al usuario la posibilidad de bloquear y modificar la notificación de una determinada aplicación de terceros por cada canal y nivel de paquete de aplicación.
  • [C-1-6] También DEBE proporcionar al usuario la posibilidad de mostrar canales de notificación eliminados.
  • [C-1-7] DEBE representar correctamente todos los recursos (imágenes, pegatinas, íconos, etc.) proporcionados a través de Notification.MessagingStyle junto con el texto de notificación sin interacción adicional del usuario. Por ejemplo, DEBE mostrar todos los recursos, incluidos los íconos proporcionados a través de android.app.Person , en una conversación grupal configurada a través de setGroupConversation .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar automáticamente la posibilidad de que un usuario bloquee la notificación de una determinada aplicación de terceros por cada canal y nivel de paquete de aplicación después de que el usuario descarte esa notificación varias veces.
  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-2] brindar al usuario la posibilidad de controlar las notificaciones que están expuestas a las aplicaciones a las que se les ha otorgado el permiso de escucha de notificaciones. La granularidad DEBE ser tal que el usuario pueda controlar para cada uno de estos oyentes de notificaciones qué tipos de notificaciones se conectan a este oyente. Los tipos DEBEN incluir notificaciones de "conversaciones", "alertas", "silenciosas" y "importantes en curso".
  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-3] brindar a los usuarios la posibilidad de especificar aplicaciones para excluirlas de la notificación a cualquier oyente de notificaciones específico.
  • DEBE admitir notificaciones enriquecidas.
  • DEBE presentar algunas notificaciones de mayor prioridad como notificaciones de aviso.
  • DEBE tener la posibilidad de que el usuario posponga las notificaciones.
  • PUEDE solo administrar la visibilidad y el momento en que las aplicaciones de terceros pueden notificar a los usuarios sobre eventos notables para mitigar problemas de seguridad como la distracción del conductor.

Android 11 presenta soporte para notificaciones de conversaciones, que son notificaciones que usan MessagingStyle y proporcionan una ID de acceso directo de personas publicada.

Implementaciones de dispositivos:

  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE agrupar y mostrar conversation notifications antes de las notificaciones que no son de conversación, con la excepción de las notificaciones de servicio en primer plano en curso y importance:high .

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

  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE mostrar esta conversación como una burbuja. La implementación de AOSP cumple con estos requisitos con la interfaz de usuario, la configuración y el iniciador del sistema predeterminados.

Si las implementaciones de dispositivos admiten notificaciones enriquecidas, estas:

  • [C-2-1] DEBE utilizar los recursos exactos proporcionados a través de la clase API Notification.Style y sus subclases para los elementos de recursos presentados.
  • DEBE presentar todos y cada uno de los elementos de recurso (por ejemplo, icono, título y texto de resumen) definidos en la clase API Notification.Style y sus subclases.

Si las implementaciones de dispositivos admiten notificaciones automáticas: ellas:

  • [C-3-1] DEBE utilizar la vista de notificación de aviso y los recursos como se describe en la clase API Notification.Builder cuando se presentan notificaciones de aviso.
  • [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 las API NotificationListenerService que permiten que las aplicaciones (una vez habilitadas explícitamente por el usuario) reciban una copia de todas las notificaciones a medida que se publican o actualizan.

Implementaciones de dispositivos:

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

Si las implementaciones de dispositivos permiten al usuario posponer notificaciones, estas:

  • [C-1-1] DEBE reflejar correctamente el estado de notificación pospuesta a través de las API estándar, como NotificationListenerService.getSnoozedNotifications() .
  • [C-1-2] DEBE hacer que esta opción de usuario esté disponible para posponer notificaciones de cada aplicación de terceros instalada, a menos que sean de servicios persistentes/en primer plano.
3.8.3.3. DND (No molestar)

Si las implementaciones de dispositivos admiten la función DND,:

  • [C-1-1] DEBE, cuando la implementación del dispositivo ha proporcionado un medio para que el usuario conceda o deniegue el acceso a aplicaciones de terceros a la configuración de la política DND, mostrar las reglas DND automáticas creadas por las aplicaciones junto con las reglas creadas por el usuario y previas. -reglas definidas.
  • [C-1-3] DEBE respetar los valores suppressedVisualEffects pasados ​​a lo largo de NotificationManager.Policy y si una aplicación ha configurado cualquiera de los indicadores SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEBE indicar al usuario que los efectos visuales están suprimidos en el menú de configuración DND.

3.8.4. Ayudar a las API

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

Si las implementaciones de dispositivos admiten la acción de asistencia, estas:

  • [C-2-1] DEBE indicar claramente al usuario final cuándo se comparte el contexto, ya sea por:
    • Cada vez que la aplicación de asistencia accede al contexto, muestra una luz blanca alrededor de los bordes de la pantalla que iguala o supera la duración y el brillo de la implementación del Proyecto de código abierto de Android.
    • Para la aplicación de asistencia preinstalada, proporcionar al usuario posibilidades a menos de dos navegaciones de la entrada de voz predeterminada y el menú de configuración de la aplicación de asistente , y solo compartir el contexto cuando el usuario invoca explícitamente la aplicación de asistencia a través de una palabra activa o la entrada de una tecla de navegación de asistencia.
  • [C-2-2] La 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 asistencia seleccionada por el usuario, en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que maneje la intención ACTION_ASSIST .

3.8.5. Alertas y Brindis

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

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] DEBE proporcionar al usuario la posibilidad de bloquear una aplicación para que no muestre ventanas de alerta que utilicen TYPE_APPLICATION_OVERLAY . La implementación de AOSP cumple con este requisito al tener controles en el tono de notificación.

  • [C-1-2] DEBE respetar la API de Toast y mostrar Toast desde las aplicaciones a los usuarios finales de alguna manera muy visible.

3.8.6. Temas

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

Android incluye una familia de temas "Holo" y "Material" como un conjunto de estilos definidos para que los utilicen los desarrolladores de aplicaciones si desean igualar la apariencia del tema Holo según lo definido por el SDK de Android.

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] NO DEBE alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones.
  • [C-1-2] DEBE admitir la familia de temas “Material” y NO DEBE alterar ninguno de los atributos del tema Material ni sus activos expuestos a las aplicaciones.
  • [C-1-3] DEBE configurar la familia de fuentes "sans-serif" en la versión 2.x de Roboto para los idiomas que admite Roboto, o proporcionar al usuario la posibilidad de cambiar la fuente utilizada para la familia de fuentes "sans-serif" a Roboto versión 2.x para los idiomas que admite Roboto.

Android también incluye una familia de temas "Predeterminado del dispositivo" como un conjunto de estilos definidos para que los utilicen los desarrolladores de aplicaciones si desean igualar la apariencia del tema del dispositivo según lo definido por el implementador del dispositivo.

Android admite una variante del tema con barras de sistema translúcidas, que permite a los desarrolladores de aplicaciones llenar el área detrás de la barra de estado y navegación con el contenido de su aplicación. Para permitir una experiencia de desarrollador consistente en esta configuración, es importante que el estilo del ícono de la barra de estado se mantenga en diferentes implementaciones de dispositivos.

Si las implementaciones de dispositivos incluyen una barra de estado del sistema, estas:

  • [C-2-1] DEBE usar blanco para los íconos de estado del sistema (como la intensidad de la señal y el nivel de la batería) y las notificaciones emitidas por el sistema, a menos que el ícono indique un estado problemático o una aplicación solicite una barra de estado luminosa usando WindowInsetsController# Bandera APPEARANCE_LIGHT_STATUS_BARS .
  • [C-2-2] Las implementaciones de dispositivos Android DEBEN cambiar el color de los íconos de estado del sistema a negro (para obtener más detalles, consulte R.style ) cuando una aplicación solicita una barra de estado luminosa.

3.8.7. Fondos de pantalla vivos

Android define un tipo de componente y su API y ciclo de vida correspondientes que permiten a las aplicaciones exponer uno o más "fondos de pantalla en vivo" al usuario final. Los fondos de pantalla en vivo son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como fondo de pantalla, detrás de otras aplicaciones.

Se considera que el hardware es capaz de ejecutar de manera confiable fondos de pantalla en vivo si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones de funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware provocan que los fondos de pantalla y/o las aplicaciones fallen, funcionen mal, consuman demasiada energía de la CPU o de la batería, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware es incapaz de ejecutar fondos de pantalla en vivo. Por ejemplo, algunos fondos de pantalla en vivo pueden usar un contexto OpenGL 2.0 o 3.x para representar su contenido. El fondo de pantalla en vivo no se ejecutará de manera confiable en hardware que no admita múltiples contextos OpenGL porque el uso del fondo de pantalla en vivo de un contexto OpenGL puede entrar en conflicto con otras aplicaciones que también usan un contexto OpenGL.

  • Las implementaciones de dispositivos capaces de ejecutar fondos de pantalla en vivo de manera confiable, como se describe anteriormente, DEBEN implementar fondos de pantalla en vivo.

Si las implementaciones de dispositivos implementan fondos de pantalla en vivo, estos:

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

3.8.8. Cambio de actividad

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

Las implementaciones del dispositivo, incluida la tecla de navegación de la función reciente, como se detalla en la sección 7.2.3 , PUEDEN alterar la interfaz.

Si las implementaciones del dispositivo, incluida la tecla de navegación de la función reciente, como se detalla en la sección 7.2.3 , alteran la interfaz:

  • [C-1-1] DEBE admitir al menos hasta 7 actividades mostradas.
  • DEBE mostrar al menos el título de 4 actividades a la vez.
  • [C-1-2] DEBE implementar el comportamiento de fijación de pantalla y proporcionar al usuario un menú de configuración para alternar la función.
  • DEBE mostrar el color de resaltado, el ícono y el título de la pantalla en los últimos tiempos.
  • DEBE mostrar una opción de cierre ("x") pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas.
  • DEBE implementar un atajo para cambiar fácilmente a la actividad anterior.
  • DEBE activar la acción de cambio rápido entre las dos aplicaciones utilizadas más recientemente, cuando se toca dos veces la tecla de función reciente.
  • DEBE activar el modo de ventana múltiple de pantalla dividida, si es compatible, cuando se presiona prolongadamente la tecla de funciones recientes.
  • PUEDE mostrar los últimos afiliados como un grupo que se mueve en conjunto.
  • [SR-1] Se RECOMIENDA ENCARECIDAMENTE utilizar la interfaz de usuario de Android (o una interfaz similar basada en miniaturas) para la pantalla de descripción general.

3.8.9. Gestión de entradas

Android incluye soporte para administración de entradas y soporte para editores de métodos de entrada de terceros.

Si las implementaciones del dispositivo permiten a los usuarios utilizar métodos de entrada de terceros en el dispositivo, ellos:

  • [C-1-1] DEBE declarar la característica de la plataforma android.software.input_methods y admitir API de IME como se define en la documentación del SDK de Android.

3.8.10. Control de medios de pantalla de bloqueo

La API del cliente de control remoto está obsoleta en Android 5.0 en favor de la plantilla de notificación multimedia que permite que las aplicaciones multimedia se integren con los controles de reproducción que se muestran en la pantalla de bloqueo.

3.8.11. Salvapantallas (anteriormente Dreams)

Consulte la sección 3.2.3.5 para conocer las configuraciones destinadas a configurar los protectores de pantalla.

3.8.12. Ubicación

Si las implementaciones del dispositivo incluyen un sensor de hardware (por ejemplo, GPS) que es capaz de proporcionar las coordenadas de ubicación,

3.8.13. Unicode y fuente

Android incluye soporte para los caracteres emoji definidos en Unicode 10.0 .

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] DEBE ser capaz de representar estos caracteres emoji en glifos de color.
  • [C-1-2] DEBE incluir soporte para:
    • Fuente Roboto 2 con diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para los idiomas disponibles en dispositivo.
    • Cobertura completa de Unicode 7.0 de latín, griego y cirílico, incluidos los rangos de latín extendido A, B, C y D, y todos los glifos en el bloque de símbolos de moneda de Unicode 7.0.
  • [C-1-3] NO DEBE eliminar ni modificar NotoColorEmoji.tff en la imagen del sistema. (Es aceptable agregar una nueva fuente de emoji para anular los emoji en NotoColorEmoji.tff)
  • DEBE admitir el tono de piel y diversos emojis familiares como se especifica en el Informe técnico de Unicode n.° 51 .

Si las implementaciones de dispositivos incluyen un IME,:

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

Android incluye soporte para representar fuentes de Myanmar. Myanmar tiene varias fuentes que no son compatibles con Unicode, comúnmente conocidas como “Zawgyi”, para representar idiomas de Myanmar.

Si las implementaciones de dispositivos incluyen soporte para birmano, estos:

  • [C-2-1] DEBE representar el texto con una fuente compatible con Unicode de forma predeterminada; La fuente que no sea compatible con Unicode NO DEBE establecerse como fuente predeterminada a menos que el usuario la elija en el selector de idioma.
  • [C-2-2] DEBE admitir una fuente Unicode y una fuente que no sea compatible con Unicode si el dispositivo admite una fuente que no es compatible con Unicode. La fuente que no es compatible con Unicode NO DEBE eliminar ni sobrescribir la fuente Unicode.
  • [C-2-3] DEBE representar texto con una fuente que no sea compatible con Unicode SÓLO SI se especifica un código de idioma con código de escritura Qaag (por ejemplo, my-Qaag). No se puede utilizar ningún otro código de región o idioma ISO (ya sea asignado, no asignado o reservado) para hacer referencia a fuentes que no sean compatibles con Unicode para Myanmar. Los desarrolladores de aplicaciones y autores de páginas web pueden especificar my-Qaag como código de idioma designado como lo harían con cualquier otro idioma.

3.8.14. Ventanas múltiples

Si las implementaciones de dispositivos tienen la capacidad de mostrar múltiples actividades al mismo tiempo:

  • [C-1-1] DEBE implementar dichos modos de ventanas múltiples de acuerdo con los comportamientos de las aplicaciones y las API descritos en la documentación de soporte del modo de ventanas múltiples del SDK de Android y cumplir con los siguientes requisitos:
  • [C-1-2] DEBE respetar android:resizeableActivity configurada por una aplicación en el archivo AndroidManifest.xml como se describe en este SDK .
  • [C-1-3] NO DEBE ofrecer modo de pantalla dividida o de forma 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 SE DEBE cambiar el tamaño de una actividad a un tamaño inferior a 220 ppp en modos de ventanas múltiples que no sean imagen en imagen.
  • Las implementaciones de dispositivos con tamaño de pantalla xlarge DEBEN admitir el modo de forma libre.

Si las implementaciones de dispositivos admiten modos de ventanas múltiples y el modo de pantalla dividida,:

  • [C-2-2] DEBE recortar la actividad acoplada de una ventana múltiple de pantalla dividida, pero DEBE mostrar parte de su contenido, si la aplicación Iniciador es la ventana enfocada.
  • [C-2-3] DEBE respetar los valores declarados AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight de la aplicación de inicio de terceros y no anular estos valores mientras muestra algún contenido de la actividad acoplada.

Si las implementaciones de dispositivos admiten modos de ventanas múltiples y modos de ventanas múltiples de imagen en imagen,:

  • [C-3-1] DEBE iniciar actividades en modo de ventana múltiple de imagen en imagen cuando la aplicación esté:

  • [C-3-2] DEBE exponer las acciones en su SystemUI según lo especificado por la actividad PIP actual a través de la API setActions() .

  • [C-3-3] DEBE admitir relaciones de aspecto mayores o iguales a 1:2,39 y menores o iguales a 2,39:1, según lo especificado por la actividad PIP a través de la API setAspectRatio() .

  • [C-3-4] DEBE usar KeyEvent.KEYCODE_WINDOW para controlar la ventana PIP; Si el modo PIP no está implementado, la clave DEBE estar disponible para la actividad en primer plano.

  • [C-3-5] DEBE proporcionar al usuario la posibilidad de bloquear la visualización de una aplicación en modo PIP; la implementación de AOSP cumple con este requisito al tener controles en el tono de notificación.

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

    • Los dispositivos con Configuration.uiMode configurado de manera distinta a UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho y alto mínimos de 108 dp.
    • Los dispositivos con Configuration.uiMode configurado en UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.

3.8.15. Recorte de pantalla

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

Si las implementaciones de dispositivos incluyen recortes de pantalla, estos:

  • [C-1-5] NO DEBE tener recortes 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 los indicadores de corte de pantalla establecidos por la aplicación a través de la API WindowManager.LayoutParams como se describe en el SDK.
  • [C-1-4] DEBE informar los valores correctos para todas las métricas de recorte definidas en la API DisplayCutout .

3.8.16. Controles del dispositivo

Android incluye ControlsProviderService y Control API para permitir que aplicaciones de terceros publiquen controles de dispositivos para obtener estados y acciones rápidas para los usuarios.

Consulte la Sección 2_2_3 para conocer los requisitos específicos del dispositivo.

3.9. Administración de dispositivos

Android incluye funciones que permiten que las aplicaciones conscientes de la seguridad realicen funciones de administración de dispositivos a nivel del sistema, como aplicar políticas de contraseña o realizar un borrado remoto, a través de la API de administración de dispositivos Android .

Si las implementaciones de dispositivos implementan toda la gama de políticas de administración de dispositivos definidas en la documentación del SDK de Android, estas:

  • [C-1-1] DEBE declarar android.software.device_admin .
  • [C-1-2] DEBE admitir el aprovisionamiento del propietario del dispositivo como se describe en la sección 3.9.1 y la sección 3.9.1.1 .

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

Si las implementaciones de dispositivos declaran android.software.device_admin ,:

  • [C-1-1] DEBE admitir la inscripción de un Cliente de Política de Dispositivo (DPC) como una aplicación de Propietario del Dispositivo como se describe a continuación:
    • Cuando la implementación del dispositivo aún no tiene datos de usuario configurados:
      • [C-1-5] DEBE inscribir la aplicación DPC como la aplicación Propietario del dispositivo si el dispositivo declara compatibilidad con comunicaciones de campo cercano (NFC) a través del indicador de función android.hardware.nfc y recibe un mensaje NFC que contiene un registro con tipo MIME MIME_TYPE_PROVISIONING_NFC .
      • [C-1-8] DEBE enviar la intención ACTION_GET_PROVISIONING_MODE después de que se active el aprovisionamiento del propietario del dispositivo para que la aplicación DPC pueda elegir si desea convertirse en propietario del dispositivo o propietario del perfil, a menos que se pueda determinar a partir del contexto que solo hay una opción válida ( (por ejemplo, para el aprovisionamiento basado en NFC donde no se admite el aprovisionamiento del propietario del perfil).
      • [C-1-9] DEBE enviar la intención ACTION_ADMIN_POLICY_COMPLIANCE a la aplicación del propietario del dispositivo si se establece un propietario del dispositivo durante el aprovisionamiento, independientemente del método de aprovisionamiento utilizado. El usuario no debe poder continuar con el Asistente de configuración hasta que finalice la aplicación Propietario del dispositivo.
    • Cuando la implementación del dispositivo tiene datos de usuario,:
      • [C-1-7] Ya no DEBE inscribir ninguna aplicación DPC como la aplicación del propietario del dispositivo.
  • [C-1-2] DEBE requerir alguna acción afirmativa antes o durante el proceso de aprovisionamiento para dar consentimiento a que la aplicación se establezca como Propietario del dispositivo. El consentimiento puede realizarse a través de la acción del usuario o mediante algún medio programático, pero DEBE mostrarse un aviso de divulgación apropiado (como se menciona en AOSP) antes de que se inicie el aprovisionamiento del propietario del dispositivo. Además, el mecanismo programático de consentimiento del propietario del dispositivo utilizado (por las empresas) para el aprovisionamiento del propietario del dispositivo NO DEBE interferir con la experiencia lista para usar para uso no empresarial.
  • [C-1-3] NO DEBE codificar el consentimiento ni impedir el uso de otras aplicaciones del propietario del dispositivo.

Si las implementaciones de dispositivos declaran android.software.device_admin , pero también incluyen una solución patentada de administración del propietario del dispositivo y proporcionan un mecanismo para promover una aplicación configurada en su solución como un "equivalente del propietario del dispositivo" al "propietario del dispositivo" estándar tal como lo reconoce el estándar. Las API de Android DevicePolicyManager :

  • [C-2-1] DEBE contar con un proceso para verificar que la aplicación específica que se promociona pertenece a una solución de administración de dispositivos empresariales legítima y que ya se ha configurado en la solución propietaria para tener los derechos equivalentes a los de "Propietario del dispositivo". .
  • [C-2-2] DEBE mostrar la misma divulgación de consentimiento del propietario del dispositivo AOSP que el flujo iniciado por android.app.action.PROVISION_MANAGED_DEVICE antes de inscribir la aplicación DPC como "Propietario del dispositivo".
  • PUEDE tener datos de usuario en el dispositivo antes de registrar la aplicación DPC como "Propietario del dispositivo".
3.9.1.2 Aprovisionamiento de perfil administrado

Si las implementaciones de dispositivos declaran android.software.managed_users ,:

  • [C-1-1] DEBE implementar las API que permiten que una aplicación de Controlador de políticas de dispositivos (DPC) se convierta en propietaria de un nuevo perfil administrado .

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

  • [C-1-3] DEBE proporcionar las siguientes posibilidades de usuario dentro de la Configuración para indicarle cuando el Controlador de política de dispositivos (DPC) ha desactivado una función particular del sistema:

    • Un ícono consistente u otra opción para el usuario (por ejemplo, el ícono de información de AOSP ascendente) para representar cuando un administrador de dispositivo restringe una configuración particular.
    • Un breve mensaje de explicación, proporcionado por el administrador del dispositivo a través de setShortSupportMessage .
    • El icono de la aplicación DPC.
  • [C-1-4] DEBE iniciar el controlador para la intención ACTION_PROVISIONING_SUCCESSFUL en el perfil de trabajo si se establece un propietario del perfil cuando la intención android.app.action.PROVISION_MANAGED_PROFILE inicia el aprovisionamiento y el DPC ha implementado el controlador.

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

  • [C-1-6] DEBE enviar la intención ACTION_GET_PROVISIONING_MODE después de que se activa el aprovisionamiento del propietario del perfil para que la aplicación DPC pueda elegir si desea convertirse en propietario del dispositivo o propietario del perfil, excepto cuando la intención activa el aprovisionamiento android.app.action.PROVISION_MANAGED_PROFILE .

  • [C-1-7] DEBE enviar la intención ACTION_ADMIN_POLICY_COMPLIANCE al perfil de trabajo cuando se establece un propietario del perfil durante el aprovisionamiento, independientemente del método de aprovisionamiento que se utilice, excepto cuando el aprovisionamiento lo activa la intención android.app.action.PROVISION_MANAGED_PROFILE . El usuario no debe poder continuar con el asistente de configuración hasta que finalice la aplicación Propietario del perfil.

  • [C-1-8] DEBE enviar la transmisión ACTION_MANAGED_PROFILE_PROVISIONED al DPC del perfil personal cuando se establece un propietario del perfil, independientemente del método de aprovisionamiento utilizado.

3.9.2 Soporte de perfil administrado

Si las implementaciones de dispositivos declaran android.software.managed_users ,:

  • [C-1-1] DEBE admitir perfiles administrados a través de las API android.app.admin.DevicePolicyManager .
  • [C-1-2] DEBE permitir la creación de un solo perfil administrado .
  • [C-1-3] DEBE usar una insignia de icono (similar a la insignia de trabajo ascendente de AOSP) para representar las aplicaciones y widgets administrados y otros elementos de la interfaz de usuario con insignias, como Recientes y Notificaciones.
  • [C-1-4] DEBE mostrar un ícono de notificación (similar a la insignia de trabajo ascendente de AOSP) para indicar cuando el usuario está dentro de una aplicación de perfil administrado.
  • [C-1-6] Cuando exista un perfil administrado, DEBE mostrar una opción visual en el 'Selector' de intención para permitir al usuario reenviar la intención desde el perfil administrado al usuario principal o viceversa, si lo habilita la Política del dispositivo. Controlador.
  • [C-1-7] Cuando exista un perfil administrado, DEBE exponer las siguientes posibilidades de usuario tanto para el usuario principal como para el perfil administrado:
    • Contabilidad separada para el uso de batería, ubicación, datos móviles y almacenamiento para el usuario principal y el perfil administrado.
    • Gestión independiente de aplicaciones VPN instaladas dentro del usuario principal o perfil administrado.
    • Gestión independiente de aplicaciones instaladas dentro del usuario principal o perfil administrado.
    • Gestión independiente de cuentas dentro del usuario principal o perfil administrado.
  • [C-1-8] DEBE garantizar que las aplicaciones de marcador, contactos y mensajería preinstaladas puedan buscar y consultar la información de la persona que llama desde el perfil administrado (si existe) junto con la del perfil principal, si el Controlador de políticas de dispositivo lo permite.
  • [C-1-9] DEBE garantizar que cumple con todos los requisitos de seguridad aplicables para un dispositivo con múltiples usuarios habilitados (consulte la sección 9.5 ), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.

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

  • [C-2-1] DEBE admitir la capacidad de especificar una pantalla de bloqueo separada que cumpla con los siguientes requisitos para otorgar acceso a aplicaciones que se ejecutan en un perfil administrado únicamente.
    • Las implementaciones de dispositivos DEBEN respetar la intención DevicePolicyManager.ACTION_SET_NEW_PASSWORD y mostrar una interfaz para configurar una credencial de pantalla de bloqueo separada para el perfil administrado.
    • Las credenciales de la pantalla de bloqueo del perfil administrado DEBEN utilizar los mismos mecanismos de administración y almacenamiento de credenciales que el perfil principal, como se documenta en el sitio del proyecto de código abierto de Android .
    • Las políticas de contraseña de DPC DEBEN aplicarse únicamente a las credenciales de la pantalla de bloqueo del perfil administrado, a menos que se soliciten en la instancia DevicePolicyManager devuelta por getParentProfileInstance .
  • Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la interfaz de usuario de llamadas entrantes, las notificaciones de llamadas en curso y perdidas, los contactos y las aplicaciones de mensajería, DEBEN tener la misma insignia que se usa para indicar las aplicaciones del perfil administrado.

3.9.3 Soporte de usuario administrado

Si las implementaciones de dispositivos declaran android.software.managed_users ,:

  • [C-1-1] DEBE proporcionar al usuario la posibilidad de cerrar la sesión del usuario actual y volver al usuario principal en una sesión de múltiples usuarios cuando isLogoutEnabled devuelve true . Se DEBE poder acceder a las prestaciones del usuario desde la pantalla de bloqueo sin desbloquear el dispositivo.

Si las implementaciones de dispositivos declaran android.software.device_admin y brindan al usuario en el dispositivo la posibilidad de agregar usuarios secundarios adicionales, estos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE mostrar las mismas divulgaciones de consentimiento del propietario del dispositivo AOSP que se mostraron en el flujo iniciado por android.app.action.PROVISION_MANAGED_DEVICE , antes de permitir que se agreguen cuentas en el nuevo usuario secundario, para que los usuarios comprendan que se gestiona el dispositivo.

3.10. Accesibilidad

Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos más fácilmente. Además, Android proporciona API de plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamadas para eventos del usuario y del sistema y generen mecanismos de retroalimentación alternativos, como texto a voz, retroalimentación háptica y navegación con trackball/d-pad.

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, estos:

  • [C-1-1] DEBE proporcionar una implementación del marco de accesibilidad de Android como se describe en la documentación del SDK de las API de accesibilidad .
  • [C-1-2] DEBE generar eventos de accesibilidad y entregar el AccessibilityEvent apropiado a todas las implementaciones registradas AccessibilityService como se documenta en el SDK.
  • [C-1-4] DEBE proporcionar al usuario la posibilidad de controlar los servicios de accesibilidad que declaran AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Tenga en cuenta que para las implementaciones de dispositivos con una barra de navegación del sistema, DEBEN permitir al usuario tener la opción de un botón en la barra de navegación del sistema para controlar estos servicios.

Si las implementaciones de dispositivos incluyen servicios de accesibilidad preinstalados, estos:

  • [C-2-1] DEBE implementar estos servicios de accesibilidad preinstalados como aplicaciones Direct Boot Aware cuando el almacenamiento de datos está cifrado con cifrado basado en archivos (FBE).
  • 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 fuente, el tamaño de visualización y los gestos de ampliación.

3.11. Texto a voz

Android incluye API que permiten que las aplicaciones utilicen servicios de texto a voz (TTS) y permite a los proveedores de servicios proporcionar implementaciones de servicios TTS.

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

Si las implementaciones de dispositivos admiten la instalación de motores TTS de terceros, estos:

  • [C-2-1] DEBE proporcionar al usuario posibilidades para permitirle seleccionar un motor TTS para su uso a nivel del sistema.

3.12. Marco de entrada de TV

Android Television Input Framework (TIF) simplifica la entrega de contenido en vivo a dispositivos Android Television. TIF proporciona una API estándar para crear módulos de entrada que controlan dispositivos Android Television.

Si las implementaciones de dispositivos admiten TIF, estas:

  • [C-1-1] DEBE declarar la característica de la plataforma android.software.live_tv .
  • [C-1-2] DEBE admitir todas las API TIF, de modo que se pueda instalar y utilizar en el dispositivo una aplicación que utilice estas API y el servicio de entradas de terceros basado en TIF .

3.13. Ajustes rápidos

Android proporciona un componente de interfaz de usuario de Configuración rápida que permite un acceso rápido a acciones utilizadas con frecuencia o que se necesitan con urgencia.

Si las implementaciones de dispositivos incluyen un componente de interfaz de usuario de Configuración rápida y admiten configuraciones rápidas de terceros, estas:

  • [C-1-1] DEBE permitir al usuario agregar o eliminar los mosaicos proporcionados a través de las API quicksettings desde una aplicación de terceros.
  • [C-1-2] NO DEBE agregar automáticamente un mosaico desde una aplicación de terceros directamente a la Configuración rápida.
  • [C-1-3] DEBE mostrar todos los mosaicos agregados por el usuario desde aplicaciones de terceros junto con los mosaicos de configuración rápida proporcionados por el sistema.

3.14. Interfaz de usuario multimedia

Si las implementaciones del dispositivo incluyen aplicaciones no activadas por voz (las Aplicaciones) que interactúan con aplicaciones de terceros a través de MediaBrowser o MediaSession , las Aplicaciones:

  • [C-1-2] DEBE mostrar claramente los iconos obtenidos mediante getIconBitmap() o getIconUri() y los títulos obtenidos mediante getTitle() como se describe en MediaDescription . Puede acortar los títulos para cumplir con las normas de seguridad (por ejemplo, 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 al usuario interactuar con toda la jerarquía MediaBrowser . PUEDE restringir el acceso a parte de la jerarquía para cumplir con las normas de seguridad (por ejemplo, distracción del conductor), pero NO DEBE dar un trato preferencial basado en el contenido o el proveedor de contenido.

  • [C-1-5] DEBE considerar el doble toque de KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent .

3.15. Aplicaciones instantáneas

Si las implementaciones de dispositivos admiten aplicaciones instantáneas, DEBEN satisfacer los siguientes requisitos:

  • [C-1-1] Las aplicaciones instantáneas solo DEBEN recibir permisos que tengan android:protectionLevel configurado en "instant" .
  • [C-1-2] Las aplicaciones instantáneas NO DEBEN interactuar con las aplicaciones instaladas mediante intenciones implícitas a menos que se cumpla una de las siguientes condiciones:
    • El filtro de patrón de intención del componente está expuesto y tiene CATEGORY_BROWSABLE
    • La acción es una de ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
    • El objetivo está expuesto explícitamente con android:visibleToInstantApps
  • [C-1-3] Las aplicaciones instantáneas NO DEBEN interactuar explícitamente con las aplicaciones instaladas a menos que el componente esté expuesto a través de android:visibleToInstantApps.
  • [C-1-4] Las aplicaciones instaladas NO DEBEN ver detalles sobre las Instant Apps en el dispositivo a menos que la Instant App se conecte explícitamente a la aplicación instalada.
  • Las implementaciones de dispositivos DEBEN proporcionar las siguientes posibilidades de usuario para interactuar con Instant Apps. El AOSP cumple con los requisitos con la interfaz de usuario, la configuración y el iniciador del sistema predeterminados. Implementaciones de dispositivos:

    • [C-1-5] DEBE proporcionar al usuario la posibilidad de ver y eliminar aplicaciones instantáneas almacenadas en caché localmente para cada paquete de aplicaciones individual.
    • [C-1-6] DEBE proporcionar una notificación de usuario persistente que se pueda contraer mientras se ejecuta una aplicación instantánea en primer plano. Esta notificación al usuario DEBE incluir que las aplicaciones instantáneas no requieren instalación y brindan una opción para el usuario que lo dirige a la pantalla de información de la aplicación en Configuración. Para las aplicaciones instantáneas iniciadas a través de intents web, según se define mediante el uso de una intención con acción configurada en Intent.ACTION_VIEW y con un esquema de "http" o "https", una opción de usuario adicional DEBE permitir al usuario no iniciar la aplicación instantánea y ejecutar el enlace asociado con el navegador web configurado, si hay un navegador disponible en el dispositivo.
    • [C-1-7] DEBE permitir el acceso a la ejecución de aplicaciones instantáneas desde la función Recientes si la función Recientes está disponible en el dispositivo.
  • [C-1-8] DEBE precargar una o más aplicaciones o componentes de servicio con un controlador de intenciones para las intenciones enumeradas en el SDK aquí y hacer que las intenciones sean visibles para las aplicaciones instantáneas.

3.16. Emparejamiento de dispositivos complementarios

Android incluye soporte para el emparejamiento de dispositivos complementarios para administrar de manera más efectiva la asociación con dispositivos complementarios y proporciona la API CompanionDeviceManager para que las aplicaciones accedan a esta función.

Si las implementaciones de dispositivos admiten la función de emparejamiento de dispositivos complementarios,:

  • [C-1-1] DEBE declarar el indicador de función FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEBE garantizar que las API del paquete android.companion estén completamente implementadas.
  • [C-1-3] DEBE proporcionar posibilidades al usuario para que seleccione/confirme que un dispositivo complementario está presente y operativo.

3.17. Aplicaciones pesadas

Si las implementaciones de dispositivos declaran la característica FEATURE_CANT_SAVE_STATE , entonces:

  • [C-1-1] DEBE tener solo una aplicación instalada que especifique cantSaveState ejecutándose en el sistema a la vez. Si el usuario abandona dicha aplicación sin salir explícitamente de ella (por ejemplo, presionando Inicio mientras abandona una actividad activa del sistema, en lugar de presionar Atrás sin que queden actividades activas en el sistema), entonces las implementaciones del dispositivo DEBEN priorizar esa aplicación en la RAM a medida que hacer para otras cosas que se espera que sigan ejecutándose, como los servicios en primer plano. Mientras una aplicación de este tipo esté en segundo plano, el sistema aún puede aplicarle funciones de administración de energía, como limitar el acceso a la CPU y a la red.
  • [C-1-2] DEBE proporcionar una interfaz de usuario para elegir la aplicación que no participará en el mecanismo de guardar/restaurar el estado normal una vez que el usuario inicie una segunda aplicación declarada con el atributo 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 de dispositivos no declaran la característica FEATURE_CANT_SAVE_STATE , entonces:

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

3.18. Contactos

Android incluye API Contacts Provider para permitir que las aplicaciones administren la información de contacto almacenada en el dispositivo. Los datos de contacto que se ingresan directamente en el dispositivo generalmente se sincronizan con un servicio web, pero los datos PUEDEN residir solo localmente en el dispositivo. Los contactos que sólo se almacenan en el dispositivo se denominan contactos locales.

Los contactos sin procesar están "asociados con" o "almacenados en" una cuenta cuando las columnas ACCOUNT_NAME y ACCOUNT_TYPE de los contactos sin procesar coinciden con los campos Account.name y Account.type correspondientes de la cuenta.

Cuenta local predeterminada : una cuenta para contactos sin procesar que solo se almacenan en el dispositivo y no están asociados con una cuenta en AccountManager , que se crean con valores nulos para las columnas ACCOUNT_NAME y ACCOUNT_TYPE .

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

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE no crear cuentas locales personalizadas .

Si las implementaciones de dispositivos utilizan una cuenta local personalizada :

  • [C-1-1] El ACCOUNT_NAME de la cuenta local personalizada DEBE ser devuelto por ContactsContract.RawContacts.getLocalAccountName
  • [C-1-2] El ACCOUNT_TYPE de la cuenta local personalizada DEBE ser devuelto por ContactsContract.RawContacts.getLocalAccountType
  • [C-1-3] Los contactos sin procesar que se insertan mediante aplicaciones de terceros con la cuenta local predeterminada (es decir, estableciendo valores nulos para ACCOUNT_NAME y ACCOUNT_TYPE ) DEBEN insertarse en la cuenta local personalizada .
  • [C-1-4] Los contactos sin procesar insertados en la cuenta local personalizada NO DEBEN eliminarse cuando se agregan o eliminan cuentas.
  • [C-1-5] Las operaciones de eliminación realizadas en la cuenta local personalizada DEBEN dar como resultado que los contactos sin procesar se purguen inmediatamente (como si el parámetro CALLER_IS_SYNCADAPTER estuviera configurado en verdadero), incluso si el parámetro CALLER\_IS\_SYNCADAPTER estuviera configurado en falso o no especificado.

4. Compatibilidad del embalaje de la aplicación

Implementaciones de dispositivos:

  • [C-0-1] DEBE ser capaz de instalar y ejecutar archivos “.apk” de Android generados por la herramienta “aapt” incluida en el SDK oficial de Android .
    • Como el requisito anterior puede ser un desafío, se RECOMIENDA que las implementaciones de dispositivos utilicen el sistema de administración de paquetes de la implementación de referencia de AOSP.

Implementaciones de dispositivos:

  • [C-0-2] DEBE admitir la verificación de archivos “.apk” utilizando el esquema de firma APK v3 , el esquema de firma APK v2 y la firma JAR .
  • [C-0-3] NO DEBE extender los formatos .apk , Android Manifest , Dalvik bytecode o RenderScript de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.
  • [C-0-4] NO DEBE permitir que aplicaciones distintas al "instalador de registro" actual del paquete desinstalen silenciosamente la aplicación sin ninguna confirmación del usuario, como se documenta en el SDK para el permiso DELETE_PACKAGE . Las únicas excepciones son la aplicación de verificación de paquetes del sistema que maneja la intención PACKAGE_NEEDS_VERIFICATION y la aplicación de administrador de almacenamiento que maneja la intención ACTION_MANAGE_STORAGE .

  • [C-0-5] DEBE tener una actividad que maneje la intención android.settings.MANAGE_UNKNOWN_APP_SOURCES .

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

    • DEBE declarar el permiso REQUEST_INSTALL_PACKAGES o tener android:targetSdkVersion configurado en 24 o menos.
    • El usuario DEBE haber recibido permiso para instalar aplicaciones de fuentes desconocidas.
  • DEBE proporcionar al usuario la posibilidad de otorgar/revocar el permiso para instalar aplicaciones de fuentes desconocidas por aplicación, pero PUEDE elegir implementar esto como una opción no operativa y devolver RESULT_CANCELED para startActivityForResult() , si la implementación del dispositivo no desea permitir a los usuarios tener esta opción. Sin embargo, incluso en tales casos, DEBEN indicar al usuario por qué no se presenta dicha opción.

  • [C-0-7] DEBE mostrar un cuadro de diálogo de advertencia con la cadena de advertencia que se proporciona a través de la API del sistema PackageManager.setHarmfulAppWarning al usuario antes de iniciar una actividad en una aplicación que ha sido marcada por la misma API del sistema PackageManager.setHarmfulAppWarning como potencialmente dañino.

  • DEBE proporcionar al usuario la posibilidad de elegir desinstalar o iniciar una aplicación en el cuadro de diálogo de advertencia.

  • [C-0-8] DEBE implementar soporte para el sistema de archivos incremental como se documenta aquí .

  • [C-0-9] DEBE admitir la verificación de archivos .apk utilizando el esquema de firma APK v4 .

5. Compatibilidad multimedia

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir los formatos de medios, codificadores, decodificadores, tipos de archivos y formatos de contenedor definidos en la sección 5.1 para todos y cada uno de los códecs declarados por MediaCodecList .
  • [C-0-2] DEBE declarar e informar el soporte de los codificadores y decodificadores disponibles para aplicaciones de terceros a través de MediaCodecList .
  • [C-0-3] DEBE poder decodificar correctamente y poner a disposición de aplicaciones de terceros todos los formatos que puede codificar. Esto incluye todos los flujos de bits que generan sus codificadores y los perfiles informados en su CamcorderProfile .

Implementaciones de dispositivos:

  • DEBEN aspirar a una latencia mínima del códec; en otras palabras,
    • NO DEBE consumir ni almacenar buffers de entrada y devolver buffers de entrada solo una vez procesados.
    • NO DEBE retener los buffers decodificados por más tiempo del especificado por el estándar (por ejemplo, SPS).
    • NO DEBE conservar los buffers codificados más tiempo del requerido por la estructura del Partido Republicano.

Todos los códecs enumerados en la sección siguiente se proporcionan como implementaciones de software en la implementación de Android preferida del Proyecto de código abierto de Android.

Tenga en cuenta que ni Google ni Open Handset Alliance garantizan que estos códecs estén libres de patentes de terceros. Se advierte a quienes deseen utilizar 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, pueden requerir licencias de patente de los titulares de patentes correspondientes.

5.1. Códecs multimedia

5.1.1. Codificación de audio

Ver más detalles en 5.1.3. Detalles de códecs de audio .

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

  • [C-1-1] PCM/ONDA
  • [C-1-2] FLAC
  • [C-1-3] Obra

Todos los codificadores de audio DEBEN admitir:

5.1.2. Decodificación de audio

Ver más detalles en 5.1.3. Detalles de códecs de audio .

Si las implementaciones de dispositivos declaran admitir la función android.hardware.audio.output , deben admitir la decodificación de 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 de bajo retardo mejorado)
  • [C-1-11] xHE-AAC (perfil HE AAC extendido ISO/IEC 23003-3, que incluye el perfil base USAC y el perfil de control de rango dinámico ISO/IEC 23003-4)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7]MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE que incluye formatos de audio de alta resolución de hasta 24 bits, frecuencia de muestreo de 192 kHz y 8 canales. Tenga en cuenta que este requisito es solo para decodificación y que un dispositivo puede reducir la resolución y la mezcla durante la fase de reproducción.
  • [C-1-10] Obra

Si las implementaciones de dispositivos admiten la decodificación de buffers de entrada AAC de transmisiones multicanal (es decir, más de dos canales) a PCM a través del decodificador de audio AAC predeterminado en la API android.media.MediaCodec , DEBE admitirse lo siguiente:

  • [C-2-1] La decodificación DEBE realizarse sin mezcla (por ejemplo, un flujo 5.0 AAC debe decodificarse en cinco canales de PCM, un flujo 5.1 AAC debe decodificarse en seis canales de PCM).
  • [C-2-2] Los metadatos del rango dinámico DEBEN ser los definidos en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3, y las claves android.media.MediaFormat DRC para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves AAC DRC se introdujeron en API 21 y son: 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 .
  • [SR-1] Se RECOMIENDA ENCARECIDAMENTE que todos los decodificadores de audio AAC cumplan los requisitos C-2-1 y C-2-2 anteriores.

Al decodificar audio USAC, MPEG-D (ISO/IEC 23003-4):

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

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

  • PUEDE admitir el control de volumen y rango dinámico utilizando el perfil de control de rango dinámico ISO/IEC 23003-4.

Si se admite ISO/IEC 23003-4 y si los metadatos de ISO/IEC 23003-4 e ISO/IEC 14496-3 están presentes en un flujo de bits decodificado, entonces:

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

Todos los decodificadores de audio DEBEN admitir la salida:

5.1.3. Detalles de 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 frecuencias de muestreo estándar de 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS AAC sin formato (.aac, ADIF no compatible)
  • MPEG-TS (.ts, no buscable, solo decodificación)
  • Matroska (.mkv, solo decodificar)
Perfil MPEG-4 HE AAC (AAC+) Compatibilidad con contenido mono/estéreo/5.0/5.1 con frecuencias de muestreo estándar de 16 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 frecuencias de muestreo estándar de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
AAC ELD (AAC de bajo retardo mejorado) Soporte para contenido mono/estéreo con frecuencias de muestreo estándar de 16 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
USAC Soporte para contenido mono/estéreo con frecuencias de muestreo estándar de 7,35 a 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75 a 12,2 kbps muestreados a 8 kHz 3GPP (.3gp)
AMR-WB 9 velocidades de 6,60 kbit/s a 23,85 kbit/s muestreadas a 16 kHz, según se define en AMR-WB, multivelocidad adaptativa: códec de voz de banda ancha 3GPP (.3gp)
FLAC Tanto para el codificador como para el decodificador: DEBEN ser compatibles al menos los modos Mono y Estéreo. DEBEN admitirse frecuencias de muestreo de hasta 192 kHz; DEBE ser compatible con resoluciones de 16 y 24 bits. El manejo de datos de audio FLAC de 24 bits DEBE estar disponible con configuración de audio de punto flotante.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv, solo decodificar)
MP3 Mono/estéreo 8-320 Kbps constante (CBR) o tasa de bits variable (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv, solo decodificar)
midi MIDI Tipo 0 y 1. DLS Versión 1 y 2. XMF y XMF móvil. Compatibilidad con formatos de tonos de llamada RTTTL/RTX, OTA e iMelody
  • Tipo 0 y 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelodía (.imy)
Vorbis
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/ONDA El códec PCM DEBE admitir PCM lineal de 16 bits y flotante de 16 bits. El extractor WAVE debe admitir PCM lineal de 16 bits, 24 bits, 32 bits y flotante de 32 bits (velocidades hasta el límite del hardware). Las velocidades de muestreo DEBEN ser compatibles entre 8 kHz y 192 kHz. ONDA (.wav)
Opus Decodificación: Soporte para contenido mono, estéreo, 5.0 y 5.1 con frecuencias de muestreo de 8000, 12000, 16000, 24000 y 48000 Hz.
Codificación: Soporte para contenido mono y estéreo con frecuencias de muestreo de 8000, 12000, 16000, 24000 y 48000 Hz.
  • Ogg (.ogg)
  • MPEG-4 (.mp4, .m4a, solo decodificación)
  • Matroska (.mkv)
  • Webm (.webm)

5.1.4. Codificación de imágenes

Ver más detalles en 5.1.6. Detalles de códecs de imagen .

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

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

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

  • [C-1-1] DEBE proporcionar un códec codificador HEVC acelerado por hardware que admita el modo de control de velocidad de bits BITRATE_MODE_CQ , el perfil HEVCProfileMainStill y un tamaño de fotograma de 512 x 512 px.

5.1.5. Decodificación de imágenes

Ver más detalles en 5.1.6. Detalles de códecs de imagen .

Las implementaciones de dispositivos 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

Si las implementaciones de dispositivos admiten la decodificación de vídeo HEVC, estas:

  • [C-1-1] DEBE admitir la decodificación de imágenes HEIF (HEIC).

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

  • [C-2-1] DEBE admitir la salida de un formato equivalente de 8 bits si lo solicita la aplicación, por ejemplo, a través de la configuración ARGB_8888 de android.graphics.Bitmap .

5.1.6. Detalles de códecs de imagen

Formato/Códec Detalles Tipos de archivos/formatos de contenedor admitidos
JPEG Base+progresiva JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Crudo ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 ( .rw2), SRW (.srw)
HEIF Imagen, Colección de imágenes, Secuencia de imágenes HEIF (.heif), HEIC (.heic)

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

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

  • [SR-1] SE RECOMIENDA ENCARECIDAMENTE admitir el formato de color RGB888 para el modo Superficie de entrada.

  • [C-1-3] DEBE admitir al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar ) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar ). Se RECOMIENDA ENCARECIDAMENTE que apoyen a ambos.

5.1.7. Códecs de vídeo

  • Para una calidad aceptable de los servicios de videoconferencia y transmisión de video web, las implementaciones de dispositivos DEBEN usar un códec de hardware VP8 que cumpla con los requisitos .

Si las implementaciones del dispositivo 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 que se adapten al cuadro comprimido y sin comprimir más grande posible según lo dicta el estándar y la configuración, pero tampoco sobreasignar.

  • [C-1-2] Los codificadores y decodificadores de video DEBEN admitir formatos de color flexibles YUV420 8:8:8 ( COLOR_FormatYUV420Flexible ) a través de CodecCapabilities .

  • [C-1-3] Los codificadores y decodificadores de video DEBEN admitir al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar ) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar ). Se RECOMIENDA ENCARECIDAMENTE que apoyen a ambos.

  • [SR-1] Se RECOMIENDA ENCARECIDAMENTE que los codificadores y decodificadores de video admitan al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar optimizado por hardware (YV12, NV12, NV21 o formato equivalente optimizado por el proveedor).

  • [C-1-5] Los decodificadores de video que admiten un formato de alta profundidad de bits (más de 9 bits por canal) DEBEN admitir la salida de un formato equivalente de 8 bits si lo solicita la aplicación. Esto DEBE reflejarse al admitir un formato de color YUV420 8:8:8 a través de android.media.MediaCodecInfo .

Si las implementaciones de dispositivos anuncian compatibilidad con perfiles HDR a través de Display.HdrCapabilities ,:

  • [C-2-1] DEBE admitir el análisis y manejo de metadatos estáticos HDR.

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

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

A menos que la aplicación especifique lo contrario utilizando la clave de formato KEY_COLOR_FORMAT , las implementaciones del decodificador de vídeo:

  • [C-4-1] DEBE tener el formato de color predeterminado optimizado para la visualización del hardware si se configura utilizando la salida de superficie.
  • [C-4-2] DEBE tener de forma predeterminada un formato de color YUV420 8:8:8 optimizado para lectura de CPU si está configurado para no usar salida de superficie.

5.1.8. Lista de códecs de vídeo

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

5.1.9. Seguridad del códec multimedia

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad del códec multimedia como se describe a continuación.

Android incluye soporte para OMX, una API de aceleración multimedia multiplataforma, así como Codec 2.0, una API de aceleración multimedia de bajo costo.

Si las implementaciones de dispositivos admiten multimedia,:

  • [C-1-1] DEBE brindar soporte para códecs multimedia a través de API OMX o Codec 2.0 (o ambos) como en el Proyecto de código abierto de Android y no deshabilitar ni eludir las protecciones de seguridad. Esto no significa específicamente que cada códec DEBE utilizar la API OMX o Codec 2.0, solo que el soporte para al menos una de estas API DEBE estar disponible, y el soporte para las API disponibles DEBE incluir las protecciones de seguridad presentes.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir soporte para la API Codec 2.0.

Si las implementaciones de dispositivos no son compatibles con la API Codec 2.0, estas:

  • [C-2-1] DEBE incluir el códec de software OMX correspondiente del Proyecto de código abierto de Android (si está disponible) para cada formato y tipo de medio (codificador o decodificador) admitido por el dispositivo.
  • [C-2-2] Códecs que tienen nombres que comienzan con "OMX.google". DEBE basarse en el código fuente del Proyecto de código abierto de Android.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que los códecs de software OMX se ejecuten en un proceso de códec que no tenga acceso a controladores de hardware que no sean asignadores de memoria.

Si las implementaciones de dispositivos admiten la API Codec 2.0, estas:

  • [C-3-1] DEBE incluir el códec de software Codec 2.0 correspondiente del Proyecto de código abierto de Android (si está disponible) para cada formato y tipo de medio (codificador o decodificador) admitido por el dispositivo.
  • [C-3-2] DEBE albergar los códecs de software Codec 2.0 en el proceso de códec de software según lo dispuesto en el Proyecto de código abierto de Android para permitir otorgar acceso más restringido a los códecs de software.
  • [C-3-3] Códecs que tienen nombres que comienzan con "c2.android". DEBE basarse en el código fuente del Proyecto de código abierto de Android.

5.1.10. Caracterización del códec multimedia

Si las implementaciones de dispositivos admiten códecs multimedia,:

  • [C-1-1] DEBE devolver valores correctos de caracterización de códec de medios a través de la API MediaCodecInfo .

En particular:

  • [C-1-2] Códecs con nombres que comienzan con "OMX". DEBE utilizar las API de OMX y tener nombres que cumplan con las pautas de nomenclatura de OMX IL.
  • [C-1-3] Códecs con nombres que comienzan con "c2". DEBE utilizar la API del Codec 2.0 y tener nombres que cumplan con las pautas de nomenclatura del Codec 2.0 para Android.
  • [C-1-4] Códecs con nombres que comienzan con "OMX.google". o "c2.android". NO DEBE caracterizarse como proveedor o acelerado por hardware.
  • [C-1-5] Los códecs que se ejecutan en un proceso de códec (proveedor o sistema) que tienen acceso a controladores de hardware distintos de asignadores y asignadores de memoria NO DEBEN caracterizarse como software únicamente.
  • [C-1-6] Los códecs que no están presentes en el proyecto de código abierto de Android o que no están basados ​​en el código fuente de ese proyecto DEBEN caracterizarse como proveedores.
  • [C-1-7] Los códecs que utilizan aceleración de hardware DEBEN caracterizarse como acelerados por hardware.
  • [C-1-8] Los nombres de los códecs NO DEBEN ser engañosos. Por ejemplo, los códecs denominados "decodificadores" DEBEN admitir la decodificación, y los denominados "codificadores" DEBEN admitir la codificación. Los códecs con nombres que contienen formatos multimedia DEBEN admitir esos formatos.

Si las implementaciones de dispositivos admiten códecs de vídeo:

  • [C-2-1] Todos los códecs de video DEBEN publicar datos de velocidad de fotogramas alcanzables para los siguientes tamaños si el códec lo admite:
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD
Resolución de video
  • 176 x 144 píxeles (H263, MPEG2, MPEG4)
  • 352 x 288 píxeles (codificador MPEG4, H263, MPEG2)
  • 320 x 180 píxeles (VP8, VP8)
  • 320 x 240 píxeles (otro)
  • 704 x 576 píxeles (H263)
  • 640 x 360 píxeles (VP8, VP9)
  • 640 x 480 píxeles (codificador MPEG4)
  • 720 x 480 píxeles (otro)
  • 1408 x 1152 píxeles (H263)
  • 1280 x 720 píxeles (otro)
1920 x 1080 px (distinto de MPEG4) 3840 x 2160 píxeles (HEVC, VP9)
  • [C-2-2] Los códecs de video que se caracterizan como acelerados por hardware DEBEN publicar información de puntos de rendimiento. Cada uno DEBE enumerar todos los puntos de rendimiento estándar admitidos (enumerados en la API PerformancePoint ), a menos que estén cubiertos por otro punto de rendimiento estándar admitido.
  • Además, DEBEN publicar puntos de rendimiento ampliados si admiten un rendimiento de vídeo sostenido distinto de uno de los estándar enumerados.

5.2. Codificación de vídeo

Si las implementaciones de dispositivos admiten cualquier codificador de vídeo y lo ponen a disposición de aplicaciones de terceros:

  • NO DEBE ser, en dos ventanas deslizantes, más del 15% sobre la tasa de bits entre intervalos intracuadro (I-frame).
  • NO DEBE superar el 100 % de la tasa de bits en una ventana deslizante de 1 segundo.

Si las implementaciones del dispositivo incluyen una pantalla integrada con una longitud diagonal de al menos 2,5 pulgadas o incluyen un puerto de salida de video o declaran la compatibilidad con una cámara a través del indicador de función android.hardware.camera.any , ellos:

  • [C-1-1] DEBE incluir el soporte de al menos uno de los codificadores de video VP8 o H.264 y ponerlo a disposición de aplicaciones de terceros.
  • DEBE admitir codificadores de vídeo VP8 y H.264 y ponerlos a disposición de aplicaciones de terceros.

Si las implementaciones de dispositivos admiten cualquiera de los codificadores de video H.264, VP8, VP9 o HEVC y lo ponen a disposición de aplicaciones de terceros,:

  • [C-2-1] DEBE admitir velocidades de bits configurables dinámicamente.
  • DEBE admitir velocidades de cuadro variables, donde el codificador de video DEBE determinar la duración instantánea del cuadro en función de las marcas de tiempo de los buffers de entrada y asignar su depósito de bits en función de la duración de ese cuadro.

Si las implementaciones de dispositivos admiten el codificador de vídeo MPEG-4 SP y lo ponen a disposición de aplicaciones de terceros, estas:

  • DEBE admitir velocidades de bits configurables dinámicamente para el codificador admitido.

Si las implementaciones de dispositivos proporcionan codificadores de imágenes o videos acelerados por hardware y admiten una o más cámaras de hardware conectadas o conectables expuestas a través de las API android.camera :

  • [C-4-1] todos los codificadores de imágenes y video acelerados por hardware DEBEN admitir cuadros de codificación de las cámaras de hardware.
  • DEBE admitir la codificación de fotogramas desde las cámaras de hardware a través de todos los codificadores de vídeo o imágenes.

Si las implementaciones de dispositivos proporcionan codificación HDR, estas:

  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] proporcionar un complemento para la API de transcodificación perfecta para convertir del formato HDR al formato SDR.

5.2.1. H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y lo ponen a disposición de aplicaciones de terceros, estos:

  • [C-1-1] DEBE admitir el nivel de perfil de referencia 45.
  • DEBE admitir velocidades de bits configurables dinámicamente para el codificador admitido.

5.2.2. H.264

Si las implementaciones de dispositivos admiten el códec H.264,:

  • [C-1-1] DEBE admitir el nivel 3 del perfil de referencia. Sin embargo, el soporte para ASO (ordenación de sectores arbitrarios), FMO (ordenamiento de macrobloques flexible) y RS (porciones redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no utilicen ASO, FMO y RS para Baseline Profile.
  • [C-1-2] DEBE admitir los perfiles de codificación de video SD (definición estándar) en la siguiente tabla.
  • DEBE admitir el nivel 4 del perfil principal.
  • DEBE admitir los perfiles de codificación de vídeo HD (alta definición) como se indica en la siguiente tabla.

Si las implementaciones de dispositivos informan que admiten la codificación H.264 para videos con resolución de 720p o 1080p a través de las API de medios,:

  • [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 240 píxeles 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 20 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 384 Kbps 2Mbps 4Mbps 10Mbps

5.2.3. VP8

Si las implementaciones de dispositivos admiten el códec VP8,:

  • [C-1-1] DEBE admitir los perfiles de codificación de video SD.
  • DEBE admitir los siguientes perfiles de codificación de video HD (alta definición).
  • [C-1-2] DEBE admitir la escritura de archivos Matroska WebM.
  • DEBE proporcionar un códec de hardware VP8 que cumpla con los requisitos de codificación de hardware RTC del proyecto WebM , para garantizar una calidad aceptable de transmisión de video web y servicios de videoconferencia.

Si las implementaciones de dispositivos informan que admiten la codificación VP8 para videos con resolución de 720p o 1080p a través de las API de medios,:

  • [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 180 píxeles 640 x 360 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 800 kbps 2Mbps 4Mbps 10Mbps

5.2.4. VP9

Si las implementaciones de dispositivos admiten el códec VP9,:

  • [C-1-2] DEBE admitir el Perfil 0 Nivel 3.
  • [C-1-1] DEBE admitir la escritura de archivos Matroska WebM.
  • [C-1-3] DEBE generar datos CodecPrivate .
  • DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] admitir los perfiles de decodificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
Dakota del Sur alta definición 720p alta definición 1080p HD
Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 1,6Mbps 4Mbps 5Mbps 20Mbps

Si las implementaciones de dispositivos afirman admitir el Perfil 2 o el Perfil 3 a través de las API de medios:

  • El soporte para formato de 12 bits es OPCIONAL.

5.2.5. H.265

Si las implementaciones de dispositivos admiten el códec H.265,:

  • [C-1-1] DEBE admitir el nivel de perfil principal 3.
  • DEBE admitir los perfiles de codificación HD como se indica en la siguiente tabla.
  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] admitir los perfiles de codificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
Dakota del Sur alta definición 720p alta definición 1080p HD
Resolución de video 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps
Bitrate de vídeo 1,6Mbps 4Mbps 5Mbps 20Mbps

5.3. Decodificación de vídeo

Si las implementaciones de dispositivos admiten los códecs VP8, VP9, ​​H.264 o H.265,:

  • [C-1-1] DEBE admitir resolución de video dinámica y cambio de velocidad de fotogramas a través de las API estándar de Android dentro de la misma transmisión para todos los códecs VP8, VP9, ​​H.264 y H.265 en tiempo real y hasta la resolución máxima admitida. por cada códec del dispositivo.

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2,:

  • [C-1-1] DEBE admitir el nivel alto del perfil principal.

5.3.2. H.263

Si las implementaciones de dispositivos admiten decodificadores H.263,:

  • [C-1-1] DEBE admitir el perfil de referencia nivel 30 y nivel 45.

5.3.3. MPEG-4

Si se implementan dispositivos con decodificadores MPEG-4, estos:

  • [C-1-1] DEBE admitir perfil simple nivel 3.

5.3.4. H.264

Si las implementaciones de dispositivos admiten decodificadores H.264,:

  • [C-1-1] DEBE admitir el nivel de perfil principal 3.1 y el perfil de referencia. La compatibilidad con ASO (ordenación de cortes arbitrarios), FMO (ordenación de macrobloques flexibles) y RS (cortes redundantes) es OPCIONAL.
  • [C-1-2] DEBE ser capaz de decodificar videos con los perfiles SD (definición estándar) enumerados en la siguiente tabla y codificados con el perfil base y el perfil principal nivel 3.1 (incluido 720p30).
  • DEBE ser capaz de decodificar vídeos con 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 mayor que la resolución del vídeo, las implementaciones del dispositivo:

  • [C-2-1] DEBE admitir los perfiles de decodificación de video HD 720p en la siguiente tabla.
  • [C-2-2] DEBE admitir los perfiles de decodificación de video HD 1080p en la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 240 píxeles 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 60 fps 30 fps ( Televisión de 60 fps)
Bitrate de vídeo 800 kbps 2Mbps 8Mbps 20Mbps

5.3.5. H.265 (HEVC)

Si las implementaciones de dispositivos admiten el códec H.265,:

  • [C-1-1] DEBE admitir el nivel principal de perfil principal nivel 3 y los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • DEBE 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 en la siguiente tabla si hay un decodificador de hardware.

Si la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, entonces:

  • [C-2-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones H.265 o VP9 de los perfiles 720, 1080 y UHD.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD
Resolución de video 352 x 288 píxeles 720 x 480 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30/60 fps ( Televisión de 60 fps con decodificación de hardware H.265 ) 60 fps
Bitrate de vídeo 600 kbps 1,6Mbps 4Mbps 5Mbps 20Mbps

Si las implementaciones de dispositivos afirman admitir un perfil HDR a través de las API de medios:

  • [C-3-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos HDR requeridos de la aplicación, así como también admitir la extracción y salida de los metadatos HDR requeridos desde el flujo de bits y/o el contenedor.
  • [C-3-2] Las implementaciones de dispositivos DEBEN mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).

5.3.6. VP8

Si las implementaciones de dispositivos admiten el códec VP8,:

  • [C-1-1] DEBE admitir los perfiles de decodificación SD en la siguiente tabla.
  • DEBE utilizar un códec de hardware VP8 que cumpla con los requisitos .
  • DEBE admitir los perfiles de decodificación HD en la siguiente tabla.

Si la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, entonces:

  • [C-2-1] Las implementaciones de dispositivos DEBEN admitir perfiles de 720p en la siguiente tabla.
  • [C-2-2] Las implementaciones de dispositivos DEBEN admitir perfiles de 1080p en la siguiente tabla.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p
Resolución de video 320 x 180 píxeles 640 x 360 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps ( Televisión de 60 fps) 30 ( Televisión de 60 fps)
Bitrate de vídeo 800 kbps 2Mbps 8Mbps 20Mbps

5.3.7. VP9

Si las implementaciones de dispositivos admiten el códec VP9,:

  • [C-1-1] DEBE admitir los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • DEBE 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 en la siguiente tabla.

Si la altura informada por el método Display.getSupportedModes() es igual o mayor que la resolución del vídeo, entonces:

  • [C-3-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones VP9 o H.265 de los perfiles 720, 1080 y UHD.
SD (baja calidad) SD (alta calidad) alta definición 720p alta definición 1080p HD
Resolución de video 320 x 180 píxeles 640 x 360 píxeles 1280 x 720 píxeles 1920 x 1080 píxeles 3840 x 2160 píxeles
Velocidad de fotogramas de vídeo 30 fps 30 fps 30 fps 30 fps ( Televisión de 60 fps con decodificación de hardware VP9 ) 60 fps
Bitrate de vídeo 600 kbps 1,6Mbps 4Mbps 5Mbps 20Mbps

Si las implementaciones de dispositivos afirman admitir VP9Profile2 o VP9Profile3 a través de las API de medios 'CodecProfileLevel' :

  • El soporte para formato de 12 bits es OPCIONAL.

Si las implementaciones de dispositivos afirman admitir un perfil HDR ( VP9Profile2HDR , VP9Profile2HDR10Plus , VP9Profile3HDR , VP9Profile3HDR10Plus ) a través de las API de medios:

  • [C-4-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos HDR requeridos ( KEY_HDR_STATIC_INFO para todos los perfiles HDR, así como 'KEY_HDR10_PLUS_INFO' para los perfiles HDR10Plus) de la aplicación. También DEBEN admitir la extracción y salida de los metadatos HDR requeridos desde el flujo de bits y/o el contenedor.
  • [C-4-2] Las implementaciones de dispositivos DEBEN mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).

5.3.8. Visión Dolby

Si las implementaciones de dispositivos declaran compatibilidad con el decodificador Dolby Vision a través de HDR_TYPE_DOLBY_VISION ,:

  • [C-1-1] DEBE proporcionar un extractor compatible con Dolby Vision.
  • [C-1-2] DEBE mostrar correctamente el contenido Dolby Vision en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).
  • [C-1-3] DEBE establecer el índice de pista de las capas base compatibles con versiones anteriores (si están presentes) para que sea el mismo que el índice de pista de la capa Dolby Vision combinada.

5.3.9. AV1

Si las implementaciones de dispositivos admiten el códec AV1,:

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

5.4. Grabación de audio

Si bien algunos de los requisitos descritos en esta sección se enumeran como DEBEN desde Android 4.3, se planea que la Definición de compatibilidad para versiones futuras los cambie a DEBE. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos que se enumeran como DEBERÍAN, o no podrán lograr la compatibilidad con Android cuando se actualicen a la versión futura.

5.4.1. Captura de audio en bruto e información de micrófono

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • [C-1-1] debe permitir la captura de contenido de audio sin procesar con las siguientes características:

    • Formato : PCM lineal, 16 bits
    • Tasas de muestreo : 8000, 11025, 16000, 44100, 48000 Hz
    • Canales : mono
  • DEBE permitir la captura de contenido de audio sin procesar con las siguientes características:

    • Formato : PCM lineal, 16 bits y 24 bits
    • Frecuencias de muestreo : 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • Canales : tantos canales como el número de micrófonos en el dispositivo
  • [C-1-2] DEBE capturar a las frecuencias de muestreo anteriores sin muestreo ascendente.

  • [C-1-3] DEBE incluir un filtro antialiasing apropiado cuando las frecuencias de muestreo indicadas anteriormente se capturan con muestreo descendente.

  • DEBE permitir la captura de contenido de audio sin procesar con calidad de radio AM y DVD, lo que significa las siguientes características:

    • Formato : PCM lineal, 16 bits
    • Frecuencias de muestreo : 22050, 48000 Hz
    • Canales : Estéreo
  • [C-1-4] debe honrar la API MicrophoneInfo y completar adecuadamente la información para los micrófonos disponibles en el dispositivo accesible para las aplicaciones de terceros a través de la API AudioManager.getMicrophones() y los micrófonos actualmente activos a los que se pueden acceder al tercer. Aplicaciones de la fiesta a través de AudioRecord.getActiveMicrophones() y MediaRecorder.getActiveMicrophones() API. Si las implementaciones de dispositivos permiten la captura con calidad de radio AM y DVD de contenido de audio sin procesar, estos:

  • [C-2-1] DEBE capturar sin muestreo ascendente en cualquier proporción superior a 16000:22050 o 44100:48000.

  • [C-2-2] DEBE incluir un filtro anti-aliasing apropiado para cualquier muestreo ascendente o descendente.

5.4.2. Captura para el reconocimiento de voz

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • [C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION en una de las frecuencias de muestreo, 44100 y 48000.
  • [C-1-2] DEBE, de forma predeterminada, desactivar cualquier procesamiento de audio de reducción de ruido al grabar una secuencia de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION .
  • [C-1-3] DEBE, de forma predeterminada, desactivar cualquier control automático de ganancia al grabar una secuencia de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION .
  • Debe grabar la transmisión de audio de reconocimiento de voz con características de amplitud aproximadamente plana versus frecuencia: específicamente, ± 3 dB, de 100 Hz a 4000 Hz.
  • Debe grabar la transmisión de audio de reconocimiento de voz con un conjunto de sensibilidad de entrada de tal manera que una fuente de nivel de potencia de sonido de 90 dB (SPL) a 1000 Hz produce RMS de 2500 para muestras de 16 bits.
  • DEBE grabar el flujo de audio de reconocimiento de voz de modo que los niveles de amplitud PCM sigan linealmente los cambios de SPL de entrada en al menos un rango de 30 dB de -18 dB a +12 dB re 90 dB SPL en el micrófono.
  • DEBE grabar el flujo de audio de reconocimiento de voz con una distorsión armónica total (THD) inferior al 1% durante 1 kHz a un nivel de entrada SPL de 90 dB en el micrófono.

Si las implementaciones de dispositivos declaran tecnologías android.hardware.microphone y de supresión (reducción) de ruido optimizadas para el reconocimiento de voz, estas:

  • [C-2-1] DEBE permitir que este efecto de audio sea controlable con la API android.media.audiofx.NoiseSuppressor .
  • [C-2-2] DEBE identificar de forma única cada implementación de tecnología de supresión de ruido a través del campo AudioEffect.Descriptor.uuid .

5.4.3. Captura para el cambio de reproducción

La clase android.media.MediaRecorder.AudioSource incluye la fuente de audio REMOTE_SUBMIX .

Si las implementaciones de dispositivos declaran tanto android.hardware.audio.output como android.hardware.microphone ,:

  • [C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX para que cuando una aplicación use la API android.media.AudioRecord para grabar desde esta fuente de audio, capture una mezcla 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 ,:

  • Debe implementar una tecnología de cancelador de eco acústico (AEC) sintonizado para la comunicación de voz y aplicarse a la ruta de captura al capturar el uso de AudioSource.VOICE_COMMUNICATION

Si las implementaciones del dispositivo proporcionan un cancelador de eco acústico que se inserta en la ruta de captura de audio cuando se selecciona AudioSource.VOICE_COMMUNICATION ,:

5.4.5. Captura concurrente

Si las implementaciones de dispositivos declaran android.hardware.microphone , DEBEN implementar la captura simultánea como se describe en este documento . Específicamente:

  • [C-1-1] DEBE permitir el acceso simultáneo al micrófono mediante un servicio de accesibilidad que capture con AudioSource.VOICE_RECOGNITION y al menos una aplicación que capture con cualquier AudioSource .
  • [C-1-2] debe permitir el acceso concurrente al micrófono mediante una aplicación preinstalada que posee un rol de asistente y al menos una aplicación que capture con cualquier AudioSource , excepto para 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 una aplicación captura con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER . Sin embargo, cuando una aplicación captura a través de AudioSource.VOICE_COMMUNICATION , otra aplicación puede capturar la llamada de voz si es una aplicación privilegiada (preinstalada) con permiso CAPTURE_AUDIO_OUTPUT .
  • [C-1-4] Si dos o más aplicaciones están capturando simultáneamente y ninguna de las aplicaciones tiene una interfaz de usuario en la parte superior, la que comenzó a capturar más recientemente recibe el audio.

5.4.6. Niveles de ganancia de micrófono

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • Debería exhibir características de amplitud versus de amplitud aproximadamente planas en el rango de frecuencia media: específicamente ± 3DB de 100 Hz a 4000 Hz para cada micrófono utilizado para grabar la fuente de audio de reconocimiento de voz.
  • Debe establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz se reproduzca a un nivel de presión de sonido de 90 dB (SPL) produce una respuesta con RMS de 2500 para 16 sesiones de bits (o -22.35 dB a escala completa para muestras de punto flotante/doble precisión) Para cada micrófono utilizado para grabar la fuente de audio de reconocimiento de voz.
  • [C-SR-1] se recomienda encarecidamente exhibir niveles de amplitud en el rango de baja frecuencia: específicamente de ± 20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencia media para cada micrófono utilizado para grabar el audio de reconocimiento de voz fuente.
  • [C-SR-2] se RECOMIENDA ENCARECIDAMENTE exhibir niveles de amplitud en el rango de frecuencia alta: específicamente desde ±30 dB de 4000 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 el audio de reconocimiento de voz. fuente.

5.5. Reproducción de audio

Android incluye soporte para permitir que las aplicaciones reproduzcan audio a través del periférico de salida de audio como se define en la sección 7.8.2.

5.5.1. Reproducción de audio crudo

Si las implementaciones de dispositivos declaran android.hardware.audio.output ,:

  • [C-1-1] DEBE permitir la reproducción de contenido de audio sin procesar con las siguientes características:

    • Formatos de origen : PCM lineal, 16 bits, 8 bits, flotante
    • Canales : Mono, Estéreo, configuraciones multicanal válidas con hasta 8 canales
    • Frecuencias de muestreo (en Hz) :
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 en las configuraciones de canales enumeradas anteriormente
      • 96000 en mono y estéreo

5.5.2. Efectos de audio

Android proporciona una API para efectos de audio para implementaciones de dispositivos.

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

  • [C-1-1] DEBE admitir las implementaciones EFFECT_TYPE_EQUALIZER y EFFECT_TYPE_LOUDNESS_ENHANCER controlables a través de las subclases AudioEffect Equalizer y LoudnessEnhancer .
  • [C-1-2] DEBE admitir la implementación de la API del visualizador, controlable a través de la clase Visualizer .
  • [C-1-3] DEBE admitir la implementación EFFECT_TYPE_DYNAMICS_PROCESSING controlable a través de la subclase AudioEffect DynamicsProcessing .
  • DEBE admitir las implementaciones EFFECT_TYPE_BASS_BOOST , EFFECT_TYPE_ENV_REVERB , EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER controlables a través de las subclases AudioEffect BassBoost , EnvironmentalReverb , PresetReverb y Virtualizer .
  • [C-SR-1] Se RECOMIENDAN ENCARECIDAMENTE para admitir efectos en punto flotante y multicanal.

5.5.3. Volumen de salida de audio

Implementaciones de dispositivos automotrices:

  • DEBE permitir ajustar el volumen de audio por separado para cada transmisión de audio utilizando el tipo de contenido o uso definido por AudioAttributes y el uso de audio del automóvil definido 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 , estas:

  • [C-SR-1] se recomienda encarecidamente recortar el contenido de audio reproducido sin gap cuando lo especifica la API de AudioTrack Gapless 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 lograr efectos de sonido en tiempo real.

A los efectos de esta sección, utilice las siguientes definiciones:

  • latencia de salida . El intervalo entre cuando una aplicación escribe un marco de datos codificados por PCM y cuando el sonido correspondiente se presenta al entorno en un transductor en el dispositivo o la señal deja el dispositivo a través de un puerto y se puede observar externamente.
  • Latencia de salida en frío . El tiempo entre el inicio de un flujo de salida y el tiempo de presentación del primer fotograma según las marcas de tiempo, cuando el sistema de salida de audio estuvo inactivo y apagado antes de la solicitud.
  • Latencia de salida continua . La latencia de salida para marcos posteriores, después de que el dispositivo reproduce audio.
  • latencia de entrada . El intervalo entre el momento en que el entorno presenta un sonido al dispositivo en un transductor del dispositivo o la señal ingresa al dispositivo a través de un puerto y el momento en que una aplicación lee el cuadro correspondiente de datos codificados en PCM.
  • entrada perdida . La porción inicial de una señal de entrada que no se puede utilizar o no está disponible.
  • Latencia de entrada en frío . El tiempo 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 estuvo inactivo y apagado antes de la solicitud.
  • Latencia de entrada continua . La latencia de entrada para fotogramas posteriores, mientras el dispositivo captura audio.
  • Fitter de salida fría . La variabilidad entre las mediciones separadas de los valores de latencia de salida de frío.
  • Fitter de entrada en frío . La variabilidad entre las mediciones separadas de los valores de latencia de entrada de frío.
  • Latencia continua de ida y vuelta . La suma de la latencia de entrada continua más la latencia de salida continua más un período de búfer. El período de búfer permite que la aplicación tenga tiempo para procesar la señal y tiempo para que la aplicación mitigue la diferencia de fase entre los flujos de entrada y salida.
  • API de cola de búfer OpenSL ES PCM . El conjunto de API de OpenSL ES relacionadas con PCM dentro del NDK de Android .
  • API de audio nativo de AAudio . El conjunto de API de AAudio dentro del NDK de Android .
  • Marca de tiempo . Un par que consta de una posición relativa del fotograma dentro de una secuencia y el tiempo estimado en que ese fotograma entra o sale del canal de procesamiento de audio en el punto final asociado. Véase también AudioTimestamp .
  • falla . Una interrupción temporal o un valor de muestra incorrecto en la señal de audio, generalmente causado por una insuficiencia de datos del búfer de salida, un desbordamiento del búfer de entrada o cualquier otra fuente de ruido digital o analógico.
  • desviación media absoluta . El promedio del valor absoluto de las desviaciones de la media para un conjunto de valores.
  • latencia de toque para tono . El tiempo entre el momento en que se toca la pantalla y el momento en que se escucha en el altavoz un tono generado como resultado de ese toque.

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

  • [C-1-1] La marca de tiempo de salida devuelta por AudioTrack.getTimestamp y AAudioStream_getTimestamp tiene una precisión de +/- 2 ms.
  • [C-1-2] Latencia de salida en frío de 500 milisegundos o menos.

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

  • [C-SR-1] Latencia de salida en frío de 100 milisegundos o menos en la ruta de datos del altavoz. Los dispositivos existentes y nuevos que ejecutan esta versión de Android están muy recomendables para cumplir con estos requisitos ahora. En una versión futura de la plataforma, requeriremos una latencia de salida en frío de 200 ms o menos como imprescindible.
  • [C-SR-2] Latencia de pulsación para tono de 80 milisegundos o menos.
  • [C-SR-3] Minimice el fluctuación de salida de salida en frío.
  • [C-SR-4] La marca de tiempo de salida devuelta por AudioTrack.getTimestamp y AAudioStream_getTimestamp tiene una precisión de +/- 1 ms.

Si las implementaciones de dispositivos cumplen con los requisitos anteriores, después de cualquier calibración inicial, cuando se utiliza la API de audio nativa AAudio, para latencia de salida continua y latencia de salida en frío en al menos un dispositivo de salida de audio compatible, son:

Si las implementaciones de dispositivos no cumplen con los requisitos de audio de baja latencia a través de la API de audio nativa AAudio,:

  • [C-2-1] NO DEBE informar soporte para audio de baja latencia.

Si las implementaciones del dispositivo incluyen android.hardware.microphone , DEBEN cumplir con estos requisitos de audio de entrada:

  • [C-3-1] Limite el error en las marcas de tiempo de entrada, según lo devuelto por AudioRecord.getTimestamp o AAudioStream_getTimestamp , a +/- 2 ms. "Error" aquí significa la desviación del valor correcto.
  • [C-3-2] Latencia de entrada en frío de 500 milisegundos o menos.

Si las implementaciones del dispositivo incluyen android.hardware.microphone , se RECOMIENDA ENCARECIDAMENTE que cumplan con estos requisitos de audio de entrada:

  • [C-SR-8] Latencia de entrada fría de 100 milisegundos o menos en la ruta de datos del micrófono. Los dispositivos existentes y nuevos que ejecutan esta versión de Android están muy recomendables para cumplir con estos requisitos ahora. En una versión de plataforma futura, requeriremos una latencia de entrada en frío de 200 ms o menos como imprescindible.
  • [C-SR-9] Latencia de entrada continua de 30 milisegundos o menos.
  • [C-SR-10] Minimice el fluctuación de entrada de frío.
  • [C-SR-11] Limite el error en las marcas de tiempo de entrada, según lo devuelto por AudioRecord.getTimestamp o AAudioStream_getTimestamp , a +/- 1 ms.

Si las implementaciones de dispositivos declaran android.hardware.audio.output y android.hardware.microphone ,:

  • [C-SR-12] Se RECOMIENDA ENCARECIDAMENTE tener una latencia media continua de ida y vuelta de 50 milisegundos o menos en 5 mediciones, con una desviación media absoluta inferior a 10 ms, en al menos una ruta admitida.

5.7. Protocolos de red

Las implementaciones de dispositivos DEBEN admitir los protocolos de red de medios para la reproducción de audio y video como se especifica en la documentación del SDK de Android.

Para cada códec y formato de contenedor que se requiere que admita una implementación de dispositivo, la implementación del dispositivo:

  • [C-1-1] DEBE admitir ese códec o contenedor a través de HTTP y HTTPS.

  • [C-1-2] DEBE admitir los formatos de segmentos de medios correspondientes como se muestra en la tabla de formatos de segmentos de medios a continuación sobre el borrador del protocolo HTTP Live Streaming, Versión 7 .

  • [C-1-3] DEBE admitir los formatos de carga útil RTSP correspondientes como se muestra en la tabla RTSP a continuación. Para excepciones, consulte las notas al pie de la tabla en la sección 5.1 .

Formatos de segmentos de medios

Formatos de segmento Referencia(s) Soporte de códec requerido
Flujo de transporte MPEG-2 ISO 13818 Códecs de vídeo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consulte la sección 5.1.8 para obtener detalles sobre H264 AVC, MPEG2-4 SP,
y MPEG-2.

Códecs de audio:

  • CAA
Consulte la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
AAC con marco ADTS y etiquetas ID3 ISO 13818-7 Consulte la sección 5.1.1 para obtener detalles sobre AAC y sus variantes.
WebVTT WebVTT

RTSP (RTP, SDP)

Nombre de perfil Referencia(s) Soporte de códec requerido
H264 AVC RFC 6184 Consulte la sección 5.1.8 para obtener detalles sobre H264 AVC.
MP4A-LATM RFC 6416 Consulte la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
H263-1998 RFC 3551
RFC 4629
RFC 2190
Consulte la sección 5.1.8 para obtener detalles sobre H263.
H263-2000 RFC 4629 Consulte la sección 5.1.8 para obtener detalles sobre H263.
RAM RFC 4867 Consulte la sección 5.1.3 para obtener detalles sobre AMR-NB.
AMR-WB RFC 4867 Consulte la sección 5.1.3 para obtener detalles sobre AMR-WB.
MP4V-ES RFC 6416 Consulte la sección 5.1.8 para obtener detalles sobre MPEG-4 SP.
MPEG4-Genérico RFC 3640 Consulte la sección 5.1.3 para obtener detalles sobre AAC y sus variantes.
Mp2t RFC 2250 Consulte MPEG-2 Transport Stream debajo de HTTP Live Streaming para obtener más detalles.

5.8. Medios seguros

Si las implementaciones de dispositivos admiten salida de video segura y son capaces de admitir superficies seguras,:

  • [C-1-1] DEBE declarar soporte para Display.FLAG_SECURE .

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y admiten el protocolo de visualización inalámbrica,:

  • [C-2-1] DEBE proteger el enlace con un mecanismo criptográficamente fuerte 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 soporte para Display.FLAG_SECURE y admiten pantalla externa cableada, ellos:

  • [C-3-1] DEBE admitir HDCP 1.2 o superior para todas las pantallas externas conectadas a través de un puerto cableado accesible para el usuario.

5.9. Interfaz digital para instrumentos musicales (MIDI)

Si las implementaciones de dispositivos informan que admiten la función android.software.midi a través de la clase android.content.pm.PackageManager ,:

  • [C-1-1] DEBE admitir MIDI en todos los transportes de hardware con capacidad MIDI para los cuales proporcionen conectividad genérica no MIDI, donde dichos transportes sean:

  • [C-1-2] DEBE admitir el transporte de software MIDI entre aplicaciones (dispositivos MIDI virtuales)

  • [C-1-3] DEBE incluir libamidi.so (soporte MIDI nativo)

  • DEBE admitir el modo periférico MIDI a través de USB, sección 7.7

5.10. Audio profesional

Si las implementaciones de dispositivos informan que son compatibles con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager ,:

  • [C-1-1] DEBE informar la compatibilidad con la función android.hardware.audio.low_latency .
  • [C-1-2] debe tener la latencia de audio de ida y vuelta continua, como se define en la Sección 5.6 Latencia de audio , debe ser de 20 milisegundos o menos y debe ser de 10 milisegundos o menos en al menos una ruta compatible.
  • [C-1-3] DEBE incluir un puerto USB que admita el modo host USB y el modo periférico USB.
  • [C-1-4] DEBE informar la compatibilidad con la función android.software.midi .
  • [C-1-5] debe cumplir con las latencias y los requisitos de audio USB utilizando la API de audio nativa de Aaudio .
  • [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-SR-1] Se RECOMIENDAN ENCARECIDAMENTE cumplir con las latencias definidas en la sección 5.6 Latencia de audio , de 20 milisegundos o menos, en 5 mediciones con una desviación absoluta media inferior a 5 milisegundos en la ruta del altavoz al micrófono.
  • [C-SR-2] Se RECOMIENDAN ENCARECIDAMENTE para cumplir con los requisitos de Pro Audio para latencia de audio de ida y vuelta continua, latencia de entrada fría y latencia de salida fría y requisitos de audio USB utilizando la API de audio nativa AAudio a través de la ruta MMAP.
  • [C-SR-3] Se RECOMIENDAN ENCARECIDAMENTE para proporcionar un nivel constante de rendimiento de la CPU mientras el audio está activo y la carga de la CPU varía. Esto debe probarse utilizando la aplicación de Android SynthMark . SynthMark utiliza un sintetizador de software que se ejecuta en un marco de audio simulado que mide el rendimiento del sistema. La aplicación SynthMark debe ejecutarse utilizando la opción "Prueba automatizada" y lograr los siguientes resultados:
    • marca de voz.90 >= 32 voces
    • latencymark.fixed.little <= 15 ms
    • latencymark.dynamic.little <= 50 ms

Consulte la documentación de SynthMark para obtener una explicación de los puntos de referencia.

  • DEBE minimizar la inexactitud del reloj de audio y la desviación en relación con la hora estándar.
  • DEBE minimizar la deriva del reloj de audio en relación con la CPU CLOCK_MONOTONIC cuando ambos están activos.
  • DEBE minimizar la latencia de audio sobre los transductores del dispositivo.
  • DEBE minimizar la latencia de audio a través del audio digital USB.
  • DEBE documentar las mediciones de latencia de audio en todas las rutas.
  • DEBE minimizar la fluctuación 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.
  • DEBE proporcionar cero fallos de audio en condiciones de uso normal y con la latencia informada.
  • DEBE proporcionar cero diferencia de latencia entre canales.
  • DEBE minimizar la latencia media MIDI en todos los transportes.
  • DEBE minimizar la variabilidad de la latencia MIDI bajo carga (jitter) en todos los transportes.
  • DEBE proporcionar marcas de tiempo MIDI precisas en todos los transportes.
  • DEBE minimizar el ruido de la señal de audio en los transductores del dispositivo, incluido el período inmediatamente posterior al arranque en frío.
  • DEBE proporcionar una diferencia de reloj de audio cero entre los lados de entrada y salida de los puntos finales correspondientes, cuando ambos están activos. Ejemplos de puntos finales correspondientes incluyen el micrófono y el altavoz del dispositivo, o la entrada y salida del conector de audio.
  • DEBE manejar devoluciones de llamada de finalización del búfer de audio para los lados de entrada y salida de los puntos finales correspondientes en el mismo hilo cuando ambos están activos, e ingresar la devolución de llamada de salida inmediatamente después del retorno de la devolución de llamada de entrada. O si no es factible manejar las devoluciones de llamada en el mismo subproceso, ingrese la devolución de llamada de salida poco después de ingresar la devolución de llamada de entrada para permitir que la aplicación tenga una sincronización consistente de los lados de entrada y salida.
  • DEBE minimizar la diferencia de fase entre el almacenamiento en búfer de audio HAL para los lados de entrada y salida de los puntos finales correspondientes.
  • DEBE minimizar la latencia táctil.
  • DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).
  • Debe tener una latencia desde la entrada táctil hasta la salida de audio de menos de o igual a 40 ms.

Si las implementaciones de dispositivos cumplen con todos los requisitos anteriores,:

  • [C-SR-4] RECOMENDAMOS ENCARECIDAMENTE informar la compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager .

Si las implementaciones del dispositivo incluyen un conector de audio de 3,5 mm de 4 conductores,:

Si las implementaciones del dispositivo omiten un conector de audio de 3,5 mm de 4 conductores e incluyen un puerto USB que admite el modo de host USB,:

  • [C-3-1] DEBE implementar la clase de audio USB.
  • [C-3-2] DEBE tener una latencia de audio de ida y vuelta continua media de 25 milisegundos o menos, en 5 mediciones con una desviación absoluta media inferior a 5 milisegundos a través del puerto en modo host USB utilizando la clase de audio USB. (Esto se puede medir utilizando un adaptador USB de 3,5 mm y un dongle de bucle invertido de audio, o utilizando una interfaz de audio USB con cables de conexión que conectan las entradas a las salidas).
  • [C-SR-6] Se RECOMIENDAN ENCARECIDAMENTE para admitir E/S simultáneas de hasta 8 canales en cada dirección, frecuencia de muestreo de 96 kHz y profundidad de 24 o 32 bits, cuando se utilizan con periféricos de audio USB que también admiten estos requisitos.
  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE cumplir con este grupo de requisitos utilizando la API de audio nativa AAudio a través de la ruta MMAP.

Si las implementaciones de dispositivos incluyen un puerto HDMI,:

  • DEBE admitir salida en estéreo y ocho canales a una profundidad de 20 o 24 bits y 192 kHz sin pérdida de profundidad de bits ni remuestreo, en al menos una configuración.

5.11. Captura para sin procesar

Android incluye soporte para la grabación de audio sin procesar a través de la fuente de audio android.media.MediaRecorder.AudioSource.UNPROCESSED . En OpenSL ES, se puede acceder a él con el registro preestablecido SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Si las implementaciones de dispositivos pretenden admitir fuentes de audio no procesadas y ponerlas a disposición de aplicaciones de terceros, deben:

  • [C-1-1] DEBE informar el soporte a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED .

  • [C-1-2] DEBE exhibir características de amplitud versus frecuencia aproximadamente planas en el rango de frecuencia media: específicamente ±10 dB de 100 Hz a 7000 Hz para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-3] DEBE exhibir niveles de amplitud en el rango de frecuencia baja: específicamente de ±20 dB de 5 Hz a 100 Hz 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-4] DEBE exhibir niveles de amplitud en el rango de frecuencia alta: específicamente desde ±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] DEBE configurar la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1000 Hz reproducida a un nivel de presión sonora (SPL) de 94 dB produzca una respuesta con RMS de 520 para muestras de 16 bits (o -36 dB de escala completa para muestras de punto flotante/doble precisión) para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [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 utilizados para grabar la fuente de audio sin procesar. (mientras que la SNR se mide como la diferencia entre 94 dB SPL y el SPL equivalente de ruido propio, ponderado A).

  • [C-1-7] DEBE tener una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de 90 dB SPL en todos y cada uno de los micrófonos utilizados para grabar la fuente de audio sin procesar.

  • [C-1-8] No DEBE tener ningún otro procesamiento de señal (por ejemplo, control automático de ganancia, filtro de paso alto o cancelación de eco) en la ruta que no sea un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:

    • [C-1-9] Si algún procesamiento de señal está presente en la arquitectura por algún motivo, DEBE desactivarse e introducir efectivamente cero retraso o latencia adicional en la ruta de la señal.
    • [C-1-10] El multiplicador de nivel, aunque se le permite estar en la ruta, NO DEBE introducir retraso o latencia en la ruta de la señal.

Todas las mediciones de SPL se realizan directamente al lado del micrófono bajo prueba. Para configuraciones de múltiples micrófonos, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone pero no admiten fuentes de audio sin procesar, estas:

  • [C-2-1] DEBE devolver null para el método API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) , para indicar correctamente la falta de soporte.
  • [C-SR-1] siguen siendo ENCARECIDAMENTE RECOMENDADOS para satisfacer la mayor cantidad posible de requisitos de ruta de señal para la fuente de grabación sin procesar.

6. Compatibilidad de opciones y herramientas de desarrollador

6.1. Herramientas de desarrollo

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir las herramientas de desarrollo de Android proporcionadas en el SDK de Android.
  • Puente de depuración de Android (adb)

    • [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y los comandos de shell proporcionados en AOSP, que pueden ser utilizados por los desarrolladores de aplicaciones, incluidas dumpsys cmd stats
    • [C-0-11] DEBE admitir el comando de shell cmd testharness . La actualización de implementaciones de dispositivos desde una versión anterior de Android sin un bloque de datos persistente PUEDE estar exenta de C-0-11.
    • [C-0-3] NO DEBE alterar el formato o el contenido de los eventos del sistema del dispositivo (batterystats, diskstats, huella digital, gráficosstats, netstats, notificación, procstats) registrados mediante el comando dumpsys.
    • [C-0-10] DEBE registrar, sin omisión, y hacer que los siguientes eventos sean accesibles y estén disponibles para el comando cmd stats shell y la clase API del sistema StatsManager .
      • ActividadForegroundStateCambiado
      • Anomalía detectada
      • AppBreadcrumbReportado
      • Se produjo un bloqueo de la aplicación
      • Inicio de aplicación ocurrido
      • Nivel de batería cambiado
      • Estado del modo de ahorro de batería cambiado
      • BleScanResultReceived
      • BleScanStateCambiado
      • Estado de carga cambiado
      • DispositivoIdleModeStateCambiado
      • Estado de servicio en primer plano cambiado
      • GpsScanStateCambiado
      • Estado del trabajo cambiado
      • EstadoEnchufadoCambiado
      • Estado del trabajo programado cambiado
      • ScreenStateChanged
      • Estado de sincronización cambiado
      • SystemelapsedRealtime
      • UidProcessStateCambiado
      • WakelockStateCambió
      • WakeUpalarmoccured
      • WifiLockStateCambiado
      • WifiMulticastLockStateCambiado
      • WifiScanStateCambiado
    • [C-0-4] DEBE tener el demonio adb del lado del dispositivo inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar el Puente de depuración de Android.
    • [C-0-5] DEBE admitir adb seguro. Android incluye soporte para adb seguro. Secure adb habilita adb en hosts autenticados conocidos.
    • [C-0-6] DEBE proporcionar un mecanismo que permita conectar adb desde una máquina host. Específicamente:

    Si las implementaciones de dispositivos sin puerto USB admiten el modo periférico,:

    • [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 a los desarrolladores conectarse al dispositivo mediante el protocolo adb.

    Si las implementaciones del dispositivo admiten conexiones ADB a una máquina host a través de Wi-Fi, ellos:

    • [C-4-1] Debe tener el método AdbManager#isAdbWifiSupported() return de retorno true .

    Si las implementaciones de dispositivos admiten conexiones ADB a una máquina host a través de Wi-Fi e incluyen al menos una cámara, ellos:

    • [C-5-1] DEBE que el método AdbManager#isAdbWifiQrSupported() devuelva true .
  • Servicio de monitorización de depuración de Dalvik (ddms)

    • [C-0-7] DEBE admitir todas las funciones de ddms según lo documentado en el SDK de Android. Como ddms usa adb, la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.
  • Mono

    • [C-0-8] debe incluir el marco de mono y ponerlo a disposición de las aplicaciones que los usen.
  • SysTrace

    • [C-0-9] DEBE admitir la herramienta systrace como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar Systrace.
  • perfecto

    • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE exponer un binario /system/bin/perfetto al usuario del shell cuyo cmdline cumpla con la documentación de perfetto .
    • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que el binario perfetto acepte como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE que el binario perfetto escriba como salida un seguimiento de protobuf que cumpla con el esquema definido en la documentación de perfetto .
    • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE proporcionar, a través del binario perfetto, al menos las fuentes de datos descritas en la documentación de perfetto .
  • Asesino de poca memoria

    • [C-0-10] debe escribir un átomo LMK_KILL_OCCURRED_FIELD_NUMBER en el registro STATSD cuando el asesino de baja memoria termina una aplicación.
  • Modo de prueba de arnés Si las implementaciones de dispositivos admiten el comando de shell cmd testharness y ejecutan cmd testharness enable ,:

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o superior a través de los indicadores de función android.hardware.vulkan.version , ellos:

  • [C-1-1] DEBE proporcionar una posibilidad para que el desarrollador de la aplicación habilite/deshabilite las capas de depuración de GPU.
  • [C-1-2] DEBE, cuando las capas de depuración de GPU están habilitadas, enumerar las capas en bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte de la plataforma o paquete de aplicación) que se encuentran en el directorio base de las aplicaciones depurables para admitir vkEnumerateInstanceLayerProperties() y vkCreateInstance () Métodos API.

6.2. Opciones de desarrollador

Android incluye soporte para los desarrolladores para configurar la configuración relacionada con el desarrollo de aplicaciones.

Las implementaciones de dispositivos DEBEN proporcionar una experiencia consistente para las Opciones de Desarrollador, ellas:

  • [C-0-1] DEBE respetar la intención de android.settings.APPLICATION_DEVELOPMENT_SETTINGS de mostrar la configuración relacionada con el desarrollo de aplicaciones. La implementación ascendente de Android oculta el menú Opciones de desarrollador de forma predeterminada y permite a los usuarios iniciar Opciones de desarrollador después de presionar siete (7) veces en el elemento de menú Configuración > Acerca del dispositivo > Número de compilación .
  • [C-0-2] DEBE ocultar las Opciones de desarrollador de forma predeterminada.
  • [C-0-3] DEBE proporcionar un mecanismo claro que no dé trato preferencial a una aplicación de terceros frente a otra para habilitar las Opciones de desarrollador. Debe proporcionar un documento o sitio web visible público que describa cómo habilitar las opciones de desarrollador. Este documento o sitio web DEBE poder vincularse desde los documentos del SDK de Android.
  • DEBE tener una notificación visual continua para el usuario cuando las Opciones de desarrollador estén habilitadas y la seguridad del usuario sea motivo de preocupación.
  • PUEDE limitar temporalmente el acceso al menú Opciones de desarrollador, ocultando o deshabilitando visualmente el menú, para evitar distracciones en escenarios en los que la seguridad del usuario es preocupante.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware particular que tiene una API correspondiente para desarrolladores externos:

  • [C-0-1] La implementación del dispositivo DEBE implementar esa 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 declara opcional y la implementación del dispositivo no posee ese componente:

  • [C-0-2] Aún DEBEN presentarse definiciones de clases completas (según lo documentado por el SDK) para las API de los componentes.
  • [C-0-3] Los comportamientos de la API DEBEN implementarse como no operativos de alguna manera razonable.
  • [C-0-4] Los métodos API DEBEN devolver valores nulos cuando lo permita la documentación del SDK.
  • [C-0-5] Los métodos API DEBEN devolver implementaciones no operativas de clases donde la documentación del SDK no permite valores nulos.
  • [C-0-6] Los métodos API NO DEBEN generar excepciones no documentadas en la documentación del SDK.
  • [C-0-7] Las implementaciones de dispositivos DEBEN informar constantemente información precisa de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella digital de compilación.

Un ejemplo típico de un escenario en el que se aplican estos requisitos es la API de telefonía: incluso en dispositivos que no son teléfonos, estas API deben implementarse como operaciones no operativas razonables.

7.1. Pantalla y gráficos

Android incluye instalaciones que ajustan automáticamente los activos de aplicación y los diseños de UI adecuadamente para el dispositivo para garantizar que las aplicaciones de terceros funcionen bien en una variedad de configuraciones de hardware . En las pantalla (s) compatible con Android donde todas las aplicaciones compatibles con Android de terceros pueden ejecutarse, las implementaciones del dispositivo deben implementar correctamente estas API y comportamientos, como se detalla en esta sección.

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

  • Tamaño diagonal físico . La distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
  • puntos por pulgada (DPI) . El número de píxeles abarcados por un tramo horizontal o vertical lineal de 1 ". Donde se enumeran los valores de DPI, tanto el DPI horizontal como el vertical deben caer dentro del rango.
  • relación de aspecto . La relación entre los píxeles de la dimensión más larga y la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480x854 píxeles sería 854/480 = 1,779, o aproximadamente “16:9”.
  • Píxel independiente de la densidad (dp) . La unidad de píxel virtual se normalizó a una pantalla de 160 dpi, calculada como: píxeles = dps * (densidad/160).

7.1.1. Configuración de pantalla

7.1.1.1. Tamaño y forma de pantalla

El marco de la interfaz de usuario de Android admite una variedad de diferentes tamaños de diseño de pantalla lógica, y permite que las aplicaciones consulten el tamaño de diseño de pantalla de la configuración actual a través Configuration.smallestScreenWidthDp Configuration.screenLayout SCREENLAYOUT_SIZE_MASK

Implementaciones de dispositivos:

  • [C-0-1] DEBE informar el tamaño de diseño correcto para Configuration.screenLayout como se define en la documentación del SDK de Android. Específicamente, las implementaciones de dispositivos DEBEN informar las dimensiones correctas de la pantalla de píxeles (dp) independientes de la densidad lógica como se muestra a continuación:

    • Los dispositivos con Configuration.uiMode configurado con cualquier valor distinto de UI_MODE_TYPE_WATCH y que informan un tamaño small para Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
    • Los dispositivos que informan un tamaño normal para Configuration.screenLayout DEBEN tener al menos 480 dp x 320 dp.
    • Los dispositivos que informan un tamaño large para Configuration.screenLayout DEBEN tener al menos 640 dp x 480 dp.
    • Los dispositivos que informan un tamaño xlarge para Configuration.screenLayout DEBEN tener al menos 960 dp x 720 dp.
  • [C-0-2] DEBE respetar correctamente la compatibilidad indicada de las aplicaciones para tamaños de pantalla a través del atributo supports-screens en 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 UI_MODE_TYPE_NORMAL e incluyen visualización (s) compatible con Android con esquinas redondeadas, ellos:

  • [C-1-1] debe asegurarse de que se cumplan al menos uno de los siguientes requisitos:

    • El radio de las esquinas redondeadas es menor o igual a 38 dp.
    • Cuando un cuadro de 15 dp por 15 dp está anclado en cada esquina de la pantalla lógica, al menos un píxel de cada cuadro es visible en la pantalla.
  • DEBE incluir la posibilidad de que el usuario cambie al modo de visualización con las esquinas rectangulares.

Si las implementaciones de dispositivos incluyen una pantalla compatible con Android que es plegable o incluye una bisagra plegable entre varios paneles de pantalla y hace que dichas pantallas estén disponibles para representar aplicaciones de terceros, estas:

Si las implementaciones de dispositivos incluyen una pantalla compatible con Android que es plegable o incluye una bisagra plegable entre varios paneles de pantalla y si la bisagra o el pliegue cruza una ventana de aplicación de pantalla completa,:

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

Para obtener detalles sobre la implementación correcta de las API de extensión o sidecar, consulte la documentación pública de Window Manager Jetpack .

7.1.1.2. Relación de aspecto de pantalla

Si bien no existe ninguna restricción en cuanto a la relación de aspecto de la pantalla física para las pantallas compatibles con Android, la relación de aspecto de la pantalla lógica donde se representan aplicaciones de terceros, que se puede derivar de los valores de alto y ancho informados a través de Las API view.Display y las API de configuración DEBEN cumplir con los siguientes requisitos:

  • [C-0-1] Implementaciones de dispositivos con Configuration.uiMode establecido en UI_MODE_TYPE_NORMAL debe tener un valor de relación de aspecto menor o igual a 1.86 (aproximadamente 16: 9), a menos que la aplicación cumpla con una de las siguientes condiciones:

    • La aplicación ha declarado que admite una relación de aspecto de pantalla más grande a través del valor de metadatos android.max_aspect .
    • La aplicación declara que se puede cambiar de tamaño mediante el atributo android:resizeableActivity .
    • La aplicación tiene como objetivo el nivel API 24 o superior y no declara android:maxAspectRatio que restringiría la relación de aspecto permitida.
  • [C-0-3] Las implementaciones de dispositivos con Configuration.uiMode configurado como UI_MODE_TYPE_WATCH DEBEN tener un valor de relación de aspecto establecido como 1,0 (1:1).

7.1.1.3. Densidad de la pantalla

El marco de la interfaz de usuario de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientar los recursos de la aplicación.

  • [C-0-1] De forma predeterminada, las implementaciones del dispositivo deben informar solo una de las densidades de Android Framework que se enumeran en DisplayMetrics a través de la API DENSITY_DEVICE_STABLE y este valor no debe cambiar en ningún momento; Sin embargo, el dispositivo puede informar una densidad arbitraria diferente de acuerdo con los cambios de configuración de visualización realizados por el usuario (por ejemplo, tamaño de pantalla) establecido después del arranque inicial.

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

Si hay la posibilidad de cambiar el tamaño de visualización del dispositivo:

  • [C-1-1] El tamaño de la pantalla no debe escalarse más de 1.5 veces la densidad nativa o producir una dimensión de pantalla mínima efectiva menor que 320dp (equivalente al calificador de recursos SW320DP), lo que ocurra primero.
  • [C-1-2] El tamaño de la pantalla no debe escalarse más pequeño que 0.85 veces la densidad nativa.
  • Para garantizar una buena usabilidad y tamaños de fuente consistentes, se RECOMIENDA que se proporcione la siguiente escala de opciones de visualización nativa (cumpliendo con los límites especificados anteriormente)
    • Pequeño: 0,85x
    • Valor predeterminado: 1x (escala de visualización nativa)
    • Grande: 1,15x
    • Más grande: 1,3x
    • Más grande 1.45x

7.1.2. Muestra métricas

Si las implementaciones de dispositivos incluyen pantallas compatibles con Android o salida de video a pantallas compatibles con Android, estas:

  • [C-1-1] DEBE informar los valores correctos para todas las métricas de visualización compatibles con Android definidas en la API android.util.DisplayMetrics .

Si las implementaciones del dispositivo no incluyen una pantalla integrada o una salida de video, ellos:

  • [C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android tal como se define en la API android.util.DisplayMetrics para la view.Display predeterminada emulada.Display .

7.1.3. Orientación de la pantalla

Implementaciones de dispositivos:

  • [C-0-1] DEBE informar qué orientaciones de pantalla admiten ( android.hardware.screen.portrait y/o android.hardware.screen.landscape ) y DEBE informar al menos una orientación admitida. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como un televisor o una computadora portátil, DEBE informar solo android.hardware.screen.landscape .
  • [C-0-2] DEBE informar el valor correcto para la orientación actual del dispositivo, siempre que se realice una consulta a través de android.content.res.Configuration.orientation , android.view.Display.getOrientation() u otras API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla,:

  • [C-1-1] DEBE admitir la orientación dinámica mediante aplicaciones en orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una orientación de pantalla específica.
  • [C-1-2] NO DEBE cambiar el tamaño o la densidad de la pantalla informados al cambiar la orientación.
  • PUEDE 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 de 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 API administradas (como a través del método GLES10.getString() ) y las API nativas.
  • [C-0-2] DEBE incluir el soporte para todas las API administradas y API nativas correspondientes para cada versión de OpenGL ES que identificaron para admitir.

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • [C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, como se incluye y detalla en la documentación del SDK de Android .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que sean compatibles con OpenGL ES 3.1.
  • DEBE admitir OpenGL ES 3.2.

Las pruebas OpenGL ES dEQP se dividen en varias listas de pruebas, cada una con un número de fecha/versión asociado. Estos están en el árbol fuente de Android en external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt . Un dispositivo que admite OpenGL ES en un nivel autoinformado indica que puede pasar las pruebas dEQP en todas las listas de pruebas de este nivel y anteriores.

Si las implementaciones de dispositivos admiten cualquiera de las versiones de OpenGL ES, estas:

  • [C-2-1] DEBEN informar a través de las API administradas de OpenGL ES y las API nativas sobre cualquier otra extensión de OpenGL ES que hayan implementado y, a la inversa, NO DEBEN informar cadenas de extensión que no admiten.
  • [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 Extensiones , EGL_ANDROID_recordable y EGL_ANDROID_GLES_layers .
  • [C-2-3] DEBE informar la versión máxima de las pruebas OpenGL ES dEQP admitidas a través del indicador de función android.software.opengles.deqp.level .
  • [C-2-4] DEBE ser al menos compatible con la versión 132383489 (desde el 1 de marzo de 2020) como se informa en el indicador de función android.software.opengles.deqp.level .
  • [C-2-5] DEBE pasar todas las pruebas dEQP de OpenGL ES en las listas de pruebas entre la versión 132383489 y la versión especificada en el indicador de función android.software.opengles.deqp.level , para cada versión de OpenGL ES compatible.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE admitir las extensiones EGL_KHR_partial_update y OES_EGL_image_external .
  • Debe informar con precisión a través del método getString() , cualquier formato de compresión de textura que admitan, que típicamente es específico del proveedor.

Si las implementaciones de dispositivos declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2,:

  • [C-3-1] DEBE exportar los símbolos de función correspondientes para esta versión además de los símbolos de función de OpenGL ES 2.0 en la biblioteca libGLESv2.so.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE admitir la extensión OES_EGL_image_external_essl3 .

Si las implementaciones de dispositivos son compatibles con OpenGL ES 3.2,:

  • [C-4-1] DEBE admitir el paquete de extensión de Android OpenGL ES en su totalidad.

Si las implementaciones de dispositivos son compatibles con OpenGL ES Android Extension Pack en su totalidad,:

  • [C-5-1] DEBE identificar el soporte a través del indicador de función android.hardware.opengles.aep .

Si las implementaciones de dispositivos exponen la compatibilidad con la extensión EGL_KHR_mutable_render_buffer ,:

  • [C-6-1] También DEBE admitir la extensión EGL_ANDROID_front_buffer_auto_refresh .
7.1.4.2 Vulkan

Android incluye soporte para Vulkan , una API multiplataforma de bajo costo para gráficos 3D de alto rendimiento.

Si las implementaciones de dispositivos son compatibles con OpenGL ES 3.1,:

  • [C-SR-1] se recomienda encarecidamente incluir apoyo para Vulkan 1.1.

Si las implementaciones de dispositivos incluyen una pantalla o salida de video, estas:

  • Debe incluir apoyo para Vulkan 1.1.

Las pruebas de Vulkan DEQP se dividen en una serie de listas de pruebas, cada una con una fecha/versión asociada. Estos están en el árbol fuente de Android en external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt . Un dispositivo que admite Vulkan en un nivel autoinformado indica que puede pasar las pruebas dEQP en todas las listas de pruebas de este nivel y anteriores.

Si las implementaciones de dispositivos incluyen soporte para Vulkan 1.0 o superior, ellos:

  • [C-1-1] DEBE informar el valor entero correcto con los indicadores de función android.hardware.vulkan.level y android.hardware.vulkan.version .
  • [C-1-2] DEBE enumerar al menos un VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] debe implementar completamente las API Vulkan 1.0 para cada VkPhysicalDevice enumerado.
  • [C-1-4] DEBE enumerar las capas contenidas en bibliotecas nativas denominadas libVkLayer*.so en el directorio de la biblioteca nativa del paquete de la aplicación, a través de las API nativas de Vulkan vkEnumerateInstanceLayerProperties() y vkEnumerateDeviceLayerProperties() .
  • [C-1-5] no deben enumerar las capas proporcionadas por bibliotecas fuera del paquete de aplicaciones, o proporcionar otras formas de rastrear o interceptar la API Vulkan, a menos que la aplicación tenga el atributo android:debuggable establecido como true .
  • [C-1-6] DEBEN informar todas las cadenas de extensión que admiten a través de las API nativas de Vulkan y, a la inversa, NO DEBEN informar las cadenas de extensión que no admiten correctamente.
  • [C-1-7] DEBE admitir las extensiones VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain y VK_KHR_incremental_present.
  • [C-1-8] DEBE informar la versión máxima de las pruebas Vulkan dEQP admitidas a través del indicador de función android.software.vulkan.deqp.level .
  • [C-1-9] DEBE ser al menos compatible con la versión 132317953 (desde el 1 de marzo de 2019) como se informa en el indicador de función android.software.vulkan.deqp.level .
  • [C-1-10] DEBE pasar todas las pruebas de Vulkan dEQP en las listas de pruebas entre la versión 132317953 y la versión especificada en el indicador de función android.software.vulkan.deqp.level .
  • [C-1-11] NO DEBE enumerar la compatibilidad con las extensiones VK_KHR_video_queue, VK_KHR_video_decode_queue o VK_KHR_video_encode_queue.
  • [C-SR-2] se recomienda encarecidamente admitir las extensiones VK_KHR_DRIVER_Properties y VK_GOOGLE_DISPLAY_TIMING.

Si las implementaciones de dispositivos no incluyen soporte para Vulkan 1.0,:

  • [C-2-1] NO DEBE declarar ninguna de las características de Vulkan (por ejemplo, android.hardware.vulkan.level , android.hardware.vulkan.version ).
  • [C-2-2] NO DEBE enumerar ningún VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .

Si las implementaciones del dispositivo incluyen soporte para Vulkan 1.1 y declaran cualquiera de los indicadores de características de Vulkan, ellos:

  • [C-3-1] DEBE exponer la compatibilidad con el semáforo externo SYNC_FD y los tipos de identificadores y la extensión VK_ANDROID_external_memory_android_hardware_buffer .
7.1.4.3 RenderScript
  • [C-0-1] Las implementaciones de dispositivos DEBEN admitir Android RenderScript , como se detalla en la documentación del SDK de Android.
7.1.4.4 Aceleración de gráficos 2D

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D en el nivel de Aplicación, Actividad, Ventana o Vista mediante el uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas API directas.

Implementaciones de dispositivos:

  • [C-0-1] debe habilitar la aceleración de hardware de forma predeterminada y debe deshabilitar la aceleración de hardware si el desarrollador así lo solicita configurando Android: HardWAccelerated = "False" o deshabilitar la aceleración de hardware directamente a través de las API de la vista Android.
  • [C-0-2] DEBE exhibir un comportamiento consistente con la documentación del SDK de Android sobre aceleración de hardware .

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas OpenGL ES aceleradas por hardware como objetivos de renderizado en una jerarquía de interfaz de usuario.

Implementaciones de dispositivos:

  • [C-0-3] debe admitir la API TextureView y debe exhibir un comportamiento consistente con la implementación de Android aguas arriba.
7.1.4.5 pantallas de vía ancha

Si las implementaciones de dispositivos afirman ser compatibles con pantallas de gama amplia a través de Configuration.isScreenWideColorGamut() ,:

  • [C-1-1] DEBE tener una pantalla con color calibrado.
  • [C-1-2] DEBE tener una pantalla cuya gama cubra completamente la gama de colores sRGB en el espacio CIE 1931 xyY.
  • [C-1-3] DEBE tener una pantalla cuya gama tenga un área de al menos el 90 % de DCI-P3 en el espacio CIE 1931 xyY.
  • [C-1-4] DEBE admitir OpenGL ES 3.1 o 3.2 e informarlo correctamente.
  • [C-1-5] DEBE anunciar soporte para 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 extensiones play_p3_linear y EGL_EXT_gl_colorspace_display_p3_passthrough .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE que sean compatibles con GL_EXT_sRGB .

Por el contrario, si las implementaciones de dispositivos no admiten pantallas de gama amplia, estas:

  • [C-2-1] DEBE cubrir el 100 % o más de sRGB en el espacio CIE 1931 xyY, aunque la gama de colores de la pantalla no está definida.

7.1.5. Modo de compatibilidad de la aplicación heredada

Android especifica un "modo de compatibilidad" en el que el marco opera en un modo de tamaño de pantalla "normal" equivalente (ancho de 320 dp) para beneficio de aplicaciones heredadas no desarrolladas para versiones antiguas de Android anteriores a la independencia del tamaño de pantalla.

7.1.6. Tecnología de pantalla

La plataforma Android incluye API que permiten a las aplicaciones representar gráficos enriquecidos en una pantalla compatible con Android. Los dispositivos DEBEN admitir todas estas API según lo definido por el SDK de Android, a menos que se permita específicamente en este documento.

Todas las pantallas compatibles con Android de la implementación de un dispositivo:

  • [C-0-1] DEBE ser capaz de reproducir gráficos en color de 16 bits.
  • DEBE admitir pantallas con capacidad para gráficos en 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 casi cuadrada (1,0) con una tolerancia del 10 al 15 %.

7.1.7. Pantallas secundarias

Android incluye soporte para pantallas secundarias compatibles con Android para permitir capacidades de intercambio de medios y API de desarrollador para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa, ya sea a través de una conexión de pantalla adicional cableada, inalámbrica o incorporada,:

  • [C-1-1] DEBE implementar el servicio del sistema DisplayManager y la API como se describe en la documentación del SDK de Android.

7.2. Los dispositivos de entrada

Implementaciones de dispositivos:

7.2.1. Teclado

Si las implementaciones de dispositivos incluyen soporte para aplicaciones de editor de métodos de entrada (IME) de terceros, estas:

Implementaciones de 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.keyboard (Qwerty o 12-key).
  • Debe incluir implementaciones adicionales de teclado suave.
  • Puede incluir un teclado de hardware.

7.2.2. Navegación no táctil

Android incluye soporte para d-pad, trackball y rueda como mecanismos para navegación no táctil.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos carecen de navegación no táctil, estas:

  • [C-1-1] DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición de texto, compatible con los motores de gestión de entrada. La implementación 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

Las funciones Inicio , Recientes y Atrás , que generalmente se brindan a través de una interacción con un botón físico dedicado o una parte distinta de la pantalla táctil, son esenciales para el paradigma de navegación de Android y, por lo tanto, para las implementaciones de dispositivos:

  • [C-0-1] DEBE proporcionar al usuario la posibilidad de iniciar aplicaciones instaladas que tengan una actividad con el <intent-filter> configurado con ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para implementaciones de dispositivos de televisión. La función Inicio DEBE ser el mecanismo para esta prestación al usuario.
  • DEBE proporcionar botones para la función Recientes y Atrás.

Si se proporcionan las funciones Inicio, Recientes o Atrás, estas:

  • [C-1-1] DEBE ser accesible con una sola acción (por ejemplo, toque, doble clic o gesto) cuando cualquiera de ellos sea accesible.
  • [C-1-2] DEBE proporcionar una indicación clara de qué acción única desencadenaría cada función. Tener un ícono visible impreso en el botón, mostrar un ícono de software en la parte de la barra de navegación de la pantalla o guiar al usuario a través de un flujo de demostración guiado paso a paso durante la experiencia de configuración inmediata son ejemplos de tal indicación.

Implementaciones de dispositivos:

  • Se RECOMIENDA ENCARECIDAMENTE [C-SR-1] no proporcionar el mecanismo de entrada para la función Menú , ya que está obsoleto en favor de la barra de acciones desde Android 4.0.

Si las implementaciones de dispositivos proporcionan la función Menú, estas:

  • [C-2-1] DEBE mostrar el botón de desbordamiento de acciones siempre que el menú emergente de desbordamiento de acciones no esté vacío y la barra de acciones esté visible.
  • [C-2-2] NO DEBE modificar la posición de la ventana emergente de desbordamiento de acción que se muestra al seleccionar el botón de desbordamiento en la barra de acciones, pero PUEDE mostrar la ventana emergente de desbordamiento de acción en una posición modificada en la pantalla cuando se muestra seleccionando el Menú función.

Si las implementaciones de dispositivos no proporcionan la función de menú, para la compatibilidad hacia atrás, ellos:

  • [C-3-1] debe hacer que la función de menú esté disponible para las aplicaciones cuando targetSdkVersion es inferior a 10, ya sea por un botón físico, una tecla de software o gestos. Esta función de menú debe ser accesible a menos que se oculte junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función Asistencia , estas:

  • [C-4-1] DEBE hacer que la función Asistencia sea accesible con una sola acción (por ejemplo, tocar, hacer doble clic o hacer un gesto) cuando se pueda acceder a otras teclas de navegación.
  • [C-SR-2] Muy recomendable para usar Long Press en la función de inicio como esta interacción designada.

Si las implementaciones de dispositivos utilizan una parte distinta de la pantalla para mostrar las teclas de navegación,:

  • [C-5-1] Las teclas de navegación DEBEN utilizar una parte distinta de la pantalla, no disponible para las aplicaciones, y NO DEBEN oscurecer ni interferir de otro modo con la parte de la pantalla disponible para las aplicaciones.
  • [C-5-2] DEBE poner a disposición de las aplicaciones una parte de la pantalla que cumpla con los requisitos definidos en la sección 7.1.1 .
  • [C-5-3] Debe honrar las banderas establecidas por la aplicación a través del método API View.setSystemUiVisibility() , de modo que esta parte distinta de la pantalla (también conocida como la barra de navegación) se oculta correctamente 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() DEBE usarse solo para informar el área de reconocimiento de gestos de Inicio.
  • [C-6-2] Los gestos que comienzan dentro de un rectángulo de exclusión proporcionado por la aplicación de primer plano a través de View#setSystemGestureExclusionRects() , pero fuera de WindowInsets#getMandatorySystemGestureInsets() , NO DEBEN ser interceptados para la función de navegación siempre que el rectángulo de exclusión está permitido dentro del límite máximo de exclusión como se especifica en la documentación de View#setSystemGestureExclusionRects() .
  • [C-6-3] DEBE enviar a la aplicación de primer plano un evento MotionEvent.ACTION_CANCEL una vez que los toques comienzan a ser interceptados por un gesto del sistema, si a la aplicación de primer plano se le envió previamente un evento MotionEvent.ACTION_DOWN .
  • [C-6-4] DEBE proporcionar al usuario la posibilidad de cambiar a una navegación en pantalla basada en botones (por ejemplo, en Configuración).
  • DEBE proporcionar la función Inicio deslizando el dedo hacia arriba desde el borde inferior de la orientación actual de la pantalla.
  • DEBE proporcionar la función Recientes deslizando hacia arriba y manteniendo presionado antes de soltarlo, desde la misma área que el gesto de Inicio.
  • Los gestos que comienzan dentro de WindowInsets#getMandatorySystemGestureInsets() NO DEBEN verse afectados por las rectificaciones de exclusión proporcionadas por la aplicación de primer plano a través de View#setSystemGestureExclusionRects() .

Si se proporciona una función de navegación desde cualquier lugar de los bordes izquierdo y derecho de la orientación actual de la pantalla:

  • [C-7-1] La función de navegación DEBE ser Atrás y proporcionarse al deslizar el dedo desde los bordes izquierdo y derecho de la orientación actual de la pantalla.
  • [C-7-2] Si se proporcionan paneles de sistema deslizables personalizados en los bordes izquierdo o derecho, deben colocarse dentro de la parte superior 1/3 de la pantalla con una indicación visual clara y persistente de que arrastrarse invocaría los paneles antes mencionados, y por lo tanto no Atrás. Un usuario PUEDE configurar un panel del sistema de manera que quede debajo del tercio superior de los bordes de la pantalla, pero el panel del sistema NO DEBE usar más de 1/3 de los bordes.
  • [C-7-3] Cuando la aplicación de primer plano tiene las banderas View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE configuradas, deslizar el dedo desde los bordes DEBE comportarse como se implementa en AOSP, que está documentado en el SDK .
  • [C-7-4] Cuando la aplicación de primer plano tiene las banderas View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE configuradas, los paneles del sistema deslizables personalizados DEBEN estar ocultos hasta que el usuario los introduzca o los desaten. el barras del sistema (también conocidas como barra de navegación y estado) tal como se implementan en AOSP.

7.2.4. Entrada de pantalla táctil

Android incluye soporte para una variedad de sistemas de entrada de puntero, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basados ​​en pantalla táctil están asociadas con una pantalla de manera que el usuario tiene la impresión de manipular directamente elementos en la pantalla. Dado que el usuario toca directamente la pantalla, el sistema no requiere ningún elemento adicional para indicar los objetos que se están manipulando.

Implementaciones de dispositivos:

  • DEBE tener un sistema de entrada de puntero de algún tipo (ya sea tipo mouse o táctil).
  • DEBE admitir punteros con seguimiento totalmente independiente.

Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor) en una pantalla principal compatible con Android,:

  • [C-1-1] DEBE informar TOUCHSCREEN_FINGER para el campo API Configuration.touchscreen .
  • [C-1-2] DEBE informar los indicadores de funciones android.hardware.touchscreen y android.hardware.faketouch .

Si las implementaciones de dispositivos incluyen una pantalla táctil que puede rastrear más de un toque en una pantalla principal compatible con Android,:

  • [C-2-1] DEBE informar los indicadores de características apropiados android.hardware.touchscreen.multitouch , android.hardware.touchscreen.multitouch.distinct , android.hardware.touchscreen.multitouch.jazzhand correspondiente al tipo de pantalla táctil específica en el dispositivo.

Si las implementaciones de dispositivos dependen de un dispositivo de entrada externo, como un mouse o trackball (es decir, que no tocan directamente la pantalla) para la entrada en una pantalla principal compatible con Android y cumplen con los requisitos de toque falso en la sección 7.2.5 ,:

  • [C-3-1] NO DEBE informar ningún indicador 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 campo API Configuration.touchscreen .

7.2.5. Entrada táctil falsa

La interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un subconjunto de capacidades de la pantalla táctil. Por ejemplo, un control remoto o mouse que impulsa un cursor en pantalla se aproxima al tacto, pero requiere que el usuario apunte o se concentre y luego haga clic. Numerosos dispositivos de entrada como el mouse, el trackpad, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el trackpad multitáctil pueden admitir interacciones táctiles falsas. Android incluye la característica constante android.hardware.faketouch, que corresponde a un dispositivo de entrada no táctil (basado en puntero) de alta fidelidad, como un mouse o trackpad, que puede emular adecuadamente la entrada táctil (incluida la compatibilidad con gestos básicos), y indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil.

Si las implementaciones de dispositivos no incluyen una pantalla táctil pero incluyen otro sistema de entrada de puntero que desean que esté disponible, ellos:

  • DEBE declarar soporte para el indicador de función android.hardware.faketouch .

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch ,:

  • [C-1-1] DEBE informar las posiciones absolutas X e Y de la ubicación del puntero en la pantalla y mostrar un puntero visual en la pantalla.
  • [C-1-2] DEBE informar el evento táctil con el código de acción que especifica el cambio de estado que ocurre en el puntero que sube o baja en la pantalla .
  • [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba sobre un objeto en la pantalla, lo que permite a los usuarios emular el toque de un objeto en la pantalla.
  • [C-1-4] DEBE admitir puntero hacia abajo, puntero hacia arriba, puntero hacia abajo y luego puntero hacia arriba en el mismo lugar de un objeto en la pantalla dentro de un umbral de tiempo, lo que permite a los usuarios emular un doble toque en un objeto en la pantalla.
  • [C-1-5] DEBE admitir un puntero hacia abajo en un punto arbitrario de la pantalla, un puntero que se mueve 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 y luego permitir a los usuarios mover rápidamente el objeto a una posición diferente en la pantalla y luego apuntar hacia arriba en la pantalla, lo que permite a los usuarios arrojar un objeto a la pantalla.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct ,:

  • [C-2-1] DEBE declarar soporte para android.hardware.faketouch .
  • [C-2-2] DEBE admitir un seguimiento distinto de dos o más entradas de puntero independientes.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.jazzhand ,:

  • [C-3-1] DEBE declarar soporte para 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 totalmente independiente.

7.2.6. Soporte de controlador de juego

7.2.6.1. Asignaciones de botones

Implementaciones de dispositivos:

  • [C-1-1] DEBE ser capaz de asignar eventos HID a las constantes InputEvent correspondientes como se enumeran en las tablas siguientes. La implementación ascendente de Android satisface este requisito.

Si las implementaciones de dispositivos incorporan un controlador o se envían con un controlador separado en la caja que proporcionaría medios para ingresar todos los eventos enumerados en las tablas a continuación,:

  • [C-2-1] DEBE declarar el indicador de función android.hardware.gamepad
Botón Uso de HID 2 Botón Android
un 1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B 1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 _ 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y 1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
pad direccional arriba 1
Control direccional abajo 1
0x01 0x0039 3 AXIS_HAT_Y 4
pad direccional izquierdo 1
pad direccional derecho 1
0x01 0x0039 3 AXIS_HAT_X 4
Botón del hombro izquierdo 1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Botón del hombro derecho 1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Clic 1 con el joystick izquierdo 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic con el joystick derecho 1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Atrás 1 0x0c 0x0224 Keycode_back (4)

1 evento clave

2 Los usos HID anteriores deben declararse dentro de una plataforma de juego 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, un máximo físico de 315, unidades en grados y un tamaño de informe de 4. El valor lógico se define como la rotación en el sentido de las agujas 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 hacia arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionan las teclas arriba e izquierda.

4 evento de movimiento

Controles analógicos 1 Uso de HID Botón Android
Gatillo izquierdo 0x02 0x00C5 AXIS_LTRIGGER
Gatillo derecho 0x02 0x00C4 AXIS_RTRIGGER
Palanca izquierda 0x01 0x0030
0x01 0x0031
EJE_X
EJE_Y
Palanca derecha 0x01 0x0032
0x01 0x0035
EJE_Z
EJE_RZ

1 evento de movimiento

7.2.7. Control remoto

Consulte la Sección 2.3.1 para conocer los requisitos específicos del dispositivo.

7.3. Sensores

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, la implementación del dispositivo 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 sensores .

Implementaciones de dispositivos:

  • [C-0-1] DEBE informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager .
  • [C-0-2] DEBE devolver una lista precisa de sensores compatibles a través de SensorManager.getSensorList() y métodos similares.
  • [C-0-3] DEBE comportarse razonablemente para todas las demás API de sensores (por ejemplo, devolviendo true o false según corresponda cuando las aplicaciones intentan registrar oyentes, no llamando a los oyentes de sensores cuando los sensores correspondientes no están presentes; etc.).

Si las implementaciones del dispositivo incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores de terceros, ellos:

  • [C-1-1] DEBE informar todas las mediciones de los sensores utilizando los valores pertinentes del Sistema Internacional de Unidades (métrico) para cada tipo de sensor, tal como se define en la documentación del SDK de Android.
  • [C-1-2] DEBE informar datos del sensor con una latencia máxima de 100 milisegundos + 2 * sample_time para el caso de un flujo de sensor con una latencia máxima solicitada de 0 ms cuando el procesador de aplicaciones está activo. Este retraso no incluye ningún retraso en el filtrado.
  • [C-1-3] DEBE informar la primera muestra del sensor dentro de los 400 milisegundos + 2 * sample_time de la activación del sensor. Es aceptable que esta muestra tenga una precisión de 0.
  • [C-1-4] Para que cualquier API indicada en la documentación del SDK de Android sea un sensor continuo , las implementaciones del dispositivo DEBEN proporcionar continuamente muestras de datos periódicas que DEBEN tener una fluctuación inferior al 3%, donde la fluctuación se define como la desviación estándar de la diferencia. de los valores de marca de tiempo informados entre eventos consecutivos.
  • [C-1-5] DEBE garantizar que el flujo de eventos del sensor NO DEBE impedir que la CPU del dispositivo entre en un estado de suspensión o se despierte 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 la hora en que ocurrió el evento y se sincronizó con el reloj SystemClock.elapsedRealtimeNano().
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE tener un error de sincronización de marca de tiempo inferior a 100 milisegundos, y DEBE tener un error de sincronización de marca de tiempo inferior a 1 milisegundo.
  • Cuando se activan varios sensores, el consumo de energía NO DEBE exceder la suma del consumo de energía informado de cada sensor individual.

La lista anterior no es exhaustiva; el comportamiento documentado del SDK de Android y la documentación de código abierto de Android sobre sensores debe considerarse autorizado.

Si las implementaciones del dispositivo incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores de terceros, ellos:

  • [C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores e informar el valor a través del método API Sensor.getResolution() .

Algunos tipos de sensores son compuestos, lo que significa que pueden derivarse de datos proporcionados por uno o más sensores. (Los ejemplos incluyen el sensor de orientación y el sensor de aceleración lineal).

Implementaciones de dispositivos:

  • DEBE implementar estos tipos de sensores, cuando incluyen los sensores físicos prerrequisitos como se describe en tipos de sensores .

Si las implementaciones de dispositivos incluyen un sensor compuesto,:

  • [C-2-1] DEBE implementar el sensor como se describe en la documentación de código abierto de Android sobre sensores compuestos .

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos y el sensor solo informa un valor, entonces las implementaciones de dispositivos:

  • [C-3-1] DEBE establecer la resolución en 1 para el sensor e informar el valor a través del método API Sensor.getResolution() .

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor está expuesto a desarrolladores externos, estos:

  • [C-4-1] NO DEBE incluir ningún parámetro de calibración fijo y determinado en fábrica en los datos proporcionados.

Si las implementaciones de dispositivos incluyen una combinación de acelerómetro de 3 ejes, un sensor giroscópico de 3 ejes o un sensor magnetómetro, son:

  • [C-SR-2] SE RECOMIENDA ENCARECIDAMENTE garantizar que el acelerómetro, el giroscopio y el magnetómetro tengan una posición relativa fija, de modo que si el dispositivo es transformable (por ejemplo, plegable), los ejes del sensor permanezcan alineados y consistentes con el sistema de coordenadas del sensor en todas las ocasiones posibles. Estados de transformación del dispositivo.

7.3.1. Acelerómetro

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes,:

  • [C-1-1] DEBE poder informar eventos con una frecuencia de al menos 50 Hz.
  • [C-1-2] debe implementar e informar el sensor TYPE_ACCELEROMETER .
  • [C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en las API de Android.
  • [C-1-4] DEBE ser capaz de medir desde caída libre hasta cuatro veces la gravedad (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 a 0,05 m/s^, donde la desviación estándar debe calcularse por eje en muestras recolectadas durante un período de al menos 3 segundos a la velocidad de muestreo más rápida.
  • [C-SR-2] se recomiendan fuertemente implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION .
  • [C-SR-3] se recomiendan en gran medida implementar e informar el sensor TYPE_ACCELEROMETER_UNCALIBRATED . Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android cumplan con este requisito para que puedan actualizarse a la versión futura de la plataforma donde esto pueda ser REQUERIDO.
  • DEBE implementar los sensores compuestos TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER como se describe en el documento del SDK de Android.
  • DEBE informar eventos de hasta al menos 200 Hz.
  • DEBE tener una resolución de al menos 16 bits.
  • DEBE calibrarse mientras está en uso si las características cambian durante el ciclo de vida y compensarse, y preservar los parámetros de compensación entre reinicios del dispositivo.
  • DEBE tener compensación de temperatura.

Si las implementaciones del dispositivo incluyen un acelerómetro de 3 ejes y cualquiera de los sensores compuestos TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER :

  • [C-2-1] La suma de su consumo de energía siempre debe ser inferior a 4 MW.
  • DEBEN estar por debajo de 2 mW y 0,5 mW cuando el dispositivo está en condición dinámica o estática.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor giroscópico de 3 ejes,:

  • [C-3-1] debe implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION .
  • [C-SR-4] se recomiendan fuertemente implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR .

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, un sensor giroscópico de 3 ejes y un sensor magnetómetro, estos:

  • [C-4-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR .

7.3.2. Magnetómetro

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un magnetómetro de 3 ejes (brújula).

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, estos:

  • [C-1-1] DEBE implementar el sensor TYPE_MAGNETIC_FIELD .
  • [C-1-2] DEBE poder informar eventos de hasta una frecuencia de al menos 10 Hz y DEBE informar eventos de hasta al menos 50 Hz.
  • [C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en las API de Android.
  • [C-1-4] DEBE ser capaz de medir entre -900 µT y +900 µT en cada eje antes de saturar.
  • [C-1-5] DEBE tener un valor de compensación de hierro duro inferior a 700 µT y DEBE tener un valor inferior a 200 µT, colocando el magnetómetro lejos de campos magnéticos dinámicos (inducidos por corriente) y estáticos (inducidos por imanes).
  • [C-1-6] DEBE tener una resolución igual o mayor a 0,6 µT.
  • [C-1-7] DEBE admitir la calibración y compensación en línea de la polarización del hierro duro y preservar los parámetros de compensación entre reinicios del dispositivo.
  • [C-1-8] DEBE tener aplicada la compensación de hierro dulce; la calibración se puede realizar mientras está en uso o durante la producción del dispositivo.
  • [C-1-9] DEBE tener una desviación estándar, calculada por eje en muestras recolectadas durante un período de al menos 3 segundos a la velocidad de muestreo más rápida, no mayor a 1,5 µT; DEBE tener una desviación estándar no mayor a 0,5 µT.
  • [C-1-10] DEBE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED .

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un sensor de acelerómetro y un sensor de giroscopio de 3 ejes, estos:

  • [C-2-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR .

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro, estos:

  • PUEDE implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR .

Si las implementaciones del dispositivo incluyen un magnetómetro de 3 ejes, un acelerómetro y un sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR , ellos:

  • [C-3-1] DEBE consumir menos de 10 mW.
  • DEBE consumir menos de 3 mW cuando el sensor está registrado para el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones de dispositivos:

  • [C-SR-1] se recomienda encarecidamente 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 del indicador de función android.hardware.location.gps , estas:

  • [C-1-1] DEBE admitir salidas de ubicación a una velocidad de al menos 1 Hz cuando se solicita a través de LocationManager#requestLocationUpdate .
  • [C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, trayectorias múltiples insignificantes, HDOP < 2) en 10 segundos (tiempo rápido para la primera fijación), cuando está conectado a una red de datos de 0,5 Mbps o más rápida. velocidad de conexión a internet. Este requisito generalmente se cumple mediante el uso de algún tipo de técnica GPS/GNSS asistida o prevista para minimizar el tiempo de bloqueo de GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y las efemérides/reloj del satélite).
    • [C-1-6] Después de hacer dicho cálculo de ubicación, las implementaciones del dispositivo deben determinar su ubicación, en Open Sky, dentro de los 5 segundos, cuando se reinician las solicitudes de ubicación, hasta una hora después del cálculo de la ubicación inicial, incluso cuando la solicitud posterior se realiza sin conexión de datos y/o después de un ciclo de encendido.
  • En condiciones de cielo abierto después de determinar la ubicación, mientras está parado o en movimiento con 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 rastrear e informar simultáneamente a través de GnssStatus.Callback de al menos 8 satélites de una constelación.
    • DEBE poder rastrear simultáneamente al menos 24 satélites, de múltiples constelaciones (por ejemplo, GPS + al menos uno de Glonass, Beidou, Galileo).
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE continuar brindando resultados de ubicación GPS/GNSS normales a través de las API del proveedor de ubicación GNSS durante una llamada telefónica de emergencia.

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE informar las mediciones GNSS de todas las constelaciones rastreadas (como se informa en los mensajes GnssStatus), con la excepción de SBAS.

  • [C-SR-4] se recomienda encarecidamente informar AGC y la frecuencia de la medición de GNSS.

  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE informar todas las estimaciones de precisión (incluidos el rumbo, la velocidad y la vertical) como parte de cada ubicación GPS/GNSS.

  • [C-SR-6] se recomienda encarecidamente informar mediciones GNSS, tan pronto como se encuentran, incluso si una ubicación calculada a partir de GPS/GNSS aún no se informa.

  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE informar pseudodistancias y velocidades de pseudodistancia GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras está estacionario o en movimiento con menos de 0,2 metros por segundo al cuadrado de aceleración, sean suficientes para calcular la posición. dentro de los 20 metros y velocidad dentro de los 0,2 metros por segundo, al menos el 95% del tiempo.

7.3.4. Giroscopio

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un sensor de giroscopio.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes,:

  • [C-1-1] DEBE poder informar eventos con una frecuencia de al menos 50 Hz.
  • [C-1-2] debe implementar el sensor TYPE_GYROSCOPE .
  • [C-1-4] DEBE tener una resolución de 12 bits o más.
  • [C-1-5] DEBE tener compensación de temperatura.
  • [C-1-6] DEBE calibrarse y compensarse mientras está en uso y preservar los parámetros de compensación entre reinicios del dispositivo.
  • [C-1-7] DEBE tener una variación no mayor a 1e-7 rad^2/s^2 por Hz (varianza por Hz o rad^2/s). Se permite que la varianza varíe con la frecuencia de muestreo, pero DEBE estar limitada por este valor. En otras palabras, si mide la varianza del giroscopio a una frecuencia de muestreo de 1 Hz, DEBE ser no mayor que 1e-7 rad^2/s^2.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que el error de calibración sea inferior a 0,01 rad/s cuando el dispositivo está estacionario a temperatura ambiente.
  • [C-SR-3] se recomiendan fuertemente implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED .
  • [C-SR-4] se recomienda encarecidamente tener una resolución de 16 bits o más.
  • DEBE informar eventos de hasta al menos 200 Hz.

Si las implementaciones del dispositivo incluyen un giroscopio de 3 ejes, un sensor de acelerómetro y un sensor de magnetómetro, ellos:

  • [C-2-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR .

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor giroscópico de 3 ejes,:

  • [C-3-1] debe implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION .
  • [C-SR-5] se recomiendan fuertemente implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR .

7.3.5. Barómetro

Implementaciones de dispositivos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir un barómetro (sensor de presión del aire ambiente).

Si las implementaciones de dispositivos incluyen un barómetro,:

  • [C-1-1] DEBE implementar e informar el sensor TYPE_PRESSURE .
  • [C-1-2] DEBE poder entregar eventos a 5 Hz o más.
  • [C-1-3] DEBE tener compensación de temperatura.
  • [C-SR-2] MUY RECOMENDADO poder informar mediciones de presión en el rango de 300 hPa a 1100 hPa.
  • DEBE tener una precisión absoluta de 1hPa.
  • DEBE tener una precisión relativa de 0,12 hPa en un rango de 20 hPa (equivalente a una precisión de ~1 m con un cambio de ~200 m al nivel del mar).

7.3.6. Termómetro

Si las implementaciones de dispositivos incluyen un termómetro ambiental (sensor de temperatura), estos:

  • [C-1-1] DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para el sensor de temperatura ambiente y el sensor DEBE medir la temperatura ambiente (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 una temperatura distinta de la temperatura ambiente, como la temperatura de la CPU,:

Si las implementaciones de dispositivos incluyen un sensor para monitorear la temperatura de la piel, entonces:

7.3.7. Fotómetro

  • Las implementaciones de dispositivos PUEDEN incluir un fotómetro (sensor de luz ambiental).

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 una lectura binaria "cerca" o "lejana",:

  • [C-1-1] DEBE medir la proximidad de un objeto en la misma dirección que la pantalla. Es decir, el sensor de proximidad DEBE estar orientado para detectar objetos cerca de la pantalla, ya que la intención principal de este tipo de sensor es detectar un teléfono en uso por el usuario. Si las implementaciones del dispositivo 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 utilizar 0 centímetros como lectura cercana y 5 centímetros como lectura lejana.
  • [C-1-4] DEBE informar un alcance 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, como se define en esta sección, y los ponen a disposición de aplicaciones de terceros,:

  • [C-1-1] DEBE identificar la capacidad a través del indicador de función android.hardware.sensor.hifi_sensors .

Si las implementaciones de dispositivos declaran android.hardware.sensor.hifi_sensors ,:

  • [C-2-1] DEBE tener un sensor TYPE_ACCELEROMETER que:

    • DEBE tener un rango de medición entre al menos -8 g y +8 g, y SE RECOMIENDA ENCARECIDAMENTE tener un rango de medición entre al menos -16 g y +16 g.
    • 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 menos.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior; DEBE admitir SensorDirectChannel RATE_VERY_FAST .
    • DEBE tener un ruido de medición no superior a 400 μg/√Hz.
    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 3000 eventos de sensor.
    • DEBE tener un consumo de energía por lotes no inferior a 3 mW.
    • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE tener un ancho de banda de medición de 3 dB de al menos el 80 % de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
    • DEBE tener una aceleración aleatoria inferior a 30 μg √Hz probada a temperatura ambiente.
    • DEBE tener un cambio de sesgo frente a la temperatura de ≤ +/- 1 mg/°C.
    • DEBE tener una no linealidad de línea de mejor ajuste de ≤ 0,5% y un cambio de sensibilidad frente a la temperatura de ≤ 0,03%/C°.
    • DEBE tener una sensibilidad transversal de < 2,5 % y una variación de la sensibilidad transversal < 0,2 % en el rango de temperatura de funcionamiento del dispositivo.
  • [C-2-2] DEBE tener un TYPE_ACCELEROMETER_UNCALIBRATED con los mismos requisitos de calidad que TYPE_ACCELEROMETER .

  • [C-2-3] Debe tener un sensor TYPE_GYROSCOPE que:

    • DEBE tener un rango de medición entre al menos -1000 y +1000 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 menos.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior; DEBE admitir SensorDirectChannel RATE_VERY_FAST .
    • DEBE tener un ruido de medición no superior a 0,014°/s/√Hz.
    • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE tener un ancho de banda de medición de 3 dB de al menos el 80 % de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
    • DEBE tener una velocidad de caminata aleatoria inferior a 0,001 °/s √Hz probada a temperatura ambiente.
    • DEBE tener un cambio de polarización frente a la temperatura de ≤ +/- 0,05 °/ s / °C.
    • DEBE tener un cambio de sensibilidad frente a la temperatura de ≤ 0,02%/°C.
    • DEBE tener una no linealidad de línea de mejor ajuste de ≤ 0,2%.
    • DEBE tener una densidad de ruido de ≤ 0,007 °/s/√Hz.
    • DEBE tener un error de calibración inferior a 0,002 rad/s en un rango de temperatura de 10 ~ 40 ℃ cuando el dispositivo está estacionario.
    • DEBE tener una sensibilidad g inferior a 0,1°/s/g.
    • DEBE tener una sensibilidad entre ejes < 4,0 % y una variación de sensibilidad entre ejes < 0,3 % en el rango de temperatura de funcionamiento del dispositivo.
  • [C-2-4] DEBE tener un TYPE_GYROSCOPE_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GYROSCOPE .

  • [C-2-5] DEBE tener un sensor TYPE_GEOMAGNETIC_FIELD que:

    • DEBE tener un rango de medición entre 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 menos.
    • Debe tener una frecuencia de medición máxima de 50 Hz o más.
    • DEBE tener un ruido de medición no superior a 0,5 uT.
  • [C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GEOMAGNETIC_FIELD y además:

    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 600 eventos de sensor.
    • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE tener un espectro de ruido blanco de 1 Hz a al menos 10 Hz cuando la frecuencia de informe sea de 50 Hz o superior.
  • [C-2-7] DEBE tener un sensor TYPE_PRESSURE que:

    • DEBE tener un rango de medición entre al menos 300 y 1100 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 menos.
    • DEBE tener una frecuencia máxima de medición de 10 Hz o superior.
    • DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
    • Debe implementar una forma no despierta de este sensor con una capacidad de amortiguación de al menos 300 eventos de sensor.
    • DEBE tener un consumo de energía por lotes no 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 que:

    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
  • [C-2-10] DEBE tener un sensor TYPE_STEP_DETECTOR que:

    • DEBE implementar una forma sin activación de este sensor con una capacidad de almacenamiento en búfer de al menos 100 eventos de sensor.
    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
    • DEBE tener un consumo de energía por lotes no inferior a 4 mW.
  • [C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER que:

    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
  • [C-2-12] DEBE tener un sensor TILT_DETECTOR que:

    • DEBE tener un consumo de energía no inferior a 0,5 mW cuando el dispositivo está estático y 1,5 mW cuando el dispositivo está en movimiento.
  • [C-2-13] La marca de tiempo del mismo evento físico reportado por el acelerómetro, el giroscopio y el magnetómetro DEBE estar dentro de los 2,5 milisegundos de diferencia entre sí. La marca de tiempo del mismo evento físico reportado por el acelerómetro y el giroscopio DEBE estar con una diferencia de 0,25 milisegundos entre sí.

  • [C-2-14] DEBE tener marcas de tiempo de eventos del sensor de giroscopio en la misma base de tiempo que el subsistema de la cámara y dentro de 1 milisegundo de error.

  • [C-2-15] DEBE entregar muestras a las aplicaciones dentro de los 5 milisegundos desde el momento en que los datos están disponibles en cualquiera de los sensores físicos anteriores para 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 el dispositivo está en movimiento cuando cualquier combinación de los siguientes sensores está habilitada:

    • 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 una capacidad de búfer mínima de 100 eventos de sensor.

Tenga en cuenta que todos los requisitos de consumo de energía en esta sección no incluyen el consumo de energía del Procesador de aplicaciones. Incluye la energía consumida por toda la cadena de sensores: el sensor, cualquier circuito de soporte, cualquier sistema de procesamiento de sensores dedicado, etc.

Si las implementaciones de dispositivos incluyen soporte directo de sensores, estos:

  • [C-3-1] DEBE declarar correctamente la compatibilidad con los tipos de canales directos y el nivel de tarifas de informes directos a través de la API isDirectChannelTypeSupported y getHighestDirectReportRateLevel .
  • [C-3-2] DEBE admitir al menos uno de los dos tipos de canal directo de sensor para todos los sensores que declaran soporte para canal directo de sensor.
  • DEBE admitir informes de eventos a través del canal directo del sensor para el sensor primario (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 información adicional sobre la medición de la seguridad de desbloqueo biométrico, consulte la documentación sobre Medición de la seguridad biométrica .

Si las implementaciones de dispositivos incluyen una pantalla de bloqueo segura,:

  • DEBE incluir un sensor biométrico

Los sensores biométricos se pueden clasificar como Clase 3 (anteriormente Fuerte ), Clase 2 (anteriormente Débil ) o Clase 1 (anteriormente Conveniencia ) en función de sus tasas de aceptación de falsificaciones e impostores, y de la seguridad de la tubería biométrica. Esta clasificación determina las capacidades que tiene el sensor biométrico para interactuar con la plataforma y con aplicaciones de terceros. Los sensores se clasifican como clase 1 por defecto, y deben cumplir con los requisitos adicionales como se detalla a continuación si desean clasificarse como Clase 2 o Clase 3 . Tanto la biometría de Clase 2 como la de Clase 3 obtienen capacidades adicionales como se detalla a continuación.

Si las implementaciones de dispositivos ponen un sensor biométrico a disposición de aplicaciones de terceros a través de android.hardware.biometrics.BiometricManager , android.hardware.biometrics.BiometricPrompt y android.provider.Settings.ACTION_BIOMETRIC_ENROLL , estos:

  • [C-4-1] DEBE cumplir con los requisitos para datos biométricos de Clase 3 o Clase 2 como se define en este documento.
  • [C-4-2] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase Autenticadores y cualquier combinación de los mismos. Por el contrario, NO DEBE respetar ni reconocer las constantes enteras pasadas a los métodos canAuthenticate(int) y setAllowedAuthenticators(int) distintas de aquellas documentadas como constantes públicas en Authenticators y cualquier combinación de las mismas.
  • [C-4-3] DEBE implementar la acción ACTION_BIOMETRIC_ENROLL en dispositivos que tienen datos biométricos de Clase 3 o Clase 2 . Esta acción solo debe presentar los puntos de entrada de inscripción para biometría de Clase 3 o Clase 2 .

Si las implementaciones de dispositivos admiten biometría pasiva,:

  • [C-5-1] DEBE requerir de forma predeterminada un paso de confirmación adicional (por ejemplo, presionar un botón).
  • [C-SR-1] se recomienda encarecidamente tener una configuración para permitir a los usuarios anular la preferencia de la aplicación y siempre requieren un paso de confirmación adjunto.
  • [C-SR-2] se recomienda encarecidamente que la acción de confirmación se asegure de manera que un sistema operativo o compromiso del núcleo no pueda falsificarla. Por ejemplo, esto significa que la acción de confirmación basada en un botón físico se enruta a través de un pin de entrada/salida de propósito general (GPIO) de solo entrada de un elemento seguro (SE) que no puede controlarse por ningún otro medio que no sea un botón físico. prensa.
  • [C-5-2] DEBE implementar adicionalmente un flujo de autenticación implícito (sin paso de confirmación) correspondiente a setConfirmationRequired(boolean) , que las aplicaciones pueden configurar para utilizar para flujos de inicio de sesión.

Si las implementaciones de dispositivos tienen múltiples sensores biométricos, estos:

  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE exigir que solo se confirme un dato biométrico por autenticación (por ejemplo, si el dispositivo tiene disponibles sensores de huellas dactilares y faciales, se debe enviar onAuthenticationSucceeded después de confirmar cualquiera de ellos).

Para que las implementaciones de dispositivos permitan el acceso a las claves del almacén de claves a aplicaciones de terceros, deben:

  • [C-6-1] DEBE cumplir con los requisitos para la Clase 3 como se define en esta sección 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 Clase 1 (anteriormente Conveniencia ), deben:

  • [C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0,002%.
  • [C-1-2] DEBE revelar que este modo puede ser menos seguro que un PIN, patrón o contraseña seguros y enumerar claramente los riesgos de habilitarlo, si las tasas de aceptación de falsificaciones e impostores son superiores al 7 % según lo medido por el Protocolos de prueba de biometría de Android .
  • [C-1-9] debe desafiar al usuario para la autenticación primaria recomendada (p. Ej. con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un biométrico registrado.
  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE reducir el número total de pruebas falsas para la verificación biométrica especificada en [C-1-9] si las tasas de aceptación de falsificaciones e impostores son superiores al 7 % según lo medido por los Protocolos de prueba biométrica de Android. .
  • [C-1-3] DEBE limitar los intentos de verificación biométrica, donde una prueba falsa es aquella con una calidad de captura adecuada ( BIOMETRIC_ACQUIRED_GOOD ) que no coincide con una prueba biométrica registrada.
  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE calificar los intentos de límite durante al menos 30 segundos después de cinco pruebas falsas para la verificación biométrica para el número máximo de pruebas falsas según [C-1-9], donde una prueba falsa es aquella con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con un dato biométrico registrado.
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE tener toda la lógica de limitación de velocidad en TEE.
  • [C-1-10] DEBE desactivar la biometría una vez que se haya activado por primera vez la interrupción de la autenticación primaria, como se describe en [C-0-2] de la sección 9.11.
  • [C-1-4] DEBE evitar agregar nuevos datos biométricos sin establecer primero una cadena de confianza haciendo que el usuario confirme la credencial del dispositivo existente o agregue una nueva (PIN/patrón/contraseña) que esté protegida por TEE; La implementación del Proyecto de código abierto de Android proporciona el mecanismo en el marco para hacerlo.
  • [C-1-5] DEBE eliminar por completo todos los datos biométricos identificables de un usuario cuando se elimina la cuenta del usuario (incluso mediante un restablecimiento de fábrica).
  • [C-1-6] DEBE respetar el indicador individual para ese elemento biométrico (es decir, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
  • [C-1-7] debe desafiar al usuario para la autenticación primaria recomendada (p. Ej. o menos para la actualización de dispositivos de Android 8 o antes.
  • [C-1-8] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) o datos biométricos de Clase 3 (FUERTE) después de uno de los siguientes:

    • un período de inactividad de 4 horas, O
    • 3 intentos fallidos de autenticación biométrica.

  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE utilizar la lógica del marco proporcionado por el Proyecto de código abierto de Android para hacer cumplir las restricciones especificadas en [C-1-7] y [C-1-8] para dispositivos nuevos.

  • [C-SR-8] Se RECOMIENDA ENCARECIDAMENTE tener una tasa de rechazo falso inferior al 10%, medida en el dispositivo.

  • [C-SR-9] Se RECOMIENDA ENCARECIDAMENTE tener una latencia inferior a 1 segundo, medida desde que se detecta el dato biométrico hasta que se desbloquea la pantalla, para cada dato biométrico registrado.

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

  • [C-2-1] DEBE cumplir con todos los requisitos para la Clase 1 anterior.
  • [C-2-2] debe tener una tasa de aceptación de la parodia e impostor no superior al 20% según lo medido por los protocolos de prueba de Biometría Android .
  • [C-2-3] debe realizar la coincidencia biométrica en un entorno de ejecución aislado fuera del usuario de Android o el espacio del núcleo, como el entorno de ejecución de confianza (TEE), o en un chip con un canal seguro para el entorno de ejecución aislado.
  • [C-2-4] DEBE tener todos los datos identificables cifrados y autenticados criptográficamente de manera que no puedan adquirirse, leerse o modificarse fuera del entorno de ejecución aislado o un chip con un canal seguro hacia el entorno de ejecución aislado como se documenta en las pautas de implementación. en el sitio del proyecto de código abierto de Android.
  • [C-2-5] Para datos biométricos basados ​​en cámaras, mientras se realiza la autenticación o inscripción biométrica:
    • Debe operar la cámara en un modo que evite que los marcos de la cámara se lean o se alteren fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado.
    • Para las soluciones RGB de una sola cámara, los marcos de la cámara PUEDEN ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para el registro, pero aún así NO DEBEN ser modificables.
  • [C-2-6] NO DEBE permitir que aplicaciones de terceros distingan entre inscripciones biométricas individuales.
  • [C-2-7] no debe permitir el acceso sin cifrar a datos biométricos identificables o cualquier datos derivados de él (como integridades) al procesador de aplicaciones fuera del contexto de la TEE. La actualización de dispositivos lanzados con la versión 9 de Android o anterior no está exenta del C-2-7.
  • [C-2-8] DEBE tener una canalización de procesamiento segura de modo que un sistema operativo o un kernel comprometido no puedan permitir que se inyecten datos directamente para autenticarse falsamente como usuario.

  • [C-SR-10] Se RECOMIENDA ENCARECIDAMENTE incluir detección de vida para todas las modalidades biométricas y detección de atención para la biometría facial.

  • [C-2-9] DEBE poner el sensor biométrico a disposición de aplicaciones de terceros.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 3 (anteriormente Fuerte ), deben:

  • [C-3-1] DEBE cumplir con todos los requisitos de la Clase 2 anterior, excepto [C-1-7] y [C-1-8].
  • [C-3-2] DEBE tener una implementación de almacén de claves respaldada por hardware.
  • [C-3-3] debe tener una tasa de aceptación de la parodia e impostura no superior al 7% según lo medido por los protocolos de prueba de Biometría Android .
  • [C-3-4] DEBE solicitar al usuario la autenticación primaria recomendada (por ejemplo, PIN, patrón, contraseña) una vez cada 72 horas o menos.
  • [C-3-5] DEBE volver a generar la ID del autenticador para todos los datos biométricos de Clase 3 admitidos en el dispositivo si alguno de ellos se vuelve a inscribir.
  • [C-3-6] Debe habilitar claves de almacén de claves con respaldo biométrico para aplicaciones de terceros.

Si las implementaciones de dispositivos contienen un sensor de huellas dactilares debajo de la pantalla (UDFPS), estas:

  • [C-SR-11] Se RECOMIENDAN ENCARECIDAMENTE para evitar que el área táctil del UDFPS interfiera con la navegación de 3 botones (que algunos usuarios pueden necesitar por motivos de accesibilidad).

7.3.12. Sensor de pose

Implementaciones de dispositivos:

  • PUEDE admitir sensor de postura con 6 grados de libertad.

Si las implementaciones de dispositivos admiten sensores de postura con 6 grados de libertad,:

  • [C-1-1] DEBE implementar e informar el sensor TYPE_POSE_6DOF .
  • [C-1-2] DEBE ser más preciso que el vector de rotación solo.

7.3.13. Sensor de ángulo de bisagra

Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra,:

7.4. Conectividad de datos

7.4.1. Telefonía

"Telefonía" como las utilizan las API de Android y este documento se refiere específicamente al hardware relacionado con la colocación de llamadas de voz y el envío de mensajes SMS a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes, son para el propósito de Android considerado independiente de cualquier conectividad de datos que pueda implementarse utilizando la misma red. En otras palabras, la funcionalidad y las API de Android se refieren específicamente a llamadas de voz y SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar/recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si utilizan una red celular para la conectividad de datos.

  • Android PUEDE usarse en dispositivos que no incluyen hardware de telefonía. Es decir, Android es compatible con dispositivos que no son teléfonos.

Si las implementaciones de dispositivos incluyen telefonía GSM o CDMA, estos:

  • [C-1-1] DEBE declarar el indicador de función android.hardware.telephony y otros indicadores de subfunciones según la tecnología.
  • [C-1-2] DEBE implementar soporte completo para la API para esa tecnología.
  • DEBE permitir todos los tipos de servicios celulares disponibles (2G, 3G, 4G, 5G, etc.) durante las llamadas de emergencia (independientemente de los tipos de red establecidos por SetAllowedNetworkTypeBitmap() ).

Si las implementaciones de dispositivos no incluyen hardware de telefonía, estas:

  • [C-2-1] DEBE implementar las API completas como no operativas.

Si las implementaciones de dispositivos admiten eUICC o eSIM/SIM integradas e incluyen un mecanismo propietario para que la funcionalidad eSIM esté disponible para desarrolladores externos, ellos:

  • [C-3-1] debe proporcionar una implementación completa de la EuiccManager API .

Si las implementaciones de dispositivos no configuran la propiedad del sistema ro.telephony.iwlan\_operation\_mode en 'legacy', entonces:

Si las implementaciones de dispositivos admiten un único registro de subsistema multimedia IP (IMS) para las funciones del servicio de telefonía multimedia (MMTEL) y del servicio de comunicación enriquecido (RCS) y se espera que cumplan con los requisitos de los operadores de telefonía celular con respecto al uso de un único registro IMS para todo el tráfico de señalización IMS, ellos:

7.4.1.1. Compatibilidad de bloqueo de números

Si las implementaciones de dispositivos informan la android.hardware.telephony feature , ellos:

  • [C-1-1] DEBE incluir soporte para 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] DEBE bloquear todas las llamadas y mensajes de un número de teléfono en 'BlockedNumberProvider' sin ninguna interacción con las aplicaciones. La única excepción es cuando el bloqueo de números se levanta temporalmente como se describe en la documentación del SDK.
  • [C-1-4] no debe escribir en el proveedor de registro de llamadas de la plataforma para una llamada bloqueada.
  • [C-1-5] NO DEBE escribir al proveedor de Telefonía para solicitar un mensaje bloqueado.
  • [C-1-6] DEBE implementar una interfaz de usuario de administración de números bloqueados, que se abre con la intención devuelta por el método TelecomManager.createManageBlockedNumbersIntent() .
  • [C-1-7] NO DEBE permitir que los usuarios secundarios vean o editen los números bloqueados en el dispositivo, ya que la plataforma Android supone que el usuario principal tiene control total de los servicios de telefonía, una sola instancia, en el dispositivo. Toda la interfaz de usuario relacionada con el bloqueo DEBE estar oculta para los usuarios secundarios y aún así DEBE respetarse la lista de bloqueados.
  • Debe migrar los números bloqueados al proveedor cuando un dispositivo se actualice a Android 7.0.
7.4.1.2. API de telecomunicaciones

Si las implementaciones de dispositivos informan android.hardware.telephony , ellos:

  • [C-1-1] DEBE admitir las API ConnectionService descritas en el SDK .
  • [C-1-2] DEBE mostrar una nueva llamada entrante y brindar al usuario la posibilidad de aceptar o rechazar la llamada entrante cuando el usuario está en una llamada en curso realizada por una aplicación de terceros que no admite la función de retención especificada a través de CAPABILITY_SUPPORT_HOLD .
  • [C-1-3] DEBE tener una aplicación que implemente InCallService .
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE notificar al usuario que al responder una llamada entrante se cancelará una llamada en curso.

    La implementación de AOSP cumple estos requisitos mediante una notificación de aviso que indica al usuario que responder a una llamada entrante provocará que se corte la otra llamada.

  • [C-SR-1] se recomienda precargar la aplicación de marcador predeterminada que muestra una entrada de registro de llamadas y el nombre de una aplicación de terceros en su registro de llamadas cuando la aplicación de terceros establece la clave EXTRA_LOG_SELF_MANAGED_CALLS en su PhoneAccount a true .

  • [C-SR-2] se recomienda encarecidamente manejar los eventos KEYCODE_MEDIA_PLAY_PAUSE de los auriculares de audio y los eventos KEYCODE_HEADSETHOOK para las API android.telecom como se muestra a continuación:

    • Llame Connection.onDisconnect() cuando se detecte una pulsación breve del evento de tecla durante una llamada en curso.
    • Llame a Connection.onAnswer() cuando se detecte una pulsación breve del evento de tecla durante una llamada entrante.
    • Llame Connection.onReject() cuando se detecte una pulsación prolongada del evento de tecla durante una llamada entrante.
    • Alternar el estado de silencio de CallAudioState .

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones de dispositivos:

  • DEBE incluir soporte para una o más formas de 802.11.

Si las implementaciones de dispositivos incluyen soporte para 802.11 y exponen la funcionalidad a una aplicación de terceros, ellos:

  • [C-1-1] DEBE implementar la API de Android correspondiente.
  • [C-1-2] DEBE informar el indicador de función de hardware android.hardware.wifi .
  • [C-1-3] DEBE implementar la API de multidifusión como se describe en la documentación del SDK.
  • [C-1-4] debe admitir DNS de multidifusión (MDNS) y no debe filtrar paquetes MDNS (224.0.0.251) en cualquier momento de la operación, incluyendo:
    • Incluso cuando la pantalla no está en un estado activo.
    • Para implementaciones de dispositivos Android Television, incluso en estados de energía en espera.
  • [C-1-5] no debe tratar la llamada del método API WifiManager.enableNetwork() como una indicación suficiente para cambiar la Network actualmente activa que se usa de forma predeterminada para el tráfico de aplicaciones y es devuelta por los métodos de la API ConnectivityManager , como getActiveNetwork y registerDefaultNetworkCallback . En otras palabras, solo PUEDEN desactivar el acceso a Internet proporcionado por cualquier otro proveedor de red (por ejemplo, datos móviles) si validan con éxito que la red Wi-Fi proporciona acceso a Internet.
  • [C-1-6] Se RECOMIENDA ENCARECIDAMENTE que, cuando se llame al método API ConnectivityManager.reportNetworkConnectivity() , vuelva a evaluar el acceso a Internet en la Network y, una vez que la evaluación determine que la Network actual ya no proporciona acceso a Internet, cambie a cualquier otra red disponible (por ejemplo, datos móviles) que proporcione acceso a Internet.
  • [C-1-7] DEBE aleatorizar la dirección MAC de origen y el número de secuencia de las tramas de solicitud de sonda, una vez al comienzo de cada escaneo, mientras STA está desconectada.
  • [C-1-8] DEBE utilizar una dirección MAC coherente (NO DEBE aleatorizar la dirección MAC a mitad de un análisis).
  • [C-1-9] DEBE iterar el número de secuencia de solicitud de sondeo de forma normal (secuencialmente) entre las solicitudes de sondeo en un escaneo.
  • [C-1-10] DEBE aleatorizar el número de secuencia de solicitud de sonda entre la última solicitud de sonda de un escaneo y la primera solicitud de sonda del siguiente escaneo.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE aleatorizar la dirección MAC de origen utilizada para todas las comunicaciones de STA a un punto de acceso (AP) mientras se asocia y asocia.
    • El dispositivo DEBE utilizar una dirección MAC aleatoria diferente para cada SSID (FQDN para Passpoint) con el que se comunica.
    • El dispositivo DEBE proporcionar al usuario una opción para controlar la aleatorización por SSID (FQDN para Passpoint) con opciones aleatorias y no aleatorias, y DEBE configurar el modo predeterminado para que las nuevas configuraciones de Wi-Fi sean aleatorias.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE utilizar un BSSID aleatorio para cualquier AP que creen.
    • La dirección MAC DEBE ser aleatoria y persistente según el SSID utilizado por el AP.
    • El DISPOSITIVO PUEDE proporcionar al usuario una opción para desactivar esta función. Si se proporciona dicha opción, la aleatorización DEBE estar habilitada de forma predeterminada.

Si las implementaciones de dispositivos incluyen soporte para el modo de ahorro de energía Wi-Fi como se define en el estándar IEEE 802.11,:

  • DEBE desactivar el modo de ahorro de energía de Wi-Fi siempre que una aplicación adquiera el bloqueo WIFI_MODE_FULL_HIGH_PERF o el bloqueo WIFI_MODE_FULL_LOW_LATENCY a través de las API WifiManager.createWifiLock() y WifiManager.WifiLock.acquire() y el bloqueo esté activo.
  • [C-3-2] La latencia promedio de ida y vuelta entre el dispositivo y un punto de acceso mientras que el dispositivo está en un bloque de Latencia de Bajo Wi-Fi ( WIFI_MODE_FULL_LOW_LATENCY ) debe ser más pequeño que la latencia durante un bloqueo de PERF de alto Wi-Fi ( modo WIFI_MODE_FULL_HIGH_PERF ).
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere y entra en vigor un bloqueo de baja latencia ( WIFI_MODE_FULL_LOW_LATENCY ).

Si las implementaciones de dispositivos admiten Wi-Fi y usan Wi-Fi para escanear la ubicación,:

7.4.2.1. Wi-Fi directo

Implementaciones de dispositivos:

  • DEBE incluir soporte para Wi-Fi Direct (Wi-Fi peer-to-peer).

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Direct,:

  • [C-1-1] DEBE implementar la API de Android correspondiente como 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 Wi-Fi y Wi-Fi Direct simultáneamente.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE aleatorizar la dirección MAC de origen para todas las conexiones Wi-Fi Direct recién formadas.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para TDLS y TDLS está habilitado por la API WiFiManager, ellos:

  • [C-1-1] debe declarar apoyo para los TDL a través de WifiManager.isTdlsSupported .
  • DEBE usar TDLS solo cuando sea posible Y beneficioso.
  • DEBE tener algo de heurística y NO usar TDLS cuando su rendimiento podría ser peor que a través del punto de acceso Wi-Fi.
7.4.2.3. Wi-Fi consciente

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Aware y exponen la funcionalidad a aplicaciones de terceros, entonces:

  • [C-1-1] DEBE implementar las API WifiAwareManager como se describe en la documentación del SDK .
  • [C-1-2] debe declarar el indicador de funciones android.hardware.wifi.aware .
  • [C-1-3] DEBE admitir operaciones Wi-Fi y Wi-Fi Aware simultáneamente.
  • [C-1-4] DEBE aleatorizar la dirección de la interfaz de administración de Wi-Fi Aware en intervalos no mayores a 30 minutos y siempre que Wi-Fi Aware esté habilitado, a menos que esté en curso una operación de rango de Aware o que una ruta de datos de Aware esté activa (la aleatorización es no se espera mientras la ruta de datos esté activa).

Si las implementaciones del dispositivo incluyen soporte para la ubicación de Wi-Fi ADAK y Wi-Fi como se describe en la Sección 7.4.2.5 y expone estas funcionalidades a las aplicaciones de terceros, entonces ellos:

7.4.2.4. Punto de paso de Wi-Fi

Si las implementaciones de dispositivos incluyen soporte para 802.11 (Wi-Fi), ellos:

  • [C-1-1] DEBE incluir soporte para Wi-Fi Passpoint .
  • [C-1-2] DEBE implementar las API WifiManager relacionadas con Passpoint como se describe en la documentación del SDK .
  • [C-1-3] DEBE admitir el estándar IEEE 802.11u, específicamente relacionado con el descubrimiento y selección de redes, como el servicio de publicidad genérica (GAS) y el protocolo de consulta de red de acceso (ANQP).
  • [C-1-4] DEBE declarar el indicador de función android.hardware.wifi.passpoint .
  • [C-1-5] DEBE seguir la implementación de AOSP para descubrir, hacer coincidir y asociarse a redes Passpoint.
  • [C-1-6] DEBE admitir al menos el siguiente subconjunto de protocolos de aprovisionamiento de dispositivos según se define en Wi-Fi Alliance Passpoint R2: autenticación EAP-TTLS y SOAP-XML.
  • [C-1-7] DEBE procesar el certificado del servidor AAA como se describe en la especificación Hotspot 2.0 R3.
  • [C-1-8] DEBE admitir el control del usuario sobre el aprovisionamiento a través del selector de Wi-Fi.
  • [C-1-9] DEBE mantener las configuraciones de Passpoint persistentes durante los reinicios.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE respaldar la función de aceptación de términos y condiciones.
  • [C-SR-2] Se RECOMIENDAN ENCARECIDAMENTE para respaldar la función de información del lugar.

Por el contrario, si las implementaciones de dispositivos no incluyen soporte para Passpoint Wi-Fi:

  • [C-2-1] La implementación de las API WifiManager relacionadas con Passpoint debe lanzar una UnsupportedOperationException .

Si se proporciona un interruptor de control de usuario de desactivación de punto de acceso global, las implementaciones:

  • [C-3-1] DEBE habilitar Passpoint de forma predeterminada.
7.4.2.5. Ubicación Wi-Fi (tiempo de ida y vuelta de Wi-Fi-RTT)

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para ubicación Wi-Fi y exponen la funcionalidad a aplicaciones de terceros, entonces:

  • [C-1-1] DEBE implementar las API WifiRttManager como se describe en la documentación del SDK .
  • [C-1-2] DEBE declarar el indicador de función android.hardware.wifi.rtt .
  • [C-1-3] DEBE aleatorizar la dirección MAC de origen para cada ráfaga de RTT que se ejecuta mientras la interfaz Wi-Fi en la que se ejecuta el RTT no está asociada a un punto de acceso.
  • [C-1-4] DEBE tener una precisión de 2 metros con un ancho de banda de 80 MHz en el percentil 68 (calculado con la función de distribución acumulativa).
7.4.2.6. Descarga Wi-Fi Keepalive

Implementaciones de dispositivos:

  • DEBE incluir soporte para la descarga de Wi-Fi keepalive.

Si las implementaciones de dispositivos incluyen soporte para la descarga de Wi-Fi keepalive y exponen la funcionalidad a aplicaciones de terceros,:

  • [C-1-1] DEBE admitir la API SocketKeepAlive .

  • [C-1-2] debe admitir al menos tres ranuras Keepalive concurrentes sobre Wi-Fi y al menos una ranura Keepalive sobre el celular.

Si las implementaciones de dispositivos no incluyen soporte para la descarga de Wi-Fi keepalive,:

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

Implementaciones de dispositivos:

Si las implementaciones de dispositivos incluyen soporte para Wi-Fi Easy Connect y exponen la funcionalidad a aplicaciones de terceros, estos:

7.4.2.8. Validación de certificado de servidor Wi-Fi empresarial

Si el certificado del servidor Wi-Fi no está validado o el nombre de dominio del servidor Wi-Fi no está configurado, las implementaciones del dispositivo:

  • [C-SR-1] se recomienda encarecidamente no proporcionar al usuario una opción para agregar manualmente la red Wi-Fi Enterprise en la aplicación Configuración.

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth,:

  • Debe admitir códecs de audio avanzados y códecs de audio Bluetooth (por ejemplo, LDAC).

Si las implementaciones de dispositivos admiten HFP, A2DP y AVRCP,:

  • DEBE admitir al menos 5 dispositivos conectados en total.

Si las implementaciones de dispositivos declaran la característica android.hardware.vr.high_performance , estas:

  • [C-1-1] debe admitir la extensión de la longitud de datos Bluetooth 4.2 y Bluetooth LE.

Android incluye soporte para Bluetooth y Bluetooth Low Energy .

Si las implementaciones de dispositivos incluyen soporte para Bluetooth y Bluetooth Low Energy,:

  • [C-2-1] DEBE declarar las características relevantes de la plataforma ( android.hardware.bluetooth y android.hardware.bluetooth_le respectivamente) e implementar las API de la plataforma.
  • DEBE implementar perfiles Bluetooth relevantes como A2DP, AVRCP, OBEX, HFP, etc., según corresponda para el dispositivo.

Si las implementaciones de dispositivos incluyen soporte para Bluetooth Low Energy (BLE), ellos:

  • [C-3-1] DEBE declarar la función de hardware android.hardware.bluetooth_le .
  • [C-3-2] DEBE habilitar las API de Bluetooth basadas en GATT (perfil de atributos genéricos) como se describe en la documentación del SDK y android.bluetooth .
  • [C-3-3] DEBE informar el valor correcto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar si se implementa la lógica de filtrado para las clases de API ScanFilter .
  • [C-3-4] DEBE informar el valor correcto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo de energía.
  • [C-3-5] DEBE implementar un tiempo de espera de dirección privada resoluble (RPA) de 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 esté usando 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.
  • DEBE admitir la descarga de la lógica de filtrado al chipset bluetooth al implementar la API ScanFilter .
  • DEBE admitir la descarga del escaneo por lotes al chipset bluetooth.
  • DEBE admitir publicidad múltiple con al menos 4 espacios.

Si las implementaciones de dispositivos admiten Bluetooth LE y utilizan Bluetooth LE para escanear la ubicación,:

  • [C-4-1] DEBE proporcionar al usuario la posibilidad de habilitar/deshabilitar el valor leído a través de la API del sistema BluetoothAdapter.isBleScanAlwaysAvailable() .

Si las implementaciones de dispositivos incluyen soporte para Bluetooth LE y perfil de audífonos, como se describe en Soporte de audio para audífonos mediante Bluetooth LE , ellos:

Si las implementaciones de dispositivos incluyen soporte para Bluetooth o Bluetooth Low Energy,:

  • [C-6-1] DEBE restringir el acceso a cualquier metadato de Bluetooth (como los resultados del escaneo) que podría usarse para derivar la ubicación del dispositivo, a menos que la aplicación solicitante pase con éxito una verificación de permiso android.permission.ACCESS_FINE_LOCATION basada en su actual estado de primer plano/fondo.

Si las implementaciones del dispositivo incluyen soporte para Bluetooth o Bluetooth Low Energy y el manifiesto de la aplicación no incluye una declaración del desarrollador que indique que no están derivando la ubicación de Bluetooth, entonces:

7.4.4. Comunicaciones de campo cercano

Implementaciones de dispositivos:

  • DEBE incluir un transceptor y hardware relacionado para comunicaciones de campo cercano (NFC).
  • [C-0-1] DEBE implementar las API android.nfc.NdefMessage y android.nfc.NdefRecord incluso si no incluyen soporte para NFC o declaran la función android.hardware.nfc ya que las clases representan un formato de representación de datos independiente del protocolo .

Si las implementaciones de dispositivos incluyen hardware NFC y planean ponerlo a disposición de aplicaciones de terceros, ellos:

  • [C-1-1] 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 de los siguientes estándares NFC:
  • [C-1-2] DEBE ser capaz de actuar como lector/escritor de NFC Forum (según lo definido por la especificación técnica de NFC Forum NFCForum-TS-DigitalProtocol-1.0) a través de los siguientes estándares NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NFC (JIS X 6319-4)
    • ISODep (ISO 14443-4)
    • Tipos de etiquetas del Foro NFC 1, 2, 3, 4, 5 (definidas por el Foro NFC)
  • [C-SR-1] RECOMIENDA ENCARECIDAMENTE ser capaz de leer y escribir mensajes NDEF, así como datos sin procesar a través de los siguientes estándares NFC. Tenga en cuenta que, si bien los estándares NFC se indican como MUY RECOMENDADOS, se prevé que la Definición de compatibilidad para una versión futura los cambie a DEBE. Estos estándares son opcionales en esta versión pero serán necesarios en versiones futuras. Se recomienda encarecidamente a los dispositivos existentes y nuevos que ejecutan esta versión de Android para cumplir con estos requisitos ahora para que puedan actualizar a las versiones de plataformas futuras.

  • [C-1-13] DEBE sondear todas las tecnologías compatibles mientras se encuentra en el modo de descubrimiento NFC.

  • DEBE estar en modo de descubrimiento NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.

  • DEBE ser capaz de leer el código de barras y la URL (si está codificada) de los productos Thinfilm NFC Barcode .

Tenga en cuenta que los enlaces disponibles públicamente no están disponibles para las especificaciones JIS, ISO y NFC Forum citadas anteriormente.

Android incluye soporte para el modo de emulación de tarjeta host NFC (HCE).

Si las implementaciones de dispositivos incluyen un chipset controlador NFC capaz de HCE (para NfcA y/o NfcB) y admiten enrutamiento de ID de aplicación (AID), estos:

  • [C-2-1] DEBE informar la constante de característica android.hardware.nfc.hce .
  • [C-2-2] DEBE admitir las API NFC HCE como se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen un chipset controlador NFC capaz de HCE para NfcF e implementan la función para aplicaciones de terceros, estos:

  • [C-3-1] DEBE informar la constante de característica android.hardware.nfc.hcef .
  • [C-3-2] debe implementar las API de emulación de la tarjeta NFCF como se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen soporte NFC general como se describe en esta sección y admiten tecnologías MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF en MIFARE Classic) en la función de lector/escritor,:

  • [C-4-1] DEBE implementar las API de Android correspondientes según lo documentado en el SDK de Android.
  • [C-4-2] DEBE informar la función com.nxp.mifare del método android.content.pm.PackageManager.hasSystemFeature () . Tenga en cuenta que esta no es una característica estándar de Android y, como tal, no aparece como una constante en la clase android.content.pm.PackageManager .

7.4.5. Protocolos de redes y API

7.4.5.1. Capacidad mínima de red

Implementaciones de dispositivos:

  • [C-0-1] DEBE incluir soporte para una o más formas de redes de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir soporte para al menos un estándar de datos capaz de 200 Kbit/seg o más. Ejemplos de tecnologías que satisfacen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet y Bluetooth PAN.
  • También debe incluir soporte para al menos un estándar de datos inalámbricos comunes, como 802.11 (Wi-Fi), cuando un estándar de red física (como Ethernet) es la conexión de datos primario.
  • PUEDE implementar más de una forma de conectividad de datos.
7.4.5.2. IPv6

Implementaciones de dispositivos:

  • [C-0-2] DEBE incluir una pila de redes IPv6 y admitir la comunicación IPv6 mediante las API administradas, como java.net.Socket y java.net.URLConnection , así como las API nativas, como los sockets AF_INET6 .
  • [C-0-3] DEBE habilitar IPv6 de forma predeterminada.
    • DEBE garantizar que la comunicación IPv6 sea tan confiable como IPv4, por ejemplo:
      • [C-0-4] DEBE mantener la conectividad IPv6 en modo dormido.
      • [C-0-5] La limitación de velocidad NO DEBE hacer que el dispositivo pierda la conectividad IPv6 en cualquier red compatible con IPv6 que utilice una vida útil de RA de 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 que se produzca ningún tipo de traducción de dirección o puerto localmente en el dispositivo. Tanto las API administradas como Socket#getLocalAddress o Socket#getLocalPort ) como las API de NDK como getsockname() o IPV6_PKTINFO DEBEN devolver la dirección IP y el puerto que realmente se utilizan para enviar y recibir paquetes en la red y que son visibles como la IP de origen y puerto a servidores de Internet (web).

El nivel requerido de compatibilidad con IPv6 depende del tipo de red, como se muestra en los siguientes requisitos.

Si las implementaciones de dispositivos admiten Wi-Fi,:

  • [C-1-1] DEBE admitir el funcionamiento de doble pila y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos admiten Ethernet,:

  • [C-2-1] DEBE admitir la operación de doble pila y solo IPv6 en Ethernet.

Si las implementaciones de dispositivos admiten datos celulares, ellos:

  • [C-3-1] DEBE admitir la operación IPv6 (solo IPv6 y posiblemente de doble pila) en dispositivos móviles.

Si las implementaciones de dispositivos admiten más de un tipo de red (por ejemplo, Wi-Fi y datos móviles), estas:

  • [C-4-1] DEBE cumplir simultáneamente 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 se refiere a una red que requiere iniciar sesión para obtener acceso a Internet.

Si las implementaciones de dispositivos proporcionan una implementación completa de la android.webkit.Webview API , estas:

  • [C-1-1] DEBE proporcionar una aplicación de portal cautivo para manejar la intención ACTION_CAPTIVE_PORTAL_SIGN_IN y mostrar la página de inicio de sesión del portal cautivo, enviando esa intención, al llamar a la API del sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle) .
  • [C-1-2] DEBE realizar la detección de portales cautivos y admitir el inicio de sesión a través de la aplicación del portal cautivo cuando el dispositivo está conectado a cualquier tipo de red, incluida la red celular/móvil, WiFi, Ethernet o Bluetooth.
  • [C-1-3] DEBE admitir el inicio de sesión en portales cautivos utilizando DNS de texto sin formato cuando el dispositivo está configurado para usar el modo estricto de DNS privado.
  • [C-1-4] DEBE utilizar DNS cifrado 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 comunica explícitamente con el portal cautivo.
  • [C-1-5] DEBE garantizar que, mientras el usuario inicia sesión en un portal cautivo, la red predeterminada utilizada por las aplicaciones (según lo devuelto por ConnectivityManager.getActiveNetwork , ConnectivityManager.registerDefaultNetworkCallback y utilizado de forma predeterminada por las API de red de Java, como java.net.socket, y las API nativas como Connect ()) son cualquier otra red disponible que proporcione acceso a Internet, si está disponible.

7.4.6. Configuración de sincronización

Implementaciones de dispositivos:

  • [C-0-1] DEBE tener la configuración de sincronización automática maestra activada de forma predeterminada para que el método getMasterSyncAutomatically() devuelva "verdadero".

7.4.7. Ahorro de datos

Si las implementaciones de dispositivos incluyen una conexión medida, son:

  • [C-SR-1] RECOMENDAMOS ENCARECIDAMENTE proporcionar el modo de ahorro de datos.

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos,:

  • [C-1-1] DEBE admitir todas las API de la clase ConnectivityManager como se describe en la documentación del SDK

Si las implementaciones de dispositivos no proporcionan el modo de ahorro de datos,:

7.4.8. Elementos seguros

Si las implementaciones de dispositivos admiten elementos seguros compatibles con Open Mobile API y los ponen a disposición de aplicaciones de terceros,:

7.5. Cámaras

Si las implementaciones de dispositivos incluyen al menos una cámara, estas:

  • [C-1-1] DEBE declarar el indicador de característica android.hardware.camera.any .
  • [C-1-2] DEBE ser posible que una aplicación asigne simultáneamente 3 mapas de bits RGBA_8888 iguales al tamaño de las imágenes producidas por el sensor de cámara de mayor resolución del dispositivo, mientras la cámara está abierta para fines de vista previa básica y fotografía fija. captura.
  • [C-1-3] DEBE garantizar que la aplicación de cámara predeterminada preinstalada que maneja los intents MediaStore.ACTION_IMAGE_CAPTURE , MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.ACTION_VIDEO_CAPTURE sea responsable de eliminar la ubicación del usuario en los metadatos de la imagen antes de enviarla a la aplicación receptora cuando La aplicación receptora no tiene ACCESS_FINE_LOCATION .

7.5.1. Cámara trasera

Una cámara trasera es una cámara ubicada en el lado del dispositivo opuesto a la pantalla; es decir, captura escenas en el lado opuesto del dispositivo, como una cámara tradicional.

Implementaciones de dispositivos:

  • DEBE incluir una cámara trasera.

Si las implementaciones de dispositivos incluyen al menos una cámara trasera, estas:

  • [C-1-1] DEBE informar el indicador 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.
  • DEBE tener implementado el enfoque automático por hardware o por software en el controlador de la cámara (transparente al software de la aplicación).
  • PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
  • PUEDE incluir un flash.

Si la cámara incluye flash:

  • [C-2-1] la lámpara del flash NO DEBE estar encendida mientras se haya registrado una instancia android.hardware.Camera.PreviewCallback 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 . Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara integrada del sistema del dispositivo, sino solo a aplicaciones de terceros que utilizan Camera.PreviewCallback .

7.5.2. Cámara frontal

Una cámara frontal es una cámara ubicada en el mismo lado del dispositivo que la pantalla; es decir, una cámara que normalmente se utiliza para tomar imágenes del usuario, como por ejemplo para videoconferencias y aplicaciones similares.

Implementaciones de dispositivos:

  • PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, estas:

  • [C-1-1] DEBE informar el indicador de función android.hardware.camera.any y android.hardware.camera.front .
  • [C-1-2] DEBE tener una resolución de al menos VGA (640x480 píxeles).
  • [C-1-3] NO DEBE usar una cámara frontal como predeterminada para la API de cámara y NO DEBE configurar la API para tratar una cámara frontal como la cámara trasera predeterminada, incluso si es la única cámara en el dispositivo.
  • [C-1-4] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación especificada por la aplicación cuando la aplicación actual ha solicitado explícitamente que la pantalla de la cámara se gire mediante una llamada al método android.hardware.Camera.setDisplayOrientation() . Por el contrario, la vista previa DEBE reflejarse a lo largo del eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicita explícitamente que se gire la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation() .
  • [C-1-5] NO DEBE reflejar la imagen fija capturada final o las transmisiones de video devueltas a las devoluciones de llamada de la aplicación o comprometidas con el almacenamiento de medios.
  • [C-1-6] DEBE reflejar la imagen mostrada por la vista posterior de la misma manera que la secuencia de imágenes de vista previa de la cámara.
  • PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras orientadas hacia atrás como se describe en la sección 7.5.1 .

Si el usuario puede girar las implementaciones del dispositivo (por ejemplo, automáticamente mediante un acelerómetro o manualmente mediante la entrada del usuario):

  • [C-2-1] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.

7.5.3. Cámara externa

Implementaciones de dispositivos:

  • PUEDE incluir soporte para una cámara externa que no necesariamente está siempre conectada.

Si las implementaciones de dispositivos incluyen soporte para una cámara externa,:

  • [C-1-1] DEBE declarar el indicador 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 la cámara externa se conecta a través del puerto host USB.
  • [C-1-3] DEBE pasar las pruebas CTS de la cámara con un dispositivo de cámara externo físico conectado. Los detalles de las pruebas de la cámara CTS están disponibles en source.android.com .
  • DEBE admitir compresiones de vídeo como MJPEG para permitir la transferencia de flujos no codificados de alta calidad (es decir, flujos de imágenes sin formato o comprimidos de forma independiente).
  • PUEDE admitir múltiples cámaras.
  • PUEDE admitir codificación de video basada en cámara.

Si se admite la codificación de vídeo basada en cámara:

  • [C-2-1] Se debe acceder a una secuencia simultánea no codificada / MJPEG (QVGA o mayor resolución) a la implementación del dispositivo.

7.5.4. Comportamiento de la API de la cámara

Android incluye dos paquetes API para acceder a la cámara, la API android.hardware.camera2 más nueva expone el control de la cámara de nivel inferior a la aplicación, incluidos flujos eficientes de ráfaga/transmisión de copia cero y controles por fotograma de exposición, ganancia y balance de blancos. , conversión de color, eliminación de ruido, nitidez y más.

El paquete API anterior, android.hardware.Camera , está marcado como obsoleto en Android 5.0, pero aún debería estar disponible para que lo utilicen las aplicaciones. Las implementaciones de dispositivos Android DEBEN garantizar el soporte continuo de la API como se describe en esta sección y en el SDK de Android.

Todas las características que son comunes entre la clase android.hardware.Camera obsoleta y el paquete android.hardware.camera2 más nuevo DEBEN tener un rendimiento y una calidad equivalentes en ambas API. Por ejemplo, con configuraciones equivalentes, la velocidad y precisión del enfoque automático deben ser idénticas y la calidad de las imágenes capturadas debe ser la misma. No es necesario que las características que dependen de las diferentes semánticas de las dos API tengan una velocidad o calidad coincidentes, pero DEBEN coincidir lo más posible.

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las API relacionadas con la cámara, para todas las cámaras disponibles. Implementaciones de dispositivos:

  • [C-0-1] DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para obtener una vista previa de los datos proporcionados a las devoluciones de llamada de la aplicación cuando una aplicación nunca ha llamado a android.hardware.Camera.Parameters.setPreviewFormat(int) .
  • [C-0-2] DEBE además estar en el formato de codificación NV21 cuando una aplicación registra una instancia android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() y el formato de vista previa es YCbCr_420_SP, los datos en el byte[ ] pasó onPreviewFrame() . Es decir, NV21 DEBE ser el predeterminado.
  • [C-0-3] DEBE admitir el formato YV12 (como lo indica la constante android.graphics.ImageFormat.YV12 ) para vistas previas de cámara tanto para cámaras frontales como traseras para android.hardware.Camera . (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxel nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
  • [C-0-4] DEBE admitir los formatos android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como salidas a través de la API android.media.ImageReader para dispositivos android.hardware.camera2 que anuncian la capacidad REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities .
  • [C-0-5] DEBE seguir implementando la API de cámara completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático por hardware u otras capacidades. Por ejemplo, las cámaras que carecen de enfoque automático DEBEN llamar a cualquier instancia registrada android.hardware.Camera.AutoFocusCallback (aunque esto no tiene relevancia para una cámara sin enfoque automático). Tenga en cuenta que esto se aplica a las cámaras frontales; por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API deben ser "falsificadas" como se describe.
  • [C-0-6] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters y la clase android.hardware.camera2.CaptureRequest . Por el contrario, las implementaciones de dispositivos NO DEBEN respetar ni reconocer las constantes de cadena pasadas al método android.hardware.Camera.setParameters() que no sean aquellas documentadas como constantes en android.hardware.Camera.Parameters . Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de cámara estándar si el hardware lo permite, y NO DEBEN admitir tipos de parámetros de cámara personalizados. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes utilizando técnicas de imágenes de alto rango dinámico (HDR) DEBEN admitir el parámetro de la cámara Camera.SCENE_MODE_HDR .
  • [C-0-7] DEBE informar el nivel adecuado de soporte con la propiedad android.info.supportedHardwareLevel como se describe en el SDK de Android e informar los indicadores de características del marco apropiados.
  • [C-0-8] También DEBE declarar las capacidades de la cámara individual de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar los indicadores de funciones apropiados; DEBE definir el indicador de función si alguno de sus dispositivos de cámara conectados admite la función.
  • [C-0-9] DEBE transmitir la intención Camera.ACTION_NEW_PICTURE cada vez que la cámara toma una nueva imagen y la entrada de la imagen se agrega al almacén de medios.
  • [C-0-10] DEBE transmitir la intención Camera.ACTION_NEW_VIDEO cada vez que la cámara graba un nuevo video y la entrada de la imagen se agrega al almacén multimedia.
  • [C-0-11] DEBE tener todas las cámaras accesibles a través de la API android.hardware.Camera obsoleta y también accesible a través de la API android.hardware.camera2 .
  • [C-0-12] DEBE garantizar que la apariencia facial NO se altere, lo que incluye, entre otros, la alteración de la geometría facial, el tono de la piel del rostro o el suavizado de la piel del rostro para cualquier API android.hardware.camera2 o android.hardware.Camera .
  • [C-SR-1] Para dispositivos con múltiples cámaras RGB que se encuentran en la misma dirección, se recomienda encarecidamente admitir un dispositivo de cámara lógico que enumera la capacidad de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA , que consiste en todas las cámaras RGB enfrentando esa dirección como subvalores físicos subvisados .

Si las implementaciones de dispositivos proporcionan una API de cámara patentada para aplicaciones de terceros, estas:

7.5.5. Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o trasera, dichas cámaras:

  • [C-1-1] DEBE estar orientado de modo 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 sostiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo; es decir, se aplica tanto a dispositivos primarios horizontales como a dispositivos primarios verticales.

Los dispositivos que cumplan con todos los criterios siguientes están exentos del requisito anterior:

  • El dispositivo implementa pantallas de geometría variable, como pantallas plegables o con bisagras.
  • Cuando cambia el estado de plegado o bisagra del dispositivo, el dispositivo cambia entre la orientación vertical primaria y horizontal primaria (o viceversa).

7.6. Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimo

Implementaciones de 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 al menos 100 MB de tamaño a la ubicación de "caché" predeterminada.

7.6.2. Aplicación Almacenamiento compartido

Implementaciones de dispositivos:

  • [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, también denominado a menudo "almacenamiento externo compartido", "almacenamiento compartido de aplicaciones" o por la ruta de Linux "/sdcard" en la que está montado.
  • [C-0-2] DEBE configurarse con almacenamiento compartido montado de forma predeterminada, en otras palabras, "listo para usar", independientemente de si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (por ejemplo, ranura para tarjeta Secure Digital). ).
  • [C-0-3] DEBE montar el almacenamiento compartido de la aplicación directamente en la sdcard SD de la ruta de Linux o incluir un enlace simbólico de Linux desde sdcard hasta el punto de montaje real.
  • [C-0-4] DEBE habilitar el almacenamiento con alcance de forma predeterminada para todas las aplicaciones orientadas al nivel API 29 o superior, excepto en la siguiente situación:
    • Cuando la aplicación ha solicitado android:requestLegacyExternalStorage="true" en su manifiesto.
  • [C-0-5] DEBE redactar metadatos de ubicación, como etiquetas GPS Exif, almacenados en archivos multimedia cuando se accede a esos archivos a través de MediaStore , excepto cuando la aplicación que llama tiene el permiso ACCESS_MEDIA_LOCATION .

Las implementaciones de dispositivos PUEDEN cumplir con los requisitos anteriores utilizando cualquiera de los siguientes:

  • Almacenamiento extraíble accesible para el usuario, como una ranura para tarjeta Secure Digital (SD).
  • Una parte del almacenamiento interno (no extraíble) implementado en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones de dispositivos utilizan almacenamiento extraíble para satisfacer los requisitos anteriores:

  • [C-1-1] DEBE implementar una interfaz de usuario emergente o de notificación que advierta al usuario cuando no hay ningún medio de almacenamiento insertado en la ranura.
  • [C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (por ejemplo, una tarjeta SD) o mostrar en la caja y en otro material disponible en el momento de la compra que el medio de almacenamiento debe adquirirse por separado.

Si las implementaciones de dispositivos utilizan una parte del almacenamiento no extraíble para satisfacer los requisitos anteriores,:

  • DEBE utilizar la implementación AOSP del almacenamiento compartido de la aplicación interna.
  • 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,:

  • [C-3-1] debe proporcionar un mecanismo para acceder a los datos en el almacenamiento compartido de la aplicación desde una computadora host.
  • DEBE exponer el contenido de ambas rutas de almacenamiento de forma transparente a través del servicio de escáner de medios de Android y android.provider.MediaStore .
  • PUEDE usar almacenamiento masivo USB, pero DEBE usar 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 admiten el Protocolo de transferencia de medios,:

  • DEBE ser compatible con el host MTP de Android de referencia, Android File Transfer .
  • DEBE informar una clase de dispositivo USB de 0x00.
  • DEBE informar un nombre de interfaz USB de 'MTP'.

7.6.3. Almacenamiento adoptable

Si se espera que el dispositivo sea de naturaleza móvil a diferencia de la televisión, las implementaciones del dispositivo son:

  • [C-SR-1] RECOMIENDA ENCARECIDAMENTE implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlos accidentalmente puede causar pérdida/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 compartimiento de la batería u otra cubierta protectora, las implementaciones del dispositivo son:

7.7. USB

Si las implementaciones de dispositivos tienen un puerto USB,:

  • Debe admitir el modo periférico USB y debe admitir el modo de host USB.
  • DEBE admitir la desactivación de la señalización de datos a través de USB.

7.7.1. Modo periférico USB

Si las implementaciones del dispositivo incluyen un puerto USB que admite el modo periférico:

  • [C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
  • [C-1-2] DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo estándar USB a través de android.os.Build.SERIAL .
  • [C-1-3] debe detectar cargadores 1.5A y 3.0A según el estándar de resistencia tipo C y debe detectar cambios en el anuncio si admiten USB tipo-C.
  • [C-SR-1] El puerto DEBE utilizar un factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
  • [C-SR-2] El puerto DEBE estar ubicado en la parte inferior del dispositivo (según la orientación natural) o permitir la rotación de la pantalla del software para todas las aplicaciones (incluida la pantalla de inicio), de modo que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
  • [C-SR-3] DEBE implementar soporte para consumir corriente de 1,5 A durante el chirrido HS y el tráfico como se especifica en la especificación de carga de batería USB, revisión 1.2 . Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a futuras versiones de la plataforma.
  • [C-SR-4] SE RECOMIENDA ENCARECIDAMENTE no admitir métodos de carga patentados que modifiquen el voltaje de Vbus más allá de los niveles predeterminados, o que alteren las funciones de fuente/sumidero, ya que tal puede resultar en problemas de interoperabilidad con los cargadores o dispositivos que admiten los métodos estándar de entrega de energía USB. Si bien esto se denomina "MUY RECOMENDADO", en futuras versiones de Android es posible que REQUIEREMOS que todos los dispositivos tipo C admitan una interoperabilidad total con los cargadores tipo C estándar.
  • [C-SR-5] SE RECOMIENDA ENCARECIDAMENTE admitir Power Delivery para el intercambio de roles de energía y datos cuando admiten USB tipo C y modo host USB.
  • DEBE admitir Power Delivery para carga de alto voltaje y soporte para modos alternativos como visualización.
  • DEBE implementar la API y la especificación del accesorio abierto de Android (AOA) como se documenta en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen un puerto USB e implementan la especificación AOA,:

  • [C-2-1] 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" al final de la descripción de la interfaz Cadena iInterface del almacenamiento masivo USB
  • NO DEBE implementar el audio AOAv2 documentado en la documentación del Protocolo de accesorios abiertos de Android 2.0. El audio AOAv2 está obsoleto a partir de la versión 8.0 de Android (nivel de API 26).

7.7.2. Modo de host USB

Si las implementaciones del dispositivo incluyen un puerto USB que admite el modo de host, ellos:

  • [C-1-1] DEBE implementar la API del host USB de Android como se documenta en el SDK de Android y DEBE declarar compatibilidad con la función de hardware android.hardware.usb.host .
  • [C-1-2] DEBEN implementar soporte para conectar periféricos USB estándar, en otras palabras, DEBEN:
    • Tener un puerto tipo C en el dispositivo o enviarse con cables que adapten un puerto propietario del dispositivo a un puerto USB tipo C estándar (dispositivo USB tipo C).
    • Tenga un dispositivo tipo A o envíelo con cables que adapten un puerto propietario del dispositivo a un puerto USB tipo A estándar.
    • Tener un puerto micro-AB en el dispositivo, que DEBE enviarse con un cable que se adapta a un puerto tipo A estándar.
  • [C-1-3] NO DEBE enviarse con un adaptador que convierta de puertos USB tipo A o micro-AB a un puerto tipo C (receptáculo).
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
  • DEBE admitir la carga del dispositivo periférico USB conectado mientras está en modo host; anunciar una fuente de corriente de al menos 1,5 A como se especifica en la sección Parámetros de terminación de la Revisión 1.2 de la especificación de conector y cable USB tipo C para conectores USB tipo C o usar el rango de corriente de salida del puerto de carga descendente (CDP) como se especifica en el USB Especificaciones de carga de batería, revisión 1.2 para conectores Micro-AB.
  • Debe implementar y admitir estándares USB tipo-C.

Si las implementaciones del dispositivo incluyen un puerto USB que admite el modo de host y la clase de audio USB, ellos:

  • [C-2-1] DEBE admitir la clase USB HID .
  • [C-2-2] DEBE admitir la detección y mapeo de los siguientes campos de datos HID especificados en las Tablas de uso de HID de USB y la Solicitud de uso de comando de voz a las constantes KeyEvent como se muestra a continuación:
    • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
    • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
    • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y Storage Access Framework (SAF), estos:

  • [C-3-1] DEBE reconocer cualquier dispositivo MTP (Protocolo de transferencia de medios) conectado remotamente y hacer que su contenido sea accesible a través de los intents ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT . .

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y USB Type-C,:

  • [C-4-1] DEBE implementar la funcionalidad de puerto de función dual según lo define la especificación USB tipo C (sección 4.5.1.3.3).
  • [C-SR-2] SE RECOMIENDA ENCARECIDAMENTE que admita DisplayPort, DEBE admitir velocidades de datos USB SuperSpeed ​​y se RECOMIENDA ENCARECIDAMENTE que admita la entrega de energía para el intercambio de roles de energía y datos.
  • [C-SR-3] SE RECOMIENDA ENCARECIDAMENTE NO admitir el modo de accesorio del adaptador de audio como se describe en el Apéndice A de la especificación del conector y cable USB tipo C, Revisión 1.2 .
  • DEBE implementar el modelo Try.* que sea más apropiado para el factor de forma del dispositivo. Por ejemplo, un dispositivo portátil DEBE implementar el modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

Si las implementaciones de dispositivos incluyen un micrófono,:

  • [C-1-1] DEBE informar la constante de la característica android.hardware.microphone .
  • [C-1-2] debe cumplir con los requisitos de grabación de audio en la Sección 5.4 .
  • [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6 .
  • [C-SR-1] Se RECOMIENDAN ENCARECIDAMENTE para admitir la grabación de ultrasonido cercano como se describe en la sección 7.8.3 .

Si las implementaciones de dispositivos omiten un micrófono,:

  • [C-2-1] NO DEBE informar la constante de la característica android.hardware.microphone .
  • [C-2-2] DEBE implementar la API de grabación de audio al menos como no operativa, según la sección 7 .

7.8.2. Salida de audio

Si las implementaciones de dispositivos incluyen un altavoz o un puerto de salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 3,5 mm de 4 conductores o un puerto de modo host USB que utiliza clase de audio USB ,:

  • [C-1-1] DEBE informar la constante de la característica android.hardware.audio.output .
  • [C-1-2] DEBE cumplir con los requisitos de reproducción de audio de la sección 5.5 .
  • [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6 .
  • [C-SR-1] RECOMENDADO ENCARECIDAMENTE para admitir la reproducción de ultrasonido cercano como se describe en la sección 7.8.3 .

Si las implementaciones de dispositivos no incluyen un altavoz o un puerto de salida de audio,:

  • [C-2-1] NO DEBE informar la función android.hardware.audio.output .
  • [C-2-2] DEBE implementar las API relacionadas con la salida de audio al menos como no operativas.

A los efectos de esta sección, un "puerto de salida" es una interfaz física como un conector de audio de 3,5 mm, HDMI o un puerto de modo host USB con clase de audio USB. La compatibilidad con salida de audio a través de protocolos basados ​​en radio, como Bluetooth, WiFi o red celular, no califica como inclusión de un "puerto de salida".

7.8.2.1. Puertos de audio analógico

Para ser compatibles con los auriculares y otros accesorios de audio que utilizan el conector de audio de 3,5 mm en todo el ecosistema Android, si las implementaciones del dispositivo incluyen uno o más puertos de audio analógico, estos:

  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE incluir al menos uno de los puertos de audio para que sea un conector de audio de 3,5 mm de 4 conductores.

Si las implementaciones de dispositivos tienen un conector de audio de 3,5 mm de 4 conductores,:

  • [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono.
  • [C-1-2] DEBE admitir enchufes de audio TRRS con el orden de distribución de pines CTIA.
  • [C-1-3] DEBE admitir la detección y el mapeo de los códigos clave para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de tierra en el conector de audio:
    • 70 ohmios o menos : KEYCODE_HEADSETHOOK
    • 210-290 ohmios : KEYCODE_VOLUME_UP
    • 360-680 ohmios : KEYCODE_VOLUME_DOWN
  • [C-1-4] DEBE activar ACTION_HEADSET_PLUG al insertar un enchufe, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
  • [C-1-5] DEBE ser capaz de manejar al menos 150 mV ± 10 % del voltaje de salida con una impedancia de altavoz de 32 ohmios.
  • [C-1-6] DEBE tener un voltaje de polarización del micrófono entre 1,8 V ~ 2,9 V.
  • [C-1-7] DEBE detectar y asignar al código clave el siguiente rango de impedancia equivalente entre el micrófono y los conductores de tierra en el conector de audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE admitir conectores de audio con el orden de distribución de pines OMTP.
  • [C-SR-3] Se RECOMIENDAN ENCARECIDAMENTE para admitir la grabación de audio desde auriculares estéreo con micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 3,5 mm de 4 conductores y admiten un micrófono, y transmiten android.intent.action.HEADSET_PLUG con el micrófono de valor adicional configurado como 1,:

  • [C-2-1] DEBE admitir la detección del micrófono en el accesorio de audio enchufado.
7.8.2.2. Puertos de audio digitales

Para ser compatible con los auriculares y otros accesorios de audio utilizando conectores USB-C e implementación (clase de audio USB) en todo el ecosistema de Android como se define en la especificación de auriculares USB de Android .

Consulte la Sección 2.2.1 para conocer los requisitos específicos del dispositivo.

7.8.3. Casi ultrasonido

El audio del ultrasonido cercano es la banda de 18,5 kHz a 20 kHz.

Implementaciones de dispositivos:

  • DEBE informar correctamente la compatibilidad con la capacidad de audio de ultrasonido cercano a través de la API AudioManager.getProperty de la siguiente manera:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es "true", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED DEBEN cumplir los siguientes requisitos:

  • [C-1-1] La respuesta de potencia media del micrófono en la banda de 18,5 kHz a 20 kHz DEBE estar no más de 15 dB por debajo de la respuesta a 2 kHz.
  • [C-1-2] La relación señal/ruido no ponderada del micrófono entre 18,5 kHz y 20 kHz para un tono de 19 kHz a -26 dBFS DEBE ser no inferior a 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es "verdadero":

  • [C-2-1] La respuesta media del altavoz en 18,5 kHz - 20 kHz DEBE ser no inferior a 40 dB por debajo de la respuesta a 2 kHz.

7.8.4. Integridad de la señal

Implementaciones de dispositivos:

  • DEBE proporcionar una ruta de señal de audio sin fallas para los flujos de entrada y salida en dispositivos portátiles, según lo definido por cero fallas medidas durante una prueba de un minuto por ruta. Pruebe usando OboeTester "Prueba de falla automatizada".

La prueba requiere un dongle de bucle invertido de audio , usado directamente en un conector de 3,5 mm y/o en combinación con un adaptador USB-C a 3,5 mm. Todos los puertos de salida de audio DEBEN probarse.

OboeTester actualmente admite rutas de AAudio, por lo que las siguientes combinaciones DEBEN probarse para detectar fallas usando AAudio:

Modo de rendimiento Intercambio Frecuencia de muestreo En Chans Fuera Chans
BAJA LATENCIA EXCLUSIVO NO ESPECIFICADO 1 2
BAJA LATENCIA EXCLUSIVO NO ESPECIFICADO 2 1
BAJA LATENCIA COMPARTIDO NO ESPECIFICADO 1 2
BAJA LATENCIA COMPARTIDO NO ESPECIFICADO 2 1
NINGUNO COMPARTIDO 48000 1 2
NINGUNO COMPARTIDO 48000 2 1
NINGUNO COMPARTIDO 44100 1 2
NINGUNO COMPARTIDO 44100 2 1
NINGUNO COMPARTIDO 16000 1 2
NINGUNO COMPARTIDO 16000 2 1

Una transmisión confiable DEBE cumplir con los siguientes criterios de relación señal-ruido (SNR) y distorsión armónica total (THD) para 2000 Hz sinusoidal.

transductor THD SNR
Altavoz incorporado principal, medido utilizando un micrófono de referencia externo. <3,0% >= 50dB
Micrófono incorporado principal, medido utilizando un altavoz de referencia externo. <3,0% >= 50dB
Conectores analógicos integrados de 3,5 mm, probados con un adaptador loopback < 1% >= 60dB
Adaptadores USB suministrados con el teléfono, probados con un adaptador loopback < 1,0% >= 60dB

7.9. Realidad virtual

Android incluye API e instalaciones para crear aplicaciones de "realidad virtual" (VR), incluidas experiencias de realidad virtual móviles de alta calidad. Las implementaciones de dispositivos DEBEN implementar correctamente estas API y comportamientos, como se detalla en esta sección.

7.9.1. Modo de realidad virtual

Android incluye soporte para el modo VR , una función que maneja la representación estereoscópica de notificaciones y desactiva los componentes de la interfaz de usuario del sistema monocular mientras una aplicación de realidad virtual se centra en el usuario.

7.9.2. Modo de realidad virtual: alto rendimiento

Si las implementaciones de dispositivos admiten el modo VR,:

  • [C-1-1] DEBE tener al menos 2 núcleos físicos.
  • [C-1-2] DEBE declarar la característica android.hardware.vr.high_performance .
  • [C-1-3] DEBE admitir el modo de rendimiento sostenido.
  • [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
  • [C-1-5] DEBE ser compatible con android.hardware.vulkan.level 0.
  • DEBE admitir android.hardware.vulkan.level 1 o superior.
  • [C-1-6] DEBE implementar EGL_KHR_mutable_render_buffer , EGL_ANDROID_front_buffer_auto_refresh , EGL_ANDROID_get_native_client_buffer , EGL_KHR_fence_sync , EGL_KHR_wait_sync , EGL_IMG_context_priority , EGL_EXT_protected_content , EGL_EXT_image_gl_colorspace colorspace y exponer las extensiones en la lista de extensiones EGL disponibles.
  • [C-1-8] DEBE implementar GL_EXT_multisampled_render_to_texture2 , GL_OVR_multiview , GL_OVR_multiview2 , GL_EXT_protected_textures y exponer las extensiones en la lista de extensiones GL disponibles.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE implementar GL_EXT_external_buffer , GL_EXT_EGL_image_array , GL_OVR_multiview_multisampled_render_to_texture y exponer las extensiones en la lista de extensiones GL disponibles.
  • [C-SR-2] Se RECOMIENDA ENCARECIDAMENTE que sean compatibles con Vulkan 1.1.
  • [C-SR-3] Se RECOMIENDA ENCARECIDAMENTE implementar VK_ANDROID_external_memory_android_hardware_buffer , VK_GOOGLE_display_timing , VK_KHR_shared_presentable_image y exponerlo en la lista de extensiones de Vulkan disponibles.
  • [C-SR-4] Se RECOMIENDA ENCARECIDAMENTE exponer al menos una familia de colas de Vulkan donde flags contengan VK_QUEUE_GRAPHICS_BIT y VK_QUEUE_COMPUTE_BIT , y queueCount sea al menos 2.
  • [C-1-7] La ​​GPU y la pantalla DEBEN poder sincronizar el acceso al búfer frontal compartido de modo que la representación de ojos alternos del contenido de realidad virtual a 60 fps con dos contextos de representación se muestre sin artefactos de desgarro visibles.
  • [C-1-9] DEBE implementar soporte para los indicadores AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER , AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT como se describe en el NDK.
  • [C-1-10] DEBE implementar soporte para AHardwareBuffer s con cualquier combinación de los indicadores de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT , AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE , AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para al menos los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM , AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM , AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM , AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT .
  • [C-SR-5] Se RECOMIENDA ENCARECIDAMENTE admitir la asignación de AHardwareBuffer con más de una capa y los indicadores y formatos especificados en C-1-10.
  • [C-1-11] DEBE admitir decodificación H.264 al menos 3840 x 2160 a 30 fps, comprimido a un promedio de 40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-10 Mbps o 2 instancias de 1920 x 1080 a 60 FPS-20 Mbps).
  • [C-1-12] DEBE admitir HEVC y VP9, ​​DEBE ser capaz de decodificar al menos 1920 x 1080 a 30 fps comprimidos a un promedio de 10 Mbps y DEBE ser capaz de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-5 Mbps).
  • [C-1-13] DEBE admitir la API HardwarePropertiesManager.getDeviceTemperatures y devolver valores precisos para la temperatura de la piel.
  • [C-1-14] DEBE tener una pantalla integrada y su resolución DEBE ser de al menos 1920 x 1080.
  • [C-SR-6] Se RECOMIENDA ENCARECIDAMENTE tener una resolución de pantalla de al menos 2560 x 1440.
  • [C-1-15] La pantalla DEBE actualizarse al menos 60 Hz mientras está en modo VR.
  • [C-1-17] La ​​pantalla DEBE admitir un modo de baja persistencia con ≤ 5 milisegundos de persistencia, definiéndose la persistencia como la cantidad de tiempo durante el cual un píxel emite luz.
  • [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la sección 7.4.3 de extensión de longitud de datos de Bluetooth LE.
  • [C-1-19] DEBE admitir e informar adecuadamente el tipo de canal directo para todos los siguientes tipos de sensores predeterminados:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] Se RECOMIENDA ENCARECIDAMENTE admitir el tipo de canal directo TYPE_HARDWARE_BUFFER para todos los tipos de canales directos enumerados anteriormente.
  • [C-1-21] DEBE cumplir con los requisitos relacionados con giroscopio, acelerómetro y magnetómetro para android.hardware.hifi_sensors , como se especifica en la sección 7.3.9 .
  • [C-SR-8] Se RECOMIENDA ENCARECIDAMENTE que admitan la función android.hardware.sensor.hifi_sensors .
  • [C-1-22] DEBE tener una latencia de movimiento a fotón de extremo a extremo que no supere los 28 milisegundos.
  • [C-SR-9] Se RECOMIENDA ENCARECIDAMENTE tener una latencia de movimiento de fotón de extremo a extremo no superior a 20 milisegundos.
  • [C-1-23] DEBE tener una relación de primer cuadro, que es la relación entre el brillo de los píxeles en el primer cuadro después de una transición de negro a blanco y el brillo de los píxeles blancos en estado estable, de al menos 85 %.
  • [C-SR-10] Se RECOMIENDA ENCARECIDAMENTE tener una relación de primer fotograma de al menos el 90 %.
  • PUEDE proporcionar un núcleo exclusivo para la aplicación en primer plano y PUEDE admitir la API Process.getExclusiveCores para devolver los números de los núcleos de la CPU que son exclusivos de la aplicación en primer plano superior.

Si es compatible con el núcleo exclusivo, entonces el núcleo:

  • [C-2-1] NO DEBE permitir que se ejecute ningún otro proceso del espacio de usuario (excepto los controladores de dispositivo utilizados por la aplicación), pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.

7.10. hápticos

Consulte la Sección 2.2.1 para conocer los requisitos específicos del dispositivo.

7.11. Clase de rendimiento de medios

La clase de rendimiento de los medios de la implementación del dispositivo se puede obtener de android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS . Los requisitos para la clase de rendimiento multimedia se definen para cada versión de Android a partir de R (versión 30). El valor especial 0 indica que el dispositivo no pertenece a una clase de rendimiento multimedia.

Si las implementaciones del dispositivo devuelven un valor distinto de cero para android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS , ellos:

  • [C-1-1] DEBE devolver al menos un valor de android.os.Build.VERSION_CODES.R .

  • [C-1-2] DEBE ser una implementación de dispositivo portátil.

  • [C-1-3] DEBE cumplir con todos los requisitos de "Clase de rendimiento de medios" descritos en la sección 2.2.7 .

Consulte la sección 2.2.7 para conocer los requisitos específicos del dispositivo.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y potencia son fundamentales para la experiencia del usuario e impactan las suposiciones básicas que los desarrolladores tendrían al desarrollar una aplicación.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si existen ciertos requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta consistentes para aplicaciones y juegos. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener requisitos mensurables para la latencia de la interfaz de usuario y el cambio de tareas, como se describe en la sección 2 .

8.2. Rendimiento del acceso a E/S de archivos

Proporcionar una base común para un rendimiento consistente del acceso a archivos en el almacenamiento de datos privados de la aplicación (partición /data ) permite a los desarrolladores de aplicaciones establecer una expectativa adecuada que ayudaría a diseñar su software. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener ciertos requisitos descritos en la sección 2 para las siguientes operaciones de lectura y escritura:

  • Rendimiento de escritura secuencial . Medido escribiendo un archivo de 256 MB utilizando un búfer de escritura de 10 MB.
  • Rendimiento de escritura aleatoria . Medido escribiendo un archivo de 256 MB utilizando un búfer de escritura de 4 KB.
  • Rendimiento de lectura secuencial . Medido leyendo un archivo de 256 MB con búfer de escritura de 10 MB.
  • Rendimiento de lectura aleatoria . Medido leyendo un archivo de 256 MB utilizando un búfer de escritura de 4 KB.

8.3. Modos de ahorro de energía

Si las implementaciones de dispositivos incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP (por ejemplo, App Standby Bucket, Doze) o extienden las funciones para aplicar restricciones más estrictas que el RESTRINGIDO App Standby Bucket , estas:

  • [C-1-1] NO DEBE desviarse de la implementación de AOSP para los algoritmos de activación, mantenimiento y activación y el uso de la configuración global del sistema o DeviceConfig de los modos de ahorro de energía App Standby y Doze.
  • [C-1-2] no debe desviarse de la implementación de AOSP para el uso de configuraciones globales o DeviceConfig para administrar el estrangulamiento de los trabajos, la alarma y la red para las aplicaciones en cada cubo para aplicaciones en espera.
  • [C-1-3] NO DEBE desviarse de la implementación de AOSP para la cantidad de depósitos de aplicaciones en espera utilizados para la aplicación en espera.
  • [C-1-4] DEBE implementar App Standby Buckets y Doze como se describe en Administración de energía .
  • [C-1-5] DEBE devolver true para PowerManager.isPowerSaveMode() cuando el dispositivo está en modo de ahorro de energía.
  • [C-1-6] DEBE proporcionar al usuario la posibilidad de mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía App Standby y Doze o cualquier optimización de la batería y DEBE implementar la intención ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATION para pedirle al usuario que permita que una aplicación ignore las optimizaciones de la batería.
  • [C-SR-1] Se RECOMIENDA ENCARECIDAMENTE brindar al usuario la posibilidad de habilitar y deshabilitar la función de ahorro de batería.
  • [C-SR-2] se recomiendan encarecidamente para proporcionar el servicio del usuario para mostrar todas las aplicaciones que están exentas de los modos de ahorro de energía y dormitorio de aplicaciones.

Si las implementaciones de dispositivos amplían las funciones de administración de energía que se incluyen en AOSP y esa extensión aplica restricciones más estrictas que el Rare App Standby Bucket , consulte la sección 3.5.1 .

Además de los modos de ahorro de energía, las implementaciones de dispositivos Android PUEDEN implementar cualquiera o todos los 4 estados de energía inactivos según lo definido por la Interfaz de energía y configuración avanzada (ACPI).

Si las implementaciones de dispositivos implementan estados de energía S4 según lo define ACPI, ellos:

  • [C-1-1] DEBE ingresar a este estado solo después de que el usuario haya realizado una acción explícita para poner el dispositivo en un estado inactivo (por ejemplo, cerrando una tapa que es físicamente parte del dispositivo o apagando un vehículo o televisión) y antes de que el usuario reactive el dispositivo (por ejemplo, abriendo la tapa o volviendo a encender el vehículo o la televisión).

Si las implementaciones de dispositivos implementan estados de energía S3 según lo define ACPI, ellos:

  • [C-2-1] DEBE cumplir con C-1-1 anterior o DEBE ingresar al estado S3 solo cuando las aplicaciones de terceros no necesiten los recursos del sistema (por ejemplo, la pantalla, la CPU).

    Por el contrario, DEBE salir del estado S3 cuando las aplicaciones de terceros necesiten los recursos del sistema, como se describe en este SDK.

    Por ejemplo, mientras las aplicaciones de terceros solicitan mantener la pantalla encendida a través de FLAG_KEEP_SCREEN_ON o mantener la CPU funcionando a través de PARTIAL_WAKE_LOCK , el dispositivo NO DEBE ingresar al estado S3 a menos que, como se describe en C-1-1, el usuario haya tomado medidas explícitas para poner el dispositivo en un estado inactivo. Por el contrario, en un momento en el que se activa una tarea que las aplicaciones de terceros implementan a través de JobScheduler o se entrega Firebase Cloud Messaging a aplicaciones de terceros, el dispositivo DEBE salir del estado S3 a menos que el usuario haya puesto el dispositivo en un estado inactivo. Estos no son ejemplos completos y AOSP implementa extensas señales de atención que provocan una atención de este estado.

8.4. Contabilidad del consumo de energía

Una contabilidad y un informe más precisos del consumo de energía proporcionan al desarrollador de la aplicación tanto los incentivos como las herramientas para optimizar el patrón de uso de energía de la aplicación.

Implementaciones de dispositivos:

  • [C-SR-1] SE RECOMIENDA ENCARECIDAMENTE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [C-SR-2] RECOMIENDA ENCARECIDAMENTE informar todos los valores de consumo de energía en miliamperios hora (mAh).
  • [C-SR-3] SE RECOMIENDA ENCARECIDAMENTE informar el consumo de energía de la CPU por el UID de cada proceso. El proyecto de código abierto de Android cumple con el requisito mediante la implementación del módulo del kernel uid_cputime .
  • [C-SR-4] SE RECOMIENDA ENCARECIDAMENTE hacer que este uso de energía esté disponible a través del comando shell adb shell dumpsys batterystats para el desarrollador de la aplicación.
  • DEBE atribuirse al propio componente de hardware si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

8.5. Rendimiento consistente

El rendimiento puede fluctuar dramáticamente para aplicaciones de alto rendimiento y larga ejecución, ya sea debido a que otras aplicaciones se ejecutan en segundo plano o a que la CPU se acelera debido a límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea capaz, la aplicación en primer plano pueda solicitar que el sistema optimice la asignación de recursos para abordar tales fluctuaciones.

Implementaciones de dispositivos:

Si las implementaciones de dispositivos informan que admiten el modo de rendimiento sostenido,:

  • [C-1-1] DEBE proporcionar a la aplicación de primer plano superior un nivel constante de rendimiento durante al menos 30 minutos, cuando la aplicación lo solicite.
  • [C-1-2] DEBE respetar la API Window.setSustainedPerformanceMode() y otras API relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU,:

  • DEBE proporcionar al menos un núcleo exclusivo que la aplicación de primer plano pueda reservar.

Si las implementaciones de dispositivos admiten la reserva de un núcleo exclusivo para la aplicación de primer plano, estas:

  • [C-2-1] DEBE informar a través del método API Process.getExclusiveCores() los números de identificación de los núcleos exclusivos que la aplicación de primer plano superior puede reservar.
  • [C-2-2] NO DEBE permitir que ningún proceso del espacio de usuario, excepto los controladores de dispositivo utilizados por la aplicación, se ejecute en los núcleos exclusivos, pero PUEDE permitir que algunos procesos del kernel se ejecuten según sea necesario.

Si las implementaciones de dispositivos no admiten un núcleo exclusivo,:

9. Compatibilidad del modelo de seguridad

Implementaciones de dispositivos:

  • [C-0-1] DEBE implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma Android como se define en el documento de referencia de seguridad y permisos en las API en la documentación para desarrolladores de Android.

  • [C-0-2] DEBE admitir la instalación de aplicaciones autofirmadas sin requerir permisos/certificados adicionales de terceros/autoridades.

Si las implementaciones de dispositivos declaran la función android.hardware.security.model.compatible ,:

  • [C-1-1] DEBE soportar los requisitos enumerados en las siguientes subsecciones.

9.1. Permisos

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir el modelo de permisos de Android y el modelo de roles de Android como se define en la documentación para desarrolladores de Android. Específicamente, DEBEN hacer cumplir cada permiso y función definidos como se describe en la documentación del SDK; no se pueden omitir, modificar ni ignorar permisos ni roles.

  • PUEDE agregar permisos adicionales, siempre que las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.\* .

  • [C-0-2] Los permisos con un protectionLevel de PROTECTION_FLAG_PRIVILEGED solo deben otorgarse a las aplicaciones preinstaladas en las rutas privilegiadas de la imagen del sistema y dentro del subconjunto de los permisos de lista aniquiladas explícitamente para cada aplicación. La implementación de AOSP cumple con este requisito leyendo y respetando los permisos permitidos para cada aplicación de los archivos en la ruta etc/permissions/ y utilizando la ruta system/priv-app como ruta privilegiada.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 las solicitan en tiempo de ejecución.

Implementaciones de dispositivos:

  • [C-0-3] DEBE mostrar una interfaz dedicada para que el usuario decida si otorga los permisos de tiempo de ejecución solicitados y también proporcionar una interfaz para que el usuario administre los permisos de tiempo de ejecución.
  • [C-0-4] DEBE tener una y sólo una implementación de ambas interfaces de usuario.
  • [C-0-5] no debe otorgar ningún permiso de tiempo de ejecución a aplicaciones preinstaladas a menos que:
    • El consentimiento del usuario se puede obtener antes de que la aplicación la use.
    • Los permisos de tiempo de ejecución están asociados con un patrón de intención para el cual la aplicación preinstalada se establece como el controlador predeterminado.
  • [C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo a las aplicaciones del sistema que registren un Agente de Recuperación debidamente protegido. Un agente de recuperación adecuadamente protegido se define como un agente de software en el dispositivo que se sincroniza con un almacenamiento remoto fuera del dispositivo, que está equipado con hardware seguro con una protección equivalente o más fuerte que la que se describe en el servicio Google Cloud Key Vault para evitar la fuerza bruta. ataques al factor de conocimiento de la pantalla de bloqueo.

Implementaciones de dispositivos:

  • [C-0-7] DEBE cumplir con las propiedades de permiso de ubicación de Android cuando una aplicación solicita datos de ubicación o actividad física a través de la API estándar de Android o un mecanismo propietario. Dichos datos incluyen, entre otros:

    • Ubicación del dispositivo (por ejemplo, latitud y longitud) como se describe en la sección 9.8.8 .
    • Información que se puede utilizar para determinar o estimar la ubicación del dispositivo (por ejemplo, SSID, BSSID, ID de celular o ubicación de la red a la que está conectado el dispositivo).
    • Actividad física del usuario o clasificación de la actividad física.

Más específicamente, implementaciones de dispositivos:

    *   [C-0-8] MUST obtain user consent to allow an app to access the
        location or physical activity data.
    *   [C-0-9] MUST grant a runtime permission ONLY to the app that holds
        sufficient permission as described on SDK.
        For example,

TelephonyManager#getServiceState requiere android.permission.ACCESS_FINE_LOCATION ).

Las únicas excepciones a las propiedades de permiso de ubicación de Android anteriores son para las aplicaciones que no acceden a la Ubicación para derivar o identificar la ubicación del usuario; específicamente:

  • Cuando las aplicaciones tienen el permiso RADIO_SCAN_WITHOUT_LOCATION .
  • Para fines de configuración y configuración de dispositivos, donde las aplicaciones del sistema tienen el permiso NETWORK_SETTINGS o NETWORK_SETUP_WIZARD .

Los permisos se pueden marcar como restringidos alterando su comportamiento.

  • [C-0-10] Los permisos marcados con la bandera hardRestricted NO DEBEN otorgarse a una aplicación a menos que:

    • Un archivo APP APK está en la partición del sistema.
    • El usuario asigna una función asociada con los permisos hardRestricted a una aplicación.
    • El instalador otorga hardRestricted a una aplicación.
    • A una aplicación se le otorga la hardRestricted en una versión anterior de Android.
  • [C-0-11] Las aplicaciones que tienen un permiso softRestricted DEBEN obtener solo acceso limitado y NO DEBEN obtener acceso completo hasta que estén incluidas en la lista permitida como se describe en el SDK, donde se define el acceso completo y limitado para cada permiso softRestricted (por ejemplo, READ_EXTERNAL_STORAGE ).

  • [C-0-12] NO DEBE proporcionar ninguna función o API personalizada para eludir las restricciones de permiso definidas en las API setPermissionPolicy y setPermissionGrantState .

  • [C-0-13] DEBE utilizar las API de AppOpsManager para registrar y rastrear todos y cada uno de los accesos programáticos a datos protegidos por permisos peligrosos de actividades y servicios de Android.

  • [C-0-14] DEBE asignar roles únicamente a aplicaciones con funcionalidades que cumplan con los requisitos del rol.

  • [C-0-15] No DEBE definir roles que sean duplicados o funcionalidades de superconjunto de roles definidos por la plataforma.

Si los dispositivos informan android.software.managed_users ,:

  • [C-1-1] NO DEBE tener los siguientes permisos otorgados silenciosamente por el administrador:
    • Ubicación (access_background_location, access_coarse_location, access_fine_location).
    • Cámara (CÁMARA)
    • Micrófono (RECORD_AUDIO)
    • Sensor corporal (Body_Sensors)
    • Actividad física (ACTIVITY_RECOGNITION)

Si las implementaciones de dispositivos brindan al usuario la posibilidad de elegir qué aplicaciones pueden superponerse a otras aplicaciones con una actividad que maneja la intención ACTION_MANAGE_OVERLAY_PERMISSION , estas:

  • [C-2-1] debe asegurarse de que todas las actividades con filtros de intención para la intención ACTION_MANAGE_OVERLAY_PERMISSION tengan la misma pantalla de interfaz de usuario, independientemente de la aplicación de iniciación o cualquier información que proporcione.

Si las implementaciones de dispositivos informan android.software.device_admin, ellos:

  • [C-3-1] debe mostrar un descargo de responsabilidad durante la configuración del dispositivo totalmente administrada (configuración del propietario del dispositivo) que indique que el administrador de TI tendrá la capacidad de permitir que las aplicaciones controlen la configuración en el teléfono, incluyendo micrófono, cámara y ubicación, con opciones para el usuario para continuar con la configuración o salir de ella A MENOS que el administrador haya optado por perder el control de los permisos en el dispositivo.

Si las implementaciones de dispositivos preinstalan cualquier paquete que contenga cualquiera de las funciones System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence o System Visual Intelligence , los paquetes:

  • [C-4-1] debe cumplir con todos los requisitos descritos para las implementaciones del dispositivo en la sección "9.8.6 Captura de contenido".
  • [C-4-2] NO DEBE tener el permiso android.permission.INTERNET. Esto es más estricto que lo MUY RECOMENDADO que figura en la sección 9.8.6.
  • [C-4-3] no debe vincularse a otras aplicaciones, excepto para las siguientes aplicaciones del sistema: Bluetooth, Contactos, Medios, Telefonía, SystemUI y Componentes que proporcionan API de Internet. Esto es más estricto que el Fasty Recomendado en la sección 9.8.6 .

9.2. UID y aislamiento de procesos

Implementaciones de dispositivos:

  • [C-0-1] DEBE admitir el modelo de zona de pruebas de aplicaciones de Android, en el que cada aplicación se ejecuta como un UID estilo Unix único y en un proceso separado.
  • [C-0-2] DEBE admitir la ejecución de múltiples aplicaciones con el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de Seguridad y Permisos .

9.3. Permisos del sistema de archivos

Implementaciones de dispositivos:

9.4. Entornos de ejecución alternativos

Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de permisos y seguridad de Android, incluso si incluyen entornos de ejecución que ejecutan aplicaciones utilizando algún otro software o tecnología que no sea el formato ejecutable Dalvik o el código nativo. En otras palabras:

  • [C-0-1] Los tiempos de ejecución alternativos deben ser aplicaciones de Android, y cumplir con el modelo de seguridad de Android estándar, como se describe en otra parte de la Sección 9 .

  • [C-0-2] NO SE DEBE otorgar acceso a tiempos de ejecución alternativos a recursos protegidos por permisos no solicitados en el archivo AndroidManifest.xml del tiempo de ejecución a través del mecanismo uses-permission .

  • [C-0-3] Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones utilicen funciones protegidas por permisos de Android restringidos a aplicaciones del sistema.

  • [C-0-4] Los tiempos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android y las aplicaciones instaladas que utilizan un tiempo de ejecución alternativo NO DEBEN reutilizar la zona de pruebas de ninguna otra aplicación instalada en el dispositivo, excepto a través de los mecanismos estándar de Android de ID de usuario compartido y certificado de firma. .

  • [C-0-5] Los tiempos de ejecución alternativos NO DEBEN iniciarse, otorgar ni recibir acceso a los entornos sandbox correspondientes a otras aplicaciones de Android.

  • [C-0-6] Los tiempos de ejecución alternativos NO DEBEN iniciarse, otorgarse ni otorgarse a otras aplicaciones ningún privilegio de superusuario (root) o de cualquier otra identificación de usuario.

  • [C-0-7] Cuando los archivos .apk de tiempos de ejecución alternativos se incluyen en la imagen del sistema de las implementaciones del dispositivo, DEBEN firmarse con una clave distinta de la clave utilizada para firmar otras aplicaciones incluidas con las implementaciones del dispositivo.

  • [C-0-8] Al instalar aplicaciones, los tiempos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android utilizados por la aplicación.

  • [C-0-9] Cuando una aplicación necesita hacer uso de un recurso del dispositivo para el cual existe un permiso de Android correspondiente (como cámara, GPS, etc.), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá para acceder a ese recurso.

  • [C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, el entorno de ejecución DEBE enumerar todos los permisos que posee el propio tiempo de ejecución al instalar cualquier aplicación que utilice ese tiempo de ejecución.

  • Los tiempos de ejecución alternativos DEBEN instalar aplicaciones a través de PackageManager en entornos aislados de Android separados (ID de usuario de Linux, etc.).

  • Los tiempos de ejecución alternativos PUEDEN proporcionar una única zona de pruebas de Android compartida por todas las aplicaciones que utilizan el tiempo de ejecución alternativo.

9.5. Soporte de múltiples usuarios

Android incluye soporte para múltiples usuarios y brinda soporte para el aislamiento completo de usuarios y la clonación de perfiles de usuario con aislamiento parcial (es decir, un único perfil de usuario adicional de tipo android.os.usertype.profile.CLONE ).

  • Las implementaciones de dispositivos PUEDEN, pero NO DEBEN, habilitar la función multiusuario si utilizan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones de dispositivos incluyen soporte para múltiples usuarios, estos:

  • [C-1-2] DEBE, para cada usuario, implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma Android como se define en el documento de referencia de Seguridad y Permisos en las API.
  • [C-1-3] Debe tener directorios de almacenamiento de aplicaciones compartidas separadas y aisladas (también conocido como /sdcard ) para cada instancia de usuario.
  • [C-1-4] debe garantizar que las aplicaciones propiedad de y en ejecución en nombre de un usuario dado no puedan enumerar, leer o escribir en los archivos propiedad de cualquier otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
  • [C-1-5] DEBE cifrar el contenido de la tarjeta SD cuando el modo multiusuario está habilitado usando una clave almacenada solo en medios no extraíbles a los que solo puede acceder el sistema si las implementaciones del dispositivo utilizan medios extraíbles para las API de almacenamiento externo. Como esto hará que los medios sean ilegibles para una PC host, se requerirá que las implementaciones del dispositivo cambien a MTP o un sistema similar para proporcionar a las PC host acceso a los datos del usuario actual.

Si las implementaciones de dispositivos incluyen soporte para múltiples usuarios, entonces para todos los usuarios, excepto los usuarios creados específicamente para ejecutar instancias duales de la misma aplicación, ellos:

  • [C-2-1] debe tener directorios de almacenamiento de aplicaciones compartidas (también conocidas como SDCARD) separadas y aisladas para cada instancia de usuario.
  • [C-2-2] DEBE garantizar que las aplicaciones que pertenecen a un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer o escribir en los archivos propiedad de cualquier otro usuario, incluso si los datos de ambos usuarios están almacenados en el mismo volumen. o sistema de archivos.

Las implementaciones de dispositivos pueden crear un único perfil de usuario adicional de type android.os.usertype.profile.CLONE contra el usuario primario (y solo contra el usuario primario) con el fin de ejecutar instancias duales de la misma aplicación. Estas instancias duales comparten almacenamiento parcialmente aislado, se presentan al usuario final en el iniciador al mismo tiempo y aparecen en la misma vista reciente. Por ejemplo, esto podría usarse para permitir que el usuario instale dos instancias separadas de una sola aplicación en un dispositivo con doble SIM.

Si las implementaciones de dispositivos crean el perfil de usuario adicional mencionado anteriormente, entonces:

  • [C-3-1] DEBE proporcionar acceso únicamente al almacenamiento o a los datos que ya sean accesibles para el perfil de usuario principal o que sean propiedad directa de este perfil de usuario adicional.
  • [C-3-2] NO DEBE tener esto como perfil de trabajo.
  • [C-3-3] DEBE tener directorios de datos de aplicaciones privadas aislados de la cuenta de usuario principal.
  • [C-3-4] NO DEBE permitir que se cree el perfil de usuario adicional si hay un Propietario del dispositivo aprovisionado (consulte la sección 3.9.1) ni permitir que se aprovisione un Propietario del dispositivo sin eliminar primero el perfil de usuario adicional.

9.6. Advertencia de SMS Premium

Android incluye soporte para los usuarios de advertencia de cualquier mensaje SMS premium saliente. Los mensajes SMS premium son mensajes de texto enviados a un servicio registrado con un operador que puede incurrir en un cargo al usuario.

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

  • [C-1-1] debe advertir a los usuarios antes de enviar un mensaje SMS a los números identificados por expresiones regulares definidas en /data/misc/sms/codes.xml archivo en el dispositivo. El proyecto de código abierto de Android Upstream proporciona una implementación que satisface este requisito.

9.7. Características de seguridad

Las implementaciones de dispositivos deben garantizar el cumplimiento de las características de seguridad tanto en el kernel como en la plataforma como se describe a continuación.

El Android Sandbox incluye características que utilizan el sistema de acceso de acceso obligatorio (Mac) mejorado con seguridad (SELinux), SECCOMP Sandboxing y otras características de seguridad en el kernel de Linux. Implementaciones de dispositivos:

  • [C-0-1] debe mantener la compatibilidad con las aplicaciones existentes, incluso cuando Selinux o cualquier otra característica de seguridad se implementan debajo del marco de Android.
  • [C-0-2] no debe tener una interfaz de usuario visible cuando una violación de seguridad sea detectada y bloqueada con éxito por la función de seguridad implementada por debajo del marco de Android, pero puede tener una interfaz de usuario visible cuando ocurre una violación de seguridad desbloqueada, lo que resulta en una exitosa explotar.
  • [C-0-3] no debe hacer que Selinux ni ninguna otra característica de seguridad implementada debajo del marco de Android configurable para el usuario o desarrollador de aplicaciones.
  • [C-0-4] no debe permitir que una aplicación que pueda afectar otra aplicación a través de una API (como una API de administración de dispositivos) para configurar una política que rompa la compatibilidad.
  • [C-0-5] debe dividir el marco de medios en múltiples procesos para que sea posible otorgar más estrechamente el acceso para cada proceso como se describe en el sitio del proyecto de código abierto de Android.
  • [C-0-6] debe implementar un mecanismo de sandboxing de aplicación de núcleo que permita el filtrado de llamadas del sistema utilizando una política configurable de programas multiproceso. El proyecto de código abierto de Android Upstream cumple con este requisito a través de habilitar el SECCOMP-BPF con la sincronización de Grupo Thread (TSYNC) como se describe en la sección Configuración del núcleo de Source.Android.com .

Las características de integridad del kernel y autoprotección son parte integral de la seguridad de Android. Implementaciones de dispositivos:

  • [C-0-7] debe implementar mecanismos de protección contra el desbordamiento del búfer de pila de núcleos. Ejemplos de tales mecanismos son CC_STACKPROTECTOR_REGULAR y CONFIG_CC_STACKPROTECTOR_STRONG .
  • [C-0-8] debe implementar estrictas protecciones de memoria del núcleo donde el código ejecutable es de solo lectura, los datos de solo lectura no son ejecutables y no escritos, y los datos de escritura no son ejecutables (por ejemplo, CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX ).
  • [C-0-9] debe implementar límites de tamaño de objeto estático y dinámico de la verificación de copias entre el espacio de usuario y el espacio del núcleo (por ejemplo, CONFIG_HARDENED_USERCOPY ) en dispositivos que se envían originalmente con el nivel API 28 o superior.
  • [C-0-10] no debe ejecutar la memoria del espacio de usuario al ejecutar en el modo kernel (por ejemplo, hardware PXN, o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN ) en dispositivos que se envían originalmente con API nivel 28 o superior.
  • [C-0-11] no debe leer ni escribir la memoria del espacio de usuario en el núcleo fuera de las API normales de acceso a la usercopy (por ejemplo, la bandeja de hardware, o emularse a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN ) en dispositivos que se envían originalmente con nivel API 28 o superior.
  • [C-0-12] debe implementar el aislamiento de la tabla de la página del núcleo si el hardware es vulnerable a CVE-2017-5754 en todos los dispositivos que se envían originalmente con el nivel API 28 o superior (por ejemplo, CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0 ).
  • [C-0-13] debe implementar el endurecimiento de la predicción de las ramas si el hardware es vulnerable a CVE-2017-5715 en todos los dispositivos que se envían originalmente con el nivel API 28 o superior (por ejemplo, CONFIG_HARDEN_BRANCH_PREDICTOR ).
  • [C-SR-1] Muy recomendable para mantener los datos del kernel que se escriben solo durante la inicialización marcada de solo lectura después de la inicialización (por ejemplo, __ro_after_init ).
  • [C-SR-2] se recomienda encarecidamente al azar el diseño del código y la memoria del núcleo, y para evitar exposiciones que comprometan la aleatorización (EG CONFIG_RANDOMIZE_BASE con la entropía de cargador de arranque a través del /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL ) .

  • [C-SR-3] se recomiendan encarecidamente que habilite la integridad del flujo de control (CFI) en el núcleo para proporcionar protección adicional contra los ataques de reutilización de código (por ejemplo CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK ).

  • [C-SR-4] se recomienda encarecidamente no deshabilitar la integridad del flujo de control (CFI), la pila de llamadas de sombra (SCS) o la desinflana de desbordamiento de entero (INTSAN) en los componentes que la tienen habilitado.

  • [C-SR-5] se recomienda encarecidamente habilitar CFI, SCS e INTSAN para cualquier componente adicional de espacio de usuario sensible a la seguridad como se explica en CFI e INTSAN .

  • [C-SR-6] se recomiendan encarecidamente para habilitar la inicialización de la pila en el núcleo para evitar usos de variables locales no inicializadas ( CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO ). Además, las implementaciones del dispositivo no deben asumir el valor utilizado por el compilador para inicializar a los locales.

  • [C-SR-7] se recomienda encarecidamente que habilite la inicialización del montón en el núcleo para evitar usos de asignaciones de montón no inicializadas ( CONFIG_INIT_ON_ALLOC_DEFAULT_ON ) y no deben asumir el valor utilizado por el núcleo para inicializar esas asignaciones.

Si las implementaciones de dispositivos usan un kernel de Linux que es capaz de admitir Selinux, ellos:

  • [C-1-1] debe implementar Selinux.
  • [C-1-2] debe establecer Selinux en el modo de ejecución global.
  • [C-1-3] Debe configurar todos los dominios en modo de ejecución. No se permiten dominios de modo permisivo, incluidos dominios específicos para un dispositivo/proveedor.
  • [C-1-4] no debe modificar, omitir ni reemplazar las reglas NeverLlow presentes dentro de la carpeta Sistema/Sepolicy proporcionada en el Proyecto de código abierto de Android (AOSP) ascendente y la política debe compilar con todas las reglas Neverlow presentes, para ambas AOSP, para ambas AOSP. Dominios Selinux, así como dominios específicos de dispositivos/proveedores.
  • [C-1-5] MUST run third-party applications targeting API level 28 or higher in per-application SELinux sandboxes with per-app SELinux restrictions on each application's private data directory.
  • SHOULD retain the default SELinux policy provided in the system/sepolicy folder of the upstream Android Open Source Project and only further add to this policy for their own device-specific configuration.

If device implementations use kernel other than Linux or Linux without SELinux, they:

  • [C-2-1] MUST use a mandatory access control system that is equivalent to SELinux.

If device implementations use I/O devices capable of DMA, they:

  • [C-SR-8] Are STRONGLY RECOMMENDED to isolate each I/O device capable of DMA, using an IOMMU (egthe ARM SMMU).

Android contains multiple defense-in-depth features that are integral to device security. In addition, Android focuses on reducing key classes of common bugs that contribute to poor quality and security.

In order to reduce memory bugs, device implementations:

  • [C-SR-9] Are STRONGLY RECOMMENDED to be tested using userspace memory error detection tools like MTE for ARMv9 devices, HWASan for ARMv8+ devices or ASan for other device types.
  • [C-SR-10] Are STRONGLY RECOMMENDED to be tested using kernel memory error detection tools like KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS for ARMv9 devices, CONFIG_KASAN_SW_TAGS for ARMv8 devices or CONFIG_KASAN_GENERIC for other device types).
  • [C-SR-11] Are STRONGLY RECOMMENDED to be using memory error detection tools in production like MTE, GWP-ASan and KFENCE.

If device implementations use an Arm TrustZone-based TEE, they:

  • [C-SR-12] Are STRONGLY RECOMMENDED to use a standard protocol for memory sharing, between Android and the TEE, like Arm Firmware Framework for Armv8-A (FF-A).
  • [C-SR-13] Are STRONGLY RECOMMENDED to restrict trusted applications to only accessing memory which has been explicitly shared with them via the above protocol. If the device has support for the Arm S-EL2 exception level, this should be enforced by the secure partition manager. Otherwise, this should be enforced by the TEE OS.

9.8. Privacidad

9.8.1. Historial de uso

Android stores the history of the user's choices and manages such history by UsageStatsManager .

Device implementations:

  • [C-0-1] MUST keep a reasonable retention period of such user history.
  • [C-SR-1] Are STRONGLY RECOMMENDED to keep the 14 days retention period as configured by default in the AOSP implementation.

Android stores the system events using the StatsLog identifiers, and manages such history via the StatsManager and the IncidentManager System API.

Device implementations:

  • [C-0-2] MUST only include the fields marked with DEST_AUTOMATIC in the incident report created by the System API class IncidentManager .
  • [C-0-3] MUST not use the system event identifiers to log any other event than what is described in the StatsLog SDK documents. If additional system events are logged, they MAY use a different atom identifier in the range between 100,000 and 200,000.

9.8.2. Grabación

Device implementations:

  • [C-0-1] MUST NOT preload or distribute software components out-of-box that send the user's private information (eg keystrokes, text displayed on the screen, bugreport) off the device without the user's consent or clear ongoing notifications.
  • [C-0-2] MUST display and obtain explicit user consent that includes exactly the same message as AOSP whenever screen casting or screen recording is enabled via MediaProjection or proprietary APIs. MUST NOT provide users an affordance to disable future display of the user consent.
  • [C-0-3] MUST have an ongoing notification to the user while screen casting or screen recording is enabled. AOSP meets this requirement by showing an ongoing notification icon in the status bar.

If device implementations include functionality in the system that either captures the contents displayed on the screen and/or records the audio stream played on the device other than via the System API ContentCaptureService , or other proprietary means described in Section 9.8.6 Content Capture , they :

  • [C-1-1] MUST have an ongoing notification to the user whenever this functionality is enabled and actively capturing/recording.

If device implementations include a component enabled out-of-box, capable of recording ambient audio and/or record the audio played on the device to infer useful information about user's context, they:

  • [C-2-1] MUST NOT store in persistent on-device storage or transmit off the device the recorded raw audio or any format that can be converted back into the original audio or a near facsimile, except with explicit user consent.

A “microphone indicator” refers to a view on screen, which is constantly visible to the user and cannot be obscured, which users understand as a microphone is in use(through unique text, color, icon, or some combination).

A “camera indicator” refers to a view on screen, which is constantly visible to the user and cannot be obscured, which users understand as a camera is in use (through unique text, color, icon, or some combination).

After the first one second displayed, an indicator can change visually, such as becoming smaller, and is not required to show as originally presented and understood.

The microphone indicator may be merged with an actively displayed camera indicator, provided that text, icons, or colors indicate to the user that microphone use has begun.

The camera indicator may be merged with an actively displayed microphone indicator, provided that text, icons, or colors indicate to the user that the camera use has begun.

Si las implementaciones de dispositivos declaran android.hardware.microphone ,:

  • [C-SR-1] Are STRONGLY RECOMMENDED to display microphone indicator when an app is accessing audio data from the microphone, but not when the microphone is only accessed by HotwordDetectionService , SOURCE_HOTWORD , ContentCaptureService , or app(s) holding the roles called out in Section 9.1 Permissions with CDD identifier [C-3-X]. .
  • [C-SR-2] Are STRONGLY RECOMMENDED to display the list of Recent and Active apps using microphone as returned from PermissionManager.getIndicatorAppOpUsageData() , along with any attribution messages associated with them.
  • [C-SR-3] Are STRONGLY RECOMMENDED to not hide the microphone indicator for system apps that have visible user interfaces or direct user interaction.

If device implementations declare android.hardware.camera.any , they:

  • [C-SR-4] Are STRONGLY RECOMMENDED to display camera indicator when an app is accessing live camera data, but not when the camera is only being accessed by app(s) holding the roles called out in Section 9.1 Permissions with CDD identifier [C-3-X].
  • [C-SR-5] Are STRONGLY RECOMMENDED to display Recent and Active apps using camera as returned from PermissionManager.getIndicatorAppOpUsageData() , along with any attribution messages associated with them.
  • [C-SR-6] Are STRONGLY RECOMMENDED to not hide the camera indicator for system apps that have visible user interfaces or direct user interaction.

9.8.3. Conectividad

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB,:

  • [C-1-1] MUST present a user interface asking for the user's consent before allowing access to the contents of the shared storage over the USB port.

9.8.4. Tráfico de red

Device implementations:

  • [C-0-1] MUST preinstall the same root certificates for the system-trusted Certificate Authority (CA) store as provided in the upstream Android Open Source Project.
  • [C-0-2] MUST ship with an empty user root CA store.
  • [C-0-3] MUST display a warning to the user indicating the network traffic may be monitored, when a user root CA is added.

If device traffic is routed through a VPN, device implementations:

  • [C-1-1] MUST display a warning to the user indicating either:
    • That network traffic may be monitored.
    • That network traffic is being routed through the specific VPN application providing the VPN.

If device implementations have a mechanism, enabled out-of-box by default, that routes network data traffic through a proxy server or VPN gateway (for example, preloading a VPN service with android.permission.CONTROL_VPN granted), they:

  • [C-2-1] MUST ask for the user's consent before enabling that mechanism, unless that VPN is enabled by the Device Policy Controller via the DevicePolicyManager.setAlwaysOnVpnPackage() , in which case the user does not need to provide a separate consent, but MUST only be notified.

If device implementations implement a user affordance to toggle on the "always-on VPN" function of a 3rd-party VPN app, they:

  • [C-3-1] MUST disable this user affordance for apps that do not support always-on VPN service in the AndroidManifest.xml file via setting the SERVICE_META_DATA_SUPPORTS_ALWAYS_ON attribute to false .

9.8.5. Identificadores de dispositivos

Device implementations:

  • [C-0-1] MUST prevent access to the device serial number and, where applicable, IMEI/MEID, SIM serial number, and International Mobile Subscriber Identity (IMSI) from an app, unless it meets one of the following requirements:
    • is a signed carrier app that is verified by device manufacturers.
    • has been granted the READ_PRIVILEGED_PHONE_STATE permission.
    • has carrier privileges as defined in UICC Carrier Privileges .
    • is a device owner or profile owner that has been granted the READ_PHONE_STATE permission.
    • (For SIM serial number/ICCID only) has the local regulations requirement that the app detect changes in the subscriber's identity.

Android, through the System API ContentCaptureService , AugmentedAutofillService , AppSearchGlobalManager.query , or by other proprietary means, supports a mechanism for device implementations to capture the following application data interactions between the applications and the user:

  • Text and graphics rendered on-screen, including but not limited to, notifications and assist data via AssistStructure API.
  • Media data, such as audio or video, recorded or played by the device.
  • Input events (eg key, mouse, gesture, voice, video, and accessibility).
  • Any other events that an application provides to the system via the Content Capture API or or AppSearchManager API a similarly capable Android and proprietary API.
  • Any text or other data sent via the TextClassifier API to the System TextClassifier ie to the system service to understand the meaning of text, as well as generating predicted next actions based on the text.
  • Data indexed by the platform AppSearch implementation, including but not limited to text, graphics, media data or other similar data.

If device implementations capture the data above, they:

  • [C-0-1] MUST encrypt all such data when stored in the device. This encryption MAY be carried out using Android File Based Encryption, or any of the ciphers listed as API version 26+ described in Cipher SDK .
  • [C-0-2] MUST NOT back up either raw or encrypted data using Android backup methods or any other back up methods.
  • [C-0-3] MUST only send all such data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
  • [C-0-4] MUST NOT associate such data with any user identity (such as Account ) on the device, except with explicit user consent each time the data is associated.
  • [C-0-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6 Content Capture), except with explicit user consent every time it is shared.
  • [C-0-6] MUST provide user affordance to erase such data that the ContentCaptureService or the proprietary means collects if the data is stored in any form on the device.
  • [C-0-7] MUST provide a user affordance to opt-out of the data, collected via AppSearch or proprietary means from being shown in android platform eg launcher.
  • [C-SR-1] Are STRONGLY RECOMMENDED NOT to request the INTERNET permission.
  • [C-SR-2] Are STRONGLY RECOMMENDED to only access the internet through structured APIs backed by publicly available open-source implementations.

If device implementations include a service that implements the System API ContentCaptureService , AppSearchManager.index , or any proprietary service that captures the data as described as above, they:

  • [C-1-1] MUST NOT allow users to replace the services with a user-installable application or service and MUST only allow the preinstalled services to capture such data.
  • [C-1-2] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data.
  • [C-1-3] MUST provide user affordance to disable the services.
  • [C-1-4] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow Android permissions model as described in Section 9.1. Permiso .
  • [C-SR-3] Are STRONGLY RECOMMENDED to keep the services separate from other system components(eg not binding the service or sharing process IDs) except for the following:

    • Telephony, Contacts, System UI, and Media

Android, through SpeechRecognizer#onDeviceSpeechRecognizer() provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.

9.8.7. Clipboard Access

Device implementations:

  • [C-0-1] MUST NOT return a clipped data on the clipboard (eg via the ClipboardManager API) unless the app is the default IME or is the app that currently has focus.

9.8.8. Ubicación

Location includes information in the Android Location class( such as Latitude, Longitude, Altitude), as well as identifiers that can be converted to Location. Location can be as fine as DGPS (Differential Global Positioning System) or as coarse as country level locations (like the country code location - MCC - Mobile Country Code).

The following is a list of location types that either directly derive a user's location or can be converted to a user's location. This is not a comprehensive list, but should be used as an example on what Location can directly or indirectly be derived from:

  • GPS/GNSS/DGPS/PPP
    • Global Positioning Solution or Global Navigation Satellite System or Differential Global Positioning Solution
    • This also includes Raw GNSS Measurements and GNSS Status
      • Fine Location can be derived from the Raw GNSS Measurements
  • Wireless Technologies with unique identifiers such as:
    • WiFi access points (MAC, BSSID, Name, or SSID)
    • Bluetooth/BLE (MAC, BSSID, Name, or SSID)
    • UWB (MAC, BSSID, Name, or SSID)
    • Cell Tower ID (3G, 4G, 5G… Iincluding all future Cellular Modem technologies that have unique identifiers)

As a primary point of reference, see the Android APIs which require ACCESS_FINE_Location or ACCESS_COARSE_Location permissions.

Device implementations:

  • [C-0-1] MUST NOT turn on/off device location setting and Wi-Fi/Bluetooth scanning settings without explicit user consent or user initiation.
  • [C-0-2] MUST provide the user affordance to access location related information including recent location requests, app level permissions and usage of Wi-Fi/Bluetooth scanning for determining location.
  • [C-0-3] MUST ensure that the application using Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] is a user initiated emergency session (eg dial 911 or text to 911). For Automotive however, a vehicle MAY initiate an emergency session without active user interaction in the case a crash/accident is detected (eg to satisfy eCall requirements).
  • [C-0-4] MUST preserve the Emergency Location Bypass API's ability to bypass device location settings without changing the settings.
  • [C-0-5] MUST schedule a notification that reminds the user after an app in the background has accessed their location using the [ ACCESS_BACKGROUND_LOCATION ] permission.

9.8.9. Aplicaciones instaladas

Android apps targeting API level 30 or above cannot see details about other installed apps by default (see Package visibility in the Android SDK documentation).

Device implementations:

  • [C-0-1] MUST NOT expose to any app targeting API level 30 or above details about any other installed app, unless the app is already able to see details about the other installed app through the managed APIs. This includes but is not limited to details exposed by any custom APIs added by the device implementer, or accessible via the filesystem.
  • [C-0-2] MUST NOT give to any app, read or write access to files in any other app's dedicated, app-specific directory within external storage. Las únicas excepciones son las siguientes:
    • The external storage provider authority (eg apps like DocumentsUI).
    • Download Provider which uses the “downloads” provider authority for downloading files to app storage.
    • Platform-signed media transfer protocol (MTP) apps which use the privileged permission ACCESS_MTP to enable transferring files to another device.
    • Apps which install other apps and have the permission INSTALL_PACKAGES can access only “obb” directories for the purpose of managing APK expansion files .

9.8.10. Connectivity Bug Report

If device implementations declare the android.hardware.telephony feature flag, they:

  • [C-1-1] MUST support generating connectivity bug reports via BUGREPORT_MODE_TELEPHONY with BugreportManager.
  • [C-1-2] MUST obtain user consent every time BUGREPORT_MODE_TELEPHONY is used to generate a report and MUST NOT prompt the user to consent to all future requests from the application.
  • [C-1-3] MUST NOT return the generated report to the requesting app without explicit user consent.
  • [C-1-4] Reports generated using BUGREPORT_MODE_TELEPHONY MUST contain at least the following information:
    • TelephonyDebugService dump
    • TelephonyRegistry dump
    • WifiService dump
    • ConnectivityService dump
    • A dump of the calling package's CarrierService instance (if bound)
    • Radio log buffer
  • [C-1-5] MUST NOT include the following in the generated reports:
    • Any kind of information that isn't directly related to connectivity debugging.
    • Any kind of user-installed application traffic logs or detailed profiles of user-installed applications/packages (UIDs are okay, package names are not).
  • MAY include additional information that is not associated with any user identity. (eg vendor logs).

If device implementations include additional information (eg vendor logs) in bug reports and that information has privacy/security/battery/storage/memory impact, they:

  • [C-SR-1] Are STRONGLY RECOMMENDED to have a developer setting defaulted to disabled. The AOSP reference implementation meets this by providing the Enable verbose vendor logging option in developer settings to include additional device-specific vendor logs in the bug reports.

9.8.11. Data blobs sharing

Android, through BlobStoreManager allows apps to contribute data blobs to the System to be shared with a selected set of apps.

If device implementations support shared data blobs as described in the SDK documentation , they:

9.8.12. Reconocimiento de música

Android, through the System API MusicRecognitionManager, supports a mechanism for device implementations to request music recognition, given an audio record, and delegate the music recognition to a privileged app implementing the MusicRecognitionService API.

If device implementations include a service that implements the System API MusicRecognitionManager or any proprietary service that streams audio data as described as above, they:

  • [C-1-1] MUST enforce that the caller of MusicRecognitionManager holds the MANAGE_MUSIC_RECOGNITION permission
  • [C-1-2] MUST enforce that a single, pre-installed, music recognition application implements MusicRecognitionService.
  • [C-1-3] MUST NOT allow users to replace the MusicRecognitionManagerService or MusicRecognitionService with a user-installable application or service.
  • [C-1-4] MUST ensure that when MusicRecognitionManagerService accesses the audio record and forwards it to the application implementing the MusicRecognitionService, the audio access is tracked via invocations of AppOpsManager.noteOp / startOp .

If device implementations of MusicRecognitionManagerService or MusicRecognitionService store any audio data captured, they:

  • [C-2-1] MUST NOT store any raw audio or audio fingerprints on disk at all, or in memory for longer than 14 days.
  • [C-2-2] MUST NOT share such data beyond the MusicRecognitionService, except with explicit user consent every time it is shared.

9.8.13. Administrador de privacidad del sensor

If device implementations provide the user a software affordance to turn off the camera and/or microphone input for the device implementation, they:

  • [C-1-1] MUST accurately return 'true' for the relevant supportsSensorToggle() API method.
  • [C-1-2] MUST, when an app tries to access a blocked microphone or camera, present the user with a non-dismissable user affordance that clearly indicates that the sensor is blocked and requires a choice to continue blocking or unblock as per the AOSP implementation which meets this requirement.
  • [C-1-3] MUST only pass blank (or fake) camera and audio data to apps and not report an error code due to the user not turning on the camera nor microphone via the user affordance presented per [C-1-2 ] arriba.

9.9. Cifrado de almacenamiento de datos

All devices MUST meet the requirements of section 9.9.1. Devices which launched on an API level earlier than that of this document are exempted from the requirements of sections 9.9.2 and 9.9.3; instead they MUST meet the requirements in section 9.9 of the Android Compatibility Definition document corresponding to the API level on which the device launched.

9.9.1. Direct Boot

Device implementations:

  • [C-0-1] MUST implement the Direct Boot mode APIs even if they do not support Storage Encryption.

  • [C-0-2] The ACTION_LOCKED_BOOT_COMPLETED and ACTION_USER_UNLOCKED Intents MUST still be broadcast to signal Direct Boot aware applications that Device Encrypted (DE) and Credential Encrypted (CE) storage locations are available for user.

9.9.2. Encryption requirements

Device implementations:

  • [C-0-1] MUST encrypt the application private data ( /data partition), as well as the application shared storage partition ( /sdcard partition) if it is a permanent, non-removable part of the device.
  • [C-0-2] MUST enable the data storage encryption by default at the time the user has completed the out-of-box setup experience.
  • [C-0-3] MUST meet the above data storage encryption requirement by implementing one of the following two encryption methods:

9.9.3. Métodos de cifrado

If device implementations are encrypted, they:

  • [C-1-1] MUST boot up without challenging the user for credentials and allow Direct Boot aware apps to access to the Device Encrypted (DE) storage after the ACTION_LOCKED_BOOT_COMPLETED message is broadcasted.
  • [C-1-2] MUST only allow access to Credential Encrypted (CE) storage after the user has unlocked the device by supplying their credentials (eg. passcode, pin, pattern or fingerprint) and the ACTION_USER_UNLOCKED message is broadcasted.
  • [C-1-13] MUST NOT offer any method to unlock the CE protected storage without either the user-supplied credentials, a registered escrow key or a resume on reboot implementation meeting the requirements in section 9.9.4 .
  • [C-1-4] MUST use Verified Boot.
9.9.3.1. File Based Encryption with Metadata Encryption

If device implementations use File Based Encryption with Metadata Encryption, they:

  • [C-1-5] MUST encrypt file contents and filesystem metadata using AES-256-XTS or Adiantum. AES-256-XTS refers to the Advanced Encryption Standard with a 256-bit cipher key length, operated in XTS mode; the full length of the key is 512 bits. Adiantum refers to Adiantum-XChaCha12-AES, as specified at https://github.com/google/adiantum. Filesystem metadata is data such as file sizes, ownership, modes, and extended attributes (xattrs).
  • [C-1-6] MUST encrypt file names using AES-256-CBC-CTS or Adiantum.
  • [C-1-12] If the device has Advanced Encryption Standard (AES) instructions (such as ARMv8 Cryptography Extensions on ARM-based devices, or AES-NI on x86-based devices) then the AES-based options above for file name, file contents, and filesystem metadata encryption MUST be used, not Adiantum.
  • [C-1-13] MUST use a cryptographically strong and non-reversible key derivation function (eg HKDF-SHA512) to derive any needed subkeys (eg per-file keys) from the CE and DE keys. "Cryptographically strong and non-reversible" means that the key derivation function has a security strength of at least 256 bits and behaves as a pseudorandom function family over its inputs.
  • [C-1-14] MUST NOT use the same File Based Encryption (FBE) keys or subkeys for different cryptographic purposes (eg for both encryption and key derivation, or for two different encryption algorithms).
  • [C-1-15] MUST ensure that all non-deleted blocks of encrypted file contents on persistent storage were encrypted using combinations of encryption key and initialization vector (IV) that depend on both the file and the offset within the file. In addition, all such combinations MUST be distinct, except where the encryption is done using inline encryption hardware that only supports an IV length of 32 bits.
  • [C-1-16] MUST ensure that all non-deleted encrypted filenames on persistent storage in distinct directories were encrypted using distinct combinations of encryption key and initialization vector (IV).
  • [C-1-17] MUST ensure that all encrypted filesystem metadata blocks on persistent storage were encrypted using distinct combinations of encryption key and initialization vector (IV).

  • Keys protecting CE and DE storage areas and filesystem metadata:

    • [C-1-7] MUST be cryptographically bound to a hardware-backed Keystore. This keystore MUST be bound to Verified Boot and the device's hardware root of trust.
    • [C-1-8] CE keys MUST be bound to a user's lock screen credentials.
    • [C-1-9] CE keys MUST be bound to a default passcode when the user has not specified lock screen credentials.
    • [C-1-10] MUST be unique and distinct, in other words no user's CE or DE key matches any other user's CE or DE keys.
    • [C-1-11] MUST use the mandatorily supported ciphers, key lengths and modes.
    • [C-1-12] MUST be securely erased during bootloader unlock and lock as described here .
  • SHOULD make preinstalled essential apps (eg Alarm, Phone, Messenger) Direct Boot aware.

The upstream Android Open Source project provides a preferred implementation of File Based Encryption based on the Linux kernel "fscrypt" encryption feature, and of Metadata Encryption based on the Linux kernel "dm-default-key" feature.

9.9.3.2. Per-User Block-Level Encryption

If device implementations use per-user block-level encryption, they:

  • [C-1-1] MUST enable multi-user support as described in section 9.5.
  • [C-1-2] MUST provide per-user partitions, either using raw partitions or logical volumes.
  • [C-1-3] MUST use unique and distinct encryption keys per-user for encryption of the underlying block devices.
  • [C-1-4] MUST use AES-256-XTS for block-level encryption of the user partitions.

  • The keys protecting the per-user block-level encrypted devices:

    • [C-1-5] MUST be cryptographically bound to a hardware-backed Keystore. This keystore MUST be bound to Verified Boot and the device's hardware root of trust.
    • [C-1-6] MUST be bound to the corresponding user's lock screen credentials.

Per-user block-level encryption can be implemented using the Linux kernel "dm-crypt" feature over per-user partitions.

9.9.4. Reanudar al reiniciar

Resume on Reboot allows unlocking the CE storage of all apps, including those that do not yet support Direct Boot, after a reboot initiated by an OTA. This feature enables users to receive notifications from installed apps after the reboot.

An implementation of Resume-on-Reboot must continue to ensure that when a device falls into an attacker's hands, it is extremely difficult for that attacker to recover the user's CE-encrypted data, even if the device is powered on, CE storage is unlocked, and the user has unlocked the device after receiving an OTA. For insider attack resistance, we also assume the attacker gains access to broadcast cryptographic signing keys.

Específicamente:

  • [C-0-1] CE storage MUST NOT be readable even for the attacker who physically has the device and then has these capabilities and limitations:

    • Can use the signing key of any vendor or company to sign arbitrary messages.
    • Can cause an OTA to be received by the device.
    • Can modify the operation of any hardware (AP, flash etc) except as detailed below, but such modification involves a delay of at least an hour and a power cycle that destroys RAM contents.
    • Cannot modify the operation of tamper-resistant hardware (eg Titan M).
    • Cannot read the RAM of the live device.
    • Cannot obtain the user's credential (PIN, pattern, password) or otherwise cause it to be entered.

By way of example, a device implementation that implements and complies with all of the descriptions found here will be compliant with [C-0-1].

9.10. Integridad del dispositivo

The following requirements ensure there is transparency to the status of the device integrity. Device implementations:

  • [C-0-1] MUST correctly report through the System API method PersistentDataBlockManager.getFlashLockState() whether their bootloader state permits flashing of the system image.

  • [C-0-2] MUST support Verified Boot for device integrity.

If device implementations are already launched without supporting Verified Boot on an earlier version of Android and can not add support for this feature with a system software update, they MAY be exempted from the requirement.

Verified Boot is a feature that guarantees the integrity of the device software. If device implementations support the feature, they:

  • [C-1-1] MUST declare the platform feature flag android.software.verified_boot .
  • [C-1-2] MUST perform verification on every boot sequence.
  • [C-1-3] MUST start verification from an immutable hardware key that is the root of trust and go all the way up to the system partition.
  • [C-1-4] MUST implement each stage of verification to check the integrity and authenticity of all the bytes in the next stage before executing the code in the next stage.
  • [C-1-5] MUST use verification algorithms as strong as current recommendations from NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048).
  • [C-1-6] MUST NOT allow boot to complete when system verification fails, unless the user consents to attempt booting anyway, in which case the data from any non-verified storage blocks MUST not be used.
  • [C-1-7] MUST NOT allow verified partitions on the device to be modified unless the user has explicitly unlocked the bootloader.
  • [C-SR-1] If there are multiple discrete chips in the device (eg radio, specialized image processor), the boot process of each of those chips is STRONGLY RECOMMENDED to verify every stage upon booting.
  • [C-1-8] MUST use tamper-evident storage: for storing whether the bootloader is unlocked. Tamper-evident storage means that the bootloader can detect if the storage has been tampered with from inside Android.
  • [C-1-9] MUST prompt the user, while using the device, and require physical confirmation before allowing a transition from bootloader locked mode to bootloader unlocked mode.
  • [C-1-10] MUST implement rollback protection for partitions used by Android (eg boot, system partitions) and use tamper-evident storage for storing the metadata used for determining the minimum allowable OS version.
  • [C-1-11] MUST securely erase all user data during bootloader unlock and lock, as per '9.12. Data Deletion' (including the userdata partition and any NVRAM spaces).
  • [C-SR-2] Are STRONGLY RECOMMENDED to verify all privileged app APK files with a chain of trust rooted in partitions protected by Verified Boot.
  • [C-SR-3] Are STRONGLY RECOMMENDED to verify any executable artifacts loaded by a privileged app from outside its APK file (such as dynamically loaded code or compiled code) before executing them or STRONGLY RECOMMENDED not to execute them at all.
  • SHOULD implement rollback protection for any component with persistent firmware (eg modem, camera) and SHOULD use tamper-evident storage for storing the metadata used for determining the minimum allowable version.

If device implementations are already launched without supporting C-1-8 through C-1-11 on an earlier version of Android and can not add support for these requirements with a system software update, they MAY be exempted from the requirements.

The upstream Android Open Source Project provides a preferred implementation of this feature in the external/avb/ repository, which can be integrated into the bootloader used for loading Android.

Device implementations:

  • [C-0-3] MUST support cryptographically verifying file content against a trusted key without reading the whole file.
  • [C-0-4] MUST NOT allow the read requests on a protected file to succeed when the read content do not verify against a trusted key.

If device implementations are already launched without the ability to verify file content against a trusted key on an earlier Android version and can not add support for this feature with a system software update, they MAY be exempted from the requirement. The upstream Android Open Source project provides a preferred implementation of this feature based on the Linux kernel fs-verity feature.

Device implementations:

If device implementations support the Android Protected Confirmation API they:

  • [C-3-1] MUST report true for the ConfirmationPrompt.isSupported() API.

  • [C-3-2] MUST ensure that code running in the Android OS including its kernel, malicious or otherwise, cannot generate a positive response without user interaction.

  • [C-3-3] MUST ensure that the user has been able to review and approve the prompted message even in the event that the Android OS, including its kernel, is compromised.

9.11. Claves y Credenciales

The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:

  • [C-0-1] MUST allow at least 8,192 keys to be imported or generated.
  • [C-0-2] The lock screen authentication MUST implement a time interval between failed attempts. With n as the failed attempt count, the time interval MUST be at least 30 seconds for 9 < n < 30. For n > 29, the time interval value MUST be at least 30*2^floor((n-30)/10)) seconds or at least 24 hours, whichever is smaller.
  • SHOULD not limit the number of keys that can be generated

When the device implementation supports a secure lock screen, it:

  • [C-1-1] MUST back up the keystore implementation with an isolated execution environment.
  • [C-1-2] MUST have implementations of RSA, AES, ECDSA and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante el uso de la implementación Trusty , pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor son opciones alternativas.
  • [C-1-3] MUST perform the lock screen authentication in the isolated execution environment and allow the authentication-bound keys to be used only after successful authentication. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. The upstream Android Open Source Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can be used to satisfy this requirement.
  • [C-1-4] MUST support key attestation where the attestation signing key is protected by secure hardware and signing is performed in secure hardware. The attestation signing keys MUST be shared across large enough number of devices to prevent the keys from being used as device identifiers. Una forma de cumplir este requisito es compartir la misma clave de certificación a menos que se produzcan al menos 100.000 unidades de un SKU determinado. Si se producen más de 100.000 unidades de un SKU, SE PUEDE utilizar una clave diferente por cada 100.000 unidades.

Tenga en cuenta que si la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la atestación de claves, a menos que declare la característica android.hardware.fingerprint que requiere un almacén de claves respaldado por un entorno de ejecución aislado.

  • [C-1-5] MUST allow the user to choose the Sleep timeout for transition from the unlocked to the locked state, with a minimum allowable timeout up to 15 seconds. Automotive devices, that lock the screen whenever the head unit is turned off or the user is switched, MAY NOT have the Sleep timeout configuration.
  • [C-1-6] MUST support IKeymasterDevice 4.0, IKeymasterDevice 4.1 or IKeyMintDevice version 1.
  • [C-SR-1] Is STRONGLY RECOMMENDED to support IKeyMintDevice version 1.

9.11.1. Secure Lock Screen and Authentication

The AOSP implementation follows a tiered authentication model where a knowledge-factory based primary authentication can be backed by either a secondary strong biometric, or by weaker tertiary modalities.

Device implementations:

  • [C-SR-1] Are STRONGLY RECOMMENDED to set only one of the following as the primary authentication method:
    • A numerical PIN
    • An alphanumerical password
    • A swipe pattern on a grid of exactly 3x3 dots

Note that the above authentication methods are referred as the recommended primary authentication methods in this document.

If device implementations add or modify the recommended primary authentication methods and use a new authentication method as a secure way to lock the screen, the new authentication method:

If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen:

  • [C-3-1] The entropy of the shortest allowed length of inputs MUST be greater than 10 bits.
  • [C-3-2] The maximum entropy of all possible inputs MUST be greater than 18 bits.
  • [C-3-3] The new authentication method MUST NOT replace any of the recommended primary authentication methods (ie PIN, pattern, password) implemented and provided in AOSP.
  • [C-3-4] The new authentication method MUST be disabled when the Device Policy Controller (DPC) application has set the password requirements policy via the DevicePolicyManager.setRequiredPasswordComplexity() with a more restrictive complexity constant than PASSWORD_COMPLEXITY_NONE or via the DevicePolicyManager.setPasswordQuality() method with a more restrictive constant than PASSWORD_QUALITY_BIOMETRIC_WEAK .
  • [C-3-5] New authentication methods MUST either fall back to the recommended primary authentication methods (ie PIN, pattern, password) once every 72 hours or less OR clearly disclose to the user that some data will not be backed up in order to preserve the privacy of their data.

If device implementations add or modify the recommended primary authentication methods to unlock the lock screen and use a new authentication method that is based on biometrics to be treated as a secure way to lock the screen, the new method:

  • [C-4-1] MUST meet all requirements described in section 7.3.10 for Class 1 (formerly Convenience ).
  • [C-4-2] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.
  • [C-4-3] MUST be disabled and only allow the recommended primary authentication to unlock the screen when the Device Policy Controller (DPC) application has set the keyguard feature policy by calling the method DevicePolicyManager.setKeyguardDisabledFeatures() ) , with any of the associated biometric flags (ie KEYGUARD_DISABLE_BIOMETRICS , KEYGUARD_DISABLE_FINGERPRINT , KEYGUARD_DISABLE_FACE , or KEYGUARD_DISABLE_IRIS ).

If the biometric authentication methods do not meet the requirements for Class 3 (formerly Strong ) as described in section 7.3.10 :

  • [C-5-1] The methods MUST be disabled if the Device Policy Controller (DPC) application has set the password requirements quality policy via the DevicePolicyManager.setRequiredPasswordComplexity() with a more restrictive complexity bucket than PASSWORD_COMPLEXITY_LOW or using DevicePolicyManager.setPasswordQuality() method with a more restrictive quality constant than PASSWORD_QUALITY_BIOMETRIC_WEAK .
  • [C-5-2] The user MUST be challenged for the recommended primary authentication (eg: PIN, pattern, password) as described in [C-1-7] and [C-1-8] in section 7.3.10 .
  • [C-5-3] The methods MUST NOT be treated as a secure lock screen, and MUST meet the requirements that start with C-8 in this section below.

If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

  • [C-6-1] They MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret and meet the requirements to be treated as a secure lock screen.
  • [C-6-2] The new method MUST be disabled and only allow one of the recommended primary authentication methods to unlock the screen when the Device Policy Controller (DPC) application has set the policy with either:
  • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less.
  • [C-6-4] The new method MUST NOT be treated as a secure lock screen and MUST follow the constraints listed in C-8 below.

If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService System API, they:

  • [C-7-1] MUST have clear indication in the settings menu and on the lock screen when device lock is deferred or can be unlocked by trust agent(s). For example, AOSP meets this requirement by showing a text description for the "Automatically lock setting" and "Power button instantly locks" in the settings menu and a distinguishable icon on the lock screen.
  • [C-7-2] MUST respect and fully implement all trust agent APIs in the DevicePolicyManager class, such as the KEYGUARD_DISABLE_TRUST_AGENTS constant.
  • [C-7-3] MUST NOT fully implement the TrustAgentService.addEscrowToken() function on a device that is used as a primary personal device (eg handheld) but MAY fully implement the function on device implementations that are typically shared (eg Android Television or Automotive device).
  • [C-7-4] MUST encrypt all stored tokens added by TrustAgentService.addEscrowToken() .
  • [C-7-5] MUST NOT store the encryption key or escrow token on the same device where the key is used. For example, it is allowed for a key stored on a phone to unlock a user account on a TV. For Automotive devices, it is not allowed for the escrow token to be stored on any part of the vehicle.
  • [C-7-6] MUST inform the user about the security implications before enabling the escrow token to decrypt the data storage.
  • [C-7-7] MUST have a fall-back mechanism to use one of the recommended primary authentication methods.
  • [C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of inquietud.
  • [C-7-9] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods as described in [C-1-7] and [C-1-8] in section 7.3.10 , unless the safety of the user (eg driver distraction) is of concern.
  • [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the constraints listed in C-8 below.
  • [C-7-11] MUST NOT allow TrustAgents on primary personal devices (eg: handheld) to unlock the device, and can only use them to keep an already unlocked device in the unlocked state for up to a maximum of 4 hours. The default implementation of TrustManagerService in AOSP meets this requirement.
  • [C-7-12] MUST use a cryptographically secure (eg UKEY2) communication channel to pass the escrow token from the storage device to the target device.

If device implementations add or modify the authentication methods to unlock the lock screen that is not a secure lock screen as described above, and use a new authentication method to unlock the keyguard:

If device implementations support separate display power states through DeviceStateManager AND support separate display lock states through KeyguardDisplayManager , they:

  • [C-SR-2] Are STRONGLY RECOMMENDED to utilize a credential meeting requirements defined in section 9.11.1 or a Biometric meeting at least Class 1 specifications defined in section 7.3.10 to allow independent unlocking from the default device display.
  • [C-SR-3] Are STRONGLY RECOMMENDED to constrain separate display unlock via a defined display timeout.
  • [C-SR-4] Are STRONGLY RECOMMENDED to allow user to globally lock all displays through lockdown from primary handheld device.

9.11.2. Caja fuerte

The Android Keystore System allows app developers to store cryptographic keys in a dedicated secure processor as well as the isolated execution environment described above. Such a dedicated secure processor is called "StrongBox". Requirements C-1-3 through C-1-11 below define the requirements a device must meet to qualify as a StrongBox.

Device implementations that have a dedicated secure processor:

  • [C-SR-1] Are STRONGLY RECOMMENDED to support StrongBox. StrongBox will likely become a requirement in a future release.

If device implementations support StrongBox, they:

  • [C-1-1] MUST declare FEATURE_STRONGBOX_KEYSTORE .

  • [C-1-2] MUST provide dedicated secure hardware that is used to back keystore and secure user authentication. The dedicated secure hardware may be used for other purposes as well.

  • [C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors or other core resources with the application processor (AP).

  • [C-1-4] MUST ensure that any peripherals shared with the AP cannot alter StrongBox processing in any way, or obtain any information from the StrongBox. The AP MAY disable or block access to StrongBox.

  • [C-1-5] MUST have an internal clock with reasonable accuracy (+-10%) that is immune to manipulation by the AP.

  • [C-1-6] MUST have a true random number generator that produces uniformly-distributed and unpredictable output.

  • [C-1-7] MUST have tamper resistance, including resistance against physical penetration, and glitching.

  • [C-1-8] MUST have side-channel resistance, including resistance against leaking information via power, timing, electromagnetic radiation, and thermal radiation side channels.

  • [C-1-9] MUST have secure storage which ensures confidentiality, integrity, authenticity, consistency, and freshness of the contents. The storage MUST NOT be able to be read or altered, except as permitted by the StrongBox APIs.

  • To validate compliance with [C-1-3] through [C-1-9], device implementations:

    • [C-1-10] MUST include the hardware that is certified against the Secure IC Protection Profile BSI-CC-PP-0084-2014 or evaluated by a nationally accredited testing laboratory incorporating High attack potential vulnerability assessment according to the Common Criteria Application of Attack Potential to Smartcards .
    • [C-1-11] MUST include the firmware that is evaluated by a nationally accredited testing laboratory incorporating High attack potential vulnerability assessment according to the Common Criteria Application of Attack Potential to Smartcards .
    • [C-SR-2] Are STRONGLY RECOMMENDED to include the hardware that is evaluated using a Security Target, Evaluation Assurance Level (EAL) 5, augmented by AVA_VAN.5. EAL 5 certification will likely become a requirement in a future release.
  • [C-SR-3] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL.

9.11.3. Credencial de identidad

The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

  • [C-SR-1] are STRONGLY RECOMMENDED to implement the Identity Credential System.

If device implementations implement the Identity Credential System, they:

  • [C-1-1] MUST return non-null for the IdentityCredentialStore#getInstance() method.

  • [C-1-2] MUST implement the Identity Credential System (eg the android.security.identity.* APIs) with code communicating with a trusted application in an area that is securely isolated from the code running on the kernel and above. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales mediante los cuales el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido DMA.

  • [C-1-3] The cryptographic operations needed to implement the Identity Credential System (eg the android.security.identity.* APIs) MUST be performed entirely in the trusted application and private key material MUST never leave the isolated execution environment unless specifically required by higher-level APIs (eg the createEphemeralKeyPair() method).

  • [C-1-4] The trusted application MUST be implemented in a way such that its security properties are not affected (eg credential data is not released unless access control conditions are satisfied, MACs can't be produced for arbitrary data) even if Android is misbehaving or compromised.

9.12. Eliminación de datos

All device implementations:

  • [C-0-1] MUST provide users a mechanism to perform a "Factory Data Reset".
  • [C-0-2] MUST delete all data on the userdata filesystem when performing a "Factory Data Reset".
  • [C-0-3] MUST delete the data in such a way that will satisfy relevant industry standards such as NIST SP800-88 when performing a "Factory Data Reset".
  • [C-0-4] MUST trigger the above "Factory Data Reset" process when the DevicePolicyManager.wipeData() API is called by the primary user's Device Policy Controller app.
  • MAY provide a fast data wipe option that conducts only a logical data erase.

9.13. Modo de arranque seguro

Android provides Safe Boot Mode, which allows users to boot up into a mode where only preinstalled system apps are allowed to run and all third-party apps are disabled. This mode, known as "Safe Boot Mode", provides the user the capability to uninstall potentially harmful third-party apps.

Device implementations are:

  • [C-SR-1] STRONGLY RECOMMENDED to implement Safe Boot Mode.

If device implementations implement Safe Boot Mode, they:

  • [C-1-1] MUST provide the user an option to enter Safe Boot Mode in such a way that is uninterruptible from third-party apps installed on the device, except when the third-party app is a Device Policy Controller and has set the UserManager.DISALLOW_SAFE_BOOT flag as true.

  • [C-1-2] MUST provide the user the capability to uninstall any third-party apps within Safe Mode.

  • SHOULD provide the user an option to enter Safe Boot Mode from the boot menu using a workflow that is different from that of a normal boot.

9.14. Aislamiento del sistema de vehículos automotrices

Android Automotive devices are expected to exchange data with critical vehicle subsystems by using the vehicle HAL to send and receive messages over vehicle networks such as CAN bus.

The data exchange can be secured by implementing security features below the Android framework layers to prevent malicious or unintentional interaction with these subsystems.

9.15. Planes de suscripción

"Subscription plans" refer to the billing relationship plan details provided by a mobile carrier through SubscriptionManager.setSubscriptionPlans() .

All device implementations:

  • [C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
  • [C-0-2] MUST NOT remotely back up or upload subscription plans.
  • [C-0-3] MUST only allow overrides, such as SubscriptionManager.setSubscriptionOverrideCongested() , from the mobile carrier app currently providing valid subscription plans.

9.16. Migración de datos de aplicaciones

If device implementations include a capability to migrate data from a device to another device and do not limit the application data it copies to what is configured by the application developer in the manifest via android:fullBackupContent attribute, they:

  • [C-1-1] MUST NOT initiate transfers of application data from devices on which the user has not set a primary authentication as described in 9.11.1 Secure Lock Screen and Authentication .
  • [C-1-2] MUST securely confirm the primary authentication on the source device and confirm with the user intent to copy the data on the source device before any data is transferred.
  • [C-1-3] MUST use security key attestation to ensure that both the source device and the target device in the device-to-device migration are legitimate Android devices and have a locked bootloader.
  • [C-1-4] MUST only migrate application data to the same application on the target device, with the same package name AND signing certificate.
  • [C-1-5] MUST show an indication that the source device has had data migrated by a device-to-device data migration in the settings menu. A user SHOULD NOT be able to remove this indication.

10. Pruebas de compatibilidad de software

Device implementations MUST pass all tests described in this section. However, note that no software test package is fully comprehensive. For this reason, device implementers are STRONGLY RECOMMENDED to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Conjunto de pruebas de compatibilidad

Device implementations:

  • [C-0-1] MUST pass the Android Compatibility Test Suite (CTS) available from the Android Open Source Project, using the final shipping software on the device.

  • [C-0-2] MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 12.

Device implementations:

  • [C-0-3] MUST pass the latest CTS version available at the time the device software is completed.

  • SHOULD use the reference implementation in the Android Open Source tree as much as possible.

10.2. Verificador CTS

The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

Device implementations:

  • [C-0-1] MUST correctly execute all applicable cases in the CTS verifier.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional.

Device implementations:

  • [C-0-2] MUST pass all tests for hardware that they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier.

Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

  • [C-0-2] Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

11. Software actualizable

  • [C-0-1] Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform “live” upgrades—that is, a device restart MAY be required. Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

    • “Over-the-air (OTA)” downloads with offline update via reboot.
    • “Tethered” updates over USB from a host PC.
    • “Offline” updates via a reboot and update from a file on removable storage.
  • [C-0-2] The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

  • [C-0-3] The entire update MUST be signed and the on-device update mechanism MUST verify the update and signature against a public key stored on device.

  • [C-SR-1] The signing mechanism is STRONGLY RECOMMENDED to hash the update with SHA-256 and validate the hash against the public key using ECDSA NIST P-256.

If the device implementations includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, then, they:

  • [C-1-1] MUST support OTA downloads with offline update via reboot.

Device implementations SHOULD verify that the system image is binary identical to the expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.1, satisfies this requirement.

Also, device implementations SHOULD support A/B system updates . The AOSP implements this feature using the boot control HAL.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, then:

  • [C-2-1] The device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

Android includes features that allow the Device Owner app (if present) to control the installation of system updates. If the system update subsystem for devices report android.software.device_admin then, they:

12. Registro de cambios del documento

For a summary of changes to the Compatibility Definition in this release:

For a summary of changes to individuals sections:

  1. Introducción
  2. Tipos de dispositivos
  3. Software
  4. Empaquetamiento de aplicaciones
  5. Multimedia
  6. Developer Tools and Options
  7. Compatibilidad de hardware
  8. Rendimiento y potencia
  9. Modelo de seguridad
  10. Software Compatibility Testing
  11. Software actualizable
  12. Document Changelog
  13. Contáctenos

12.1. Changelog Viewing Tips

Changes are marked as follows:

  • CDD
    Substantive changes to the compatibility requirements.

  • Documentos
    Cosmetic or build related changes.

For best viewing, append the pretty=full and no-merges URL parameters to your changelog URLs.

13. Contáctenos

You can join the android-compatibility forum and ask for clarifications or bring up any issues that you think the document does not cover.