1. Introducción
En este documento, se enumeran los requisitos que deben cumplirse para que los dispositivos sean compatibles con Android 14.
El uso de los términos "DEBER", "NO DEBER", "REQUERIDO", "DEBEN", "NO DEBEN", "DEBEN", "NO DEBEN", "RECOMENDADO", "PUEDEN" y "OPCIONAL" se realiza de acuerdo con el estándar de IETF definido en la RFC2119.
En el uso que se hace de este documento, un "implementador de dispositivos" o "implementador" es una persona o una organización que desarrolla una solución de hardware o software que ejecuta Android 14. Una “implementación de dispositivos” o “implementación” es la solución de hardware y software que se desarrolló.
Para que se consideren compatibles con Android 14, las implementaciones del dispositivo DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos que se incorporan como referencia.
Cuando esta definición o las pruebas de software que se describen en la sección 10 no se mencionan, son ambiguas o están incompletas, es responsabilidad del implementador del dispositivo garantizar la compatibilidad con las implementaciones existentes.
Por este motivo, el Proyecto de código abierto de Android es la implementación de referencia y preferida de Android. Se RECOMIENDA ENFATICAMENTE a los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente "upstream" disponible en el Proyecto de código abierto de Android. Si bien, hipotéticamente, algunos componentes se pueden reemplazar con implementaciones alternativas, se RECOMIENDA NO seguir esta práctica, ya que aprobar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento total con la implementación estándar de Android, incluido el conjunto de pruebas de compatibilidad y más allá de este. Por último, ten en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.
Muchos de los recursos a los que se hace referencia en este documento se derivan directa o indirectamente del SDK de Android y serán funcionalmente idénticos a la información de 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 coincidan con la documentación del SDK, la documentación del SDK se considerará oficial. Cualquier detalle técnico que se proporcione en los recursos vinculados a lo largo de este documento se considera 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 se dedica a un tipo de dispositivo específico.
Todos los demás requisitos, que se aplican de forma universal a cualquier implementación de dispositivos Android, se enumeran en las secciones posteriores a la Sección 2. En este documento, se hace referencia a estos requisitos como "Requisitos principales".
1.1.2. ID del requisito
El ID de requisito se asigna para los requisitos OBLIGATORIOS.
- El ID se asigna solo para los requisitos OBLIGATORIOS.
- Los requisitos ALTAMENTE RECOMENDADOS se marcan como [SR], pero no se les asigna un ID.
- El ID consta de lo siguiente : ID de tipo de dispositivo, ID de condición y ID de requisito (p.ej., C-0-1).
Cada ID se define de la siguiente manera:
- ID de tipo de dispositivo (obtén más información en 2. Tipos de dispositivos).
- C: Núcleo (requisitos que se aplican a todas las implementaciones de dispositivos Android)
- H: Dispositivo de mano Android
- T: Dispositivo Android Television
- A: Implementación de Android Automotive
- W: Implementación de Android Watch
- Pestaña: Implementación de tablets Android
- ID de la condición
- Cuando el requisito es incondicional, este ID se establece como 0.
- Cuando el requisito es condicional, se asigna 1 para la 1ª condición y el número aumenta en 1 dentro de la misma sección y el mismo tipo de dispositivo.
- ID del requisito
- Este ID comienza en 1 y aumenta de a 1 dentro de la misma sección y la misma condición.
1.1.3. ID del requisito en la sección 2
Los IDs de requisitos de la Sección 2 tienen dos partes. El primero corresponde a un ID de sección, como se describió anteriormente. La segunda parte identifica el factor de forma y el requisito específico del factor de forma.
de la sección seguido del ID de requisito que se describió anteriormente.
- El ID de la Sección 2 consta de lo siguiente: ID de la sección / ID de tipo de dispositivo - ID de condición - ID de requisito (p.ej., 7.4.3/A-0-1).
2. Tipos de dispositivos
El Proyecto de código abierto de Android proporciona una pila de software que se puede usar para una variedad de tipos de dispositivos y factores de forma. Para admitir la seguridad en los dispositivos, se espera que la pila de software, incluido cualquier SO de reemplazo o una implementación de kernel alternativo, se ejecute en un entorno seguro, como se describe en el artículo 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.
En esta sección, se describen esos tipos de dispositivos, así como los requisitos y las recomendaciones adicionales aplicables a cada uno.
Todas las implementaciones de dispositivos Android que no se ajusten a ninguno de los tipos de dispositivos descritos DEBEN cumplir con todos los requisitos de las otras secciones de esta definición de compatibilidad.
2.1 Configuraciones de dispositivos
Para conocer las principales diferencias en la configuración de hardware por tipo de dispositivo, consulta los requisitos específicos de cada dispositivo que se indican a continuación en esta sección.
2.2. Requisitos de dispositivos portátiles
Un dispositivo portátil Android hace referencia a una implementación de dispositivo Android que, por lo general, se usa sosteniéndolo en la mano, como un reproductor de mp3, un teléfono o una tablet.
Las implementaciones de dispositivos Android se clasifican como dispositivos de mano si cumplen con todos los criterios a continuación:
- Tener una fuente de alimentación que proporcione movilidad, como una batería
- Tener un tamaño de pantalla diagonal físico de entre 4 pulgadas
3.3 pulgadas (o 2.5 pulgadas para implementaciones de dispositivos que se enviaron en el nivel de API 29 o versiones anteriores)y 8 pulgadas - Tener una interfaz de entrada de pantalla táctil
Los requisitos adicionales que se mencionan en el resto de esta sección son específicos de las implementaciones de dispositivos de mano para Android.
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.pantalla que mida al menos 5.6 cm (2.2") en el borde corto y 8.6 cm (3.4") en el borde largo. [7.1.1.3/H-SR-1] SE RECOMIENDA VETAMENTE proporcionar a los usuarios una indicación visual para cambiar el tamaño de la pantalla (densidad de pantalla).
[7.1.1.1/H-0-2] DEBE admitir la composición de GPU de búferes gráficos que sean, al menos, tan grandes como la resolución más alta de cualquier pantalla integrada.
Cómo iniciar nuevos requisitos
[7.1.1.1/H-0-3]* DEBEN asignar cada pantalla
UI_MODE_NORMAL
que se pone a disposición de aplicaciones de terceros a un área física de la pantalla sin obstrucciones que tenga al menos 5.6 cm (2.2") en el borde corto y 8.6 cm (3.4") en el borde largo.[7.1.1.3/H-0-1]* DEBE establecer el valor de
DENSITY_DEVICE_STABLE
en un 92% o más de la densidad física real de la pantalla correspondiente.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos portátiles admiten la rotación de pantalla de software, hacen lo siguiente:
- [7.1.1.1/H-1-1]* DEBE hacer que la pantalla lógica que se pone a disposición de las aplicaciones de terceros tenga al menos 5.08 cm(2") en los bordes cortos y 6.86 cm(2.7") en los bordes largos. Es POSIBLE que los dispositivos que se enviaron con el nivel de API de Android 29 o versiones anteriores estén exentos de este requisito.
Si las implementaciones de dispositivos de mano no admiten la rotación de pantalla de software, hacen lo siguiente:
- [7.1.1.1/H-2-1]* DEBE hacer que la pantalla lógica que se pone a disposición de las aplicaciones de terceros tenga al menos 6.9 cm(2.7") en los bordes cortos. Es POSIBLE que los dispositivos que se enviaron con el nivel de API de Android 29 o versiones anteriores estén exentos de este requisito.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos portátiles incluyen compatibilidad con Vulkan, tienen las siguientes características:
- [7.1.4.2/H-1-1] DEBEN satisfacer los requisitos especificados en el perfil de Baseline de Android 2021.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos portátiles afirman admitir pantallas de alto rango dinámico a través de Configuration.isScreenHdr()
, hacen lo siguiente:
- [7.1.4.5/H-1-1] DEBEN anunciar la compatibilidad con las extensiones
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
yVK_EXT_hdr_metadata
.
Implementaciones de dispositivos portátiles:
- [7.1.4.6/H-0-1] DEBE informar si el dispositivo admite la función de generación de perfiles de GPU a través de una propiedad del sistema
graphics.gpu.profiler.support
.
Si las implementaciones de dispositivos de mano declaran compatibilidad a través de una propiedad del sistema graphics.gpu.profiler.support
, hacen lo siguiente:
- [7.1.4.6/H-1-1] DEBE informar como resultado un registro de protobuf que cumpla con el esquema de contadores de GPU y etapas de renderización de GPU definidos en la documentación de Perfetto.
- [7.1.4.6/H-1-2] DEBEN informar valores conformes para los contadores de GPU del dispositivo según el prototipo de paquete de registro de contador de GPU.
- [7.1.4.6/H-1-3] DEBEN informar valores conformes para las etapas de renderización de la GPU del dispositivo según el prototipo de paquete de seguimiento de la etapa de renderización.
- [7.1.4.6/H-1-4] DEBE informar un punto de seguimiento de frecuencia de GPU como se especifica en el formato: power/gpu_frequency.
Implementaciones de dispositivos portátiles:
- [7.1.5/H-0-1] DEBE incluir compatibilidad con el modo de compatibilidad de aplicaciones heredadas, tal como lo implementa el código fuente abierto de Android upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los activadores ni los umbrales en los que se activa el modo de compatibilidad, ni alterar el comportamiento del modo de compatibilidad.
- [7.2.1/H-0-1] DEBE incluir compatibilidad con aplicaciones de Editor de método de entrada (IME) de terceros.
- [7.2.3/H-0-2] DEBE enviar el evento de presionar y mantener pulsados la función Atrás (
KEYCODE_BACK
) a la aplicación en primer plano. El sistema NO DEBE consumir estos eventos y PUEDEN activarse fuera del dispositivo Android (p.ej., un teclado de hardware externo conectado al dispositivo Android). - [7.2.3/H-0-3] DEBEN proporcionar la función de inicio en todas las pantallas compatibles con Android que proporcionen la pantalla principal.
- [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.4/H-0-1] DEBE admitir la entrada de la pantalla táctil.
- [7.2.4/H-SR-1] SE RECOMIENDA ENFATICAMENTE que inicies la app de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService, o una actividad que controle el
ACTION_ASSIST
cuando se mantenga presionada la teclaKEYCODE_MEDIA_PLAY_PAUSE
oKEYCODE_HEADSETHOOK
si la actividad en primer plano no controla esos eventos de mantener presionada la tecla. - [7.3.1/H-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un acelerómetro de 3 ejes.
Si las implementaciones de dispositivos portátiles incluyen un acelerómetro de 3 ejes, tienen las siguientes características:
- [7.3.1/H-1-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.
Si las implementaciones de dispositivos portátiles incluyen un receptor de GPS/GNSS y registran la función a las aplicaciones a través de la marca de función android.hardware.location.gps
, hacen lo siguiente:
- [7.3.3/H-2-1] DEBEN informar las mediciones de GNSS en cuanto se encuentren, incluso si aún no se informa una ubicación calculada a partir del GPS/GNSS.
- [7.3.3/H-2-2] DEBEN informar las pseudorangos y las tasas de pseudorangos del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras están inmóviles o se mueven con menos de 0.2 metros por segundo cuadrado de aceleración, son suficientes para calcular la posición dentro de 20 metros y la velocidad dentro de 0.2 metros por segundo, al menos el 95% del tiempo.
Si las implementaciones de dispositivos portátiles incluyen un giroscopio de 3 ejes, tienen las siguientes características:
- [7.3.4/H-3-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.
- [7.3.4/H-3-2] DEBE ser capaz de medir cambios de orientación de hasta 1,000 grados por segundo.
Implementaciones de dispositivos de mano que pueden realizar una llamada de voz y que indican cualquier valor que no sea 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 RECOMIENDA ENFATICAMENTE admitir el sensor de pose con 6 grados de libertad.
- [7.4.3/H] DEBE incluir compatibilidad con Bluetooth y Bluetooth LE.
Si los dispositivos admiten el protocolo Neighbor Awareness Networking (NAN) de Wi-Fi mediante la declaración de PackageManager.FEATURE_WIFI_AWARE
y la ubicación Wi-Fi (tiempo de ida y vuelta de Wi-Fi: RTT) mediante la declaración de PackageManager.FEATURE_WIFI_RTT
, hacen lo siguiente:
[7.4.2.5/H-1-1] DEBE informar el rango con precisión dentro de +/-1 metro con un ancho de banda de 160 MHz en el percentil 68 (como se calcula con la función de distribución acumulativa), +/-2 metros con un ancho de banda de 80 MHz en el percentil 68, +/-4 metros con un ancho de banda de 40 MHz en el percentil 68 y +/-8 metros con un ancho de banda de 20 MHz en el percentil 68 a distancias de 10 cm, 1 m, 3 m y 5 m, como se observa a través de la API de Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] SE RECOMIENDA ENFATICAMENTE informar el rango con precisión dentro de +/-1 metro con un ancho de banda de 160 MHz en el percentil 90 (como se calcula con la función de distribución acumulada), +/-2 metros con un ancho de banda de 80 MHz en el percentil 90, +/-4 metros con un ancho de banda de 40 MHz en el percentil 90 y +/-8 metros con un ancho de banda de 20 MHz en el percentil 90 a distancias de 10 cm, como se observa a través de la API de Android WifiRttManager#startRanging.
SE RECOMIENDA URGENTEMENTE que sigas los pasos de configuración de medición que se especifican en Calibración de presencia.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos de mano declaran FEATURE_BLUETOOTH_LE
, hacen lo siguiente:
- [7.4.3/H-1-3] DEBE medir y compensar el desplazamiento de Rx para garantizar que el RSSI promedio de BLE sea de -50 dBm ± 15 dB a 1 m de distancia de un dispositivo de referencia que transmite a
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] DEBE medir y compensar el desplazamiento de Tx para garantizar que el RSSI BLE medio sea de -50 dBm ± 15 dB cuando se escanea desde un dispositivo de referencia ubicado a 1 m de distancia y que transmite a
ADVERTISE_TX_POWER_HIGH
.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos de mano incluyen un dispositivo de cámara lógico que enumera las capacidades con CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, hacen lo siguiente:
- [7.5.4/H-1-1] DEBE tener un campo visual (FOV) normal de forma predeterminada y DEBE estar entre 50 y 60 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 mostrar “true” para
ActivityManager.isLowRamDevice()
cuando haya menos de 1 GB de memoria disponible para el kernel y el espacio de usuario.
Si las implementaciones de dispositivos portátiles declaran compatibilidad solo con una ABI de 32 bits, haz lo siguiente:
[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 usa resoluciones de búfer de trama de hasta qHD (p.ej., FWVGA).
[7.6.1/H-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 592 MB si la pantalla predeterminada usa resoluciones de búfer de trama de hasta HD+ (p.ej., HD, WSVGA).
[7.6.1/H-3-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si la pantalla predeterminada usa resoluciones de búfer de trama de hasta FHD (p.ej., WSXGA+).
[7.6.1/H-4-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1344 MB si la pantalla predeterminada usa resoluciones de búfer de trama de hasta QHD (p.ej., QWXGA).
Si las implementaciones de dispositivos portátiles declaran compatibilidad con cualquier ABI de 64 bits (con o sin ABI de 32 bits), haz lo siguiente:
[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 usa resoluciones de framebuffer de hasta qHD (p.ej., 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 usa resoluciones de búfer de trama de hasta HD+ (p.ej., 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 usa resoluciones de búfer de trama de hasta FHD (p.ej., 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 usa resoluciones de framebuffer de hasta QHD (p.ej., QWXGA).
Ten en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior hace referencia al espacio de memoria proporcionado, además de la memoria ya dedicada a componentes de hardware, como radio, video, etcétera, que no están bajo el control del kernel en las implementaciones de dispositivos.
Si las implementaciones de dispositivos portátiles incluyen menos de 1 GB de memoria disponible para el kernel y el espacio de usuario, sucede lo siguiente:
- [7.6.1/H-9-1] DEBE declarar la marca de función
android.hardware.ram.low
. - [7.6.1/H-9-2] DEBE tener al menos 1.1 GB de almacenamiento no volátil para 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, hacen lo siguiente:
- [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 la marca de función
android.hardware.ram.normal
.
Si las implementaciones de dispositivos portátiles incluyen más de 2 GB o menos de 4 GB de memoria disponible para el kernel y el espacio de usuario, sucede lo siguiente:
- [7.6.1/H-SR-1] SE RECOMIENDA ENFATICAMENTE admitir solo el espacio de usuario de 32 bits (tanto las apps como el 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, sucede lo siguiente:
- [7.6.1/H-1-1] DEBE admitir solo una ABI (solo de 64 bits o solo de 32 bits).
Implementaciones de dispositivos portátiles:
- [7.6.2/H-0-1] NO DEBE proporcionar un almacenamiento compartido de la aplicación menor que 1 GiB.
- [7.7.1/H] DEBE incluir un puerto USB compatible con el modo periférico.
Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con el modo periférico, hacen lo siguiente:
- [7.7.1/H-1-1] DEBE implementar la API de Android Open Accessory (AOA).
Si las implementaciones de dispositivos portátiles incluyen un puerto USB compatible con el modo host, hacen lo siguiente:
- [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 pueden cumplir con todos los requisitos de rendimiento para admitir el modo de VR y lo incluyen, deben cumplir con los siguientes requisitos:
- [7.9.1/H-1-1] DEBE declarar la marca 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 VR puedan habilitar a través deandroid.app.Activity#setVrModeEnabled
.
Si las implementaciones de dispositivos portátiles incluyen uno o más puertos USB-C en modo de host y implementan (clase de audio USB), además de los requisitos de la sección 7.7.2, deben cumplir con lo siguiente:
- [7.8.2.2/H-1-1] DEBE proporcionar la siguiente asignación de software de los códigos HID:
Función | Asignaciones | Contexto | Comportamiento |
---|---|---|---|
A | Página de uso de HID: 0x0C Uso de HID: 0x0CD Clave del kernel: KEY_PLAYPAUSE Clave de Android: KEYCODE_MEDIA_PLAY_PAUSE |
Reproducción de contenido multimedia | Entrada: Presionar brevemente Salida: Reproducir o pausar |
Entrada: Mantener presionado Salida: Iniciar comando por voz Envía: android.speech.action.VOICE_SEARCH_HANDS_FREE si el dispositivo está bloqueado o la pantalla está apagada. Envía android.speech.RecognizerIntent.ACTION_WEB_SEARCH de lo contrario. |
|||
Llamada entrante | Entrada: Presionar brevemente Salida: Aceptar llamada |
||
Entrada: Mantener presionado Salida: Rechazar llamada |
|||
Llamada en curso | Entrada: Presionar brevemente Salida: Finalizar llamada |
||
Entrada: Mantener presionado Salida: Activar o desactivar 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 de contenido multimedia, Llamada en curso | Entrada: Mantener presionado o presionar brevemente Salida: Aumenta el volumen del sistema o de los auriculares. |
C | Página de uso de HID: 0x0C Uso de HID: 0x0EA Clave del kernel: KEY_VOLUMEDOWN Clave de Android: VOLUME_DOWN |
Reproducción de contenido multimedia, Llamada en curso | Entrada: Mantener presionado o presionar brevemente Salida: Disminuye el volumen del sistema o de los auriculares. |
D | Página de uso de HID: 0x0C Uso de HID: 0x0CF Clave del kernel: KEY_VOICECOMMAND Clave de Android: KEYCODE_VOICE_ASSIST |
Todos. Se puede activar en cualquier instancia. | Entrada: Presionar brevemente o mantener presionado Salida: Iniciar el comando por voz |
- [7.8.2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG cuando se inserta un enchufe, pero solo después de que se hayan enumerado correctamente las interfaces y los extremos de audio USB para identificar el tipo de terminal conectada.
Cuando se detectan los tipos de terminales de audio USB 0x0302, sucede lo siguiente:
- [7.8.2.2/H-2-1] DEBE transmitir el intent ACTION_HEADSET_PLUG con el valor adicional "microphone" establecido en 0.
Cuando se detectan los tipos de terminales de audio USB 0x0402, sucede lo siguiente:
- [7.8.2.2/H-3-1] DEBE transmitir el intent ACTION_HEADSET_PLUG con el valor adicional “microphone” establecido en 1.
Cuando se llama a AudioManager.getDevices() de la API mientras el periférico USB está conectado, sucede lo siguiente:
[7.8.2.2/H-4-1] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y el rol isSink() si el campo de tipo de terminal de audio USB es 0x0302.
[7.8.2.2/H-4-2] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y el rol 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 el rol isSource() si el campo de tipo de terminal de audio USB es 0x0402.
[7.8.2.2/H-4-4] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y el rol isSink() si el campo de tipo de terminal de audio USB es 0x603.
[7.8.2.2/H-4-5] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y el rol isSource() si el campo de tipo de terminal de audio USB es 0x604.
[7.8.2.2/H-4-6] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y el rol isSink() si el campo de tipo de terminal de audio USB es 0x400.
[7.8.2.2/H-4-7] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_DEVICE y el rol isSource() si el campo de tipo de terminal de audio USB es 0x400.
[7.8.2.2/H-SR-1] SE RECOMIENDA ENFATICAMENTE que, cuando se conecte un periférico de audio USB-C, se realice la enumeración de los descriptores USB, se identifiquen los tipos de terminales y se transmita el intent ACTION_HEADSET_PLUG en menos de 1,000 milisegundos.
Si las implementaciones de dispositivos portátiles declaran android.hardware.audio.output
y android.hardware.microphone
, hacen lo siguiente:
[5.6/H-1-1] DEBE tener una latencia de ida y vuelta continua promedio de 300 milisegundos o menos en 5 mediciones, con una desviación absoluta promedio inferior a 30 ms en las siguientes rutas de datos: "bocina a micrófono", adaptador de bucle invertido de 3.5 mm (si es compatible) y bucle invertido USB (si es compatible).
[5.6/H-1-2] DEBE tener una latencia promedio de toque para tono de 300 milisegundos o menos en al menos 5 mediciones en la ruta de datos de la bocina al micrófono.
Si las implementaciones de dispositivos portátiles incluyen al menos un actuador táctil, deben cumplir con los siguientes requisitos:
- [7.10/H]* NO DEBE usar un actuador táctil (vibrador) de masa rotativa excéntrica (ERM).
- [7.10/H]* DEBE implementar todas las constantes públicas para la retroalimentación táctil clara en android.view.HapticFeedbackConstants, es decir, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START y GESTURE_END).
- [7.10/H]* DEBE implementar todas las constantes públicas para la haptics clara en android.os.VibrationEffect, es decir, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK y EFFECT_DOUBLE_CLICK) y todas las constantes
PRIMITIVE_*
públicas posibles para la haptics enriquecida en android.os.VibrationEffect.Composition, es decir, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Algunas de estas primitivas, como LOW_TICK y SPIN, solo pueden ser factibles si el vibrador puede admitir frecuencias relativamente bajas. - [7.10/H]* DEBE seguir las instrucciones para asignar constantes públicas en android.view.HapticFeedbackConstants a las constantes recomendadas de android.os.VibrationEffect, con las relaciones de amplitud correspondientes.
- [7.10/H]* DEBE seguir la evaluación de calidad para las APIs de createOneShot() y createWaveform().
- [7.10/H]* DEBE verificar que el resultado de la API pública android.os.Vibrator.hasAmplitudeControl() refleje correctamente las capacidades del vibrador.
- [7.10/H]* DEBE colocar el actuador cerca de la ubicación en la que se suele sostener o tocar el dispositivo con las manos.
Un actuador resonante lineal (LRA) es un sistema de resorte de masa única que tiene una frecuencia resonante dominante en la que la masa se traduce en la dirección del movimiento deseado.
Si las implementaciones de dispositivos portátiles incluyen al menos un actuador resonante lineal de propósito general 7.10 , deben cumplir con los siguientes requisitos:
Cómo iniciar nuevos requisitos
- [7.10/H] DEBE colocar el actuador cerca de la ubicación en la que se suele sostener o tocar el dispositivo con las manos.
Fin de los nuevos requisitos
- [7.10/H] Debe mover el actuador táctil en el eje X (izquierda-derecha) de la orientación natural
verticaldel dispositivo.
Si las implementaciones de dispositivos portátiles tienen un actuador táctil de uso general que es un actuador resonante lineal (LRA) del eje X, tienen las siguientes características:
- [7.10/H] Debe tener la frecuencia resonante del LRA del eje X inferior a 200 Hz.
Si las implementaciones de dispositivos de mano siguen la asignación de constantes táctiles, hacen lo siguiente:
- [7.10/H]* DEBE verificar el estado de la implementación ejecutando las APIs de android.os.Vibrator.areAllEffectsSupported() y android.os.Vibrator.arePrimitivesSupported().
[7.10/H]* DEBE realizar una evaluación de calidad para las constantes táctiles.
[7.10/H]* DEBE verificar y actualizar, si es necesario, la configuración de resguardo para las primitivas no admitidas, como se describe en la guía de implementación para constantes.
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 las aplicaciones de terceros:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] Perfil AAC de MPEG-4 (AAC LC)
- [5.1/H-0-4] Perfil HE AAC de MPEG-4 (AAC+)
- [5.1/H-0-5] AAC ELD (AAC mejorado de bajo retraso)
Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de las aplicaciones de terceros:
Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de las aplicaciones de terceros:
2.2.3. Software
Implementaciones de dispositivos portátiles:
- [3.2.3.1/H-0-1] DEBE tener una aplicación que controle los intents
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
yACTION_CREATE_DOCUMENT
como se describe en los documentos del SDK, y proporcionarle al usuario indicaciones visuales para acceder a los datos del proveedor de documentos mediante la API deDocumentsProvider
. - [3.2.3.1/H-0-2]* DEBEN cargarse previamente una o más aplicaciones o componentes de servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de la aplicación que se indican aquí.
- [3.2.3.1/H-SR-1] SE RECOMIENDA encarecidamente que se cargue previamente una aplicación de correo electrónico que pueda controlar los intents ACTION_SENDTO, ACTION_SEND o ACTION_SEND_MULTIPLE para enviar un correo electrónico.
- [3.4.1/H-0-1] DEBE proporcionar una implementación completa de la API de
android.webkit.Webview
. - [3.4.2/H-0-1] DEBE incluir una aplicación de navegador independiente para la navegación web general del usuario.
- [3.8.1/H-SR-1] SE RECOMIENDA URGENTEMENTE implementar un selector predeterminado que admita la fijación en la app de atajos, widgets y widgetFeatures.
- [3.8.1/H-SR-2] SE RECOMIENDA INTENSAMENTE implementar un selector predeterminado que proporcione acceso rápido a los atajos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager.
- [3.8.1/H-SR-3] SE RECOMIENDA URGENTEMENTE incluir una app de selector predeterminada que muestre insignias para los íconos de la app.
- [3.8.2/H-SR-1] SE RECOMIENDA VETAMENTE admitir widgets de apps de terceros.
- [3.8.3/H-0-1] DEBEN permitir que las apps de terceros notifiquen a los usuarios sobre eventos importantes a través de las clases de API
Notification
yNotificationManager
. - [3.8.3/H-0-2] DEBE admitir notificaciones enriquecidas.
- [3.8.3/H-0-3] DEBEN admitir notificaciones de alerta.
- [3.8.3/H-0-4] DEBE incluir un panel de notificaciones que le permita al usuario controlar directamente (p.ej., responder, posponer, descartar o bloquear) las notificaciones a través de indicaciones visuales, como botones de acción o el panel de control, tal como se implementa en el AOSP.
- [3.8.3/H-0-5] DEBE mostrar las opciones proporcionadas a través de
RemoteInput.Builder setChoices()
en la barra de notificaciones. - [3.8.3/H-SR-1] SE RECOMIENDA INTENSAMENTE mostrar la primera opción proporcionada a través de
RemoteInput.Builder setChoices()
en la pantalla de notificaciones sin interacción adicional del usuario. - [3.8.3/H-SR-2] SE RECOMIENDA INTENSAMENTE mostrar todas las opciones proporcionadas a través de
RemoteInput.Builder setChoices()
en el panel de notificaciones cuando el usuario expanda todas las notificaciones en el panel de notificaciones. - [3.8.3.1/H-SR-1] SE RECOMIENDA INTENSAMENTE mostrar acciones para las que
Notification.Action.Builder.setContextual
se establece comotrue
en línea con las respuestas que muestraNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] SE RECOMIENDA INTENSAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.
Si las implementaciones de dispositivos de mano admiten notificaciones MediaStyle, hacen lo siguiente:
- [3.8.3.1/H-SR-2] SE RECOMIENDA FUERTEMENTE proporcionar una indicación visual para el usuario (por ejemplo, un selector de salida) al que se pueda acceder desde la IU del sistema y que permita a los usuarios cambiar entre las rutas de acceso multimedia disponibles adecuadas (por ejemplo, dispositivos Bluetooth y rutas proporcionadas a
MediaRouter2Manager
) cuando una app publique una notificaciónMediaStyle
con un tokenMediaSession
.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos que incluyen la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, alteran la interfaz, sucede lo siguiente:
- [3.8.3/H-1-1] DEBE implementar el comportamiento de fijación de pantalla y proporcionarle al usuario un menú de configuración para activar o desactivar la función.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos de mano admiten la acción de asistencia, hacen lo siguiente:
- [3.8.4/H-SR-2] SE RECOMIENDA INTENSAMENTE que uses la acción de mantener presionada la tecla
HOME
como la interacción designada para iniciar la app de asistencia, como se describe en la sección 7.2.3. DEBE iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementaVoiceInteractionService
, o una actividad que controle el intentACTION_ASSIST
.
Si las implementaciones de dispositivos de mano admiten conversation notifications
y las agrupan en una sección separada de las notificaciones de alerta y silenciosas que no son de conversación, hacen lo siguiente:
- [3.8.4/H-1-1]* DEBEN mostrar notificaciones de conversación antes que las que no son de conversación, a excepción de las notificaciones de servicios en primer plano en curso y las notificaciones de importancia:alta.
Si las implementaciones de dispositivos portátiles Android admiten una pantalla de bloqueo, deben cumplir con los siguientes requisitos:
- [3.8.10/H-1-1] DEBEN mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación multimedia.
Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:
- [3.9/H-1-1] DEBEN implementar la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android.
Si las implementaciones de dispositivos portátiles incluyen compatibilidad con las APIs de ControlsProviderService
y Control
, y permiten que las aplicaciones de terceros publiquen controles de dispositivos, deben cumplir con los siguientes requisitos:
- [3.8.16/H-1-1] DEBE declarar la marca de función
android.software.controls
y establecerla entrue
. - [3.8.16/H-1-2] DEBEN proporcionar una indicación visual al usuario con la capacidad de agregar, editar, seleccionar y operar los controles de dispositivos favoritos del usuario desde los controles registrados por las aplicaciones de terceros a través de las APIs de
ControlsProviderService
yControl
. - [3.8.16/H-1-3] DEBE proporcionar acceso a esta indicación visual para el usuario dentro de tres interacciones desde un selector predeterminado.
[3.8.16/H-1-4] DEBEN renderizar con precisión en esta indicación visual para el usuario el nombre y el ícono de cada app de terceros que proporcione controles a través de la API de
ControlsProviderService
, así como cualquier campo especificado que proporcionen las APIs deControl
.[3.8.16/H-1-5] DEBEN proporcionar una indicación visual para el usuario para inhabilitar los controles de dispositivos triviales de autenticación designados por la app de los controles registrados por las aplicaciones de terceros a través de la API de
ControlsProviderService
yControl
Control.isAuthRequired
.
Cómo iniciar nuevos requisitos
- [3.8.16/H-1-6] Las implementaciones de dispositivos deben renderizar con precisión la indicación visual para el usuario de la siguiente manera:
- Si el dispositivo configuró
config_supportsMultiWindow=true
y la app declara los metadatosMETA_DATA_PANEL_ACTIVITY
en la declaraciónControlsProviderService
, incluido el ComponentName de una actividad válida (según lo define la API), la app DEBE incorporar esa actividad en esta indicación visual para el usuario. - Si la app no declara metadatos
META_DATA_PANEL_ACTIVITY
, entonces DEBE renderizar los campos especificados como lo proporciona la API deControlsProviderService
, así como cualquier campo especificado que proporcionen las APIs de Control.
- Si el dispositivo configuró
- [3.8.16/H-1-7] Si la app declara los metadatos
META_DATA_PANEL_ACTIVITY
, DEBE pasar el valor de la configuración definida en [3.8.16/H-1-5] conEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
cuando se inicia la actividad incorporada.
Fin de los nuevos requisitos
Por el contrario, si las implementaciones de dispositivos portátiles no implementan esos controles, hacen lo siguiente:
- [3.8.16/H-2-1] DEBE informar
null
para las APIs deControlsProviderService
yControl
. - [3.8.16/H-2-2] DEBES declarar la marca de función
android.software.controls
y configurarla enfalse
.
Si las implementaciones de dispositivos de mano no se ejecutan en el modo de tarea de bloqueo, cuando se copia contenido en el portapapeles, sucede lo siguiente:
- [3.8.17/H-1-1] DEBE presentarle al usuario una confirmación de que los datos se copiaron en el portapapeles (p. ej., una miniatura o una alerta de "Contenido copiado"). Además, incluye aquí una indicación si los datos del portapapeles se sincronizarán en todos los dispositivos.
Implementaciones de dispositivos portátiles:
- [3.10/H-0-1] DEBE admitir servicios de accesibilidad de terceros.
- [3.10/H-SR-1] SE RECOMIENDA ENFATICAMENTE que se carguen previamente servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de Accesibilidad mejorada y TalkBack (para los idiomas compatibles con el motor de texto a voz preinstalado) o que la superen, como se proporciona en el proyecto de código abierto de TalkBack.
- [3.11/H-0-1] DEBE admitir la instalación de motores de TTS de terceros.
- [3.11/H-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un motor de TTS que admita los idiomas disponibles en el dispositivo.
- [3.13/H-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un componente de IU de Configuración rápida.
Si las implementaciones de dispositivos de mano de Android declaran compatibilidad con FEATURE_BLUETOOTH
o FEATURE_WIFI
, hacen lo siguiente:
- [3.16/H-1-1] DEBE admitir la función de vinculación de dispositivos complementarios.
Si la función de navegación se proporciona como una acción en pantalla basada en gestos, haz lo siguiente:
- [7.2.3/H] La zona de reconocimiento de gestos para la función de inicio NO DEBE tener una altura superior a 32 dp 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, haz lo siguiente:
- [7.2.3/H-0-1] El área de gestos de la función de navegación DEBE ser inferior a 40 dp de ancho en cada lado. El área del gesto DEBE ser de 24 dp de ancho de forma predeterminada.
Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura y tienen más de 2 GB de memoria disponible para el kernel y el espacio de usuario, hacen lo siguiente:
- [3.9/H-1-2] DEBE declarar la compatibilidad con los perfiles administrados a través de la marca de función
android.software.managed_users
.
Si las implementaciones de dispositivos de mano de Android declaran la compatibilidad con la cámara a través de android.hardware.camera.any
, hacen lo siguiente:
- [7.5.4/H-1-1] DEBE respetar los intents
android.media.action.STILL_IMAGE_CAMERA
yandroid.media.action.STILL_IMAGE_CAMERA_SECURE
, y activar la cámara en el modo de imagen fija como se describe en el SDK. - [7.5.4/H-1-2] DEBE respetar la intención
android.media.action.VIDEO_CAMERA
para iniciar la cámara en modo de video, como se describe en el SDK.
Si la aplicación de configuración de la implementación del dispositivo implementa una funcionalidad dividida con la incorporación de actividades, hace lo siguiente:
- [3.2.3.1/ H-1-1] DEBE tener una actividad que controle el intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY cuando la función de división esté activada. La actividad DEBE estar protegida por
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
y DEBE iniciar la actividad del intent analizado desde Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos permiten que los usuarios realicen llamadas de cualquier tipo,
- [7.4.1.2/H-0-1] DEBE declarar la marca de función
android.software.telecom
. - [7.4.1.2/H-0-2] DEBE implementar el framework de telecomunicaciones.
Fin de los nuevos requisitos
2.2.4. Rendimiento y energía
- [8.1/H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas incoherente o una demora para renderizar fotogramas NO DEBEN ocurrir más de 5 veces 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 del usuario de baja latencia mediante el desplazamiento de una lista de 10,000 entradas de lista, como lo define el Conjunto de pruebas de compatibilidad (CTS) de Android, en menos de 36 segundos.
- [8.1/H-0-3] Cambio de tareas. Cuando se inician varias aplicaciones, el reinicio de una aplicación que ya se está ejecutando 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 extienden las funciones que se incluyen en AOSP, deben cumplir con los siguientes requisitos:
- [8.3/H-1-1] DEBE proporcionar indicaciones visuales para el usuario para habilitar y deshabilitar la función de ahorro de batería.
- [8.3/H-1-2] DEBE proporcionar indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.
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 la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
- [8.4/H-0-2] DEBEN informarse todos los valores de consumo de energía en miliamperes-hora (mAh).
- [8.4/H-0-3] DEBE informar el consumo de energía de la CPU por UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de 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 para el desarrollador de la app a través del comando de shell
adb shell dumpsys batterystats
. - [8.4/H] DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo de energía del componente de hardware a una aplicación.
Si las implementaciones de dispositivos portátiles incluyen una pantalla o una salida de video, deben cumplir con los siguientes requisitos:
- [8.4/H-1-1] DEBEN respetar el intent
android.intent.action.POWER_USAGE_SUMMARY
y mostrar un menú de configuración que muestre este consumo de energía.
Implementaciones de dispositivos portátiles:
- [8.5/H-0-1] DEBEN proporcionar una indicación visual para el usuario
en el menú Configuraciónpara ver todas las apps con servicios en primer plano activos o tareas iniciadas por el usuario, incluida la duración de cada uno de estos servicios desde que se inició, como se describe en el documento del SDK.y la capacidad de detener una app que ejecuta un servicio en primer plano o una tarea iniciada por el usuario.con la capacidad de detener una app que ejecuta un servicio en primer plano y mostrar todas las apps que tienen servicios en primer plano activos y la duración de cada uno de estos servicios desde que se inició, como se describe en el documento del SDK.- Es POSIBLE que algunas apps estén exentas de detenerse o aparecer en una indicación visual para el usuario como se describe en el documento del SDK.
Cómo iniciar nuevos requisitos
- [8.5/H-0-2]DEBE proporcionar una indicación visual para el usuario para detener una app que ejecuta un servicio en primer plano o una tarea iniciada por el usuario.
Fin de los nuevos requisitos
2.2.5. Modelo de seguridad
Implementaciones de dispositivos portátiles:
- [9/H-0-1] DEBE declarar la función
android.hardware.security.model.compatible
. - [9.1/H-0-1] DEBEN permitir que las apps 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 esas apps en respuesta al intentandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony
, hacen lo siguiente:
- [9.5/H-1-1] NO DEBE configurar
UserManager.isHeadlessSystemUserMode
entrue
.
Fin de los nuevos requisitos
Implementaciones de dispositivos portátiles:
- [9.11/H-0-2] DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
- [9.11/H-0-3] DEBE tener implementaciones de algoritmos de criptografía RSA, AES, ECDSA y HMAC, y funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles del sistema de almacén de claves de Android en un área que esté aislada de forma segura del código que se ejecuta en el kernel y en niveles superiores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos con los que el código del kernel o del espacio de usuario pueda acceder al estado interno del entorno aislado, incluida la DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante la implementación de 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 aislado y, solo cuando se realice correctamente, permitir que se usen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
- [9.11/H-0-5] DEBE admitir la certificación de claves en la que la clave de firma de certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse en una cantidad de dispositivos lo suficientemente grande como para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con 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 usar una clave diferente para cada 100,000 unidades.
Ten en cuenta que, si ya se lanzó una implementación de dispositivo en una versión anterior de Android, ese dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la certificación de claves, a menos que declare la función 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, hacen lo siguiente:
- [9.11/H-1-1] DEBE permitir que el usuario elija el tiempo de espera de suspensión más corto, que es un tiempo de transición del estado desbloqueado al estado bloqueado, de 15 segundos o menos.
- [9.11/H-1-2] DEBE proporcionar indicaciones visuales para el usuario para ocultar las notificaciones y inhabilitar todas las formas de autenticación, excepto la autenticación principal que se describe en 9.11.1 Pantalla de bloqueo segura. El AOSP cumple con el requisito como modo de bloqueo.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y, además, incluyen uno o más agentes de confianza que implementan la API del sistema TrustAgentService
, hacen lo siguiente:
- [9.11.1/H-1-1] DEBE solicitarle al usuario uno de los métodos de autenticación principales recomendados (p. ej., PIN, patrón o contraseña) con más frecuencia que una vez cada 72 horas.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos portátiles incluyen varios usuarios y no declaran la marca de función android.hardware.telephony
, sucede lo siguiente:
- [9.5/H-2-1] DEBEN admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
Si las implementaciones de dispositivos de mano incluyen varios usuarios y declaran la marca de función android.hardware.telephony
, hacen lo siguiente:
- [9.5/H-3-1] NO DEBEN admitir perfiles restringidos, pero DEBEN alinearse con la implementación de controles de AOSP para habilitar o inhabilitar que otros usuarios accedan a las llamadas de voz y los SMS.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos de mano establecen UserManager.isHeadlessSystemUserMode
en true
,
- [9.5/H-4-1] NO DEBE incluir compatibilidad con eUICC ni con eSIM con capacidad de llamada.
- [9.5/H-4-2] NO DEBE declarar compatibilidad con
android.hardware.telephony
.
Fin de los nuevos requisitos
Android, a través de la API de System VoiceInteractionService, admite un mecanismo para la detección segura de palabras activas siempre activas sin indicación de acceso al micrófono y la detección de consultas siempre activas, sin indicación de acceso al micrófono ni a la cámara.
Si las implementaciones de dispositivos portátiles admiten la API del sistema HotwordDetectionService
o algún otro mecanismo para la detección de palabras clave sin indicación de acceso al micrófono, deben cumplir con los siguientes requisitos:
- [9.8/H-1-1] DEBEN asegurarse de que el servicio de detección de palabras clave solo pueda transmitir datos al sistema,
ContentCaptureService
, o al servicio de reconocimiento de voz integrado en el dispositivo creado porSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-2] DEBE asegurarse de que el servicio de detección de palabras clave solo pueda transmitir datos de audio del micrófono o datos derivados de él al servidor del sistema a través de la API de
HotwordDetectionService
o aContentCaptureService
a través de la API deContentCaptureManager
. - [9.8/H-1-3] NO DEBE proporcionar audio del micrófono que dure más de 30 segundos para una solicitud individual activada por hardware al servicio de detección de palabras clave.
- [9.8/H-1-4] NO DEBE proporcionar audio del micrófono almacenado en búfer de más de 8 segundos para una solicitud individual al servicio de detección de palabras clave.
- [9.8/H-1-5] NO DEBE proporcionar audio del micrófono almacenado en búfer de más de 30 segundos al servicio de interacción por voz o a una entidad similar.
- [9.8/H-1-6] NO DEBE permitir que se transmitan más de 100 bytes de datos del servicio de detección de palabras clave en cada resultado correcto de palabra clave , excepto los datos de audio que se pasan a través de HotwordAudioStream.
- [9.8/H-1-7] NO DEBE permitir que se transmitan más de 5 bits de datos desde el servicio de detección de palabras clave en cada resultado negativo de palabras clave.
- [9.8/H-1-8] SOLO DEBE permitir la transmisión de datos fuera del servicio de detección de palabras clave en una solicitud de validación de palabras clave 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 clave.
- [9.8/H-1-10] NO DEBEN aparecer en los datos cuantitativos de la IU sobre el uso del micrófono por parte del servicio de detección de palabras clave.
- [9.8/H-1-11] DEBE registrar la cantidad de bytes incluidos en cada transmisión del servicio de detección de palabras clave para permitir la capacidad de inspección 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 del servicio de detección de palabras clave para permitir la capacidad de inspección de los investigadores de seguridad.
- [9.8/H-1-14] DEBE mostrar el indicador de micrófono, como se describe en el artículo 9.8.2, cuando se transmite un resultado correcto de la palabra clave al servicio de interacción por voz o a una entidad similar.
Cómo iniciar nuevos requisitos
- [9.8/H-1-15] DEBE garantizar que las transmisiones de audio proporcionadas en los resultados correctos de las palabras clave se transmitan de una sola manera desde el servicio de detección de palabras clave al servicio de interacción por voz.
Fin de los nuevos requisitos
- [9.8/H-SR-1] SE RECOMIENDA ENFATICAMENTE notificar a los usuarios antes de configurar una aplicación como proveedor del servicio de detección de palabras clave.
- [9.8/H-SR-2] SE RECOMIENDA ENFATICAMENTE que no se permita la transmisión de datos no estructurados desde el servicio de detección de palabras clave.
- [9.8/H-SR-3] SE RECOMIENDA ENFATICAMENTE que reinicies el proceso que aloja el servicio de detección de palabras clave al menos una vez por hora o cada 30 eventos de activación de hardware, lo que ocurra primero.
Si las implementaciones de dispositivos incluyen una aplicación que usa la API del sistema HotwordDetectionService
, o un mecanismo similar para la detección de palabras clave sin indicación de uso del micrófono, la aplicación hace lo siguiente:
- [9.8/H-2-1] DEBEN proporcionar un aviso explícito al usuario para cada frase de palabra clave que se admita.
- [9.8/H-2-2] NO DEBE conservar datos de audio sin procesar ni datos derivados de ellos a través del servicio de detección de palabras clave.
- [9.8/H-2-3] NO DEBE transmitir desde el servicio de detección de palabras clave, datos de audio, datos que se puedan usar para reconstruir (total o parcialmente) el audio o contenido de audio no relacionado con la palabra clave, excepto a
ContentCaptureService
o al servicio de reconocimiento de voz integrado en el dispositivo.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos portátiles admiten la API del sistema VisualQueryDetectionService
o algún otro mecanismo para la detección de consultas sin indicación de acceso al micrófono o a la cámara, hacen lo siguiente:
- [9.8/H-3-1] DEBE asegurarse de que el servicio de detección de consultas solo pueda transmitir datos al sistema, a
ContentCaptureService
o al servicio de reconocimiento de voz integrado en el dispositivo (creado porSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] NO DEBE permitir que se transmita información de audio o video desde el
VisualQueryDetectionService
, excepto aContentCaptureService
o al servicio de reconocimiento de voz integrado en el dispositivo. - [9.8/H-3-3] DEBE mostrar un aviso para el usuario en la IU del sistema cuando el dispositivo detecte la intención del usuario de interactuar con la aplicación de asistente digital (p. ej., mediante la detección de la presencia del usuario a través de la cámara).
- [9.8/H-3-4] DEBE mostrar un indicador de micrófono y la consulta del usuario detectada en la IU justo después de que se detecte.
- [9.8/H-3-5] NO DEBE permitir que una aplicación instalable por el usuario proporcione el servicio de detección de consultas visuales.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos de mano declaran android.hardware.microphone
, hacen lo siguiente:
- [9.8.2/H-4-1] DEBE mostrar el indicador de micrófono cuando una app accede a datos de audio del micrófono, pero no cuando solo
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
o apps que tengan los roles mencionados en la sección 9.1 acceden al micrófono con el identificador de CDD [C-4-X]. - [9.8.2/H-4-2] DEBE mostrar la lista de apps recientes y activas que usan el micrófono como se muestra en
PermissionManager.getIndicatorAppOpUsageData()
, junto con cualquier mensaje de atribución asociado con ellas.
Si las implementaciones de dispositivos de mano declaran android.hardware.camera.any
, hacen lo siguiente:
- [9.8.2/H-5-1] DEBE mostrar el indicador de cámara cuando una app accede a datos de cámara en vivo, pero no cuando solo las apps que tienen los roles mencionados en la sección 9.1 con el identificador de CDD [C-4-X] acceden a la cámara.
- [9.8.2/H-5-2] DEBEN mostrar las apps recientes y activas que usan la cámara como se muestra en
PermissionManager.getIndicatorAppOpUsageData()
, junto con cualquier mensaje de atribución asociado con ellas.
2.2.6. Compatibilidad de las herramientas y opciones para desarrolladores
Implementaciones de dispositivos de mano (* No se aplica a tablets):
- [6.1/H-0-1]* DEBE admitir el comando de shell
cmd testharness
.
Implementaciones de dispositivos de mano ("No aplicable a tablets"):
- Perfetto
- [6.1/H-0-2]* DEBE exponer un objeto binario
/system/bin/perfetto
al usuario de shell cuya línea de comandos cumpla con la documentación de perfetto. - [6.1/H-0-3]* El objeto binario de 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 objeto binario de perfetto DEBE escribir como resultado un registro 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 objeto binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
- [6.1/H-0-6]* El daemon de seguimiento de perfetto DEBE estar habilitado de forma predeterminada (propiedad del sistema
persist.traced.enable
).
- [6.1/H-0-2]* DEBE exponer un objeto binario
2.2.7. Clase de rendimiento del contenido multimedia para dispositivos portátiles
Consulta la Sección 7.11 para ver la definición de la clase de rendimiento multimedia.
2.2.7.1. Contenido multimedia
Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- DEBEN cumplir con los requisitos de contenido multimedia que se indican en la sección 2.2.7.1 del CDD de Android 13.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos de mano muestranandroid.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- [5.1/H-1-1] DEBE anunciar la cantidad máxima de sesiones de decodificador de video de hardware que se pueden ejecutar de forma simultánea en cualquier combinación de códecs a través de los métodos
CodecCapabilities.getMaxSupportedInstances()
yVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] DEBE admitir 6 instancias de sesiones de decodificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecute de forma simultánea con 3 sesiones a una resolución de 1080p a 30 fps y 3 sesiones a una resolución de 4K a 30 fps. Los códecs AV1 solo deben admitir la resolución 1080p, pero aún deben admitir 6 instancias a 1080p30fps.
- [5.1/H-1-3] DEBE anunciar la cantidad máxima de sesiones de codificador de video de hardware que se pueden ejecutar de forma simultánea en cualquier combinación de códecs a través de los métodos
CodecCapabilities.getMaxSupportedInstances()
yVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] DEBE admitir 6 instancias de sesiones de codificador de video de hardware de 8 bits (SDR) (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecute de forma simultánea con 4 sesiones a una resolución de 1080p a 30 fps y 2 sesiones a una resolución de 4K a 30 fps. Los códecs AV1 solo deben admitir la resolución 1080p, pero aún deben admitir 6 instancias a 1080p30fps.
- [5.1/H-1-5] DEBE anunciar la cantidad máxima de sesiones de codificador y decodificador de video de hardware que se pueden ejecutar de forma simultánea en cualquier combinación de códecs a través de los métodos
CodecCapabilities.getMaxSupportedInstances()
yVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] DEBE admitir 6 instancias de decodificador de video de hardware de 8 bits (SDR) y sesiones de codificador de video de hardware (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecute de forma simultánea con 3 sesiones en resolución 4K a 30 fps, de las cuales, como máximo, 2 son sesiones de codificador y 3 sesiones con resolución 1080p. Los códecs AV1 solo deben admitir la resolución 1080p, pero aún deben admitir 6 instancias a 1080p30fps.
- [5.1/H-1-19] DEBE admitir 3 instancias de decodificador de video de hardware de 10 bits (HDR) y sesiones de codificador de video de hardware (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecute de forma simultánea con una resolución de 4K a 30 fps, de las cuales, como máximo, 1 es una sesión de codificador, que se puede configurar en formato de entrada RGBA_1010102 a través de una superficie GL. No se requiere que el codificador genere metadatos HDR si se codifica desde la superficie de GL. Las sesiones de códec AV1 solo deben admitir la resolución 1080p, incluso cuando este requisito requiera 4K.
- [5.1/H-1-7] DEBE tener una latencia de inicialización del códec de 40 ms o menos para una sesión de codificación de video de 1080p o menor para todos los codificadores de video de hardware cuando estén en carga. La carga aquí se define como una sesión de transcodificación simultánea de solo video de 1080p a 720p que usa códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p. Para el códec Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
- [5.1/H-1-8] DEBE tener una latencia de inicialización del códec de 30 ms o menos para una sesión de codificación de audio de 128 Kbps o menos para todos los codificadores de audio cuando estén en carga. La carga aquí se define como una sesión de transcodificación simultánea de solo video de 1080p a 720p que usa códecs de video de hardware junto con la inicialización de grabación de audio y video de 1080p.
- [5.1/H-1-9] DEBE admitir 2 instancias de sesiones de decodificador de video de hardware seguro (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecute de forma simultánea a una resolución de 1080p a 30 fps para contenido HDR de 8 bits (SDR) y de 10 bits.
- [5.1/H-1-10] DEBE admitir 3 instancias de sesiones de decodificador de video de hardware no seguro junto con 1 instancia de sesión de decodificador de video de hardware seguro (4 instancias en total) (AVC, HEVC, VP9, AV1 o versiones posteriores) en cualquier combinación de códecs que se ejecute de forma simultánea con 3 sesiones en resolución 4K a 30 fps, que incluya una sesión de decodificador seguro y 1 sesión no segura en resolución 1080p a 30 fps, en la que como máximo 2 sesiones pueden estar en HDR de 10 bits. Las sesiones de códec AV1 solo deben admitir la resolución 1080p, incluso cuando este requisito requiera 4K.
- [5.1/H-1-11] DEBE admitir un decodificador seguro para cada decodificador AVC, HEVC, VP9 o AV1 de hardware en el dispositivo.
- [5.1/H-1-12] DEBE tener una latencia de inicialización del códec de 40 ms o menos para una sesión de decodificación de video de 1080p o menos para todos los decodificadores de video de hardware cuando estén en carga. La carga aquí se define como una sesión de transcodificación de solo video de 1080p a 720p simultánea que usa códecs de video de hardware junto con la inicialización de reproducción de audio y video de 1080p. Para el códec Dolby Vision, la latencia de inicialización del códec DEBE ser de 50 ms o menos.
- [5.1/H-1-13] DEBE tener una latencia de inicialización del códec de 30 ms o menos para una sesión de decodificación de audio de 128 Kbps o menos para todos los decodificadores de audio cuando estén en carga. La carga aquí se define como una sesión de transcodificación simultánea de solo video de 1080p a 720p que usa códecs de video de hardware junto con la inicialización de reproducción de audio y video de 1080p.
- [5.1/H-1-14] DEBE admitir el decodificador de hardware de AV1 Main 10, nivel 4.1 y grano de película.
- [5.1/H-1-15] DEBE tener al menos 1 decodificador de video de hardware compatible con 4K60.
- [5.1/H-1-16] DEBE tener al menos 1 codificador de video de hardware compatible con 4K60.
- [5.3/H-1-1] NO DEBE perder más de 1 fotograma en 10 segundos (es decir, menos del 0.167% de pérdida de fotogramas) para una sesión de video 4K a 60 fps bajo carga.
- [5.3/H-1-2] NO DEBE perder más de 1 fotograma en 10 segundos durante un cambio de resolución de video en una sesión de video de 60 fps bajo carga para una sesión 4K.
- [5.6/H-1-1] DEBE tener una latencia de toque para tono de 80 milisegundos o menos con la prueba de toque para tono del verificador de CTS.
- [5.6/H-1-2] DEBE tener una latencia de audio de ida y vuelta de 80 milisegundos o menos en al menos una ruta de datos compatible.
- [5.6/H-1-3] DEBE admitir audio de más de 24 bits para la salida estéreo a través de conectores de audio de 3.5 mm, si están presentes, y a través de audio USB, si es compatible con toda la ruta de datos para configuraciones de transmisión y baja latencia. Para la configuración de baja latencia, la app debe usar AAudio en el modo de devolución de llamada de baja latencia. Para la configuración de transmisión, la app debe usar un AudioTrack de Java. En las configuraciones de baja latencia y transmisión, el sumidero de salida de HAL debe aceptar
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
oAUDIO_FORMAT_PCM_FLOAT
para su formato de salida de destino. - [5.6/H-1-4] DEBE admitir dispositivos de audio USB de más de 4 canales (los controladores de DJ los usan para obtener una vista previa de las canciones).
- [5.6/H-1-5] DEBEN admitir dispositivos MIDI que cumplan con la clase y declarar la marca de función MIDI.
- [5.6/H-1-9] DEBE admitir al menos 12 canales de mezcla. Esto implica la capacidad de abrir un AudioTrack con una máscara de canales 7.1.4 y espacializar o mezclar todos los canales en estéreo de forma correcta.
- [5.6/H-SR] SE RECOMIENDA URGENTEMENTE admitir la mezcla de 24 canales con al menos compatibilidad con las máscaras de canales 9.1.6 y 22.2.
- [5.7/H-1-2] DEBE admitir
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
con las siguientes capacidades de desencriptación de contenido.
Tamaño mínimo de la muestra | 4 MiB |
Cantidad mínima de submuestras: H264 o HEVC | 32 |
Cantidad mínima de submuestras: VP9 | 9 |
Cantidad mínima de submuestras: AV1 | 288 |
Tamaño mínimo del búfer de submuestra | 1 MiB |
Tamaño mínimo del búfer de criptografía genérica | 500 KiB |
Cantidad mínima de sesiones simultáneas | 30 |
Cantidad mínima de claves por sesión | 20 |
Cantidad total mínima de claves (todas las sesiones) | 80 |
Cantidad mínima total de claves de DRM (todas las sesiones) | 6 |
Tamaño del mensaje | 16 KiB |
Fotogramas desencriptados por segundo | 60 fps |
- [5.1/H-1-17] DEBE tener al menos 1 decodificador de imágenes de hardware compatible con el perfil de Baseline de AVIF.
- [5.1/H-1-18] DEBE admitir el codificador AV1, que puede codificar hasta una resolución de 480p a 30 fps y 1 Mbps.
[5.12/H-1-1] OBLIGATORIAMENTE[5.12/H-SR] Se recomienda que admitan la funciónFeature_HdrEditing
para todos los codificadores de hardware AV1 y HEVC presentes en el dispositivo.- [5.12/H-1-2] DEBE admitir el formato de color RGBA_1010102 para todos los codificadores AV1 y HEVC de hardware presentes en el dispositivo.
- [5.12/H-1-3] DEBE anunciar la compatibilidad con la extensión EXT_YUV_target para muestrear texturas YUV en 8 y 10 bits.
- [7.1.4/H-1-1] DEBE tener al menos 6 superposiciones de hardware en la unidad de procesamiento de la pantalla (DPU), con al menos 2 de ellas capaces de mostrar contenido de video de 10 bits.
Si las implementaciones de dispositivos portátiles muestran android.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
y admiten un codificador AVC o HEVC de hardware, cumplen con los siguientes requisitos:
- [5.2/H-2-1] DEBE cumplir con el objetivo de calidad mínimo definido por las curvas de tasa de distorsión del codificador de video para los códecs AVC y HEVC de hardware, como se define en Run Performance Class 14 (PC14)-Video encoding quality (VEQ) tests.
Fin de los nuevos requisitos
2.2.7.2. Cámara
Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- DEBEN cumplir con los requisitos de contenido multimedia que se indican en la sección 2.2.7.2 del CDD de Android 13.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos de mano muestranandroid.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- [7.5/H-1-1] DEBE tener una cámara principal posterior con una resolución de al menos 12 megapíxeles que admita la captura de video en 4K a 30 fps. La cámara posterior principal es la que tiene el ID más bajo.
- [7.5/H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 6 megapíxeles y admitir captura de video en 1080p a 30 fps. La cámara frontal principal es la que tiene el ID más bajo.
- [7.5/H-1-3] DEBE admitir la propiedad
android.info.supportedHardwareLevel
comoFULL
o superior para la cámara principal posterior yLIMITED
o superior para la cámara principal frontal. - [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 de JPEG de camera2 inferior a 1000
900ms para una resolución de 1080p, según lo mida la prueba de rendimiento de la cámara CTS en las condiciones de iluminación de ITS (3000 K) para ambas cámaras principales. - [7.5/H-1-6] DEBE tener una latencia de inicio de Camera2 (abrir la cámara hasta el primer fotograma de vista previa) inferior a 500 ms, según lo mida la prueba de rendimiento de la cámara CTS en condiciones de iluminación ITS (3000 K) para ambas cámaras principales.
- [7.5/H-1-8] DEBE admitir
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
yandroid.graphics.ImageFormat.RAW_SENSOR
para la cámara posterior principal. - [7.5/H-1-9] DEBE tener una cámara principal posterior compatible con 720p o 1080p a 240 fps.
- [7.5/H-1-10] DEBE tener un ZOOM_RATIO mínimo inferior a 1.0 para las cámaras principales si hay una cámara RGB ultra gran angular orientada en la misma dirección.
- [7.5/H-1-11] DEBEN implementar la transmisión simultánea frontal y posterior en las cámaras principales.
- [7.5/H-1-12] DEBE admitir
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
para la cámara frontal y la posterior principales. - [7.5/H-1-13] DEBE admitir la función
LOGICAL_MULTI_CAMERA
para la cámara posterior principal si hay más de 1 cámara posterior RGB. - [7.5/H-1-14] DEBE admitir la función
STREAM_USE_CASE
para la cámara frontal y la posterior principales. - [7.5/H-1-15] DEBEN admitir las extensiones de
Bokeh ymodo nocturno a través de las extensiones de CameraX y Camera2 para las cámaras principales. - [7.5/H-1-16] DEBE admitir la función DYNAMIC_RANGE_TEN_BIT para las cámaras principales.
- [7.5/H-1-17] DEBEN admitir CONTROL_SCENE_MODE_FACE_PRIORITY y detección de rostros (STATISTICS_FACE_DETECT_MODE_SIMPLE o STATISTICS_FACE_DETECT_MODE_FULL) para las cámaras principales.
Fin de los nuevos requisitos
2.2.7.3. Hardware
Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- DEBEN cumplir con los requisitos de contenido multimedia que se indican en la sección 2.2.7.3 del CDD de Android 13.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos de mano muestranandroid.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- [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 dpi.
- [7.1.1.3/H-3-1] DEBE tener una pantalla HDR compatible con al menos 1,000 nits de promedio.
- [7.6.1/H-2-1] DEBE tener al menos 8 GB de memoria física.
Fin de los nuevos requisitos
2.2.7.4. Rendimiento
Si las implementaciones de dispositivos de mano muestran android.os.Build.VERSION_CODES.T
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- DEBEN cumplir con los requisitos de rendimiento que se indican en la sección 2.2.7.4 del CDD de Android 13.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos de mano muestranandroid.os.Build.VERSION_CODES.U
para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, sucede lo siguiente:
- [8.2/H-1-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 150 MB/s.
- [8.2/H-1-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 10 MB/s.
- [8.2/H-1-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 250 MB/s.
- [8.2/H-1-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 100 MB/s.
- [8.2/H-1-5] DEBE garantizar un rendimiento de lectura y escritura secuencial en paralelo con el doble de rendimiento de lectura y el rendimiento de escritura de al menos 50 MB/s.
Fin de los nuevos requisitos
2.3. Requisitos de la televisión
Un dispositivo Android Television hace referencia a una implementación de dispositivo Android que es una interfaz de entretenimiento para consumir contenido multimedia digital, películas, juegos, apps o TV en vivo para usuarios que se sientan a unos tres metros de distancia (una interfaz de usuario “reclinada” o “de 10 pies”).
Las implementaciones de dispositivos Android se clasifican como una televisión si cumplen con todos los siguientes criterios:
- Proporcionaste un mecanismo para controlar de forma remota la interfaz de usuario renderizada en la pantalla que podría estar a tres metros de distancia del usuario.
- Tener una pantalla integrada con una longitud diagonal superior a 60 cm O incluir un puerto de salida de video, como VGA, HDMI, DisplayPort o un puerto inalámbrico para la pantalla
Los requisitos adicionales que se mencionan 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 TV:
- [7.2.2/T-0-1] DEBE admitir el pad direccional.
- [7.2.3/T-0-1] DEBEN proporcionar las funciones Inicio y Atrás.
- [7.2.3/T-0-2] DEBE enviar el evento de presión normal y prolongada de la función Atrás (
KEYCODE_BACK
) a la aplicación en primer plano. - [7.2.6.1/T-0-1] DEBE incluir compatibilidad con los controles de juegos y declarar la marca de función
android.hardware.gamepad
. - [7.2.7/T] DEBE proporcionar un control remoto desde el que los usuarios puedan acceder a las entradas de navegación no táctil y teclas de navegación principales.
Si las implementaciones de dispositivos de TV incluyen un giroscopio de 3 ejes, tienen las siguientes características:
- [7.3.4/T-1-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.
- [7.3.4/T-1-2] DEBE ser capaz de medir cambios de orientación de hasta 1,000 grados por segundo.
Implementaciones de dispositivos de TV:
- [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 TV incluyen un puerto USB que admite el modo host, hacen lo siguiente:
- [7.5.3/T-1-1] DEBE incluir compatibilidad con una cámara externa que se conecte 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, haz lo siguiente:
[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 usa alguna de las siguientes densidades:
- 400 dpi o superior en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas extragrandes
Si las implementaciones de dispositivos de TV son de 64 bits, haz lo siguiente:
[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 usa alguna de las siguientes densidades:
- 400 dpi o superior en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas extragrandes
Ten en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior hace referencia al espacio de memoria proporcionado además de la memoria que ya está dedicada a componentes de hardware, como radio, video, etcétera, que no están bajo el control del kernel en las implementaciones de dispositivos.
Implementaciones de dispositivos de TV:
- [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 TV DEBEN admitir los siguientes formatos de codificación y decodificación de audio, y ponerlos a disposición de las aplicaciones de terceros:
- [5.1/T-0-1] Perfil AAC de MPEG-4 (AAC LC)
- [5.1/T-0-2] Perfil HE AAC de MPEG-4 (AAC+)
- [5.1/T-0-3] AAC ELD (AAC mejorado de bajo retraso)
Las implementaciones de dispositivos de TV DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de las aplicaciones de terceros:
Implementaciones de dispositivos de TV:
- [5.2.2/T-SR-1] SE RECOMIENDA ENFATICAMENTE que admitan la codificación H.264 de videos con resolución de 720p y 1080p a 30 fotogramas por segundo.
Las implementaciones de dispositivos de TV DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de las aplicaciones de terceros:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
Las implementaciones de dispositivos de TV DEBEN admitir la decodificación de MPEG-2, como se detalla en el artículo 5.3.1, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:
- [5.3.1/T-1-1] HD 1080p a 29.97 fotogramas por segundo con nivel alto de perfil principal
- [5.3.1/T-1-2] HD 1080i a 59.94 fotogramas por segundo con nivel alto de perfil principal DEBEN desentrelazar el video MPEG-2 entrelazado y ponerlo a disposición de aplicaciones de terceros.
Las implementaciones de dispositivos de TV DEBEN admitir la decodificación H.264, como se detalla en el artículo 5.3.4, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:
- [5.3.4/T-1-1] HD 1080p a 60 fotogramas por segundo con perfil de Baseline
- [5.3.4/T-1-2] HD 1080p a 60 fotogramas por segundo con perfil principal
- [5.3.4/T-1-3] HD 1080p a 60 fotogramas por segundo con nivel de perfil alto 4.2
Las implementaciones de dispositivos de TV con decodificadores de hardware H.265 DEBEN admitir la decodificación H.265, como se detalla en el artículo 5.3.5, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:
- [5.3.5/T-1-1] HD 1080p a 60 fotogramas por segundo con nivel de perfil principal 4.1
Si las implementaciones de dispositivos de TV con decodificadores de hardware H.265 admiten la decodificación H.265 y el perfil de decodificación UHD, hacen lo siguiente:
- [5.3.5/T-2-1] DEBE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil de nivel principal Main10 de nivel 5.
Las implementaciones de dispositivos de TV DEBEN admitir la decodificación de VP8, como se detalla en el artículo 5.3.6, en velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:
- [5.3.6/T-1-1] Perfil de decodificación de HD 1080p a 60 fotogramas por segundo
Las implementaciones de dispositivos de TV con decodificadores de hardware VP9 DEBEN admitir la decodificación de VP9, como se detalla en el artículo 5.3.7, con velocidades de fotogramas de video estándar y resoluciones hasta las siguientes:
- [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 TV con decodificadores de hardware VP9 admiten la decodificación de VP9 y el perfil de decodificación UHD, hacen lo siguiente:
- [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-SR1] SE RECOMIENDA ENFATICAMENTE 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 TV:
- [5.5/T-0-1] DEBE incluir compatibilidad con el volumen principal del sistema y la atenuación del volumen de salida de audio digital en las salidas compatibles, excepto para la salida de transferencia de audio comprimido (en la que no se realiza la decodificación de audio en el dispositivo).
Si las implementaciones de dispositivos de TV no tienen una pantalla integrada, pero admiten una pantalla externa conectada a través de HDMI, tienen las siguientes características:
- [5.8/T-0-1] SE DEBE configurar el modo de salida HDMI en la resolución más alta para el formato de píxeles elegido que funcione con una frecuencia de actualización de 50 Hz o 60 Hz para la pantalla externa, según la frecuencia de actualización de video de la región en la que se vende el dispositivo.
DEBES configurar el modo de salida HDMI para seleccionar la resolución máxima que se puede admitir con una frecuencia de actualización de 50 Hz o 60 Hz. - [5.8/T-SR-1] SE RECOMIENDA ENFATICAMENTE que proporcionen un selector de frecuencia de actualización HDMI configurable por el usuario.
- [5.8] DEBE establecer la frecuencia de actualización del modo de salida HDMI en 50 Hz o 60 Hz, según la frecuencia de actualización de video de la región en la que se vende el dispositivo.
Si las implementaciones de dispositivos de TV no tienen una pantalla integrada, pero admiten una pantalla externa conectada a través de HDMI, tienen las siguientes características:
- [5.8/T-1-1] DEBE admitir HDCP 2.2.
Si las implementaciones de dispositivos de TV no admiten la decodificación UHD, pero sí una pantalla externa conectada a través de HDMI, sucede lo siguiente:
- [5.8/T-2-1] DEBE admitir HDCP 1.4.
2.3.3. Software
Implementaciones de dispositivos de TV:
- [3/T-0-1] DEBEN declarar las funciones
android.software.leanback
yandroid.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 intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de la aplicación que se enumeran aquí.
- [3.4.1/T-0-1] DEBE proporcionar una implementación completa de la API de
android.webkit.Webview
.
Si las implementaciones de dispositivos Android TV admiten una pantalla de bloqueo,deben cumplir con los siguientes requisitos:
- [3.8.10/T-1-1] DEBEN mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación multimedia.
Implementaciones de dispositivos de TV:
- [3.8.14/T-SR-1] SE RECOMIENDA VETAMENTE que admitan el modo multiventana de imagen en imagen (PIP).
- [3.10/T-0-1] DEBE admitir servicios de accesibilidad de terceros.
- [3.10/T-SR-1] SE RECOMIENDA ENFATICAMENTE que se carguen previamente servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de accesibilidad con interruptores y TalkBack (para los idiomas compatibles con el motor de texto a voz preinstalado) o que la superen, como se proporciona en el proyecto de código abierto de TalkBack.
Si las implementaciones de dispositivos de TV informan la función android.hardware.audio.output
, hacen lo siguiente:
- [3.11/T-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un motor de TTS que admita los idiomas disponibles en el dispositivo.
- [3.11/T-1-1] DEBE admitir la instalación de motores de TTS de terceros.
Implementaciones de dispositivos de TV:
- [3.12/T-0-1] DEBE admitir el framework de entrada de TV.
2.3.4. Rendimiento y energía
- [8.1/T-0-1] Latencia de fotogramas coherente. La latencia de fotogramas incoherente o una demora para renderizar fotogramas NO DEBEN ocurrir más de 5 veces 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 TV incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o extienden las funciones que se incluyen en AOSP, deben cumplir con los siguientes requisitos:
- [8.3/T-1-1] DEBE proporcionar indicaciones visuales para el usuario para habilitar y deshabilitar la función de ahorro de batería.
Si las implementaciones de dispositivos de TV no tienen una batería, sucede lo siguiente:
- [8.3/T-1-2] DEBE registrar el dispositivo como un dispositivo sin batería, como se describe en Compatibilidad con dispositivos sin batería.
Si las implementaciones de dispositivos de TV tienen una batería, hacen lo siguiente:
- [8.3/T-1-3] DEBEN proporcionar indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.
Implementaciones de dispositivos de TV:
- [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 la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del proyecto de código abierto de Android.
- [8.4/T-0-2] DEBEN informarse 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 UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo del kernel
uid_cputime
. - [8.4/T] DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo de energía del componente de hardware a una aplicación.
- [8.4/T-0-4] DEBE hacer que este consumo de energía esté disponible para el desarrollador de la app a través del comando de shell
adb shell dumpsys batterystats
.
2.3.5. Modelo de seguridad
Implementaciones de dispositivos de TV:
- [9/T-0-1] DEBE declarar la función
android.hardware.security.model.compatible
. - [9.11/T-0-1] DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
- [9.11/T-0-2] DEBEN tener implementaciones de algoritmos de criptografía RSA, AES, ECDSA y HMAC, y funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles del sistema de almacén de claves de Android en un área que esté aislada de forma segura del código que se ejecuta en el kernel y en niveles superiores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos con los que el código del kernel o del espacio de usuario pueda acceder al estado interno del entorno aislado, incluida la DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante la implementación de 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 aislado y, solo cuando se realice correctamente, permitir que se usen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
- [9.11/T-0-4] DEBE admitir la certificación de claves en la que la clave de firma de certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse en una cantidad de dispositivos lo suficientemente grande como para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con 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 usar una clave diferente para cada 100,000 unidades.
Ten en cuenta que, si ya se lanzó una implementación de dispositivo en una versión anterior de Android, ese dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la certificación de claves, a menos que declare la función android.hardware.fingerprint
, que requiere un almacén de claves respaldado por un entorno de ejecución aislado.
Si las implementaciones de dispositivos de TV admiten una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:
- [9.11/T-1-1] DEBE permitir que el usuario elija el tiempo de espera de suspensión 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 TV incluyen varios usuarios y no declaran la marca de función android.hardware.telephony
, sucede lo siguiente:
- [9.5/T-2-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
Si las implementaciones de dispositivos de TV incluyen varios usuarios y declaran la marca de función android.hardware.telephony
, hacen lo siguiente:
- [9.5/T-3-1] NO DEBEN admitir perfiles restringidos, pero DEBEN alinearse con la implementación de controles de AOSP para habilitar o inhabilitar que otros usuarios accedan a las llamadas de voz y los SMS.
Si las implementaciones de dispositivos de TV declaran android.hardware.microphone
, hacen lo siguiente:
- [9.8.2/T-4-1] DEBE mostrar el indicador de micrófono cuando una app accede a datos de audio del micrófono, pero no cuando solo HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService o apps que tengan los roles mencionados en la sección 9.1 de Permisos con el identificador de CDD C-3-X acceden al micrófono.
- [9.8.2/T-4-2] NO DEBE ocultar el indicador de micrófono de las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
Si las implementaciones de dispositivos de TV declaran android.hardware.camera.any
, hacen lo siguiente:
- [9.8.2/T-5-1] DEBE mostrar el indicador de cámara cuando una app accede a datos de cámara en vivo, pero no cuando solo las apps que tienen los roles que se mencionan en la sección 9.1 Permisos con identificador de CDD [C-3-X] acceden a la cámara.
- [9.8.2/T-5-2] NO DEBEN ocultar el indicador de la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
2.3.6. Compatibilidad de las herramientas y opciones para desarrolladores
Implementaciones de dispositivos de TV:
- Perfetto
- [6.1/T-0-1] DEBE exponer un objeto binario
/system/bin/perfetto
al usuario de shell cuya línea de comandos cumpla con la documentación de perfetto. - [6.1/T-0-2] El objeto binario de perfetto DEBE aceptar como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto.
- [6.1/T-0-3] El objeto binario de perfetto DEBE escribir como resultado un registro de protobuf que cumpla con el esquema definido en la documentación de perfetto.
- [6.1/T-0-4] DEBE proporcionar, a través del archivo binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
- [6.1/T-0-1] DEBE exponer un objeto binario
2.4. Requisitos del reloj
Un dispositivo Android Watch hace referencia a una implementación de dispositivo Android diseñada para usarse en el cuerpo, por ejemplo, en la muñeca.
Las implementaciones de dispositivos Android se clasifican como relojes si cumplen con todos los criterios a continuación:
- Tener una pantalla con una longitud diagonal física de entre 1.1 y 2.5 pulgadas
- Tener un mecanismo para llevarlo en el cuerpo
Los requisitos adicionales que se mencionan en el resto de esta sección son específicos de las implementaciones de dispositivos Android Watch.
2.4.1. Hardware
Mira las implementaciones de dispositivos:
[7.1.1.1/W-0-1] DEBE tener una pantalla con el 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 la pantalla táctil.
[7.3.1/W-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un acelerómetro de 3 ejes.
Si las implementaciones de dispositivos de reloj incluyen un receptor GPS/GNSS y reportan la función a las aplicaciones a través de la marca de función android.hardware.location.gps
, hacen lo siguiente:
- [7.3.3/W-1-1] DEBEN informar las mediciones de GNSS en cuanto se encuentren, incluso si aún no se informa una ubicación calculada a partir del GPS/GNSS.
- [7.3.3/W-1-2] DEBEN informar las pseudorangos y las tasas de pseudorangos del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras están inmóviles o se mueven con menos de 0.2 metros por segundo cuadrado de aceleración, son suficientes para calcular la posición dentro de 20 metros y la velocidad dentro de 0.2 metros por segundo, al menos el 95% del tiempo.
Si las implementaciones de dispositivos de reloj incluyen un giroscopio de 3 ejes, tienen las siguientes características:
- [7.3.4/W-2-1] DEBE ser capaz de medir cambios de orientación de hasta 1,000 grados por segundo.
Mira las 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
No hay requisitos adicionales.
2.4.3. Software
Mira las implementaciones de dispositivos:
- [3/W-0-1] DEBE declarar la función
android.hardware.type.watch
. - [3/W-0-2] DEBE admitir uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] DEBE precargar uno o más componentes de servicio o aplicación con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de la aplicación que se indican aquí.
Mira las implementaciones de dispositivos:
- [3.8.4/W-SR-1] SE RECOMIENDA INTENSAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.
Mira las implementaciones de dispositivos que declaran la marca 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 ENFATICAMENTE que se carguen previamente servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de Accesibilidad con interruptores y TalkBack (para los idiomas compatibles con el motor de texto a voz preinstalado), o que la superen, como se proporciona en el proyecto de código abierto de TalkBack.
Si las implementaciones de dispositivos de reloj informan la función android.hardware.audio.output, hacen lo siguiente:
[3.11/W-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un motor de TTS compatible con los idiomas disponibles en el dispositivo.
[3.11/W-0-1] DEBE admitir la instalación de motores de TTS de terceros.
2.4.4. Rendimiento y energía
Si las implementaciones de dispositivos de reloj incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o extienden las funciones que se incluyen en AOSP, deben cumplir con los siguientes requisitos:
- [8.3/W-SR-1] SE RECOMIENDA ENFATICAMENTE que se proporcione una indicación visual para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Doze.
- [8.3/W-SR-2] SE RECOMIENDA ENFATICAMENTE que se proporcione una indicación visual para el usuario para habilitar y deshabilitar la función de ahorro de batería.
Mira las 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 la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del proyecto de código abierto de Android.
- [8.4/W-0-2] DEBEN informarse 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 UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de 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 para el desarrollador de la app a través del comando de shell
adb shell dumpsys batterystats
. - [8.4/W] DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo de energía del componente de hardware a una aplicación.
2.4.5. Modelo de seguridad
Mira las implementaciones de dispositivos:
- [9/W-0-1] DEBE declarar la función
android.hardware.security.model.compatible
.
Si las implementaciones de dispositivos para Wear incluyen varios usuarios y no declaran la marca de función android.hardware.telephony
, sucede lo siguiente:
- [9.5/W-1-1] DEBEN admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
Si las implementaciones de dispositivos de reloj incluyen varios usuarios y declaran la marca de función android.hardware.telephony
, hacen lo siguiente:
- [9.5/W-2-1] NO DEBEN admitir perfiles restringidos, pero DEBEN alinearse con la implementación de controles de AOSP para habilitar o inhabilitar que otros usuarios accedan a las llamadas de voz y los SMS.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y, además, incluyen uno o más agentes de confianza que implementan la API del sistema TrustAgentService
, hacen lo siguiente:
- [9.11.1/W-1-1] DEBE solicitarle al usuario uno de los métodos de autenticación principales recomendados (p. ej., PIN, patrón o contraseña) con más frecuencia que una vez cada 72 horas.
Fin de los nuevos requisitos
2.5. Requisitos de Automotive
La implementación de Android Automotive hace referencia a una consola central de un vehículo que ejecuta Android como sistema operativo para parte o la totalidad del sistema o la funcionalidad de infoentretenimiento.
Las implementaciones de dispositivos Android se clasifican como Automotive si declaran la función android.hardware.type.automotive
o cumplen con todos los siguientes criterios.
- Se incorporan como parte de un vehículo automotor o se pueden conectar a él.
- Usan una pantalla en la fila del asiento del conductor como pantalla principal.
Los requisitos adicionales que se mencionan en el resto de esta sección son específicos de las implementaciones de dispositivos Android Automotive.
2.5.1. Hardware
Implementaciones de dispositivos para la industria automotriz:
- [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 × 480 dp.
- [7.2.3/A-0-1] DEBE proporcionar la función de inicio y PUEDE proporcionar las funciones Atrás y Recientes.
- [7.2.3/A-0-2] DEBE enviar el evento de presión normal y prolongada de la función Atrás (
KEYCODE_BACK
) a la aplicación en primer plano. - [7.3/A-0-1] DEBEN implementar y generar informes sobre
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
yPARKING_BRAKE_ON
. - [7.3/A-0-2] El valor de la marca
NIGHT_MODE
DEBE ser coherente con el modo día/noche del panel y DEBE basarse en la entrada del sensor de luz ambiental. El sensor de luz ambiente 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-SR1] PUEDE calcular la ubicación por medio de la fusión de GPS/GNSS con sensores adicionales. Si la Ubicación se calcula por inferencia, te RECOMENDAMOS que implementes y registres los tipos de Sensor o los IDs de propiedad del vehículo que se usan.
[7.3/A-0-4] La ubicación que se solicita a través de LocationManager#requestLocationUpdates() NO DEBE coincidir con el mapa.
[7.3.1/A-0-4] DEBEN cumplir con el sistema de coordenadas de sensores de automóviles de Android.
[7.3/A-SR-1] SE RECOMIENDA_ENFATICAMENTE incluir un acelerómetro y un giroscopio de 3 ejes.
[7.3/A-SR-2] SE RECOMIENDA_ENFATICAMENTE implementar y generar informes del sensor
TYPE_HEADING
.
Si las implementaciones de dispositivos para la industria automotriz admiten OpenGL ES 3.1, tienen las siguientes características:
- [7.1.4.1/A-0-1] DEBE declarar OpenGL ES 3.1 o versiones posteriores.
- [7.1.4.1/A-0-2] DEBE admitir Vulkan 1.1.
- [7.1.4.1/A-0-3] DEBE incluir el cargador de Vulkan y exportar todos los símbolos.
Si las implementaciones de dispositivos para la industria automotriz incluyen un acelerómetro, tienen las siguientes características:
- [7.3.1/A-1-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.
Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, tienen las siguientes características:
- [7.3.1/A-SR-1] SE RECOMIENDA ENFATICAMENTE implementar el sensor compuesto para el acelerómetro de ejes limitados.
Si las implementaciones de dispositivos para la industria automotriz incluyen un acelerómetro con menos de 3 ejes, sucede lo siguiente:
- [7.3.1/A-1-3] DEBEN implementar y registrar el sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] DEBEN implementar y generar informes sobre el sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Si las implementaciones de dispositivos para la industria automotriz incluyen un giroscopio, tienen las siguientes características:
- [7.3.4/A-2-1] DEBE poder informar eventos hasta 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 ENFATICAMENTE configurar el rango de medición del giroscopio en +/-250 dps para maximizar la resolución posible.
Si las implementaciones de dispositivos para la industria automotriz incluyen un giroscopio de 3 ejes, tienen las siguientes características:
- [7.3.4/A-SR-2] SE RECOMIENDA ENFATICAMENTE implementar el sensor compuesto para el giroscopio de ejes limitados.
Si las implementaciones de dispositivos para la industria automotriz incluyen un giroscopio con menos de 3 ejes, tienen las siguientes características:
- [7.3.4/A-4-1] DEBEN implementar y generar informes sobre el sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] DEBEN implementar y generar informes sobre el sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Si las implementaciones de dispositivos para vehículos incluyen un receptor GPS/GNSS, pero no incluyen conectividad de datos basada en redes móviles, tienen las siguientes características:
- [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 en un plazo de 60 segundos.
- [7.3.3/A-3-2] DEBEN cumplir con los criterios de tiempo para la primera correcció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). Por lo general, el requisito 7.3.3/C-1-2 se cumple en vehículos sin conectividad de datos basada en redes celulares mediante predicciones de órbitas del GNSS calculadas en el receptor o con la última ubicación conocida del vehículo junto con la capacidad de realizar un cálculo de posición durante al menos 60 segundos con una precisión de posición que cumpla con 7.3.3/C-1-3, o una combinación de ambas.
Si las implementaciones de dispositivos para la industria automotriz incluyen un sensor TYPE_HEADING
, hacen lo siguiente:
- [7.3.4/A-4-3] DEBE poder informar eventos hasta una frecuencia de al menos 1 Hz.
- [7.3.4/A-SR-3] SE_RECOMIENDA_ENFATICAMENTE informar eventos hasta una frecuencia de al menos 10 Hz.
- DEBE estar en referencia al norte verdadero.
- DEBE estar disponible incluso cuando el vehículo está detenido.
- DEBE tener una resolución de al menos 1 grado.
Implementaciones de dispositivos para la industria automotriz:
- [7.4.3/A-0-1] DEBE ser compatible con Bluetooth y DEBE ser compatible con Bluetooth LE.
- [7.4.3/A-0-2] Las implementaciones de Android Automotive deben admitir los siguientes perfiles de Bluetooth:
- Llamadas telefónicas con el perfil de manos libres (HFP)
- Reproducción de contenido multimedia a través del perfil de distribución de audio (A2DP)
- Control de reproducción de contenido multimedia a través del perfil de control remoto (AVRCP)
- Uso compartido de contactos con el perfil de acceso a la libreta de direcciones (PBAP)
[7.4.3/A-SR-1] SE RECOMIENDA ENFATICAMENTE que admitan el Perfil de Acceso a Mensajes (MAP).
[7.4.5/A] DEBE incluir compatibilidad con la conectividad de datos basada en redes móviles.
[7.4.5/A] PUEDE usar la constante
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
de la API del sistema para las redes que deberían estar disponibles para las apps del sistema.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos incluyen compatibilidad con la radio de transmisión AM/FM y exponen la funcionalidad a cualquier aplicación, hacen lo siguiente:
- [7.4
.10/A-0-1] Debe declarar compatibilidad conFEATURE_BROADCAST_RADIO
.
Fin de los nuevos requisitos
Una cámara de visión exterior es una cámara que captura imágenes de escenas fuera de la implementación del dispositivo, como la cámara retrovisor.
Implementaciones de dispositivos para la industria automotriz:
- DEBE incluir una o más cámaras con vista exterior.
Si las implementaciones de dispositivos para la industria automotriz incluyen una cámara de visión exterior, para esa cámara, deben cumplir con los siguientes requisitos:
- [7.5/A-1-1] NO DEBEN tener cámaras de visión exterior a las que se pueda acceder a través de las APIs de la cámara de Android, a menos que cumplan con los requisitos principales de la cámara.
[7.5/A-SR-1] SE RECOMIENDA NO rotar ni duplicar horizontalmente la vista previa de la cámara.
[7.5/A-SR-2] SE RECOMIENDA ENFATICAMENTE que tengan una resolución de al menos 1.3 megapíxeles.
DEBE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
PUEDE tener el enfoque automático de hardware o software implementado en el controlador de la cámara.
Si las implementaciones de dispositivos para la industria automotriz incluyen una o más cámaras de vista exterior y cargan el servicio del sistema de vista exterior (EVS), para una cámara de este tipo, hacen lo siguiente:
- [7.5/A-2-1] NO DEBE rotar ni reflejar horizontalmente la vista previa de la cámara.
Implementaciones de dispositivos para la industria automotriz:
- PUEDE incluir una o más cámaras que estén disponibles para aplicaciones de terceros.
Si las implementaciones de dispositivos para automóviles incluyen al menos una cámara y la ponen a disposición de aplicaciones de terceros, deben cumplir con los siguientes requisitos:
- [7.5/A-3-1] DEBE informar la marca de función
android.hardware.camera.any
. - [7.5/A-3-2] NO DEBE declarar la cámara como una cámara del sistema.
- PUEDEN admitir cámaras externas como se describe en la sección 7.5.3.
- PUEDE incluir funciones (como el enfoque automático, etcétera) disponibles para las cámaras posteriores, como se describe en la sección 7.5.1.
Cómo iniciar nuevos requisitos
Una cámara posterior es una cámara orientada al exterior que se puede ubicar en cualquier lugar del vehículo y que está orientada hacia el exterior de la cabina del vehículo, es decir, captura imágenes de escenas en el extremo más alejado de la carrocería del vehículo, como la cámara retrovisor.
Una cámara frontal es una cámara orientada al usuario que se puede ubicar en cualquier lugar del vehículo y que está orientada hacia el interior de la cabina del vehículo, es decir, que captura imágenes del usuario, como en el caso de las videoconferencias y aplicaciones similares.
Implementaciones de dispositivos para la industria automotriz:
- [7.5/A-SR-1] SE RECOMIENDA ENFATICAMENTE incluir una o más cámaras orientadas hacia el exterior.
- PUEDEN incluir una o más cámaras orientadas al usuario.
- [7.5/A-SR-2] SE RECOMIENDA ENFATICAMENTE admitir la transmisión simultánea de varias cámaras.
Si las implementaciones de dispositivos para la industria automotriz incluyen al menos una cámara que está orientada hacia el exterior, para esa cámara, deben cumplir con los siguientes requisitos:
- [7.5/A-1-1] DEBE estar orientado de modo que la dimensión larga de la cámara se alinee con el plano XY de los ejes del sensor de Android Automotive.
- [7.5/A-SR-3] SE RECOMIENDA ENFATICAMENTE que tengas hardware con enfoque fijo o EDOF (profundidad de campo extendida).
- [7.5/A-1-2] DEBE tener la cámara principal orientada hacia el exterior como la cámara orientada hacia el exterior con el ID de cámara más bajo.
Si las implementaciones de dispositivos para la industria automotriz incluyen al menos una cámara orientada al usuario, para esa cámara, haz lo siguiente:
- [7.5/A-2-1] La cámara principal orientada al usuario DEBE ser la cámara orientada al usuario con el ID de cámara más bajo.
- PUEDE orientarse de modo que la dimensión larga de la cámara se alinee con el plano XY de los ejes de los sensores de Automotive de Android.
Si las implementaciones de dispositivos para la industria automotriz incluyen una cámara a la que se puede acceder a través de la API de android.hardware.Camera
o android.hardware.camera2
, deben cumplir con los siguientes requisitos:
- [7.5/A-3-1] DEBEN cumplir con los requisitos principales de la cámara que se indican en el artículo 7.5.
Si las implementaciones de dispositivos para la industria automotriz incluyen una cámara a la que no se puede acceder a través de la API de android.hardware.Camera
o android.hardware.camera2
, sucede lo siguiente:
- [7.5/A-4-1] SE DEBE poder acceder a él a través del servicio del sistema de vista extendida.
Si las implementaciones de dispositivos para vehículos incluyen una o más cámaras a las que se puede acceder a través del servicio del sistema de vista extendida, para una cámara de este tipo, deben cumplir con los siguientes requisitos:
- [7.5/A-5-1] NO DEBE rotar ni duplicar horizontalmente la vista previa de la cámara.
- [7.5/A-SR-4] SE RECOMIENDA ENFATICAMENTE que tengan una resolución de al menos 1.3 megapíxeles.
Si las implementaciones de dispositivos para la industria automotriz incluyen una o más cámaras a las que se puede acceder a través del servicio del sistema de vista extendida y la API de android.hardware.Camera
o android.hardware.Camera2
, para una cámara de este tipo, se hace lo siguiente:
- [7.5/A-6-1] DEBE informar el mismo ID de cámara.
Si las implementaciones de dispositivos para la industria automotriz proporcionan una API de cámara propietaria, deben cumplir con los siguientes requisitos:
- [7.5/A-7-1] DEBE implementar una API de cámara de este tipo con la API de
android.hardware.camera2
o la API de Extended View System.
Fin de los nuevos requisitos
Implementaciones de dispositivos para la industria automotriz:
[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 rendimiento y una longevidad mejorados en el almacenamiento flash, por ejemplo, con el sistema de archivos
f2fs
.
Si las implementaciones de dispositivos para la industria automotriz proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble, hacen lo siguiente:
- [7.6.1/A-SR-1] SE RECOMIENDA ENFATICAMENTE reducir la sobrecarga de E/S en las operaciones que se realizan en el almacenamiento externo, por ejemplo, con
SDCardFS
.
Si las implementaciones de dispositivos para la industria automotriz son de 64 bits, haz lo siguiente:
[7.6.1/A-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 816 MB si se usa alguna de las siguientes densidades:
- 280 dpi o menos en pantallas pequeñas o normales
- ldpi o inferior en pantallas extragrandes
- mdpi o inferior en pantallas grandes
[7.6.1/A-2-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si se usa alguna de las siguientes densidades:
- xhdpi o superior en pantallas pequeñas o normales
- hdpi o superior en pantallas grandes
- mdpi o superior en pantallas extragrandes
[7.6.1/A-2-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se usa alguna de las siguientes densidades:
- 400 dpi o superior en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas extragrandes
[7.6.1/A-2-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1824 MB si se usa alguna de las siguientes densidades:
- 560 dpi o superior en pantallas pequeñas o normales
- 400 dpi o superior en pantallas grandes
- xhdpi o superior en pantallas extragrandes
Ten en cuenta que la "memoria disponible para el kernel y el espacio de usuario" anterior hace referencia al espacio de memoria proporcionado, además de la memoria ya dedicada a componentes de hardware, como radio, video, etcétera, que no están bajo el control del kernel en las implementaciones de dispositivos.
Implementaciones de dispositivos para la industria automotriz:
- [7.7.1/A] DEBE incluir un puerto USB compatible con el modo periférico.
Implementaciones de dispositivos para la industria automotriz:
- [7.8.1/A-0-1] DEBE incluir un micrófono.
Implementaciones de dispositivos para la industria automotriz:
- [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 para vehículos DEBEN admitir los siguientes formatos de codificación y decodificación de audio, y ponerlos a disposición de las aplicaciones de terceros:
- [5.1/A-0-1] Perfil AAC de MPEG-4 (AAC LC)
- [5.1/A-0-2] Perfil HE AAC de MPEG-4 (AAC+)
- [5.1/A-0-3] AAC ELD (AAC mejorado de bajo retraso)
Las implementaciones de dispositivos para vehículos DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de las aplicaciones de terceros:
Las implementaciones de dispositivos para vehículos DEBEN admitir los siguientes formatos de decodificación de video y ponerlos a disposición de las aplicaciones de terceros:
Se RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos para vehículos admitan la siguiente decodificación de video:
- [5.3/A-SR-1] H.265 HEVC
2.5.3. Software
Implementaciones de dispositivos para la industria automotriz:
[3/A-0-1] DEBE declarar la función
android.hardware.type.automotive
.[3/A-0-2] DEBE admitir uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] DEBE admitir todas las APIs públicas en el espacio de nombres
android.car.*
.
Si las implementaciones de dispositivos de Automotive proporcionan una API propietaria con android.car.CarPropertyManager
con android.car.VehiclePropertyIds
, hacen lo siguiente:
- [3/A-1-1] NO DEBE adjuntar privilegios especiales al uso de estas propiedades por parte de la aplicación del sistema ni impedir que las aplicaciones de terceros las usen.
- [3/A-1-2] NO DEBE replicar una propiedad de vehículo que ya exista en el SDK.
Implementaciones de dispositivos para la industria automotriz:
[3.2.1/A-0-1] DEBE admitir y aplicar todas las constantes de permisos como se documenta en la página de referencia de permisos de Automotive.
[3.2.3.1/A-0-1] DEBEN cargarse previamente una o más aplicaciones o componentes de servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de la aplicación que se enumeran aquí.
[3.4.1/A-0-1] DEBE proporcionar una implementación completa de la API de
android.webkit.Webview
.
Cómo iniciar nuevos requisitos
- [3.8/A-0-1] NO DEBE permitir que los usuarios secundarios completos que no sean el usuario actual en primer plano inicien actividades y tengan acceso a la IU en ninguna pantalla.
Fin de los nuevos requisitos
[3.8.3/A-0-1] DEBEN mostrar notificaciones que usen la API de
Notification.CarExtender
cuando lo soliciten aplicaciones de terceros.[3.8.4/A-SR-1] Se recomienda implementar un asistente en el dispositivo para controlar la acción de asistencia.
Si las implementaciones de dispositivos para la industria automotriz incluyen un botón de pulsar para hablar, deben cumplir con los siguientes requisitos:
- [3.8.4/A-1-1] DEBE usar una presión breve del botón Push-to-Talk como la interacción designada para iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa
VoiceInteractionService
.
Implementaciones de dispositivos para la industria automotriz:
- [3.8.3.1/A-0-1] DEBE renderizar correctamente los recursos como se describe en la documentación del SDK de
Notifications on Automotive OS
. - [3.8.3.1/A-0-2] DEBE mostrar INICIAR y SILENCIAR para las acciones de notificación en lugar de las que se proporcionan a través de
Notification.Builder.addAction()
. - [3.8.3.1/A] DEBE restringir el uso de tareas de administración enriquecidas, como los controles por canal de notificación. PUEDE usar indicaciones visuales de la IU por aplicación para reducir los controles.
Si las implementaciones de dispositivos para la industria automotriz admiten propiedades de HAL del usuario, hacen lo siguiente:
- [3.9.3/A-1-1] DEBE implementar todas las propiedades del ciclo de vida del usuario.
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
Implementaciones de dispositivos para la industria automotriz:
- [3.14/A-0-1] DEBE incluir un framework de IU para admitir apps de terceros que usen las APIs de contenido multimedia, como se describe en la sección 3.14.
- [3.14/A-0-2] DEBE permitir que el usuario interactúe de forma segura con las aplicaciones multimedia mientras conduce.
- [3.14/A-0-3] DEBE admitir la acción de intent implícita
CAR_INTENT_ACTION_MEDIA_TEMPLATE
con el elemento adicionalCAR_EXTRA_MEDIA_PACKAGE
. - [3.14/A-0-4] DEBEN proporcionar una indicación para navegar a la actividad de preferencias de una aplicación multimedia, pero solo DEBEN habilitarla cuando no estén vigentes las restricciones de la UX de vehículos.
- [3.14/A-0-5] DEBEN mostrar los mensajes de error establecidos por las aplicaciones multimedia y DEBEN admitir los elementos adicionales opcionales
ERROR_RESOLUTION_ACTION_LABEL
yERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] DEBEN admitir una indicación visual de búsqueda en la app para las apps que admiten búsquedas.
- [3.14/A-0-7] DEBE respetar las definiciones de
CONTENT_STYLE_BROWSABLE_HINT
yCONTENT_STYLE_PLAYABLE_HINT
cuando se muestra la jerarquía de MediaBrowser.
Si las implementaciones de dispositivos para la industria automotriz incluyen una app de selector predeterminada, deben cumplir con los siguientes requisitos:
- [3.14/A-1-1] DEBEN incluir servicios multimedia y abrirlos con el intent
CAR_INTENT_ACTION_MEDIA_TEMPLATE
.
Implementaciones de dispositivos para la industria automotriz:
- [3.8/A] PUEDE restringir las solicitudes de la aplicación para ingresar a un 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 IU del sistema, para garantizar que esos elementos sean claramente visibles en todo momento.
2.5.4. Rendimiento y energía
Implementaciones de dispositivos para la industria automotriz:
- [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 kerneluid_sys_stats
. - [8.3/A-1-3] DEBE admitir el Modo garaje.
- [8.3/A] DEBE estar en modo de garaje durante al menos 15 minutos después de cada viaje, a menos que se den las siguientes situaciones:
- La batería se agotó.
- No se programaron trabajos inactivos.
- El conductor sale del modo de cochera.
- [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 la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del proyecto de código abierto de Android.
- [8.4/A-0-2] DEBEN informarse 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 UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo del kernel
uid_cputime
. - [8.4/A] DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo 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 para el desarrollador de la app a través del comando de shell
adb shell dumpsys batterystats
.
2.5.5. Modelo de seguridad
Si las implementaciones de dispositivos de Automotive admiten varios usuarios, deben cumplir con los siguientes requisitos:
- [9.5/A-1-1] NO DEBE permitir que los usuarios interactúen con el usuario del sistema sin cabeza ni cambien a él, excepto para el aprovisionamiento de dispositivos.
- [9.5/A-1-2] DEBE cambiar a un usuario secundario antes de
BOOT_COMPLETED
. - [9.5/A-1-3] DEBE admitir la capacidad de crear un usuario invitado incluso cuando se alcanza la cantidad máxima de usuarios en un dispositivo.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos para automóviles declaran android.hardware.microphone
, hacen lo siguiente:
- [9.8.2/A-1-1] DEBE mostrar el indicador de micrófono cuando una app accede a datos de audio del micrófono, pero no cuando solo
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
o apps que tengan los roles mencionados en la sección 9.1 con el identificador de CDD [C-4-X] acceden al micrófono. - [9.8.2/A-1-2] NO DEBE ocultar el indicador de micrófono de las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
- [9.8.2/A-1-3] DEBE proporcionar una indicación visual para el usuario para activar o desactivar el micrófono en la app de Configuración.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos para la industria automotriz declaran android.hardware.camera.any
, hacen lo siguiente:
- [9.8.2/A-2-1] DEBE mostrar el indicador de cámara cuando una app accede a datos de cámara en vivo, pero no cuando solo las apps que tienen los roles definidos
se mencionanen la Sección 9.1 Permisos con el identificador de CDD [C-4-X][C-3-X]. - [9.8.2/A-2-2] NO DEBE ocultar el indicador de la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
Cómo iniciar nuevos requisitos
- [9.8.2/A-2-3] DEBE proporcionar una indicación visual para el usuario para activar o desactivar la cámara en la app de Configuración.
- [9.8.2/A-2-4] DEBEN mostrar las apps recientes y activas que usan la cámara como se muestra en
PermissionManager.getIndicatorAppOpUsageData()
, junto con cualquier mensaje de atribución asociado con ellas.
Fin de los nuevos requisitos
Implementaciones de dispositivos para la industria automotriz:
- [9/A-0-1] DEBE declarar la función
android.hardware.security.model.compatible
. - [9.11/A-0-1] DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
- [9.11/A-0-2] DEBE tener implementaciones de algoritmos de criptografía RSA, AES, ECDSA y HMAC, y funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles del sistema de almacén de claves de Android en un área que esté aislada de forma segura del código que se ejecuta en el kernel y en niveles superiores. El aislamiento seguro DEBE bloquear todos los posibles mecanismos con los que el código del kernel o del espacio de usuario pueda acceder al estado interno del entorno aislado, incluida la DMA. El Proyecto de código abierto de Android (AOSP) cumple con este requisito mediante la implementación de 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 aislado y, solo cuando se realice correctamente, permitir que se usen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
- [9.11/A-0-4] DEBE admitir la certificación de claves en la que la clave de firma de certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse en una cantidad de dispositivos lo suficientemente grande como para evitar que se usen como identificadores de dispositivos. Una forma de cumplir con 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 usar una clave diferente para cada 100,000 unidades.
Ten en cuenta que, si ya se lanzó una implementación de dispositivo en una versión anterior de Android, ese dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la certificación de claves, a menos que declare la función android.hardware.fingerprint
, que requiere un almacén de claves respaldado por un entorno de ejecución aislado.
Implementaciones de dispositivos para la industria automotriz:
- [9.14/A-0-1] DEBE controlar los mensajes de los subsistemas de vehículos del framework de Android, p.ej., permitir tipos de mensajes y fuentes de mensajes permitidos.
- [9.14/A-0-2] DEBE supervisar los ataques de denegación del servicio desde el framework de Android o apps de terceros. Esto protege contra software malicioso que inunde la red del vehículo con tráfico, lo que puede provocar fallas en los subsistemas del vehículo.
2.5.6. Compatibilidad de las herramientas y opciones para desarrolladores
Implementaciones de dispositivos para la industria automotriz:
- Perfetto
- [6.1/A-0-1] DEBE exponer un objeto binario
/system/bin/perfetto
al usuario de shell cuya línea de comandos cumpla con la documentación de perfetto. - [6.1/A-0-2] El objeto binario de perfetto DEBE aceptar como entrada una configuración de protobuf que cumpla con el esquema definido en la documentación de perfetto.
- [6.1/A-0-3] El objeto binario de perfetto DEBE escribir como resultado un registro de protobuf que cumpla con el esquema definido en la documentación de perfetto.
- [6.1/A-0-4] DEBE proporcionar, a través del objeto binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
- [6.1/A-0-1] DEBE exponer un objeto binario
2.6. Requisitos de la tablet
Un dispositivo Android Tablet hace referencia a una implementación de dispositivo Android que, por lo general, cumple con todos los siguientes criterios:
- Se usa con ambas manos.
- No tiene una configuración de libro o convertible.
- Las implementaciones de teclado físico que se usan con el dispositivo se conectan a través de una conexión estándar (p.ej., USB o Bluetooth).
Tiene una fuente de alimentación que proporciona movilidad, como una batería.
Tiene un tamaño de pantalla superior a 7" y menor a 18", medido diagonalmente.
Las implementaciones de dispositivos de tablet tienen requisitos similares a las implementaciones de dispositivos de mano. Las excepciones se indican con un * en esa sección y se mencionan como referencia en esta sección.
2.6.1. Hardware
Giroscopio
Si las implementaciones de dispositivos de tablet incluyen un giroscopio de 3 ejes, tienen las siguientes características:
- [7.3.4/Tab-1-1] DEBE ser capaz de medir cambios de orientación de hasta 1,000 grados por segundo.
Memoria y almacenamiento mínimos (Sección 7.6.1)
Las densidades de pantalla que se indican para pantallas pequeñas o normales en los requisitos de los dispositivos de mano no se aplican a las tablets.
Modo periférico USB (Sección 7.7.1)
Si las implementaciones de dispositivos de tablet incluyen un puerto USB compatible con el modo periférico, tienen las siguientes características:
- [7.7.1/Tab] PUEDE implementar la API de Android Open Accessory (AOA).
Modo de realidad virtual (Sección 7.9.1)
Rendimiento alto de la realidad virtual (sección 7.9.2)
Los requisitos de realidad virtual no se aplican a las tablets.
2.6.2. Modelo de seguridad
Llaves y credenciales (Sección 9.11)
Consulta el artículo [9.11].
Si las implementaciones de dispositivos de tablet incluyen varios usuarios y no declaran la marca de función android.hardware.telephony
, sucede lo siguiente:
- [9.5/T-1-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que trabajen usuarios adicionales, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
Si las implementaciones de dispositivos de tablet incluyen varios usuarios y declaran la marca de función android.hardware.telephony
, hacen lo siguiente:
- [9.5/T-2-1] NO DEBEN admitir perfiles restringidos, pero DEBEN alinearse con la implementación de controles de AOSP para habilitar o inhabilitar que otros usuarios accedan a las llamadas de voz y los SMS.
2.6.2. Software
- [3.2.3.1/Tab-0-1] DEBE precargar uno o más componentes de servicio o aplicación con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de la aplicación que se enumeran aquí.
3. Software
3.1. Compatibilidad de APIs administradas
El entorno de ejecución de código de bytes Dalvik administrado es el vehículo principal para las aplicaciones para Android. La interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma de Android expuestas a las aplicaciones que se ejecutan en el entorno de ejecución administrado.
Implementaciones de dispositivos:
[C-0-1] DEBEN proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada que exponga el SDK de Android o cualquier API decorada con el marcador "@SystemApi" en el código fuente de Android upstream.
[C-0-2] DEBE admitir o preservar todas las clases, los métodos y los elementos asociados marcados con la anotación TestApi (@TestApi).
[C-0-3] NO DEBE omitir ninguna API administrada, alterar las interfaces o las firmas de la API, desviarse del comportamiento documentado ni incluir no-ops, excepto cuando esta definición de compatibilidad lo permita de forma específica.
[C-0-4] DEBEN seguir manteniendo las APIs presentes y comportarse de manera razonable, incluso cuando se omiten algunas funciones de hardware para las que Android incluye APIs. Consulta la sección 7 para conocer los requisitos específicos de esta situación.
[C-0-5] NO DEBE permitir que las apps de terceros usen interfaces que no sean del SDK, que se definen como métodos y campos en los paquetes del lenguaje Java que se encuentran en la ruta de acceso de inicio en AOSP y que no forman parte del SDK público. Esto incluye las APIs decoradas con la anotación
@hide
, pero no con una@SystemAPI
, como se describe en los documentos del SDK y los miembros de clase privados y privados del paquete.[C-0-6] DEBEN enviarse con cada interfaz que no pertenece al SDK en las mismas listas restringidas que se proporcionan a través de las marcas provisionales y de la lista de entidades rechazadas en la ruta de acceso
prebuilts/runtime/appcompat/hiddenapi-flags.csv
para la rama del nivel de API adecuada en el AOSP.[C-0-7] DEBE admitir el mecanismo de actualización dinámica de la configuración firmada para quitar interfaces que no pertenecen al SDK de una lista restringida mediante la incorporación de la configuración firmada en cualquier APK, con las claves públicas existentes presentes en AOSP.
Sin embargo, tienen las siguientes características:
- SI, si no hay una API oculta o se implementa de forma diferente en la implementación del dispositivo, mueve la API oculta a la lista de entidades rechazadas o omítela de todas las listas restringidas.
- SI ES POSIBLE, si aún no existe una API oculta en el AOSP, agrégala a cualquiera de las listas restringidas.
Cómo iniciar nuevos requisitos
- [C-0-8] NO DEBE admitir la instalación de aplicaciones que se orienten a un nivel de API inferior a 23.
Fin de los nuevos requisitos
3.1.1. Extensiones de Android
Android admite la extensión de la plataforma de API administrada de un nivel de API en particular mediante la actualización de la versión de extensión de ese nivel de API. La API de android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
muestra 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 de AOSP de la biblioteca compartida
ExtShared
y los serviciosExtServices
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 de API 24 DEBEN incluir al menos la versión 1.[C-0-2] SOLO DEBE mostrar el número de versión de extensión válido que definió el AOSP.
[C-0-3] DEBE admitir todas las APIs definidas por las versiones de extensión que muestra
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
de la misma manera que se admiten otras APIs administradas, de acuerdo con los requisitos de la sección 3.1.
3.1.2. Biblioteca de Android
Debido a la baja del cliente HTTP de Apache, las implementaciones de dispositivos hacen lo siguiente:
- [C-0-1] NO DEBE colocar la biblioteca
org.apache.http.legacy
en el bootclasspath. - [C-0-2] DEBE agregar la biblioteca
org.apache.http.legacy
a la ruta de acceso de clases de la aplicación solo cuando la app cumpla con una de las siguientes condiciones:- Se orienta al nivel de API 28 o versiones anteriores.
- Declara en su manifiesto que necesita la biblioteca configurando el atributo
android:name
de<uses-library>
enorg.apache.http.legacy
.
La implementación de AOSP cumple con estos requisitos.
3.2. Compatibilidad de API flexible
Además de las APIs administradas de la sección 3.1, Android también incluye una API "soft" significativa solo para el tiempo de ejecución, en forma de intents, permisos y aspectos similares de las aplicaciones para 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 aplicar todas las constantes de permisos, como se documenta en la página de referencia de permisos. Ten en cuenta que en la sección 9 se enumeran requisitos adicionales relacionados con el modelo de seguridad de Android.
3.2.2. Parámetros de compilación
Las APIs de Android incluyen una serie de constantes en la clase android.os.Build que tienen como objetivo 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 cumplir las implementaciones de dispositivos.
Parámetro | Detalles |
---|---|
VERSION.RELEASE | Es 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 Permitted Version Strings for Android 14. |
VERSION.SDK | Es la versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. Para Android 14, este campo DEBE tener el valor de número entero 14_INT. |
VERSION.SDK_INT | Es la versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. Para Android 14, este campo DEBE tener el valor de número entero 14_INT. |
VERSION.INCREMENTAL | Es un valor que elige el implementador del dispositivo y que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO se DEBE volver a usar para diferentes compilaciones que se ponen a disposición de 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 código fuente se usó para generar la compilación. El valor de este campo DEBE poder codificarse como ASCII de 7 bits imprimible y coincidir con la expresión regular “^[^ :\/~]+$”. |
JUEGOS DE MESA | Es un valor que elige el implementador del dispositivo que identifica el hardware interno específico que usa 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 codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. |
SEGURIDAD | Es un valor que refleja el nombre de la marca asociado con el dispositivo tal como lo conocen los usuarios finales. DEBE estar en formato legible por humanos y DEBE representar al fabricante del dispositivo o la marca de la empresa con la que 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 | Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
SUPPORTED_32_BIT_ABIS | Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
SUPPORTED_64_BIT_ABIS | Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
CPU_ABI | Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
CPU_ABI2 | Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
DISPOSITIVO | Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código que identifica la configuración de las funciones de 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_-]+$”. Este nombre de dispositivo NO DEBE cambiar durante la vida útil del producto. |
FINGERPRINT | Es una cadena que identifica de forma exclusiva esta compilación. DEBE ser legible por humanos. DEBE seguir esta plantilla:
$(BRAND)/$(PRODUCT)/ Por ejemplo: acme/myproduct/ La huella digital NO DEBE incluir caracteres de espacio en blanco. El valor de este campo DEBE poder codificarse como ASCII de 7 bits. |
HARDWARE | Es el nombre del hardware (de la línea de comandos del kernel o /proc). DEBE ser legible por humanos. El valor de este campo DEBE codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9_-]+$". |
HOST | Es una cadena que identifica de forma exclusiva el host en el que se compiló 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 ni una cadena vacía (""). |
ID | Es un identificador que elige 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 lo 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 | Es el nombre comercial del fabricante del equipo original (OEM) del producto. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto. |
SOC_MANUFACTURER | Es el nombre comercial del fabricante del sistema principal en chip (SoC) que se usa en el producto. Los dispositivos con el mismo fabricante de SOC deben usar el mismo valor constante. Pídele al fabricante del SOC la constante correcta que se debe usar. El valor de este campo DEBE 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 | Es el nombre del modelo del sistema principal en chip (SoC) que se usa en el producto. Los dispositivos con el mismo modelo de SOC deben usar el mismo valor constante. Pídele al fabricante del SOC la constante correcta que debes usar. 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 NO DEBE ser igual a “desconocido”. Este campo NO DEBE cambiar durante la vida útil del producto. |
MODELO. | Es un valor que elige el implementador del dispositivo y que contiene el nombre del dispositivo tal como lo conoce el usuario final. 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 ni una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto. |
PRODUCTO | Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBEN ser legibles por humanos, pero no necesariamente están destinados a que los usuarios finales los vean. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. Este nombre del producto NO DEBE cambiar durante la vida útil del producto. |
ODM_SKU | Es un valor opcional que elige el implementador del dispositivo y que contiene el SKU (unidad de mantenimiento de inventario) que se usa para hacer un seguimiento de las 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.,_-]+)$ . |
SERIAL | DEBE mostrar "UNKNOWN". |
ETIQUETAS | Es una lista de etiquetas separadas por comas que elige el implementador del dispositivo y que distingue aún más la compilación. Las etiquetas DEBEN 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 de Android: claves de lanzamiento, claves de desarrollador y claves de prueba. |
TIEMPO | Es un valor que representa la marca de tiempo de la compilación. |
TIPO | Es un valor que elige el implementador del dispositivo y que especifica la configuración del entorno de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas del entorno de ejecución de Android: user, userdebug 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 ni una cadena vacía (""). |
SECURITY_PATCH | Es un valor que indica el nivel de revisión de seguridad de una compilación. DEBE indicar que la compilación no es vulnerable de ninguna manera a ninguno de los problemas descritos en el boletín de seguridad público de Android designado. DEBE estar en 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". |
BASE_OS | Es un valor que representa el parámetro FINGERPRINT de la compilación que, en términos generales, es idéntico a esta, excepto por los parches proporcionados en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si no existe tal compilación, informar una cadena vacía (""). |
BOOTLOADER | Es un valor que elige el implementador del dispositivo y que identifica la versión específica del bootloader interno que se usa en el dispositivo, en formato legible por humanos. El valor de este campo DEBE codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”. |
getRadioVersion() | DEBE (ser o mostrar) un valor que elija el implementador del dispositivo que identifique la versión específica de radio o módem interna que se usa en el dispositivo, en formato legible por humanos. Si un dispositivo no tiene ninguna radio o módem interno, DEBE mostrar NULL. El valor de este campo DEBE codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”. |
getSerial() | DEBE (ser o devolver) un número de serie de hardware, que DEBE estar disponible y ser único en todos los dispositivos con el mismo MODELO y FABRICANTE. El valor de este campo DEBE codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9]+$”. |
3.2.3. Compatibilidad con intents
3.2.3.1. Intents de aplicación comunes
Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidades de otros componentes de Android. El proyecto upstream de Android incluye una lista de aplicaciones que implementan varios patrones de intents para realizar acciones comunes.
Implementaciones de dispositivos:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que se carguen previamente una o más aplicaciones o componentes de servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por los siguientes intents de la aplicación que se indican aquí y que se proporcione la entrega, es decir, que se cumplan las expectativas del desarrollador para estos intents de aplicación comunes, como se describe en el SDK.
Consulta la Sección 2 para obtener información sobre los intents de aplicación obligatorios para cada tipo de dispositivo.
3.2.3.2. Resolución de intents
[C-0-1] Como Android es una plataforma extensible, las implementaciones de dispositivos DEBEN permitir que aplicaciones de terceros anulen cada patrón de intent al que se hace referencia en la sección 3.2.3.1, excepto Configuración. La implementación de código abierto de Android upstream lo permite de forma predeterminada.
[C-0-2] Los implementadores de dispositivos NO DEBEN adjuntar privilegios especiales al uso de estos patrones de intents por parte de las aplicaciones del sistema ni impedir que las aplicaciones de terceros se vinculen a estos patrones y asuman el control de ellos. Esta prohibición incluye, entre otras, la inhabilitación de la interfaz de usuario "Selector" que permite al usuario elegir entre varias aplicaciones que controlan el mismo patrón de intent.
[C-0-3] Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario para que los usuarios modifiquen la actividad predeterminada de los intents.
Sin embargo, las implementaciones de dispositivos PUEDEN proporcionar actividades predeterminadas para patrones de URI específicos (p.ej., 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 intents que especifica el URI de datos "http://www.android.com" es más específico que el patrón de intent principal del navegador para "http://".
Android también incluye un mecanismo para que las apps de terceros declaren un comportamiento de vinculación de apps predeterminado y autorizado para ciertos tipos de intents de URI web. Cuando se definen esas declaraciones autorizadas en los patrones de filtro de intents de una app, las implementaciones de dispositivos hacen lo siguiente:
- [C-0-4] DEBE intentar validar cualquier filtro de intents realizando los pasos de validación definidos en la especificación de Vínculos de recursos digitales que implementa el Administrador de paquetes en el proyecto de código abierto de Android upstream.
- [C-0-5] DEBE intentar validar los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de URI validados correctamente como controladores de apps predeterminados para sus URIs.
- PUEDEN establecer filtros de intents de URI específicos como controladores de apps predeterminados para sus URIs, si se verifican correctamente, pero otros filtros de URI candidatos no pasan la verificación. Si una implementación de dispositivo hace esto, DEBE proporcionar al usuario las anulaciones de patrones por URI adecuadas en el menú de configuración.
- DEBEN proporcionarle al usuario controles de vínculos de aplicaciones por app en Configuración de la siguiente manera:
- [C-0-6] El usuario DEBE poder anular de forma integral el comportamiento predeterminado de los vínculos de apps para que una app esté siempre abierta, siempre pregunte o nunca se abra, lo que se debe aplicar a todos los filtros de intents de URI candidatos por igual.
- [C-0-7] El usuario DEBE poder ver una lista de los filtros de intents de URI candidatos.
- La implementación del dispositivo PUEDE proporcionar al usuario la capacidad de anular filtros de intents de URI candidatos específicos que se verificaron correctamente, por filtro de intent.
- [C-0-8] La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intents de URI candidato específicos si la implementación del dispositivo permite que algunos filtros de intents de URI candidato tengan éxito en la verificación, mientras que otros pueden fallar.
3.2.3.3. Espacios de nombres de intents
- [C-0-1] Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que respete ningún patrón de intent nuevo o de intent de transmisión con una ACTION, CATEGORY o alguna otra cadena clave en el espacio de nombres android.* o com.android.*.
- [C-0-2] Los implementadores de dispositivos NO DEBEN incluir componentes de Android que respeten patrones de intents nuevos o de intents de transmisión con una ACTION, CATEGORY o alguna otra cadena clave en un espacio de paquete que pertenezca a otra organización.
- [C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni extender ninguno de los patrones de intents que se enumeran en la sección 3.2.3.1.
- Las implementaciones de dispositivos PUEDEN incluir patrones de intents que usan espacios de nombres asociados de forma clara y obvia con su propia organización. Esta prohibición es similar a la especificada para las clases del lenguaje Java en la sección 3.6.
3.2.3.4. Intents de transmisión
Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intents y notificarles sobre los cambios en el entorno de hardware o software.
Implementaciones de dispositivos:
- [C-0-1] DEBE transmitir los intents de transmisión pública que se indican aquí en respuesta a los eventos del sistema adecuados, como se describe en la documentación del SDK. Ten en cuenta que este requisito no entra en conflicto con el artículo 3.5, ya que la limitación para las aplicaciones en segundo plano también se describe en la documentación del SDK. Además, ciertos intents de transmisión dependen de la compatibilidad con el hardware. Si el dispositivo admite el hardware necesario, DEBEN transmitir los intents y proporcionar el comportamiento intercalado con la documentación del SDK.
3.2.3.5. Intents de aplicación condicionales
Android incluye parámetros de configuración que les brindan a los usuarios una forma fácil de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla principal o los SMS.
Cuando sea apropiado, las implementaciones de dispositivos DEBEN proporcionar un menú de configuración similar y ser compatibles con el patrón de filtro de intents y los métodos de la API que se describen en la documentación del SDK, como se indica a continuación.
Si las implementaciones de dispositivos informan android.software.home_screen
, hacen lo siguiente:
- [C-1-1] DEBE respetar la intención
android.settings.HOME_SETTINGS
para mostrar un menú de configuración de app predeterminado para la pantalla principal.
Si las implementaciones de dispositivos informan android.hardware.telephony.calling
, hacen lo siguiente:
[C-2-1] DEBE proporcionar un menú de configuración que llame al intent
android.provider.Telephony.ACTION_CHANGE_DEFAULT
para mostrar un diálogo que cambie la aplicación de SMS predeterminada.[C-2-2] DEBE respetar la intención
android.telecom.action.CHANGE_DEFAULT_DIALER
para mostrar un diálogo que le permita al usuario cambiar la aplicación de Teléfono predeterminada.- DEBEN usar la IU predeterminada de la app de teléfono que selecciona el usuario para las llamadas entrantes y salientes, excepto las llamadas de emergencia, que usarían la app de teléfono preinstalada.
[C-2-3] DEBE respetar el intent android.telecom.action.CHANGE_PHONE_ACCOUNTS para proporcionar al usuario indicaciones visuales para configurar el
ConnectionServices
asociado con elPhoneAccounts
, así como una PhoneAccount predeterminada que usará el proveedor de servicios de telecomunicaciones para realizar llamadas salientes. La implementación de AOSP cumple con este requisito, ya que incluye un menú "Calling Accounts option" en el menú de configuración "Calls".[C-2-4] DEBE permitir
android.telecom.CallRedirectionService
para una app que tenga el rolandroid.app.role.CALL_REDIRECTION
.[C-2-5] DEBE proporcionarle al usuario una indicación visual para que elija una app que tenga el rol
android.app.role.CALL_REDIRECTION
.[C-2-6] DEBE respetar los intents android.intent.action.SENDTO y android.intent.action.VIEW, y proporcionar una actividad para enviar o mostrar mensajes SMS.
[C-SR-1] SE RECOMIENDA ENFATICAMENTE que se respeten los intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW y android.intent.action.DIAL con una aplicación de marcado precargada que pueda controlar estos intents y proporcionar la entrega como se describe en el SDK.
Si las implementaciones de dispositivos informan android.hardware.nfc.hce
, hacen lo siguiente:
- [C-3-1] DEBE respetar la intención android.settings.NFC_PAYMENT_SETTINGS para mostrar un menú de configuración de la app predeterminado para el pago sin contacto.
- [C-3-2] DEBE respetar el intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT para mostrar una actividad que abra un diálogo para pedirle al usuario que cambie el servicio de emulación de tarjetas predeterminado de una categoría determinada, como se describe en el SDK.
Si las implementaciones de dispositivos informan android.hardware.nfc
, hacen lo siguiente:
- [C-4-1] DEBE respetar estos intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED y android.nfc.action.TECH_DISCOVERED para mostrar una actividad que cumpla con las expectativas de los desarrolladores para estos intents, como se describe en el SDK.
Si las implementaciones de dispositivos informan android.hardware.bluetooth
, hacen lo siguiente:
- [C-5-1] DEBE respetar el intent "android.bluetooth.adapter.action.REQUEST_ENABLE" y mostrar una actividad del sistema para permitir que el usuario active Bluetooth.
- [C-5-2] DEBE respetar el intent "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE" y mostrar una actividad del sistema que solicite el modo detectable.
Si las implementaciones de dispositivos admiten la función No interrumpir, hacen lo siguiente:
- [C-6-1] DEBE implementar una actividad que responda al intent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
, que, para las implementaciones con UI_MODE_TYPE_NORMAL, DEBE ser una actividad en la que el usuario pueda otorgar o denegar el acceso de la app a las configuraciones de la política de No interrumpir.
Si las implementaciones de dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con los siguientes requisitos:
- [C-7-1] DEBE proporcionar un mecanismo accesible para el usuario para agregar y configurar métodos de entrada de terceros en respuesta al intent
android.settings.INPUT_METHOD_SETTINGS
.
Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con los siguientes requisitos:
- [C-8-1] DEBE respetar la intención de
android.settings.ACCESSIBILITY_SETTINGS
para proporcionar un mecanismo accesible para el usuario que permita habilitar y deshabilitar los servicios de accesibilidad de terceros junto con los servicios de accesibilidad precargados.
Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Easy Connect y exponen la funcionalidad a apps de terceros, hacen lo siguiente:
- [C-9-1] DEBE implementar las APIs de intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI como se describe en la documentación del SDK.
Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos, hacen lo siguiente:
- [C-10-1] DEBE proporcionar una interfaz de usuario en la configuración que controle el intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, lo que permite a los usuarios agregar aplicaciones a la lista de entidades permitidas o quitarlas de ella.
Si las implementaciones de dispositivos no proporcionan el modo Ahorro de datos, sucede lo siguiente:
- [C-11-1] DEBE tener una actividad que controle el intent
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, pero PUEDE implementarlo como una operación no operativa.
Si las implementaciones de dispositivos declaran compatibilidad con la cámara a través de android.hardware.camera.any
, hacen lo siguiente:
- [C-12-3] DEBEN controlar y solo permitir que las aplicaciones preinstaladas de Android controlen los siguientes intents:
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
yMediaStore.ACTION_VIDEO_CAPTURE
, como se describe en el documento del SDK.
Si las implementaciones de dispositivos informan android.software.device_admin
, hacen lo siguiente:
[C-13-1] DEBE respetar el intent
android.app.action.ADD_DEVICE_ADMIN
para invocar una IU que le indique al usuario que agregue el administrador de dispositivos al sistema (o le permita rechazarlo).[C-13-2] DEBE respetar los intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD y android.app.action.START_ENCRYPTION, y tener una actividad para proporcionar la entrega de estos intents como se describe aquí en el SDK.
Si las implementaciones de dispositivos declaran la marca de función android.software.autofill
, hacen lo siguiente:
- [C-14-1] DEBEN implementar por completo las APIs de
AutofillService
yAutofillManager
, y respetar el intent android.settings.REQUEST_SET_AUTOFILL_SERVICE para mostrar un menú de configuración de la app predeterminado que habilite y deshabilite el autocompletado, y cambie el servicio de autocompletado predeterminado para el usuario.
Si las implementaciones de dispositivos incluyen una app preinstalada o desean permitir que las apps de terceros accedan a las estadísticas de uso, deben cumplir con los siguientes requisitos:
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE proporcionar un mecanismo accesible para el usuario para otorgar o revocar el acceso a las estadísticas de uso en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS para las apps que declaran el permiso
android.permission.PACKAGE_USAGE_STATS
.
Si las implementaciones de dispositivos tienen la intención de no permitir que ninguna app, incluidas las preinstaladas, acceda a las estadísticas de uso, deben cumplir con lo siguiente:
- [C-15-1] SIEMPRE DEBE tener una actividad que controle el patrón de intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, pero DEBE implementarlo como una no operación, es decir, debe tener un comportamiento equivalente al que se produce cuando se rechaza el acceso del usuario.
Si las implementaciones de dispositivos muestran vínculos a las actividades especificadas por AutofillService_passwordsActivity en Configuración o vínculos a las contraseñas del usuario a través de un mecanismo similar, hacen lo siguiente:
- [C-16-1] DEBEN mostrar esos vínculos para todos los servicios de autocompletado instalados.
Si las implementaciones de dispositivos admiten VoiceInteractionService
y tienen más de una aplicación que usa esta API instalada a la vez, hacen lo siguiente:
- [C-18-1] DEBE respetar la intención
android.settings.ACTION_VOICE_INPUT_SETTINGS
para mostrar un menú de configuración predeterminado de la app para la entrada de voz y la asistencia.
Si las implementaciones de dispositivos informan la función android.hardware.audio.output
, hacen lo siguiente:
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE que los intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA y android.speech.tts.engine.GET_SAMPLE_TEXT tengan una actividad para proporcionar la entrega de estos intents, como se describe en el SDK aquí.
Android incluye compatibilidad con protectores de pantalla interactivos, que antes se denominaban "Dreams". Los protectores de pantalla permiten que los usuarios interactúen con las aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o en una estación de carga. Implementaciones de dispositivos:
- DEBE incluir compatibilidad con protectores de pantalla y proporcionar una opción de configuración para que los usuarios los configuren en respuesta al intent
android.settings.DREAM_SETTINGS
.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos informan android.hardware.nfc.uicc
o android.hardware.nfc.ese
, hacen lo siguiente:
- [C-19-1] DEBE implementar la API de intents NfcAdapter.ACTION_TRANSACTION_DETECTED (como "EVT_TRANSACTION" definido en la especificación técnica TS.26 de la Asociación GSM: Requisitos de los teléfonos celulares NFC).
Fin de los nuevos requisitos
3.2.4. Actividades en pantallas secundarias o múltiples
Si las implementaciones de dispositivos permiten iniciar actividades de Android normales en más de una pantalla, hacen lo siguiente:
- [C-1-1] DEBE establecer la marca de función
android.software.activities_on_secondary_displays
. - [C-1-2] DEBE garantizar la compatibilidad de la API similar a una actividad que se ejecuta en la pantalla principal.
- [C-1-3] DEBE ubicar la actividad nueva en la misma pantalla que la actividad que la inició, cuando la actividad nueva se inicia sin especificar una pantalla de destino a través de la API de
ActivityOptions.setLaunchDisplayId()
. - [C-1-4] DEBEN destruirse todas las actividades cuando se quita una pantalla con la marca
Display.FLAG_PRIVATE
. - [C-1-5] DEBEN 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 app acepte mostrarse en la parte superior de la pantalla de bloqueo con la API de
Activity#setShowWhenLocked()
. - DEBE tener
android.content.res.Configuration
que corresponde a esa pantalla para mostrarse, funcionar correctamente y mantener la compatibilidad si se inicia una actividad en la pantalla secundaria.
Si las implementaciones de dispositivos permiten iniciar actividades de Android normales en pantallas secundarias y una pantalla secundaria tiene la marca android.view.Display.FLAG_PRIVATE, haz lo siguiente:
- [C-3-1] Solo el propietario de esa pantalla, el sistema y las actividades que ya están en esa pantalla DEBEN poder iniciarse en ella. Cualquier persona puede iniciar una pantalla que tenga la marca android.view.Display.FLAG_PUBLIC.
3.3. Compatibilidad con la API nativa
La compatibilidad con el código nativo es un desafío. Por este motivo, los implementadores de dispositivos tienen las siguientes características:
- [C-SR-1] SE RECOMIENDA URGENTEMENTE que uses las implementaciones de las bibliotecas que se indican a continuación del Proyecto de código abierto de Android upstream.
3.3.1. Interfaces binarias de la aplicación
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 .so
ELF 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 aplicación (ABI) en el NDK de Android.
Implementaciones de dispositivos:
- [C-0-1] DEBE ser compatible con una o más ABIs del NDK de Android definidas.
- [C-0-2] DEBE incluir compatibilidad con el código que se ejecuta en el entorno administrado para llamar al código nativo con la semántica estándar de la interfaz nativa de Java (JNI).
- [C-0-3] DEBEN ser compatibles con la fuente (es decir, con el encabezado) y con el código binario (para la ABI) con cada biblioteca requerida de la siguiente lista.
- [C-0-5] DEBE informar con precisión la interfaz binaria de la aplicación (ABI) nativa que admite el dispositivo a través de los parámetros
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
yandroid.os.Build.SUPPORTED_64_BIT_ABIS
, cada uno de los cuales es una lista de ABIs separadas por comas ordenadas de la más a la menos preferida. [C-0-6] DEBE informar, a través de los parámetros anteriores, un subconjunto de la siguiente lista de ABIs y NO DEBE informar ninguna ABI que no esté en la lista.
armeabi
(el NDK ya no lo admite como destino)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] DEBEN hacer que todas las siguientes bibliotecas, que proporcionan APIs nativas, estén disponibles para las apps que incluyen código nativo:
- libaaudio.so (compatibilidad con audio nativo de AAudio)
- libamidi.so (compatibilidad nativa con MIDI, si se reclama la función
android.software.midi
como se describe en el artículo 5.9) - libandroid.so (compatibilidad con actividades nativas de Android)
- libc (biblioteca C)
- libcamera2ndk.so
- libdl (vinculador dinámico)
- libEGL.so (administración nativa de la superficie de OpenGL)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (registro de Android)
- libmediandk.so (compatibilidad con APIs de medios nativos)
- libm (biblioteca matemática)
- libneuralnetworks.so (API de Neural Networks)
- libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
- libOpenSLES.so (Compatibilidad con audio de OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (Compatibilidad mínima con C++)
- libvulkan.so (Vulkan)
- libz (compresión zlib)
- Interfaz de JNI
[C-0-8] NO DEBE agregar ni quitar las funciones públicas de las bibliotecas nativas enumeradas anteriormente.
[C-0-9] DEBE enumerar bibliotecas adicionales que no sean de AOSP expuestas directamente a apps 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 apps de terceros que se orienten al nivel de API 24 o versiones posteriores, ya que están reservadas.
[C-0-11] DEBES exportar todos los símbolos de función de OpenGL ES 3.1 y el Paquete de extensión de Android, como se define en el NDK, a través de la biblioteca
libGLESv3.so
. Ten en cuenta que, si bien TODOS los símbolos DEBEN estar presentes, en el artículo 7.1.4.1 se describen con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.[C-0-12] DEBES exportar símbolos de función para los símbolos de función principales de
Vulkan 1.0y Vulkan 1.1, así como las extensionesVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
yVK_KHR_get_physical_device_properties2
a través de la bibliotecalibvulkan.so
. Ten en cuenta que, si bien todos los símbolos DEBEN estar presentes, en la sección 7.1.4.2 se describen con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.DEBE compilarse con el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android upstream.
Ten en cuenta que es posible que las versiones futuras de Android admitan ABI adicionales.
3.3.2. Compatibilidad con código nativo ARM de 32 bits
Si las implementaciones de dispositivos informan la compatibilidad con la ABI de armeabi
, hacen lo siguiente:
- [C-3-1] TAMBIÉN DEBE admitir
armeabi-v7a
y notificar su compatibilidad, ya quearmeabi
solo es para la retrocompatibilidad con apps anteriores.
Si las implementaciones de dispositivos informan la compatibilidad con la ABI de armeabi-v7a
, para las apps que usan esta ABI, sucede lo siguiente:
[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 lean.Features:
, seguida de una lista de las funciones opcionales de la CPU ARMv7 que admite el dispositivo.CPU architecture:
, seguido de un número entero que describe la arquitectura ARM más reciente compatible del dispositivo (p.ej., “8” para dispositivos ARMv8).
[C-2-2] SIEMPRE DEBE mantener disponibles las siguientes operaciones, incluso en el caso en que la ABI se implemente en una arquitectura ARMv8, ya sea a través de la compatibilidad con la CPU nativa o a través de la emulación de software:
- Instrucciones SWP y SWPB.
- Operaciones de barrera CP15ISB, CP15DSB y CP15DMB
[C-2-3] DEBE incluir compatibilidad con 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 de android.webkit.Webview
, hacen lo siguiente:
- [C-1-1] DEBE informar
android.software.webview
. - [C-1-2] DEBES usar la compilación del proyecto Chromium del proyecto de código abierto de Android upstream en la rama de Android 14 para la implementación de la API de
android.webkit.WebView
. [C-1-3] La cadena de usuario-agente que informa WebView DEBE tener este formato:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/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 lo está, DEBE tener el mismo valor que android.os.Build.MODEL.
- SE PUEDE omitir "Build/$(BUILD)", pero si está presente, la cadena $(BUILD) DEBE ser la misma 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 upstream.
- Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del usuario-agente.
El componente WebView DEBE incluir compatibilidad con la mayor cantidad posible de funciones HTML5 y, si es compatible con la función, DEBE cumplir con la especificación HTML5.
[C-1-4] DEBE renderizar el contenido proporcionado o el contenido de la URL remota en un proceso distinto de la aplicación que crea una instancia de WebView. Específicamente, el proceso de renderización independiente DEBE tener privilegios más bajos, ejecutarse como un ID de usuario independiente, no tener acceso al directorio de datos de la app, no tener acceso directo a la red y solo tener acceso a los servicios del sistema mínimos requeridos a través de Binder. La implementación de WebView de AOSP cumple con este requisito.
Ten en cuenta que, si las implementaciones de dispositivos son de 32 bits o declaran la marca 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, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE admitir cada una de estas APIs asociadas con HTML5:
- [C-1-2] DEBE admitir la API de WebStorage de HTML5/W3C y DEBE admitir la API de IndexedDB de HTML5/W3C. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer IndexedDB en lugar de WebStorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.
- PUEDE enviar una cadena de usuario-agente personalizada en la aplicación independiente del navegador.
- DEBE implementar la compatibilidad con la mayor cantidad posible de HTML5 en la aplicación independiente del navegador (ya sea que se base en la aplicación del navegador WebKit upstream o en un reemplazo de terceros).
Sin embargo, si las implementaciones de dispositivos no incluyen una aplicación de navegador independiente, sucede lo siguiente:
- [C-2-1] DEBEN seguir admitiendo los patrones de intents públicos como se describe en la sección 3.2.3.1.
3.5. Compatibilidad de comportamiento de la API
Implementaciones de dispositivos:
- [C-0-9] DEBEN garantizar que se aplique la compatibilidad de comportamiento de la API para todas las apps 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 de entidades permitidas que garantiza la compatibilidad de comportamiento de la API solo para las apps que seleccionan los implementadores de dispositivos.
Los comportamientos de cada uno de los tipos de API (administrados, flexibles, nativos y web) deben ser coherentes con la implementación preferida del proyecto de código abierto de Android upstream. Estas son algunas áreas específicas de compatibilidad:
- [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent estándar.
- [C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etcétera).
- [C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
- Los dispositivos NO DEBEN alterar las limitaciones aplicadas a las aplicaciones en segundo plano.
Más específicamente, para las apps en segundo plano:
- [C-0-4] DEBEN dejar de ejecutar las devoluciones de llamada que registra la app para recibir resultados de
GnssMeasurement
yGnssNavigationMessage
. - [C-0-5] DEBEN limitar la frecuencia de las actualizaciones que se proporcionan a la app a través de la clase de la API
LocationManager
o el métodoWifiManager.startScan()
. - [C-0-6] Si la app se orienta al nivel de API 25 o superior, NO DEBE permitir el registro de receptores de emisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la app, a menos que el intent de emisión requiera un permiso
"signature"
o"signatureOrSystem"
protectionLevel
o esté en la lista de exenciones. - [C-0-7] Si la app se orienta al nivel de API 25 o superior, DEBE detener los servicios en segundo plano de la app, tal como si la app hubiera llamado al método
stopSelf()
de los servicios, a menos que la app se coloque en una lista de entidades permitidas temporal para controlar una tarea que el usuario pueda ver. - [C-0-8] Si la app se orienta al nivel de API 25 o versiones posteriores, DEBE liberar los bloqueos de activación que contiene.
- [C-0-4] DEBEN dejar de ejecutar las devoluciones de llamada que registra la app para recibir resultados de
- [C-0-11] Los dispositivos DEBEN mostrar los siguientes proveedores de seguridad como los primeros siete valores del array del método
Security.getProviders()
, en el orden y con los nombres (como los muestraProvider.getName()
) y las clases determinados, a menos que la app haya modificado la lista a través deinsertProviderAt()
oremoveProvider()
. Los dispositivos PUEDEN mostrar proveedores adicionales después de la lista de proveedores especificada a continuación.- AndroidNSSP:
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL:
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider:
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround:
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC:
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE:
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore:
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP:
La lista anterior no es exhaustiva. El conjunto de pruebas de compatibilidad (CTS) prueba partes significativas de la plataforma para verificar la compatibilidad de comportamiento, pero no todas. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento con el Proyecto de código abierto de Android. Por este motivo, los implementadores de dispositivos DEBEN usar 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 aplicaciones
Si las implementaciones de dispositivos implementan un mecanismo propietario para restringir apps (p.ej., cambiar o restringir los comportamientos de la API que se describen en el SDK) y ese mecanismo es más restrictivo que el segmento de App Standby restringido, sucede lo siguiente:
- [C-1-1] DEBE permitir que el usuario vea la lista de apps restringidas.
- [C-1-2] DEBE proporcionar indicaciones visuales para que el usuario active o desactive todas estas restricciones de propiedad en cada app.
[C-1-3] NO DEBEN aplicar automáticamente estas restricciones de propiedad sin evidencia de un comportamiento deficiente del estado del sistema, pero PUEDEN aplicar las restricciones en las apps cuando se detecta un comportamiento deficiente del estado del sistema, como bloqueos de activación atascados, servicios de larga duración y otros criterios. Los implementadores de dispositivos PUEDEN determinar los criterios, pero DEBEN estar relacionados con el impacto de la app en el estado del sistema. NO se DEBEN usar otros criterios que no se relacionen únicamente con el estado del sistema, como la falta de popularidad de la app en el mercado.
[C-1-4] NO DEBE aplicar automáticamente estas restricciones de propiedad para las apps cuando un usuario las haya desactivado de forma manual y PUEDE sugerirle al usuario que aplique estas restricciones de propiedad.
[C-1-5] DEBEN informar a los usuarios si estas restricciones de propiedad se aplican automáticamente a una app. Dicha información DEBE proporcionarse en el período de 24 horas que precede a la aplicación de estas restricciones de propiedad.
[C-1-6] DEBE mostrar verdadero para el método ActivityManager.isBackgroundRestricted() para cualquier llamada a la API desde una app.
[C-1-7] NO DEBE restringir la app en primer plano que el usuario usa de forma explícita.
[C-1-8] DEBEN suspender estas restricciones de propiedad en una app cada vez que un usuario comienza a usarla de forma explícita, lo que la convierte en la aplicación en primer plano.
[C-1-10] DEBEN proporcionar un documento o sitio web público y claro que describa cómo se aplican las restricciones de propiedad. Este documento o sitio web DEBE poder vincularse desde los documentos del SDK de Android y DEBE incluir lo siguiente:
- Activación de condiciones para restricciones de propiedad
- Qué se puede restringir en una app y cómo hacerlo
- Cómo se puede eximir una app de esas restricciones
- Cómo una app puede solicitar una exención de las restricciones de propiedad, si es que admite una exención de este tipo para las apps que el usuario puede instalar
Si una app está preinstalada en el dispositivo y un usuario nunca la usó de forma explícita durante más de 30 días, se eximen [C-1-3] [C-1-5].
Si las implementaciones de dispositivos extienden las restricciones de apps que se implementan en AOSP, hacen lo siguiente:
- [C-2-1]DEBEN seguir la implementación que se describe en este documento.
3.5.2. Hibernación de apps
Si las implementaciones de dispositivos incluyen la hibernación de apps que se incluye en el AOSP o extienden la función que se incluye en el AOSP, hacen lo siguiente:
- [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 app de un usuario cuando haya evidencia de que el usuario no la usó durante un período determinado. Te RECOMENDAMOS que la 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 de UsageStats#getLastTimeVisible() o cualquier elemento que haga que una app salga del estado de detención forzosa, incluidas las vinculaciones de servicios, las vinculaciones de proveedores de contenido, las transmisiones explícitas, etcétera, de las que se realizará un seguimiento con una nueva API UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] SOLO se deben aplicar restricciones que afecten a todos los usuarios del dispositivo cuando haya evidencia de que NINGÚN usuario usó el paquete durante un período determinado. Te recomendamos que la duración sea de un mes o más.
- [C-1-4] NO DEBE hacer que la app no pueda responder a intents de actividad, vinculaciones de servicio, solicitudes de proveedores de contenido ni transmisiones explícitas.
La hibernación de apps en AOSP cumple con los requisitos anteriores.
3.6. Espacios de nombres de la 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 (consulta a continuación) en estos espacios de nombres de paquetes:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Es decir, tienen las siguientes características:
- [C-0-1] NO DEBE modificar las APIs expuestas públicamente en la plataforma de Android cambiando las firmas de métodos o clases, o quitando 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) ni APIs de prueba o del sistema a las APIs de 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 ascendente.
Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero estas modificaciones deben cumplir con los siguientes requisitos:
- [C-0-3] NO DEBE afectar el comportamiento declarado ni la firma en lenguaje Java de ninguna API expuesta públicamente.
- [C-0-4] NO DEBEN promocionarse ni exponerse a los desarrolladores.
Sin embargo, los implementadores de dispositivos PUEDEN agregar APIs personalizadas fuera del espacio de nombres estándar de Android, pero las APIs personalizadas deben cumplir con los siguientes requisitos:
- [C-0-5] NO DEBE estar en un espacio de nombres que pertenezca a otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres
com.google.*
ni a uno similar: solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a los espacios de nombres de otras empresas. - [C-0-6] DEBEN empaquetarse en una biblioteca compartida de Android para que solo las apps que las usen de forma explícita (a través del mecanismo <uses-library>) se vean afectadas por el aumento del uso de memoria de esas APIs.
Los implementadores de dispositivos PUEDEN agregar APIs personalizadas en lenguajes nativos, fuera de las APIs del NDK, pero las APIs personalizadas deben cumplir con los siguientes requisitos:
- [C-1-1] NO DEBE estar en una biblioteca del NDK ni en una biblioteca que pertenezca a otra organización, como se describe aquí.
Si un implementador de dispositivos propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando una funcionalidad nueva y útil a una API existente o agregando una API nueva), 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.
Ten en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar APIs en el lenguaje de programación Java. El objetivo de esta sección es reforzar esas convenciones y hacerlas vinculantes a través de su inclusión en esta Definición de Compatibilidad.
3.7. Compatibilidad del entorno de ejecución
Implementaciones de dispositivos:
[C-0-1] DEBE admitir el formato ejecutable Dalvik (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 de Android upstream y según se especifica en la siguiente tabla. (Consulta la sección 7.1.1 para obtener definiciones de tamaño y densidad de pantalla).
DEBE usar Android Runtime (ART), la implementación de referencia upstream del formato ejecutable de Dalvik y el sistema de administración de paquetes de la implementación de referencia.
DEBE ejecutar pruebas de fuzz en varios modos de ejecución y arquitecturas de destino para garantizar la estabilidad del entorno de ejecución. Consulta JFuzz y DexFuzz en el sitio web del Proyecto de código abierto de Android.
Ten en cuenta que los valores de memoria que se especifican a continuación se consideran valores mínimos y las implementaciones de dispositivos PUEDEN asignar más memoria por aplicación.
Diseño de la pantalla | Densidad de la pantalla | Memoria mínima de la aplicación |
---|---|---|
Reloj Android | 120 dpi (ldpi) | 32 MB |
140 dpi (140 dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180 dpi) | ||
200 dpi (200 dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220 dpi) | 36 MB | |
240 dpi (hdpi) | ||
280 dpi (280 dpi) | ||
320 dpi (xhdpi) | 48 MB | |
360 dpi (360 dpi) | ||
400 dpi (400dpi) | 56 MB | |
420 dpi (420 dpi) | 64 MB | |
480 dpi (xxhdpi) | 88 MB | |
560 dpi (560dpi) | 112 MB | |
640 dpi (xxxhdpi) | 154 MB | |
pequeño/normal | 120 dpi (ldpi) | 32 MB |
140 dpi (140 dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180 dpi) | 48 MB | |
200 dpi (200 dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220 dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280 dpi) | ||
320 dpi (xhdpi) | 80 MB | |
360 dpi (360 dpi) | ||
400 dpi (400dpi) | 96 MB | |
420 dpi (420 dpi) | 112 MB | |
480 dpi (xxhdpi) | 128 MB | |
560 dpi (560dpi) | 192 MB | |
640 dpi (xxxhdpi) | 256 MB | |
Grande | 120 dpi (ldpi) | 32 MB |
140 dpi (140 dpi) | 48 MB | |
160 dpi (mdpi) | ||
180 dpi (180 dpi) | 80 MB | |
200 dpi (200 dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220 dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280 dpi) | 96 MB | |
320 dpi (xhdpi) | 128 MB | |
360 dpi (360 dpi) | 160 MB | |
400 dpi (400dpi) | 192 MB | |
420 dpi (420 dpi) | 228 MB | |
480 dpi (xxhdpi) | 256 MB | |
560 dpi (560dpi) | 384 MB | |
640 dpi (xxxhdpi) | 512 MB | |
Extragrande | 120 dpi (ldpi) | 48 MB |
140 dpi (140 dpi) | 80 MB | |
160 dpi (mdpi) | ||
180 dpi (180 dpi) | 96 MB | |
200 dpi (200 dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220 dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280 dpi) | 144 MB | |
320 dpi (xhdpi) | 192 MB | |
360 dpi (360 dpi) | 240 MB | |
400 dpi (400dpi) | 288 MB | |
420 dpi (420 dpi) | 336 MB | |
480 dpi (xxhdpi) | 384 MB | |
560 dpi (560dpi) | 576 MB | |
640 dpi (xxxhdpi) | 768 MB |
3.8. Compatibilidad de la interfaz de usuario
3.8.1. Selector (pantalla principal)
Android incluye una aplicación de selector (pantalla principal) y compatibilidad con aplicaciones de terceros para reemplazar el selector del dispositivo (pantalla principal).
Si las implementaciones de dispositivos permiten que aplicaciones de terceros reemplacen la pantalla principal del dispositivo, estas deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE declarar la función de plataforma
android.software.home_screen
. - [C-1-2] DEBE mostrar el objeto
AdaptiveIconDrawable
cuando la aplicación de terceros use la etiqueta<adaptive-icon>
para proporcionar su ícono y se llamen a los métodosPackageManager
para recuperar íconos.
Si las implementaciones de dispositivos incluyen un selector predeterminado que admite la fijación de accesos directos en la app, hacen lo siguiente:
- [C-2-1] DEBE informar
true
paraShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] DEBE tener una indicación visual para el usuario antes de agregar un atajo que soliciten las apps a través del método de la API de
ShortcutManager.requestPinShortcut()
. - [C-2-3] DEBE admitir accesos directos fijos y dinámicos y estáticos, como se documenta en la página Accesos directos de apps.
Por el contrario, si las implementaciones de dispositivos no admiten la fijación de atajos en la app, sucede lo siguiente:
- [C-3-1] DEBE informar
false
paraShortcutManager.isRequestPinShortcutSupported()
.
Si las implementaciones de dispositivos implementan un selector predeterminado que proporciona acceso rápido a los accesos directos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager, hacen lo siguiente:
- [C-4-1] DEBE admitir todas las funciones de acceso directo documentadas (p.ej., accesos directos estáticos y dinámicos, accesos directos de fijación) y, además, implementar por completo las APIs de la clase de API
ShortcutManager
.
Si las implementaciones de dispositivos incluyen una app de selector predeterminada que muestra insignias para los íconos de la app, hacen lo siguiente:
- [C-5-1] DEBE respetar el método de la API de
NotificationChannel.setShowBadge()
. En otras palabras, muestra una indicación visual asociada con el ícono de la app si el valor se establece comotrue
y no muestres ningún esquema de insignias de íconos de apps cuando todos los canales de notificaciones de la app hayan establecido el valor comofalse
. - PUEDEN anular las insignias del ícono de la app con su esquema de insignias propietario cuando las aplicaciones de terceros indican compatibilidad con el esquema de insignias propietario a través del uso de APIs propietarias, pero DEBEN usar los recursos y valores proporcionados a través de las APIs de insignias de notificaciones que se describen en el SDK, como las APIs de
Notification.Builder.setNumber()
yNotification.Builder.setBadgeIconType()
.
Si las implementaciones de dispositivos admiten íconos monocromáticos, estos íconos tienen las siguientes características:
- [C-6-1] DEBEN usarse solo cuando un usuario los habilita de forma explícita (p.ej., a través del menú de configuración o del selector de fondo de pantalla).
3.8.2. Widgets
Android admite widgets de apps de terceros definiendo un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan un “AppWidget” al usuario final.
Si las implementaciones de dispositivos admiten widgets de apps de terceros, pueden hacer lo siguiente:
- [C-1-1] DEBE declarar la compatibilidad con la función de plataforma
android.software.app_widgets
. [C-1-2] DEBE incluir compatibilidad integrada con AppWidgets y exponer los indicadores de la interfaz de usuario para agregar, configurar, ver y quitar AppWidgets.
[C-1-3] DEBE ser capaz de renderizar widgets de 4 × 4 en el tamaño de cuadrícula estándar. Consulta las Pautas de diseño de widgets de apps en la documentación del SDK de Android para obtener más información.
PUEDE admitir widgets de aplicaciones en la pantalla de bloqueo.
Si las implementaciones de dispositivos admiten widgets de apps de terceros y la fijación de accesos directos en la app, hacen lo siguiente:
- [C-2-1] DEBE informar
true
paraAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] DEBE tener una indicación visual para el usuario antes de agregar un atajo que soliciten las apps a través del método de la API de
AppWidgetManager.requestPinAppWidget()
.
3.8.3. Notificaciones
Android incluye las APIs de Notification
y NotificationManager
que permiten a los desarrolladores de apps de terceros notificar a los usuarios sobre eventos importantes y atraer su atención con los componentes de hardware (p.ej., sonido, vibración y luz) y las funciones de software (p.ej., panel de notificaciones y barra del sistema) del dispositivo.
3.8.3.1. Presentación de notificaciones
Si las implementaciones de dispositivos permiten que las apps de terceros notifiquen a los usuarios sobre eventos importantes, hacen lo siguiente:
- [C-1-1] DEBE admitir notificaciones que usen 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 una implementación de dispositivo incluye un vibrador, DEBE implementar correctamente las APIs de vibración. Si una implementación de dispositivo carece de hardware, las APIs correspondientes DEBEN implementarse como no-ops. Este comportamiento se detalla en la sección 7.
- [C-1-2] DEBEN renderizar correctamente todos los recursos (íconos, archivos de animación, etc.) que se proporcionan en las APIs o en la guía de estilo de íconos de la barra de estado o del sistema, aunque PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de código abierto de Android de referencia.
- [C-1-3] DEBEN cumplir y, además, implementar correctamente los comportamientos descritos para las APIs para actualizar, quitar y agrupar notificaciones.
- [C-1-4] DEBE proporcionar el comportamiento completo de la API de NotificationChannel documentada en el SDK.
- [C-1-5] DEBE proporcionar una indicación visual para el usuario para bloquear y modificar la notificación de una app de terceros determinada por cada canal y nivel de paquete de la app.
- [C-1-6] También DEBE proporcionar una indicación visual para el usuario para mostrar los canales de notificaciones borrados.
[C-1-7] DEBEN renderizar correctamente todos los recursos (imágenes, calcomanías, íconos, etcétera) proporcionados a través de Notification.MessagingStyle junto con el texto de la notificación sin interacción adicional del usuario. Por ejemplo, DEBEN mostrar todos los recursos, incluidos los íconos proporcionados a través de android.app.Person en una conversación grupal que se establece a través de setGroupConversation.
[C-SR-1] SE RECOMIENDA ENFATICAMENTE que se proporcione una indicación visual para que el usuario controle las notificaciones que se exponen a las apps a las que se les otorgó el permiso de objeto de escucha de notificaciones. El nivel de detalle DEBE ser tal que el usuario pueda controlar para cada objeto de escucha de notificaciones qué tipos de notificaciones se conectan a este objeto. Los tipos DEBEN incluir notificaciones "conversaciones", "alertas", "silenciadas" y "importantes continuas".
[C-SR-2] SE RECOMIENDA ENFATICAMENTE proporcionar una indicación para que los usuarios especifiquen las apps que se excluirán de notificar a cualquier objeto de escucha de notificaciones específico.
[C-SR-3] SE RECOMIENDA ENFATICAMENTE que muestres automáticamente una indicación visual para el usuario para bloquear la notificación de una app de terceros determinada por cada canal y nivel de paquete de la app después de que el usuario descarte esa notificación varias veces.
DEBE admitir notificaciones enriquecidas.
DEBE presentar algunas notificaciones de prioridad más alta como notificaciones de atención.
DEBE tener una indicación visual para el usuario para posponer las notificaciones.
SOLO PUEDEN administrar la visibilidad y el tiempo en que las apps de terceros pueden notificar a los usuarios sobre eventos importantes para mitigar problemas de seguridad, como la distracción del conductor.
Android 11 presenta compatibilidad con las notificaciones de conversación, que son notificaciones que usan MessagingStyle y proporcionan un ID de acceso directo de Personas publicado.
Implementaciones de dispositivos:
- [C-SR-4] SE RECOMIENDA ENFATICAMENTE que se agrupen y muestren las notificaciones de
conversation notifications
antes de las notificaciones que no sean de conversación, a excepción de las notificaciones de servicios en primer plano en curso y deimportance:high
.
Si las implementaciones de dispositivos admiten conversation notifications
y la app proporciona los datos necesarios para bubbles
, hacen lo siguiente:
- [C-SR-5] SE RECOMIENDA ENFATICAMENTE que muestres esta conversación como una burbuja. La implementación de AOSP cumple con estos requisitos con la IU del sistema, la configuración y el selector predeterminados.
Si las implementaciones de dispositivos admiten notificaciones enriquecidas, pueden hacer lo siguiente:
- [C-2-1] DEBEN usar los recursos exactos como se proporciona a través de la clase de API de
Notification.Style
y sus subclases para los elementos de recursos presentados. - DEBE presentar todos los elementos de recursos (p.ej., ícono, título y texto de resumen) definidos en la clase de API de
Notification.Style
y sus subclases.
Las notificaciones de atención son notificaciones que se le presentan al usuario a medida que llegan, independientemente de la plataforma en la que se encuentre. Si las implementaciones de dispositivos admiten notificaciones de atención, hacen lo siguiente:
- [C-3-1] DEBE usar la vista y los recursos de notificaciones de atención como se describe en la clase de API de
Notification.Builder
cuando se presentan notificaciones de atención. - [C-3-2] DEBE mostrar las acciones proporcionadas a través de
Notification.Builder.addAction()
junto con el contenido de la notificación sin interacción adicional del usuario, como se describe en el SDK.
3.8.3.2. Servicio de objeto de escucha de notificaciones
Android incluye las APIs de NotificationListenerService
que permiten que las apps (una vez que el usuario las habilita de forma explícita) reciban una copia de todas las notificaciones a medida que se publican o actualizan.
Implementaciones de dispositivos:
- [C-0-1] DEBEN actualizar correctamente y de forma oportuna las notificaciones en su totalidad a todos los servicios de objeto de escucha instalados y habilitados por el usuario, incluidos todos los metadatos adjuntos al objeto Notification.
- [C-0-2] DEBE respetar la llamada a la API de
snoozeNotification()
, descartar la notificación y realizar una devolución de llamada después de la duración de posposición establecida en la llamada a la API.
Si las implementaciones de dispositivos tienen una indicación visual para que el usuario posponga las notificaciones, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE reflejar el estado de la notificación pospuesta correctamente a través de las APIs estándar, como
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] DEBE hacer que esta indicación visual para el usuario esté disponible para posponer las notificaciones de cada app de terceros instalada, a menos que provengan de servicios persistentes o en primer plano.
3.8.3.3. DND (No interrumpir) / Modo de prioridad
Si las implementaciones de dispositivos admiten la función No interrumpir (también llamada modo Prioridad), hacen lo siguiente:
- [C-1-1] DEBE, cuando la implementación del dispositivo haya proporcionado un medio para que el usuario otorgue o deniegue el acceso de apps de terceros a la configuración de la política de No interrumpir, mostrar las reglas de No interrumpir automáticas creadas por las aplicaciones junto con las reglas predefinidas y creadas por el usuario.
- [C-1-3] DEBE respetar los valores de
suppressedVisualEffects
que se pasan a través deNotificationManager.Policy
y, si una app configuró cualquiera de las marcas SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEBE indicarle al usuario que se suprimen los efectos visuales en el menú de configuración de No interrumpir.
3.8.4. APIs de Assist
Android incluye las APIs de Assist 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 Asistente, hacen lo siguiente:
- [C-2-1] DEBE indicar claramente al usuario final cuándo se comparte el contexto de una de las siguientes maneras:
- Cada vez que la app de asistencia accede al contexto, se muestra una luz blanca alrededor de los bordes de la pantalla que cumple o supera la duración y el brillo de la implementación del proyecto de código abierto de Android.
- Para la app de asistencia preinstalada, proporciona una indicación visual para el usuario a menos de dos navegaciones de la entrada de voz predeterminada y el menú de configuración de la app de asistencia, y comparte el contexto solo cuando el usuario invoque explícitamente la app de asistencia a través de una palabra clave o una entrada de tecla de navegación de asistencia.
- [C-2-2] La interacción designada para iniciar la app de asistencia, como se describe en la sección 7.2.3, DEBE iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa
VoiceInteractionService
, o una actividad que controle el intentACTION_ASSIST
.
3.8.5. Alertas y notificaciones emergentes
Las aplicaciones pueden usar la API de Toast
para mostrarle al usuario final cadenas cortas no modales que desaparecen después de un período breve y usar la API de tipo de ventana TYPE_APPLICATION_OVERLAY
para mostrar ventanas de alerta como una superposición sobre otras apps.
Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:
[C-1-1] DEBE proporcionar una indicación visual para el usuario para bloquear una app de mostrar ventanas de alerta que usen
TYPE_APPLICATION_OVERLAY
. La implementación de AOSP cumple con este requisito porque tiene controles en la barra de notificaciones.[C-1-2] DEBE respetar la API de Toast y mostrar notificaciones de Toast desde las aplicaciones a los usuarios finales de una manera muy visible.
3.8.6. Temas
Android proporciona “temas” como un mecanismo para que las aplicaciones apliquen estilos en una actividad o aplicación completa.
Android incluye una familia de temas "Holo" y "Material" como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si desean que coincidan con el aspecto y estilo del tema Holo, como lo define el SDK de Android.
Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:
- [C-1-1] NO DEBE alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones.
- [C-1-2] DEBEN admitir la familia de temas "Material" y NO DEBEN alterar ninguno de los atributos del tema de Material ni sus recursos 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 bien proporcionar una indicación visual para el usuario para cambiar la fuente que se usa para la familia de fuentes "sans-serif" a la versión 2.x de Roboto para los idiomas que admite Roboto.
[C-1-4] DEBEN generar paletas tonales de colores dinámicos como se especifica en la documentación de AOSP de
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(consultaandroid.theme.customization.system_palette
yandroid.theme.customization.theme_style
).[C-1-5] DEBEN generar paletas de tonos de color dinámicos con estilos de temas de color enumerados en la documentación de
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(consultaandroid.theme.customization.theme_styles
), comoTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, yMONOCHROMATIC
."Color de origen" que se usa para generar paletas tonales de colores dinámicos cuando se envía con
android.theme.customization.system_palette
(como se documenta enSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] DEBE tener un valor de croma
CAM16
de 5 o superior.DEBE derivarse del fondo de pantalla a través de
com.android.systemui.monet.ColorScheme#getSeedColors
, que proporciona varios colores de origen válidos para elegir uno.DEBE usar el valor
0xFF1B6EF3
si ninguno de los colores proporcionados cumple con el requisito de color de origen anterior.
Android también incluye una familia de temas "Device Default" como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si desean que coincidan con el aspecto del tema del dispositivo, según lo define el implementador del dispositivo.
- Las implementaciones de dispositivos PUEDEN modificar los atributos del tema predeterminado del dispositivo expuestos a las aplicaciones.
Android admite un tema de variante con barras de sistema traslúcidas, lo que permite a los desarrolladores de aplicaciones completar el área detrás de la barra de estado y de navegación con el contenido de su app. Para permitir una experiencia de desarrollador coherente en esta configuración, es importante que el estilo del ícono de la barra de estado se mantenga en las diferentes implementaciones de dispositivos.
Si las implementaciones de dispositivos incluyen una barra de estado del sistema, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBE usar el color blanco para los íconos de estado del sistema (como la intensidad de la señal y el nivel de batería) y las notificaciones que emite el sistema, a menos que el ícono indique un estado problemático o una app solicite una barra de estado clara con la marca WindowInsetsController#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 información, consulta R.style) cuando una app solicite una barra de estado clara.
3.8.7. Fondos de pantalla animados
Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan uno o más "Fondos de pantalla animados" al usuario final. Los fondos de pantalla animados son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como un fondo de pantalla detrás de otras aplicaciones.
El hardware se considera capaz de ejecutar fondos de pantalla en vivo de forma confiable si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones en la funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware hacen que los fondos de pantalla o las aplicaciones fallen, funcionen mal, consuman energía de la CPU o de la batería de forma excesiva, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware no es capaz de ejecutar fondos de pantalla en vivo. A modo de ejemplo, algunos fondos de pantalla en vivo pueden usar un contexto de OpenGL 2.0 o 3.x para renderizar su contenido. El fondo de pantalla en vivo no se ejecutará de forma confiable en hardware que no admita varios contextos de OpenGL, ya que el uso de un contexto de OpenGL en el fondo de pantalla en vivo puede entrar en conflicto con otras aplicaciones que también usan un contexto de OpenGL.
- Las implementaciones de dispositivos que pueden ejecutar fondos de pantalla de forma confiable, como se describe anteriormente, DEBEN implementar fondos de pantalla.
Si las implementaciones de dispositivos implementan fondos de pantalla animados, hacen lo siguiente:
- [C-1-1] DEBE informar la marca de función de la plataforma android.software.live_wallpaper.
3.8.8. Cambio de actividad
El código fuente de Android upstream incluye la pantalla de descripción general, una interfaz de usuario a nivel del sistema para cambiar de tarea y mostrar actividades y tareas a las que se accedió recientemente con una imagen en miniatura del estado gráfico de la aplicación en el momento en que el usuario salió de ella por última vez.
Es POSIBLE que las implementaciones de dispositivos que incluyan la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, alteren la interfaz.
Si las implementaciones de dispositivos, incluida la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, alteran la interfaz, sucede lo siguiente:
- [C-1-1] DEBE admitir al menos 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 proporcionarle al usuario un menú de configuración para activar o desactivar la función.
- DEBE mostrar el color de resaltado, el ícono y el título de la pantalla en Recientes.
- DEBE mostrar un indicador de cierre ("x"), pero PUEDE retrasarlo 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 apps que se usaron más recientemente cuando se presiona dos veces la tecla de función de apps recientes.
- DEBE activar el modo multiventana de pantalla dividida, si es compatible, cuando se mantiene presionada la tecla de funciones recientes.
- PUEDE mostrar contenido reciente afiliado como un grupo que se mueve junto.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que uses la interfaz de usuario de Android upstream (o una interfaz similar basada en miniaturas) para la pantalla de descripción general.
3.8.9. Administración de entradas
Android incluye compatibilidad con la Administración de entrada y con editores de métodos de entrada de terceros.
Si las implementaciones de dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE declarar la función de plataforma android.software.input_methods y admitir las APIs de IME como se define en la documentación del SDK de Android.
3.8.10. Control de contenido multimedia en la pantalla de bloqueo
La API de Remote Control Client dejó de estar disponible a partir de Android 5.0 en favor de la Media Notification Template, 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. Protectores de pantalla (anteriormente, Fantasías)
Consulta la sección 3.2.3.5 para obtener información sobre el intent de configuración para configurar protectores de pantalla.
3.8.12. Ubicación
Si las implementaciones de dispositivos incluyen un sensor de hardware (p.ej., GPS) que puede proporcionar las coordenadas de ubicación,
- [C-1-2] DEBE mostrar el estado actual de la ubicación en el menú Ubicación de Configuración.
- [C-1-3] NO DEBE mostrar los modos de ubicación en el menú Ubicación de Configuración.
3.8.13. Unicode y fuente
Android incluye compatibilidad con los caracteres de emoji definidos en Unicode 10.0.
Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:
- [C-1-1] DEBE ser capaz de renderizar estos caracteres de emojis en glifos de color.
- [C-1-2] DEBE incluir compatibilidad con lo siguiente:
- Fuente Roboto 2 con diferentes grosores: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed y sans-serif-condensed-light para los idiomas disponibles en el dispositivo
- Cobertura completa de Unicode 7.0 de los alfabetos latino, griego y cirílico, incluidos los rangos A, B, C y D de la extensión latina, y todos los glifos del bloque de símbolos de moneda de Unicode 7.0.
- [C-1-3] NO DEBES quitar ni modificar NotoColorEmoji.tff en la imagen del sistema. (Se puede agregar una nueva fuente de emojis para anular los emojis en NotoColorEmoji.tff).
- DEBE admitir el tono de piel y los emojis de diversas familias, como se especifica en el Informe técnico n° 51 de Unicode.
Si las implementaciones de dispositivos incluyen un IME, hacen lo siguiente:
- DEBE proporcionarle al usuario un método de entrada para estos caracteres de emoji.
Android incluye compatibilidad para renderizar fuentes birmanas. Birmania tiene varias fuentes que no cumplen con Unicode, conocidas comúnmente como “Zawgyi”, para renderizar los idiomas de Birmania.
Si las implementaciones de dispositivos incluyen compatibilidad con birmano, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBE renderizar 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 sea compatible con Unicode. La fuente que no cumple con Unicode NO DEBE quitar ni reemplazar la fuente Unicode.
- [C-2-3] DEBE renderizar texto con una fuente que no sea compatible con Unicode SOLO SI se especifica un código de idioma con el código de escritura Qaag (p.ej., my-Qaag). No se pueden usar otros códigos de idioma o región ISO (ya sea asignados, no asignados o reservados) para hacer referencia a una fuente que no sea compatible con Unicode para Birmania. Los desarrolladores de apps y los autores de páginas web pueden especificar my-Qaag como el código de idioma designado, como lo harían con cualquier otro idioma.
3.8.14. Multiventanas
Si las implementaciones de dispositivos tienen la capacidad de mostrar varias actividades al mismo tiempo, hacen lo siguiente:
- [C-1-1] DEBEN implementar esos modos multiventana de acuerdo con los comportamientos de la aplicación y las APIs que se describen en la documentación de compatibilidad con el modo multiventana del SDK de Android y cumplir con los siguientes requisitos:
- [C-1-2] DEBE respetar el
android:resizeableActivity
que establece una app en el archivoAndroidManifest.xml
, como se describe en este SDK. - [C-1-3] NO DEBE ofrecer el modo de pantalla dividida ni de forma libre si la altura de la pantalla es inferior a 440 dp y el ancho es inferior a 440 dp.
- [C-1-4] El tamaño de una actividad NO DEBE cambiarse a un tamaño inferior a 220 dp en los modos multiventana que no sean de pantalla en pantalla.
- Las implementaciones de dispositivos con tamaño de pantalla
xlarge
DEBEN admitir el modo de formato libre.
Si las implementaciones de dispositivos admiten los modos multiventana y de pantalla dividida, hacen lo siguiente:
- [C-2-2] DEBE recortar la actividad anclada de una ventana múltiple de pantalla dividida, pero DEBE mostrar parte de su contenido si la app del selector es la ventana enfocada.
- [C-2-3] DEBE respetar los valores declarados de
AndroidManifestLayout_minWidth
yAndroidManifestLayout_minHeight
de la aplicación del selector de terceros y no anularlos cuando se muestra parte del contenido de la actividad en la estación de carga.
Si las implementaciones de dispositivos admiten modos multiventana y el modo multiventana de pantalla en pantalla, hacen lo siguiente:
- [C-3-1] DEBE iniciar actividades en el modo multiventana de pantalla en pantalla cuando la app cumpla con las siguientes condiciones:
* Se orienta al nivel de API 26 o superior y declara
android:supportsPictureInPicture
* Se orienta al nivel de API 25 o inferior y declaraandroid:resizeableActivity
yandroid:supportsPictureInPicture
. - [C-3-2] DEBEN exponer las acciones en su SystemUI como lo especifique la actividad de PIP actual a través de la API de
setActions()
. - [C-3-3] DEBE admitir relaciones de aspecto superiores o iguales a 1:2.39 y menores o iguales a 2.39:1, como lo especifica la actividad de PIP a través de la API de
setAspectRatio()
. - [C-3-4] DEBE usar
KeyEvent.KEYCODE_WINDOW
para controlar la ventana de PIP. Si no se implementa el modo PIP, la clave DEBE estar disponible para la actividad en primer plano. - [C-3-5] DEBE proporcionar una indicación visual para el usuario para bloquear una app de mostrarse en modo PIP. La implementación de AOSP cumple con este requisito porque tiene controles en el panel de notificaciones.
[C-3-6] DEBE asignar el siguiente ancho y la altura mínimos para la ventana de PIP cuando una aplicación no declara ningún valor para
AndroidManifestLayout_minWidth
yAndroidManifestLayout_minHeight
:- Los dispositivos con Configuration.uiMode establecido de otra manera que no sea
UI_MODE_TYPE_TELEVISION
DEBEN asignar un ancho y una altura mínimos de 108 dp. - Los dispositivos con Configuration.uiMode configurado como
UI_MODE_TYPE_TELEVISION
DEBEN asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.
- Los dispositivos con Configuration.uiMode establecido de otra manera que no sea
3.8.15. Corte de pantalla
Android admite un recorte de pantalla como se describe en el documento del SDK. La API de DisplayCutout
define un área en el borde de la pantalla que puede no ser funcional para una aplicación debido a un recorte de pantalla o una pantalla curva en los bordes.
Si las implementaciones de dispositivos incluyen recortes de pantalla, deben cumplir con los siguientes requisitos:
- [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 las marcas de recorte de pantalla que establece la app a través de la API de
WindowManager.LayoutParams
, como se describe en el SDK. - [C-1-4] DEBE informar valores correctos para todas las métricas de recorte definidas en la API de
DisplayCutout
.
3.8.16. Controles de dispositivos
Android incluye las APIs de ControlsProviderService
y Control
para permitir que las aplicaciones de terceros publiquen controles de dispositivos para el estado y la acción rápidos de los usuarios.
Consulta la sección 2_2_3 para conocer los requisitos específicos de los dispositivos.
3.8.17. Portapapeles
Implementaciones de dispositivos:
- [C-0-1] NO DEBE enviar datos del portapapeles a ningún componente, actividad, servicio ni a través de ninguna conexión de red sin una acción explícita del usuario (p.ej., presionar un botón en la superposición) o una indicación de que se está enviando contenido, excepto por los servicios mencionados en 9.8.6 Captura de contenido y búsqueda de apps.
Si las implementaciones de dispositivos generan una vista previa visible para el usuario cuando se copia contenido en el portapapeles para cualquier elemento ClipData
en el que ClipData.getDescription().getExtras()
contenga android.content.extra.IS_SENSITIVE
, hacen lo siguiente:
- [C-1-1] DEBE ocultar la vista previa visible para el usuario.
La implementación de referencia de AOSP satisface estos requisitos del portapapeles.
3.9. Administración del dispositivo
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ñas o realizar limpiezas remotas, a través de la API de administración de dispositivos Android.
Si las implementaciones de dispositivos implementan la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android, hacen lo siguiente:
- [C-1-1] DEBE declarar
android.software.device_admin
. - [C-1-2] DEBE admitir el aprovisionamiento del propietario del dispositivo, como se describe en 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
, hacen lo siguiente:
- [C-1-1] DEBE admitir la inscripción de un cliente de políticas de dispositivos (DPC) como una app de propietario del dispositivo, como se describe a continuación:
- Cuando la implementación del dispositivo no tiene configurados usuarios ni datos del usuario, sucede lo siguiente:
- [C-1-5] DEBE inscribir la aplicación de DPC como la app del propietario del dispositivo o habilitar la app de DPC para que elija si convertirse en propietario del dispositivo o del perfil, si el dispositivo declara compatibilidad con la comunicación de campo cercano (NFC) a través de la marca de función
android.hardware.nfc
y recibe un mensaje NFC que contiene un registro con el tipo MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] DEBE enviar el intent ACTION_GET_PROVISIONING_MODE después de que se active el aprovisionamiento del propietario del dispositivo para que la app de DPC pueda elegir si convertirse en propietario del dispositivo o del perfil, según los valores de
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, a menos que se pueda determinar a partir del contexto que solo hay una opción válida. - [C-1-9] DEBE enviar la intención ACTION_ADMIN_POLICY_COMPLIANCE a la app del propietario del dispositivo si se establece un propietario del dispositivo durante el aprovisionamiento, independientemente del método de aprovisionamiento que se use. El usuario no debe poder continuar en el Asistente de configuración hasta que finalice la app de propietario del dispositivo.
- [C-1-5] DEBE inscribir la aplicación de DPC como la app del propietario del dispositivo o habilitar la app de DPC para que elija si convertirse en propietario del dispositivo o del perfil, si el dispositivo declara compatibilidad con la comunicación de campo cercano (NFC) a través de la marca de función
- Cuando la implementación del dispositivo tiene usuarios o datos del usuario, hace lo siguiente:
- [C-1-7] Ya NO se DEBE inscribir ninguna aplicación de DPC como la app del propietario del dispositivo.
- Cuando la implementación del dispositivo no tiene configurados usuarios ni datos del usuario, sucede lo siguiente:
[C-1-2] DEBEN mostrar un aviso de divulgación adecuado (como el que se menciona en el AOSP) y obtener el consentimiento afirmativo del usuario final antes de que se configure una app como propietario del dispositivo, a menos que el dispositivo esté configurado de forma programática para el modo de demostración de venta minorista antes de la interacción en pantalla del usuario final. Si las implementaciones de dispositivos declaran
android.software.device_admin
, pero también incluyen una solución de administración de dispositivos propietaria y proporcionan un mecanismo para promocionar una aplicación configurada en su solución como un "propietario del dispositivo equivalente" al "propietario del dispositivo" estándar, como lo reconocen las APIs estándar de DevicePolicyManager de Android, hacen lo siguiente:[C-2-1] DEBEN tener un proceso para verificar que la app específica que se promociona pertenezca a una solución legítima de administración de dispositivos empresariales y que se haya configurado en la solución propietaria para tener los derechos equivalentes de "propietario del dispositivo".
[C-2-2] DEBE mostrar la misma divulgación de consentimiento del propietario del dispositivo de AOSP que el flujo iniciado por
android.app.action.PROVISION_MANAGED_DEVICE
antes de inscribir la aplicación del DPC como "Propietario del dispositivo".[C-2-3] NO DEBE codificar de forma fija el consentimiento ni impedir el uso de otras apps del propietario del dispositivo.
3.9.1.2 Aprovisionamiento de perfiles administrados
Si las implementaciones de dispositivos declaran android.software.managed_users
, hacen lo siguiente:
[C-1-1] DEBE implementar las APIs que permiten que una aplicación de controlador de políticas de dispositivos (DPC) se convierta en el propietario de un nuevo perfil administrado.
[C-1-2] El proceso de aprovisionamiento de perfiles administrados (el flujo que inicia el DPC con android.app.action.PROVISION_MANAGED_PROFILE) o 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 indicaciones visuales para el usuario en la configuración para indicarle al usuario cuando el controlador de políticas de dispositivos (DPC) haya inhabilitado una función del sistema en particular:
- Un ícono coherente o cualquier otra indicación visual para el usuario (por ejemplo, el ícono de información de AOSP upstream) que represente cuándo un administrador de dispositivos restringe un parámetro de configuración en particular
- Un mensaje de explicación breve, como el que proporciona el administrador de dispositivos a través de
setShortSupportMessage
. - El ícono de la aplicación del DPC
[C-1-4] DEBE iniciar el controlador para el intent ACTION_PROVISIONING_SUCCESSFUL en el perfil de trabajo si se establece un propietario de perfil cuando el intent android.app.action.PROVISION_MANAGED_PROFILE inicia el aprovisionamiento y el DPC implementó 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 inicie el aprovisionamiento.
[C-1-6] DEBE enviar el intent ACTION_GET_PROVISIONING_MODE después de que se active el aprovisionamiento del propietario del perfil para que la app del DPC pueda elegir si convertirse en propietario del dispositivo o del perfil, excepto cuando el intent android.app.action.PROVISION_MANAGED_PROFILE active el aprovisionamiento.
[C-1-7] DEBE enviar el intent ACTION_ADMIN_POLICY_COMPLIANCE al perfil de trabajo cuando se establece un propietario de perfil durante el aprovisionamiento, independientemente del método de aprovisionamiento que se use, excepto cuando el intent android.app.action.PROVISION_MANAGED_PROFILE activa el aprovisionamiento. El usuario no debe poder continuar en el Asistente de configuración hasta que finalice la app del 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 de perfil, independientemente del método de aprovisionamiento que se use.
3.9.2 Compatibilidad con perfiles administrados
Si las implementaciones de dispositivos declaran android.software.managed_users
, hacen lo siguiente:
- [C-1-1] DEBE admitir perfiles administrados a través de las APIs de
android.app.admin.DevicePolicyManager
. - [C-1-2] DEBE permitir que se cree un solo perfil administrado.
- [C-1-3] DEBE usar una insignia de ícono (similar a la insignia de trabajo upstream de AOSP) para representar las aplicaciones y los widgets administrados, y otros elementos de la IU con insignias, como Recientes y Notificaciones.
- [C-1-4] DEBE mostrar un ícono de notificación (similar a la insignia de trabajo upstream de AOSP) para indicar cuándo el usuario se encuentra en una aplicación de perfil administrado.
- [C-1-5] DEBE mostrar una notificación del sistema que indique que el usuario está en el perfil administrado si el dispositivo se activa (ACTION_USER_PRESENT) y la aplicación en primer plano está dentro del perfil administrado.
- [C-1-6] Cuando existe un perfil administrado, DEBE mostrarse una indicación visual en el "Selector" de intents para permitir que el usuario reenvíe el intent del perfil administrado al usuario principal o viceversa, si el Controlador de políticas de dispositivos lo habilita.
- [C-1-7] Cuando existe un perfil administrado, DEBE exponer los siguientes indicadores visuales para el usuario principal y el perfil administrado:
- Contabilización independiente del uso de la batería, la ubicación, los datos móviles y el almacenamiento para el usuario principal y el perfil administrado
- Administración independiente de las aplicaciones de VPN instaladas en el usuario principal o el perfil administrado
- Administración independiente de las aplicaciones instaladas en el usuario principal o el perfil administrado
- Administración independiente de las cuentas dentro del usuario principal o el perfil administrado
- [C-1-8] DEBEN garantizar que el selector, los contactos y las aplicaciones de mensajería preinstalados puedan buscar y consultar la información del emisor desde el perfil administrado (si existe) junto con la del perfil principal, si el controlador de políticas de dispositivos lo permite.
- [C-1-9] DEBE garantizar que cumpla con todos los requisitos de seguridad aplicables a un dispositivo con varios usuarios habilitados (consulta la sección 9.5), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.
Cómo iniciar nuevos requisitos
- [C-1-10] DEBE garantizar que los datos de la captura de pantalla se guarden en el almacenamiento del perfil de trabajo cuando se captura una captura de pantalla con una ventana
topActivity
que tenga enfoque (la última con la que el usuario interactuó entre todas las actividades) y pertenezca a una app de perfil de trabajo. - [C-1-11] NO DEBE capturar ningún otro contenido de pantalla (barra del sistema, notificaciones o cualquier contenido del perfil personal), excepto las ventanas de la aplicación del perfil de trabajo cuando se guarda una captura de pantalla en el perfil de trabajo (para garantizar que los datos del perfil personal no se guarden en el perfil de trabajo).
Fin de los nuevos requisitos
Si las implementaciones de dispositivos declaran android.software.managed_users
y android.software.secure_lock_screen
, hacen lo siguiente:
- [C-2-1] DEBE admitir la capacidad de especificar una pantalla de bloqueo independiente que cumpla con los siguientes requisitos para otorgar acceso solo a las apps que se ejecutan en un perfil administrado.
- Las implementaciones de dispositivos DEBEN respetar el intent
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
y mostrar una interfaz para configurar una credencial de pantalla de bloqueo independiente para el perfil administrado. - Las credenciales de la pantalla de bloqueo del perfil administrado DEBEN usar los mismos mecanismos de almacenamiento y administración de credenciales que el perfil superior, como se documenta en el sitio del proyecto de código abierto de Android.
- Las políticas de contraseñas del DPC DEBEN aplicarse solo a las credenciales de la pantalla de bloqueo del perfil administrado, a menos que se llame a la instancia
DevicePolicyManager
que muestra getParentProfileInstance.
- Las implementaciones de dispositivos DEBEN respetar el intent
- Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la IU durante la llamada, las notificaciones de llamadas en curso y perdidas, los contactos y las apps de mensajería, DEBEN tener la misma insignia que se usa para indicar las aplicaciones de perfil administrado.
3.9.3 Asistencia para usuarios administrados
Si las implementaciones de dispositivos declaran android.software.managed_users
, hacen lo siguiente:
- [C-1-1] DEBE proporcionar una indicación visual para que el usuario salga del usuario actual y vuelva al usuario principal en la sesión de varios usuarios cuando
isLogoutEnabled
devuelvatrue
. Se DEBE poder acceder a la indicación visual para el usuario desde la pantalla de bloqueo sin desbloquear el dispositivo.
Si las implementaciones de dispositivos declaran android.software.device_admin
y proporcionan una indicación visual para el usuario en el dispositivo para agregar usuarios secundarios adicionales, hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que se muestren las mismas divulgaciones de consentimiento del propietario del dispositivo de 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, de modo que los usuarios comprendan que el dispositivo está administrado.
3.9.4 Requisitos de los roles de administración de políticas de dispositivos
Si las implementaciones de dispositivos informan android.software.device_admin
o android.software.managed_users
, hacen lo siguiente:
- [C-1-1] DEBE admitir el rol de administración de políticas del dispositivo, como se define en la sección 9.1. La aplicación que tiene el rol de administración de políticas del dispositivo PUEDE definirse si se establece
config_devicePolicyManagement
en el nombre del paquete. El nombre del paquete DEBE ir seguido de:
y el certificado de firma, a menos que la aplicación esté cargada previamente.
Si no se define un nombre de paquete para config_devicePolicyManagement
como se describió anteriormente, ocurrirá lo siguiente:
- [C-2-1] Las implementaciones de dispositivos DEBEN admitir el aprovisionamiento sin una aplicación de titular de rol de administración de políticas de dispositivos (AOSP proporciona una implementación de referencia).
Si se define un nombre de paquete para config_devicePolicyManagement
como se describió anteriormente, haz lo siguiente:
- [C-3-1] La aplicación DEBE estar instalada en todos los perfiles de un usuario.
- [C-3-2] Las implementaciones de dispositivos PUEDEN definir una aplicación que actualice el titular del rol de administración de políticas del dispositivo antes del aprovisionamiento configurando
config_devicePolicyManagementUpdater
.
Si se define un nombre de paquete para config_devicePolicyManagementUpdater
como se describió anteriormente, haz lo siguiente:
- [C-4-1] La aplicación DEBE estar preinstalada en el dispositivo.
- [C-4-2] La aplicación DEBE implementar un filtro de intents que resuelva
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
Cómo iniciar nuevos requisitos
3.9.5 Framework de resolución de políticas de dispositivos
Si las implementaciones de dispositivos informan android.software.device_admin
o android.software.managed_users
, hacen lo siguiente:
- [C-1-1] DEBE resolver los conflictos de políticas de dispositivos según se documenta en el Framework de resolución de políticas de dispositivos.
Fin de los nuevos requisitos
3.10. Accesibilidad
Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos con mayor facilidad. Además, Android proporciona APIs de la plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamada para eventos del usuario y del sistema, y generen mecanismos de comentarios alternativos, como texto a voz, comentarios táctiles y navegación con trackball o mando de control.
Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE proporcionar una implementación del framework de accesibilidad de Android como se describe en la documentación del SDK de las APIs de accesibilidad.
- [C-1-2] DEBE generar eventos de accesibilidad y entregar el
AccessibilityEvent
apropiado a todas las implementaciones registradas deAccessibilityService
, como se documenta en el SDK. - [C-1-4] DEBE proporcionar una indicación visual para el usuario para controlar los servicios de accesibilidad que declaran AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Ten en cuenta que, en el caso de las implementaciones de dispositivos con una barra de navegación del sistema, DEBEN permitir que el usuario tenga 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, tienen las siguientes características:
- [C-2-1] DEBEN implementar estos servicios de accesibilidad preinstalados como apps compatibles con el inicio directo cuando el almacenamiento de datos esté encriptado con la encriptación basada en archivos (FBE).
- DEBE proporcionar un mecanismo en el flujo de configuración listo para usar para que los usuarios habiliten los servicios de accesibilidad relevantes, así como opciones para ajustar el tamaño de la fuente, el tamaño de la pantalla y los gestos de magnificación.
3.11. Text-to-Speech
Android incluye APIs que permiten que las aplicaciones usen servicios de texto a voz (TTS) y que los proveedores de servicios proporcionen implementaciones de servicios de TTS.
Si las implementaciones de dispositivos informan la función android.hardware.audio.output, hacen lo siguiente:
- [C-1-1] DEBE admitir las APIs de Android TTS framework.
Si las implementaciones de dispositivos admiten la instalación de motores de TTS de terceros, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBE proporcionar indicaciones visuales para que el usuario seleccione un motor de TTS para usarlo a nivel del sistema.
3.12. Framework de entrada de TV
El marco de trabajo de entrada de Android Television (TIF) simplifica la entrega de contenido en vivo a los dispositivos Android Television. El TIF proporciona una API estándar para crear módulos de entrada que controlen dispositivos de Android TV.
Si las implementaciones de dispositivos admiten TIF, hacen lo siguiente:
- [C-1-1] DEBE declarar la función de plataforma
android.software.live_tv
. - [C-1-2] DEBE admitir todas las APIs de TIF para que se pueda instalar y usar en el dispositivo una aplicación que use estas APIs y el servicio de entradas basadas en TIF de terceros.
3.13. Configuración rápida
Android proporciona un componente de IU de Quick Settings que permite un acceso rápido a acciones que se usan con frecuencia o que se necesitan con urgencia.
Si las implementaciones de dispositivos incluyen un componente de IU de Configuración rápida y admiten Configuración rápida de terceros, hacen lo siguiente:
- [C-1-1] DEBE permitir que el usuario agregue o quite las tarjetas proporcionadas a través de las APIs de
quicksettings
desde una app de terceros. - [C-1-2] NO DEBE agregar automáticamente una tarjeta de una app de terceros directamente a la Configuración rápida.
- [C-1-3] DEBE mostrar todas las tarjetas agregadas por el usuario de apps de terceros junto con las tarjetas de configuración rápida proporcionadas por el sistema.
3.14. IU de contenido multimedia
Si las implementaciones de dispositivos incluyen aplicaciones que no se activan por voz (las Apps) que interactúan con aplicaciones de terceros a través de MediaBrowser
o MediaSession
, las Apps deben cumplir con lo siguiente:
[C-1-2] DEBEN mostrar claramente los íconos obtenidos a través de
getIconBitmap()
ogetIconUri()
y los títulos obtenidos a través degetTitle()
, como se describe enMediaDescription
. Se pueden acortar los títulos para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor).[C-1-3] DEBE mostrar el ícono de la aplicación de terceros cada vez que se muestre contenido proporcionado por esta aplicación.
[C-1-4] DEBE permitir que el usuario interactúe con toda la jerarquía de
MediaBrowser
. PUEDEN restringir el acceso a parte de la jerarquía para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor), pero NO DEBEN dar un tratamiento preferencial en función del contenido o el proveedor de contenido.[C-1-5] DEBE considerar el doble toque de
KEYCODE_HEADSETHOOK
oKEYCODE_MEDIA_PLAY_PAUSE
comoKEYCODE_MEDIA_NEXT
paraMediaSession.Callback#onMediaButtonEvent
.
3.15. Apps instantáneas
Si las implementaciones de dispositivos admiten apps instantáneas, DEBEN cumplir con los siguientes requisitos:
- [C-1-1] Solo se DEBEN otorgar permisos a las apps instantáneas que tengan el
android:protectionLevel
configurado en"instant"
. - [C-1-2] Las apps instantáneas NO DEBEN interactuar con las apps instaladas a través de intents implícitos, a menos que se cumpla una de las siguientes condiciones:
- El filtro de patrones de intents del componente está expuesto y tiene CATEGORY_BROWSABLE.
- La acción es una de las siguientes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
- El objetivo se expone de forma explícita con android:visibleToInstantApps.
- [C-1-3] Las apps instantáneas NO DEBEN interactuar de forma explícita con las apps instaladas, a menos que el componente esté expuesto a través de android:visibleToInstantApps.
- [C-1-4] Las apps instaladas NO DEBEN ver detalles sobre las apps instantáneas en el dispositivo, a menos que la app instantánea se conecte de forma explícita a la aplicación instalada.
Las implementaciones de dispositivos DEBEN proporcionar los siguientes indicadores visuales para el usuario para interactuar con las apps instantáneas. El AOSP cumple con los requisitos con la IU del sistema, la configuración y el selector predeterminados. Implementaciones de dispositivos:
- [C-1-5] DEBE proporcionar una indicación visual para el usuario para ver y borrar las apps instantáneas almacenadas en caché de forma local para cada paquete de app individual.
- [C-1-6] DEBE proporcionar una notificación persistente para el usuario que se pueda contraer mientras se ejecuta una app instantánea en primer plano. Esta notificación del usuario DEBE incluir que las apps instantáneas no requieren instalación y proporcionar una indicación visual que dirija al usuario a la pantalla de información de la aplicación en Configuración. En el caso de las apps instantáneas que se inician a través de intents web, como se define con un intent con la acción establecida en
Intent.ACTION_VIEW
y con un esquema de "http" o "https", una indicación visual adicional del usuario DEBE permitir que el usuario no inicie la app instantánea y, en su lugar, inicie el vínculo asociado con el navegador web configurado, si hay un navegador disponible en el dispositivo. - [C-1-7] DEBE permitir que se acceda a las apps instantáneas en ejecución desde la función Recientes si esta función está disponible en el dispositivo.
[C-1-8] DEBES precargar una o más aplicaciones o componentes de servicio con un controlador de intents para los intents que se enumeran en el SDK aquí y hacer que los intents sean visibles para las apps instantáneas.
3.16. Sincronización de dispositivos complementarios
Android incluye compatibilidad con la vinculación de dispositivos complementarios para administrar de manera más eficaz la asociación con dispositivos complementarios y proporciona la API de CompanionDeviceManager
para que las apps accedan a esta función.
Si las implementaciones de dispositivos admiten la función de vinculación de dispositivos complementarios, hacen lo siguiente:
- [C-1-1] DEBE declarar la marca de función
FEATURE_COMPANION_DEVICE_SETUP
. - [C-1-2] DEBES asegurarte de que las APIs del paquete
android.companion
estén implementadas por completo. - [C-1-3] DEBEN proporcionar indicaciones visuales para que el usuario seleccione o confirme que un dispositivo complementario está presente y en funcionamiento.
3.17. Apps pesadas
Si las implementaciones de dispositivos declaran la función FEATURE_CANT_SAVE_STATE
, hacen lo siguiente:
- [C-1-1] DEBE tener solo una app instalada que especifique
cantSaveState
ejecutándose en el sistema a la vez. Si el usuario abandona una app de este tipo sin salir de ella de forma explícita (por ejemplo, presionando el botón de inicio mientras sale de una actividad activa del sistema, en lugar de presionar atrás sin que queden actividades activas en el sistema), las implementaciones de dispositivos DEBEN priorizar esa app en la RAM, como lo hacen con otros elementos que se espera que permanezcan en ejecución, como los servicios en primer plano. Mientras una app de este tipo está en segundo plano, el sistema 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 indicación visual de la IU para elegir la app que no participará en el mecanismo normal de guardado y restablecimiento del estado una vez que el usuario inicie una segunda app declarada con el atributo
cantSaveState
. - [C-1-3] NO DEBE aplicarse ningún otro cambio en la política a las apps que especifiquen
cantSaveState
, como cambiar el rendimiento de la CPU o la priorización de programación.
Si las implementaciones de dispositivos no declaran la función FEATURE_CANT_SAVE_STATE
, sucede lo siguiente:
- [C-1-1] DEBE ignorar el atributo
cantSaveState
que establecen las apps y NO DEBE cambiar el comportamiento de la app según ese atributo.
3.18. Contactos
Android incluye APIs de 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 suelen sincronizarse con un servicio web, pero es posible que los datos también residan de forma local en el dispositivo.
Los contactos que solo se almacenan en el dispositivo se denominan contactos locales.
RawContacts se "asocian con" o se "almacenan 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: Es 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: Es 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 NO crear cuentas locales personalizadas.
Si las implementaciones de dispositivos usan una cuenta local personalizada, haz lo siguiente:
- [C-1-1]
ContactsContract.RawContacts.getLocalAccountName
DEBE mostrar elACCOUNT_NAME
de la cuenta local personalizada. - [C-1-2]
ContactsContract.RawContacts.getLocalAccountType
DEBE mostrar elACCOUNT_TYPE
de la cuenta local personalizada. - [C-1-3] Los contactos sin procesar que insertan aplicaciones de terceros con la cuenta local predeterminada (es decir, configurando valores nulos para
ACCOUNT_NAME
yACCOUNT_TYPE
) DEBEN insertarse en la cuenta local personalizada. - [C-1-4] Los contactos sin procesar que se insertan en la cuenta local personalizada NO deben quitarse cuando se agregan o quitan cuentas.
- [C-1-5] Las operaciones de eliminación realizadas en la cuenta local personalizada deben hacer que los contactos sin procesar se borren de inmediato (como si el parámetro
CALLER_IS_SYNCADAPTER
se estableciera como verdadero), incluso si el parámetroCALLER\_IS\_SYNCADAPTER
se estableció como falso o no se especificó.
4. Compatibilidad de empaquetado de aplicaciones
Implementaciones de dispositivos:
[C-0-1] DEBE ser capaz de instalar y ejecutar archivos ".apk" de Android como los genera 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 usen el sistema de administración de paquetes de la implementación de referencia de AOSP.
[C-0-2] DEBE admitir la verificación de archivos ".apk" con el esquema de firma de APK v3.1, el esquema de firma de APK v3, el esquema de firma de APK v2 y la firma de JAR.
[C-0-3] NO DEBE extender los formatos de código de bytes .apk, manifiesto de Android, Dalvik ni RenderScript de manera tal que se impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.
[C-0-4] NO DEBE permitir que apps que no sean el "instalador de registro" actual del paquete desinstalen la app de forma silenciosa sin ninguna confirmación del usuario, como se documenta en el SDK para el permiso
DELETE_PACKAGE
. Las únicas excepciones son la app del verificador de paquetes del sistema que controla el intent PACKAGE_NEEDS_VERIFICATION y la app del administrador de almacenamiento que controla el intent ACTION_MANAGE_STORAGE.[C-0-5] DEBE tener una actividad que controle el intent
android.settings.MANAGE_UNKNOWN_APP_SOURCES
.[C-0-6] NO DEBE instalar paquetes de aplicaciones desde fuentes desconocidas, a menos que la app que solicita la instalación cumpla con todos los siguientes requisitos:
- DEBE declarar el permiso
REQUEST_INSTALL_PACKAGES
o tener elandroid:targetSdkVersion
establecido en 24 o menos. - El usuario DEBE haber otorgado permiso para instalar apps desde fuentes desconocidas.
- DEBE declarar el permiso
DEBE proporcionar una indicación visual para el usuario para otorgar o revocar el permiso para instalar apps de fuentes desconocidas por aplicación, pero PUEDE optar por implementarlo como una operación sin efecto y mostrar
RESULT_CANCELED
parastartActivityForResult()
si la implementación del dispositivo no quiere permitir que los usuarios tengan esta opción. Sin embargo, incluso en esos casos, DEBEN indicarle al usuario por qué no se presenta esa opción.[C-0-7] DEBE mostrar un diálogo de advertencia con la cadena de advertencia que se proporciona al usuario a través de la API del sistema
PackageManager.setHarmfulAppWarning
antes de iniciar una actividad en una aplicación que la misma API del sistemaPackageManager.setHarmfulAppWarning
haya marcado como potencialmente dañina.DEBE proporcionar una indicación visual para que el usuario elija desinstalar o iniciar una aplicación en el diálogo de advertencia.
[C-0-8] DEBE implementar la compatibilidad con el sistema de archivos incremental como se documenta aquí.
[C-0-9] DEBE admitir la verificación de archivos .apk con el Esquema de firma de APK v4 y el Esquema de firma de APK v4.1.
5. Compatibilidad multimedia
Implementaciones de dispositivos:
- [C-0-1] DEBE admitir los formatos multimedia, los codificadores, los decodificadores, los tipos de archivos y los formatos de contenedor definidos en la sección 5.1 para cada códec declarado por
MediaCodecList
. - [C-0-2] DEBE declarar y notificar la compatibilidad con 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 las apps 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 apuntar a la latencia mínima del códec, en otras palabras, deben cumplir con los siguientes requisitos:
- NO DEBE consumir ni almacenar búferes de entrada ni mostrarlos solo una vez que se procesen.
- NO DEBE retener los búferes decodificados por más tiempo de lo especificado en el estándar (p.ej., SPS).
- NO DEBE retener los búferes codificados más tiempo del necesario según la estructura de GOP.
Todos los códecs que se enumeran en la siguiente sección se proporcionan como implementaciones de software en la implementación preferida de Android del Proyecto de código abierto de Android.
Ten en cuenta que ni Google ni la Open Handset Alliance hacen ninguna representación de que estos códecs no tengan patentes de terceros. Se recomienda a quienes tengan la intención de usar este código fuente en productos de hardware o software que las implementaciones de este código, incluido en software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes relevantes.
5.1. Códecs multimedia
5.1.1. Codificación de audio
Consulta más detalles en 5.1.3. Audio Codecs Details.
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 las apps de terceros:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Todos los codificadores de audio DEBEN admitir lo siguiente:
- [C-3-1] Marcos de audio de orden de bytes nativo de PCM de 16 bits a través de la API de
android.media.MediaCodec
5.1.2. Decodificación de audio
Consulta más detalles en 5.1.3. Audio Codecs Details.
Si las implementaciones de dispositivos declaran compatibilidad con la función android.hardware.audio.output
, deben admitir la decodificación de los siguientes formatos de audio:
- [C-1-1] Perfil AAC de MPEG-4 (AAC LC)
- [C-1-2] Perfil HE AAC de MPEG-4 (AAC+)
- [C-1-3] Perfil HE AACv2 de MPEG-4 (AAC+ mejorado)
- [C-1-4] AAC ELD (AAC mejorado de bajo retraso)
- [C-1-11] xHE-AAC (perfil HE AAC extendido ISO/IEC 23003-3, que incluye el perfil de Baseline de 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, incluidos formatos de audio de alta resolución de hasta 24 bits, una tasa de muestreo de 192 kHz y 8 canales Ten en cuenta que este requisito es solo para la decodificación y que un dispositivo puede reducir la muestra y la combinación durante la fase de reproducción.
- [C-1-10] Opus
Si las implementaciones de dispositivos admiten la decodificación de búferes 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 de android.media.MediaCodec
, SE DEBE admitir lo siguiente:
- [C-2-1] La decodificación DEBE realizarse sin una reducción de canales (p.ej., una transmisión AAC 5.0 se debe decodificar a cinco canales de PCM, una transmisión AAC 5.1 se debe decodificar a seis canales de PCM).
- [C-2-2] Los metadatos del rango dinámico DEBEN ser como se define en "Control de rango dinámico (DRC)" en la norma ISO/IEC 14496-3 y las claves de DRC
android.media.MediaFormat
para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves de DRC de AAC se introdujeron en la API 21 y son las siguientes:KEY_AAC_DRC_ATTENUATION_FACTOR
,KEY_AAC_DRC_BOOST_FACTOR
,KEY_AAC_DRC_HEAVY_COMPRESSION
,KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
yKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] SE RECOMIENDA ENFÉCTIVAMENTE que todos los decodificadores de audio AAC satisfagan los requisitos C-2-1 y C-2-2 anteriores.
Cuando se decodifica audio USAC, MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Los metadatos de volumen y DRC DEBEN interpretarse y aplicarse según el nivel 1 del perfil de control de rango dinámico MPEG-D DRC.
- [C-3-2] El decodificador DEBE comportarse según la configuración establecida con las siguientes claves
android.media.MediaFormat
:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
yKEY_AAC_DRC_EFFECT_TYPE
.
Decodificadores de perfiles MPEG-4 AAC, HE AAC y HE AACv2:
- PUEDE admitir el control de volumen y rango dinámico con el perfil de control de rango dinámico ISO/IEC 23003-4.
Si se admite ISO/IEC 23003-4 y si los metadatos ISO/IEC 23003-4 y ISO/IEC 14496-3 están presentes en un flujo de bits decodificado, haz lo siguiente:
- Los metadatos de ISO/IEC 23003-4 TIENEN que tener prioridad.
Todos los decodificadores de audio DEBEN admitir la salida de los siguientes formatos:
- [C-6-1] Marcos de audio de orden de bytes nativo de PCM de 16 bits a través de la API de
android.media.MediaCodec
Si las implementaciones de dispositivos admiten la decodificación de búferes 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 de android.media.MediaCodec
, entonces SE DEBE admitir lo siguiente:
- [C-7-1] LA aplicación DEBE poder configurarse con la decodificación con la clave
KEY_MAX_OUTPUT_CHANNEL_COUNT
para controlar si el contenido se baja a estéreo (cuando se usa un valor de 2) o se envía con la cantidad nativa de canales (cuando se usa un valor igual o superior a esa cantidad). Por ejemplo, un valor de 6 o superior configuraría un decodificador para que genere 6 canales cuando se le proporcione contenido 5.1. - [C-7-2] Durante la decodificación, el decodificador DEBE anunciar la máscara de canal que se usa en el formato de salida con la clave
KEY_CHANNEL_MASK
, con las constantesandroid.media.AudioFormat
(por ejemplo,CHANNEL_OUT_5POINT1
).
Si las implementaciones de dispositivos admiten decodificadores de audio distintos del decodificador de audio AAC predeterminado y son capaces de generar audio multicanal (es decir, más de 2 canales) cuando se les proporciona contenido multicanal comprimido, haz lo siguiente:
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que la aplicación pueda configurar el decodificador mediante la decodificación con la clave
KEY_MAX_OUTPUT_CHANNEL_COUNT
para controlar si el contenido se baja a estéreo (cuando se usa un valor de 2) o se envía con la cantidad nativa de canales (cuando se usa un valor igual o superior a esa cantidad). Por ejemplo, un valor de 6 o superior configuraría un decodificador para que genere 6 canales cuando se le proporcione contenido 5.1. - [C-SR-3] Cuando se decodifica, se RECOMIENDA ENFATICAMENTE que el decodificador anuncie la máscara de canales que se usa en el formato de salida con la clave
KEY_CHANNEL_MASK
, con las constantes android.media.AudioFormat (por ejemplo,CHANNEL_OUT_5POINT1
).
5.1.3. Detalles de los códecs de audio
Formato/códec | Detalles | Tipos de archivos o formatos de contenedor compatibles |
---|---|---|
Perfil AAC de MPEG-4 (AAC LC) |
Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 8 a 48 kHz. |
|
Perfil HE AAC de MPEG-4 (AAC+) | Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz. |
|
Perfil HE AACv2 de MPEG-4 (AAC+ mejorado) |
Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz. |
|
AAC ELD (AAC mejorado de bajo retraso) | Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 a 48 kHz |
|
USAC | Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 7.35 a 48 kHz | MPEG-4 (.mp4, .m4a) |
AMR-NB | De 4.75 a 12.2 Kbps con muestreo a 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz, como se define en AMR-WB, códec de voz de banda ancha de varias tasas adaptables | 3GPP (.3gp) |
FLAC | Para el codificador y el decodificador, SE DEBEN admitir al menos los modos mono y estéreo. SE DEBEN admitir tasas de muestreo de hasta 192 kHz y resoluciones de 16 y 24 bits. El manejo de datos de audio de 24 bits de FLAC DEBE estar disponible con la configuración de audio de punto flotante. |
|
MP3 | Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps |
|
MIDI | MIDI tipo 0 y 1. Versión 1 y 2 de DLS. XMF y Mobile XMF. Compatibilidad con los formatos de tono RTTTL/RTX, OTA y iMelody |
|
Vorbis | Decodificación: Compatibilidad con contenido mono, estéreo, 5.0 y 5.1 con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. Codificación: Compatibilidad con contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. |
|
PCM/WAVE | El códec PCM DEBE admitir PCM lineal de 16 bits y punto flotante de 16 bits. El extractor de WAVE debe admitir PCM lineal de 16, 24 y 32 bits, y punto flotante de 32 bits (las tasas dependen del límite del hardware). Las tasas de muestreo DEBEN ser compatibles de 8 kHz a 192 kHz. | WAVE (.wav) |
Opus | Decodificación: Compatibilidad con contenido mono, estéreo, 5.0 y 5.1 con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz.
Codificación: Compatibilidad con contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. |
|
5.1.4. Codificación de imágenes
Consulta más detalles en 5.1.6. Detalles de los códecs de imagen.
Las implementaciones de dispositivos DEBEN admitir la codificación de las siguientes imágenes:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
Cómo iniciar nuevos requisitos
- [C-0-4] AVIF
- Los dispositivos deben admitir
BITRATE_MODE_CQ
y el perfil de Baseline.
- Los dispositivos deben admitir
Fin de los nuevos requisitos
Si las implementaciones de dispositivos admiten la codificación HEIC a través de android.media.MediaCodec
para el tipo de contenido multimedia MIMETYPE_IMAGE_ANDROID_HEIC
, hacen lo siguiente:
- [C-1-1] DEBE proporcionar un códec de codificador HEVC con aceleración de hardware que admita el modo de control de tasa de bits
BITRATE_MODE_CQ
, el perfilHEVCProfileMainStill
y el tamaño de fotogramas de 512 x 512 px.
5.1.5. Decodificación de imágenes
Consulta más detalles en 5.1.6. Detalles de los códecs de imagen.
Las implementaciones de dispositivos DEBEN admitir la decodificación de la siguiente codificación de imagen:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Sin procesar
- [C-0-7] AVIF (perfil de Baseline)
Si las implementaciones de dispositivos admiten la decodificación de video HEVC, deben cumplir con los siguientes requisitos: * [C-1-1] DEBEN admitir la decodificación de imágenes HEIF (HEIC).
Decodificadores de imágenes que admiten un formato de profundidad de bits alta (más de 9 bits por canal):
- [C-2-1] DEBE admitir la salida de un formato equivalente de 8 bits si la aplicación lo solicita, por ejemplo, a través de la configuración de
ARGB_8888
deandroid.graphics.Bitmap
.
5.1.6. Detalles de los códecs de imagen
Formato/códec | Detalles | Formatos de contenedores y tipos de archivos compatibles |
---|---|---|
JPEG | Básica + progresiva | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
Sin procesar | ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) | |
HEIF | Imagen, colección de imágenes, secuencia de imágenes | HEIF (.heif), HEIC (.heic) |
AVIF (perfil de Baseline) | Perfil de Baseline de imágenes, colecciones de imágenes y secuencias de imágenes | Contenedor HEIF (.avif) |
Codificadores y decodificadores de imágenes expuestos a través de la API de MediaCodec
[C-1-1] DEBE admitir el formato de color flexible YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) a través deCodecCapabilities
.[C-SR-1] SE RECOMIENDA URGENTEMENTE admitir el formato de color RGB888 para el modo de entrada de Surface.
[C-1-3] DEBE admitir al menos uno de los siguientes formatos de color YUV420 8:8:8 planar o semiplanar:
COLOR_FormatYUV420PackedPlanar
(equivalente aCOLOR_FormatYUV420Planar
) oCOLOR_FormatYUV420PackedSemiPlanar
(equivalente aCOLOR_FormatYUV420SemiPlanar
). SE RECOMIENDA URGENTEMENTE que admita ambos.
5.1.7. Códecs de video
- Para obtener una calidad aceptable de los servicios de transmisión de video por Internet y de videoconferencia, las implementaciones de dispositivos DEBEN usar un códec VP8 de hardware que cumpla con los requisitos.
Si las implementaciones de dispositivos incluyen un decodificador o codificador de video, haz lo siguiente:
[C-1-1] Los códecs de video DEBEN admitir tamaños de búfer de bytes de entrada y salida que admitan la trama comprimida y descomprimida más grande posible, según lo indiquen el estándar y la configuración, pero que tampoco asignen más recursos de los necesarios.
[C-1-2] Los codificadores y decodificadores de video DEBEN admitir formatos de color flexibles YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) a través deCodecCapabilities
.[C-1-3] Los codificadores y decodificadores de video DEBEN admitir al menos uno de los siguientes formatos de color YUV420 8:8:8 planar o semiplanar:
COLOR_FormatYUV420PackedPlanar
(equivalente aCOLOR_FormatYUV420Planar
) oCOLOR_FormatYUV420PackedSemiPlanar
(equivalente aCOLOR_FormatYUV420SemiPlanar
). SE RECOMIENDA URGENTEMENTE que admitan ambos.[C-SR-1] SE RECOMIENDA ENFATICAMENTE que los codificadores y decodificadores de video admitan al menos uno de los siguientes formatos de color YUV420 8:8:8 planar o semiplanar optimizados por hardware (YV12, NV12, NV21 o un formato equivalente optimizado por el proveedor).
[C-1-5] Los decodificadores de video que admiten un formato de profundidad de bits alta (más de 9 bits por canal) DEBEN admitir la salida de un formato equivalente de 8 bits si la aplicación lo solicita. Esto DEBE reflejarse admitiendo un formato de color YUV420 8:8:8 a través de
android.media.MediaCodecInfo
.
Si las implementaciones de dispositivos anuncian la compatibilidad con el perfil HDR a través de Display.HdrCapabilities
, hacen lo siguiente:
- [C-2-1] DEBE admitir el análisis y el manejo de metadatos estáticos HDR.
Si las implementaciones de dispositivos anuncian la compatibilidad con la actualización interna a través de FEATURE_IntraRefresh
en la clase MediaCodecInfo.CodecCapabilities
, hacen lo siguiente:
- [C-3-1] DEBE admitir los períodos de actualización en el rango de 10 a 60 fotogramas y funcionar con precisión dentro del 20% del período de actualización configurado.
A menos que la aplicación especifique lo contrario con la clave de formato KEY_COLOR_FORMAT
, las implementaciones de decodificadores de video deben cumplir con los siguientes requisitos:
- [C-4-1] DEBE usar de forma predeterminada el formato de color optimizado para la pantalla de hardware si se configura con la salida de Surface.
- [C-4-2] DEBE usar de forma predeterminada un formato de color YUV420 8:8:8 optimizado para la lectura de la CPU si está configurado para no usar la salida de Surface.
5.1.8. Lista de códecs de video
Formato/códec | Detalles | Tipos de archivos o formatos de contenedor compatibles |
---|---|---|
H.263 |
|
|
H.264 AVC | Consulta las secciones 5.2 y 5.3 para obtener más información. |
|
H.265 HEVC | Consulta la sección 5.3 para obtener más detalles. |
|
MPEG-2 | Perfil principal |
|
MPEG-4 SP |
|
|
VP8 | Consulta las secciones 5.2 y 5.3 para obtener más información. |
|
VP9 | Consulta la sección 5.3 para obtener más detalles. |
|
AV1 | Consulta la sección 5.2 y la sección 5.3 para obtener más información. |
|
5.1.9. Seguridad de códecs 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 compatibilidad con OMX, una API de aceleración multimedia multiplataforma, así como Codec 2.0, una API de aceleración multimedia de baja sobrecarga.
Si las implementaciones de dispositivos admiten contenido multimedia, hacen lo siguiente:
- [C-1-1] DEBE admitir códecs multimedia a través de las APIs de OMX o Codec 2.0 (o ambas) como en el Proyecto de código abierto de Android y no inhabilitar ni eludir las protecciones de seguridad. Esto no significa específicamente que cada codificador DEBE usar la API de OMX o Codec 2.0, solo que la compatibilidad con al menos una de estas APIs DEBE estar disponible, y la compatibilidad con las APIs disponibles DEBE incluir las protecciones de seguridad presentes.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas compatibilidad con la API de Codec 2.0.
Si las implementaciones de dispositivos no son compatibles con la API de Codec 2.0, sucede lo siguiente:
- [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 contenido multimedia (codificador o decodificador) que admita el dispositivo.
- [C-2-2] Códecs que tienen nombres que comienzan con "OMX.google" DEBEN basarse en el código fuente del Proyecto de código abierto de Android.
- [C-SR-2] SE RECOMIENDA ENFÉCTIVAMENTE que los códecs de software OMX se ejecuten en un proceso de códec que no tenga acceso a controladores de hardware distintos de los asignadores de memoria.
Si las implementaciones de dispositivos admiten la API de Codec 2.0, hacen lo siguiente:
- [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 contenido multimedia (codificador o decodificador) que admita el dispositivo.
- [C-3-2] DEBEN alojar los códecs de software Codec 2.0 en el proceso de códec de software como se proporciona en el Proyecto de código abierto de Android para permitir otorgar acceso a los códecs de software de manera más limitada.
- [C-3-3] Codecs que tienen nombres que comienzan con "c2.android" DEBEN basarse en el código fuente del Proyecto de código abierto de Android.
5.1.10. Caracterización de códecs multimedia
Si las implementaciones de dispositivos admiten códecs multimedia, hacen lo siguiente:
- [C-1-1] DEBE mostrar valores correctos de la caracterización del códec multimedia a través de la API de
MediaCodecInfo
.
En particular:
- [C-1-2] Códecs con nombres que comienzan con "OMX" DEBEN usar las APIs de OMX y tener nombres que cumplan con los lineamientos de nombres de OMX IL.
- [C-1-3] Códecs con nombres que comienzan con “c2”. DEBEN usar la API de Codec 2.0 y tener nombres que cumplan con los lineamientos de nombres de Codec 2.0 para Android.
- [C-1-4] Códecs con nombres que comienzan con “OMX.google.” o “c2.android.” NO deben caracterizarse como proveedores ni como hardware acelerado.
- [C-1-5] Los códecs que se ejecutan en un proceso de códec (del proveedor o del sistema) que tienen acceso a controladores de hardware distintos de los asignadores y asignadores de memoria NO DEBEN caracterizarse como solo software.
- [C-1-6] Los códecs que no están presentes en el Proyecto de código abierto de Android o que no se basan en el código fuente de ese proyecto DEBEN caracterizarse como del proveedor.
- [C-1-7] Los códecs que usan 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 video, haz lo siguiente:
- [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 los admite:
SD (baja calidad) | SD (alta calidad) | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|---|
Resolución de video |
|
|
|
1,920 x 1,080 px (excepto MPEG4, AV1) | 3840 × 2160 px (HEVC, VP9, AV1) |
- [C-2-2] Los códecs de video que se caracterizan como acelerados por hardware DEBEN publicar información sobre los puntos de rendimiento. DEBEN enumerar todos los puntos de rendimiento estándar compatibles (que se indican en la API de
PerformancePoint
), a menos que estén cubiertos por otro punto de rendimiento estándar compatible. - Además, DEBEN publicar puntos de rendimiento extendidos si admiten un rendimiento de video sostenido que no sea uno de los estándares mencionados.
5.2. Codificación de video
- NO DEBE ser, en dos ventanas deslizantes, superior al 15% de la tasa de bits entre intervalos de fotogramas intratrama (fotogramas I).
- NO DEBE superar el 100% de la tasa de bits en un período deslizante de 1 segundo.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos admiten cualquier codificador de video y lo ponen a disposición de apps de terceros, y establecenMediaFormat.KEY_BITRATE_MODE
en BITRATE_MODE_VBR
para que el codificador funcione en modo de tasa de bits variable, entonces, siempre que no afecte el nivel mínimo de calidad, la tasa de bits codificada :
[C-5-1] DEBENO exceder, en un período deslizante, el 15% de la tasa de bits entre intervalos intrafotogramas (fotogramas I).[C-5-2] DEBENO DEBE exceder el 100% de la tasa de bits en un período deslizante de 1 segundo.
Si las implementaciones de dispositivos admiten cualquier codificador de video y lo ponen a disposición de apps de terceros, y establecen MediaFormat.KEY_BITRATE_MODE
en BITRATE_MODE_CBR
para que el codificador funcione en modo de tasa de bits constante, la tasa de bits codificada:
[C-6-1] DEBE[C-SR-2] SE RECOMIENDA URGENTEMENTE NO superar en un 15% la tasa de bits objetivo en un período deslizante de 1 segundo.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos incluyen una pantalla incorporada con una diagonal de al menos 6.35 cm (2.5"), un puerto de salida de video o la declaración de compatibilidad con una cámara a través de la marca de función android.hardware.camera.any
, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE incluir la compatibilidad con 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 video VP8 y H.264, y ponerlos a disposición de las 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, deben cumplir con lo siguiente:
- [C-2-1] DEBE admitir tasas de bits configurables de forma dinámica.
- DEBE admitir velocidades de fotogramas variables, en las que el codificador de video DEBE determinar la duración instantánea de los fotogramas en función de las marcas de tiempo de los búferes de entrada y asignar su bucket de bits en función de esa duración.
Si las implementaciones de dispositivos admiten el codificador de video MPEG-4 SP y lo ponen a disposición de apps de terceros, hacen lo siguiente:
- DEBE admitir tasas de bits configurables de forma dinámica para el codificador compatible.
Si las implementaciones de dispositivos proporcionan codificadores de imágenes o videos con aceleración de hardware y admiten una o más cámaras de hardware conectadas o enchufables expuestas a través de las APIs de android.camera
, haz lo siguiente:
- [C-4-1] Todos los codificadores de imágenes y videos acelerados por hardware DEBEN admitir la codificación de fotogramas de las cámaras de hardware.
- DEBE admitir la codificación de fotogramas de las cámaras de hardware a través de todos los codificadores de video o imagen.
Si las implementaciones de dispositivos proporcionan codificación HDR, hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que proporcionen un complemento para la API de transcodificación sin interrupciones para convertir de formato HDR a formato SDR.
5.2.1. H.263
Si las implementaciones de dispositivos admiten codificadores H.263 y los ponen a disposición de apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE admitir la resolución QCIF (176 x 144) con el nivel de perfil de Baseline 45. La resolución SQCIF es opcional.
DEBEN admitir tasas de bits configurables de forma dinámica para el codificador compatible.
5.2.2. H.264
Si las implementaciones de dispositivos admiten el códec H.264, hacen lo siguiente:
- [C-1-1] DEBE admitir el nivel 3 del perfil de Baseline. Sin embargo, la compatibilidad con ASO (ordenación arbitraria de segmentos), FMO (ordenación flexible de macrobloques) y RS (segmentos redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no usen ASO, FMO ni RS para el perfil de Baseline.
- [C-1-2] DEBE admitir los perfiles de codificación de video de definición estándar (SD) que se indican en la siguiente tabla.
- DEBE admitir el perfil principal nivel 4.
- DEBE admitir los perfiles de codificación de video HD (alta definición) como se indica en la siguiente tabla.
Si las implementaciones de dispositivos informan la compatibilidad con la codificación H.264 para videos de resolución 720p o 1080p a través de las APIs de contenido multimedia, hacen lo siguiente:
- [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.
SD (baja calidad) | SD (alta calidad) | HD: 720p | HD: 1080 p | |
---|---|---|---|---|
Resolución de video | 320 × 240 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px |
Velocidad de fotogramas del video | 20 fps | 30 fps | 30 fps | 30 fps |
Tasa de bits del video | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3. VP8
Si las implementaciones de dispositivos admiten el códec VP8, hacen lo siguiente:
- [C-1-1] DEBEN 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 VP8 de hardware que cumpla con los requisitos de codificación de hardware de RTC del proyecto WebM para garantizar una calidad aceptable de los servicios de transmisión de video web y videoconferencias.
Si las implementaciones de dispositivos informan la compatibilidad con la codificación VP8 para videos de resolución 720p o 1080p a través de las APIs de contenido multimedia, hacen lo siguiente:
- [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.
SD (baja calidad) | SD (alta calidad) | HD: 720p | HD: 1080 p | |
---|---|---|---|---|
Resolución de video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30 fps |
Tasa de bits del video | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4. VP9
Si las implementaciones de dispositivos admiten el códec VP9, hacen lo siguiente:
- [C-1-2] DEBE admitir el perfil 0 de nivel 3.
- [C-1-1] DEBE admitir la escritura de archivos Matroska WebM.
- [C-1-3] DEBE generar datos CodecPrivate.
- DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que admitan los perfiles de decodificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
SD | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|
Resolución de video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 × 2160 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30 fps |
Tasa de bits del video | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Si las implementaciones de dispositivos afirman admitir el perfil 2 o el perfil 3 a través de las APIs de Media, haz lo siguiente:
- La compatibilidad con el formato de 12 bits es OPCIONAL.
5.2.5. H.265
Si las implementaciones de dispositivos admiten el códec H.265, hacen lo siguiente:
- [C-1-1] DEBE admitir el perfil principal nivel 3 hasta una resolución de 512 x 512.
DEBEN admitir los perfiles de codificación HD como se indica en la siguiente tabla.- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que admitan el perfil SD de 720 × 480 y los perfiles de codificación HD como se indica en la siguiente tabla si hay un codificador de hardware.
SD | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|
Resolución de video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 × 2160 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30 fps |
Tasa de bits del video | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Cómo iniciar nuevos requisitos
5.2.6. AV1
Si las implementaciones de dispositivos admiten el códec AV1, hacen lo siguiente:
- [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.
[C-1-2] DEBEN publicar datos de rendimiento, es decir, informar datos de rendimiento a través de las APIs de
getSupportedFrameRatesFor()
ogetSupportedPerformancePoints()
para las resoluciones admitidas en la siguiente tabla.[C-1-3] DEBE aceptar metadatos HDR y enviarlos al flujo de bits.
Si el codificador AV1 está acelerado por hardware, hace lo siguiente:
- [C-2-1] DEBE admitir hasta el perfil de codificación HD1080p de la siguiente tabla:
SD | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|
Resolución de video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 × 2160 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30 fps |
Tasa de bits del video | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
Fin de los nuevos requisitos
5.3. Decodificación de video
Si las implementaciones de dispositivos admiten los códecs VP8, VP9, H.264 o H.265, hacen lo siguiente:
- [C-1-1] DEBE admitir resolución de video dinámica y cambio de velocidad de fotogramas a través de las APIs 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, tienen las siguientes características:
- [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, hacen lo siguiente:
- [C-1-1] DEBE admitir el nivel de perfil de Baseline 30 (resoluciones CIF, QCIF y SQCIF a 30 fps y 384 Kbps) y el nivel 45 (resoluciones QCIF y SQCIF a 30 fps y 128 Kbps).
5.3.3. MPEG-4
Si las implementaciones de dispositivos tienen decodificadores MPEG-4, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE admitir el nivel 3 del perfil simple.
5.3.4. H.264
Si las implementaciones de dispositivos admiten decodificadores H.264, hacen lo siguiente:
- [C-1-1] DEBE admitir el perfil principal nivel 3.1 y el perfil de Baseline. La compatibilidad con ASO (ordenación de segmentos arbitraria), FMO (ordenación de macrobloques flexibles) y RS (slices redundantes) es OPCIONAL.
- [C-1-2] DEBE ser capaz de decodificar videos con los perfiles de SD (definición estándar) que se indican en la siguiente tabla y codificados con el perfil básico y el perfil principal de nivel 3.1 (incluidos 720p30).
- DEBE ser capaz de decodificar videos con los perfiles HD (alta definición) como se indica en la siguiente tabla.
Si la altura que informa el método Display.getSupportedModes()
es igual o mayor que la resolución del video, las implementaciones de dispositivos hacen lo siguiente:
- [C-2-1] DEBE admitir los perfiles de decodificación de video HD 720p que se indican en la siguiente tabla.
- [C-2-2] DEBE admitir los perfiles de decodificación de video HD 1080p que se indican en la siguiente tabla.
SD (baja calidad) | SD (alta calidad) | HD: 720p | HD: 1080 p | |
---|---|---|---|---|
Resolución de video | 320 × 240 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 60 fps | 30 fps (60 fps en televisión) |
Tasa de bits del video | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5. H.265 (HEVC)
Si las implementaciones de dispositivos admiten el códec H.265, hacen lo siguiente:
- [C-1-1] DEBE admitir el nivel principal del perfil principal de 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 que informa el método Display.getSupportedModes()
es igual o mayor que la resolución de video, haz lo siguiente:
- [C-2-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones H.265 o VP9 de perfiles 720, 1080 y UHD.
SD (baja calidad) | SD (alta calidad) | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|---|
Resolución de video | 352 x 288 px | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 × 2160 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30/60 FPS (60 FPS en televisores con decodificación de hardware H.265) | 60 fps |
Tasa de bits del video | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Si las implementaciones de dispositivos afirman admitir un perfil HDR a través de las APIs de Media, haz lo siguiente:
- [C-3-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos HDR requeridos de la aplicación, así como admitir la extracción y salida de los metadatos HDR requeridos del flujo de bits 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 (p.ej., HDMI).
5.3.6. VP8
Si las implementaciones de dispositivos admiten el códec VP8, hacen lo siguiente:
- [C-1-1] DEBE admitir los perfiles de decodificación de SD que se indican en la siguiente tabla.
- DEBE usar un códec VP8 de hardware que cumpla con los requisitos.
- DEBE admitir los perfiles de decodificación HD que se muestran en la siguiente tabla.
Si la altura que informa el método Display.getSupportedModes()
es igual o mayor que la resolución del video, haz lo siguiente:
- [C-2-1] Las implementaciones de dispositivos DEBEN admitir los perfiles de 720p que se indican en la siguiente tabla.
- [C-2-2] Las implementaciones de dispositivos DEBEN admitir los perfiles de 1080p que se indican en la siguiente tabla.
SD (baja calidad) | SD (alta calidad) | HD: 720p | HD: 1080 p | |
---|---|---|---|---|
Resolución de video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps (60 fps en televisión) | 30 (60 fps en televisión) |
Tasa de bits del video | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7. VP9
Si las implementaciones de dispositivos admiten el códec VP9, hacen lo siguiente:
- [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, haz lo siguiente:
- [C-2-1] DEBE admitir los perfiles de decodificación HD 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 de video, haz lo siguiente:
- [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) | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|---|
Resolución de video | 320 x 180 px | 640 x 360 px | 1280 x 720 px | 1920 x 1080 px | 3840 × 2160 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30 fps (60 fps en televisores con decodificación por hardware de VP9) | 60 fps |
Tasa de bits del video | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
Si las implementaciones de dispositivos afirman admitir VP9Profile2
o VP9Profile3
a través de las APIs de contenido multimedia 'CodecProfileLevel', haz lo siguiente:
- La compatibilidad con el 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 APIs de contenido multimedia, haz lo siguiente:
- [C-4-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos de 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 necesarios del flujo de bits 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 (p.ej., HDMI).
5.3.8. Dolby Vision
Si las implementaciones de dispositivos declaran compatibilidad con el decodificador Dolby Vision a través de HDR_TYPE_DOLBY_VISION
, hacen lo siguiente:
- [C-1-1] DEBE proporcionar un extractor compatible con Dolby Vision.
- [C-1-2] DEBE mostrar correctamente el contenido de Dolby Vision en la pantalla del dispositivo o en un puerto de salida de video estándar (p.ej., HDMI).
- [C-1-3] DEBE establecer el ID de pista de las capas básicas retrocompatibles (si las hay) de modo que sea igual al ID de pista de la capa combinada de Dolby Vision.
5.3.9. AV1
- [C-1-1] DEBE admitir el perfil 0, incluido el contenido de 10 bits.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos admiten el códec AV1 y lo ponen a disposición de aplicaciones de terceros, hacen lo siguiente:- [C-1-1] DEBE admitir el perfil principal, incluido el contenido de 8 y 10 bits.
Si las implementaciones de dispositivos admiten el códec AV1 con un decodificador con aceleración de hardware, hacen lo siguiente:
- [C-2-1] DEBE poder decodificar al menos los perfiles de decodificación de video HD 720p de la siguiente tabla cuando la altura que informa el método
Display.getSupportedModes()
sea igual o superior a 720p. - [C-2-2] DEBE poder decodificar al menos los perfiles de decodificación de video HD 1080p de la siguiente tabla cuando la altura que informa el método
Display.getSupportedModes()
sea igual o superior a 1080p.
SD | HD: 720p | HD: 1080 p | UHD | |
---|---|---|---|---|
Resolución de video | 720 x 480 px | 1280 x 720 px | 1920 x 1080 px | 3840 × 2160 px |
Velocidad de fotogramas del video | 30 fps | 30 fps | 30 fps | 30 fps |
Tasa de bits del video | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
Si las implementaciones de dispositivos admiten el perfil HDR a través de las APIs de Media, hacen lo siguiente:
- [C-3-1] DEBE admitir la extracción y salida de metadatos HDR del flujo de bits o contenedor.
- [C-3-2] DEBE mostrar correctamente el contenido HDR en la pantalla del dispositivo o en un puerto de salida de video estándar (por ejemplo, HDMI).
Fin de los nuevos requisitos
5.4. Grabación de audio
Si bien algunos de los requisitos que se describen en esta sección se indican como RECOMENDADOS desde Android 4.3, se planea que la definición de compatibilidad de las versiones futuras los cambie a OBLIGATORIOS. Se RECOMIENDAN que los dispositivos Android existentes y nuevos cumplan con estos requisitos que se indican como DEBER, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.
5.4.1. Captura de audio sin procesar y datos del micrófono
Si las implementaciones de dispositivos declaran android.hardware.microphone
, hacen lo siguiente:
[C-1-1] DEBE permitir la captura de contenido de audio sin procesar para cualquier flujo de entrada
AudioRecord
oAAudio
que se abra correctamente. Como mínimo, SE DEBEN admitir las siguientes características:- Formato: PCM lineal, 16 bits
- Tasas de muestreo: 8,000, 11,025, 16,000, 44,100 y 48,000 Hz
- Canales: Mono
- Fuentes de audio:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
oVOICE_PERFORMANCE
. Esto también se aplica a los parámetros de configuración de entrada equivalentes enAAudio
, por ejemplo,AAUDIO_INPUT_PRESET_CAMCORDER
.
DEBE permitir la captura de contenido de audio sin procesar con las siguientes características:
- Formato: PCM lineal, de 16 y 24 bits
- Tasas de muestreo: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 y 48,000 Hz
- Canales: La cantidad de canales es igual a la cantidad de micrófonos del dispositivo.
[C-1-2] DEBE capturar a tasas de muestreo superiores sin aumento de la muestra.
[C-1-3] DEBE incluir un filtro antialiasing adecuado cuando las tasas de muestreo anteriores se capturan con reducción de muestras.
DEBE permitir la captura de contenido de audio sin procesar con calidad de radio AM y DVD, lo que significa que debe tener las siguientes características:
- Formato: PCM lineal, 16 bits
- Tasas de muestreo: 22,050 y 48,000 Hz
- Canales: Estéreo
[C-1-4] DEBEN respetar la API de
MicrophoneInfo
y completar correctamente la información de los micrófonos disponibles en el dispositivo a los que las aplicaciones de terceros pueden acceder a través de la API deAudioManager.getMicrophones()
para AudioRecord activo conMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
oVOICE_PERFORMANCE
. Si las implementaciones de dispositivos permiten la captura de contenido de audio sin procesar con calidad de radio AM y DVD, tienen las siguientes características:[C-2-1] DEBE capturar sin aumento de la muestra en cualquier relación superior a 16,000:22,050 o 44,100:48,000.
[C-2-2] DEBE incluir un filtro de antialiasing adecuado para cualquier aumento o disminución de la muestra.
5.4.2. Captura para el reconocimiento de voz
Si las implementaciones de dispositivos declaran android.hardware.microphone
, hacen lo siguiente:
- [C-1-1] DEBE capturar la fuente de audio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
a una de las tasas de muestreo, 44,100 y 48,000. - [C-1-2] DEBE inhabilitar, de forma predeterminada, cualquier procesamiento de audio de reducción de ruido cuando se graba una transmisión de audio desde la fuente de audio
AudioSource.VOICE_RECOGNITION
. [C-1-3] DEBE inhabilitar, de forma predeterminada, cualquier control automático de ganancia cuando se graba un flujo de audio desde la fuente de audio
AudioSource.VOICE_RECOGNITION
.DEBEN mostrar características de amplitud en relación con la frecuencia aproximadamente planas en el rango de frecuencia media: específicamente, ±3 dB de 100 Hz a 4,000 Hz para cada micrófono que se use para grabar la fuente de audio de reconocimiento de voz.
[C-SR-1] SE RECOMIENDA ENFATICAMENTE que muestren niveles de amplitud en el rango de frecuencia baja: específicamente de ±20 dB de 30 Hz a 100 Hz en comparación con el rango de frecuencia media de cada micrófono que se usa para grabar la fuente de audio de reconocimiento de voz.
[C-SR-2] SE RECOMIENDA ENFATICAMENTE que muestren niveles de amplitud en el rango de frecuencia alta: específicamente de ±30 dB de 4000 Hz a 22 KHz en comparación con el rango de frecuencia media de cada micrófono que se usa 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 que se reproduce a un nivel de presión sonora (SPL) de 90 dB (medido a una distancia de 30 cm de junto al micrófono) genere una respuesta ideal de RMS 2500 dentro de un rango de 1770 y 3530 para muestras de 16 bits (o -22.35 dB ±3 dB de escala completa para muestras de punto flotante o precisión doble) para cada micrófono que se use para grabar la fuente de audio de reconocimiento de voz.
DEBE grabar la transmisión de audio de reconocimiento de voz para que los niveles de amplitud de PCM sigan de forma lineal los cambios de SPL de entrada en un rango de al menos 30 dB, de -18 dB a +12 dB en relación con 90 dB SPL en el micrófono.
DEBE grabar la transmisión de audio de reconocimiento de voz con una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.
Si las implementaciones de dispositivos declaran android.hardware.microphone
y tecnologías de supresión (reducción) de ruido ajustadas para el reconocimiento de voz, hacen lo siguiente:
- [C-2-1] DEBE permitir que este efecto de audio se pueda controlar con la API de
android.media.audiofx.NoiseSuppressor
. - [C-2-2] DEBE identificar de forma inequívoca cada implementación de tecnología de supresión de ruido a través del campo
AudioEffect.Descriptor.uuid
.
5.4.3. Captura para redireccionar la reproducción
La clase android.media.MediaRecorder.AudioSource
incluye la fuente de audio REMOTE_SUBMIX
.
Si las implementaciones de dispositivos declaran android.hardware.audio.output
y android.hardware.microphone
, hacen lo siguiente:
[C-1-1] DEBE implementar correctamente la fuente de audio
REMOTE_SUBMIX
para que, cuando una aplicación use la API deandroid.media.AudioRecord
para grabar desde esta fuente de audio, capture una combinación de todas las transmisiones de audio, excepto las siguientes:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Cancelador de eco acústico
Si las implementaciones de dispositivos declaran android.hardware.microphone
, hacen lo siguiente:
- DEBE implementar una tecnología de cancelación de eco acústico (AEC) ajustada para la comunicación por voz y aplicada a la ruta de captura cuando se captura con
AudioSource.VOICE_COMMUNICATION
.
Si las implementaciones de dispositivos proporcionan un cancelador de eco acústico que se inserta en la ruta de audio de captura cuando se selecciona AudioSource.VOICE_COMMUNICATION
, hacen lo siguiente:
- [C-SR-1] SE_RECOMIENDAN_CON_MUCHÍSIMA_INSISTENCIA que declares esto a través del método de la API de AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
- [C-SR-2] se RECOMIENDA_CON_MUCHÍSIMA_INSISTENCIA para permitir que este efecto de audio se pueda controlar con la API de AcousticEchoCanceler.
- [C-SR-3] SE RECOMIENDA_CON_MUCHÍSIMA_INSISTENCIA identificar de forma inequívoca cada implementación de la tecnología de AEC a través del campo AudioEffect.Descriptor.uuid.
5.4.5. Captura simultánea
Si las implementaciones de dispositivos declaran android.hardware.microphone
,DEBEN implementar la captura simultánea como se describe en este documento. Más precisamente:
- [C-1-1] DEBE permitir el acceso simultáneo al micrófono por parte de un servicio de accesibilidad que capture con
AudioSource.VOICE_RECOGNITION
y al menos una aplicación que capture con cualquierAudioSource
. - [C-1-2] DEBE permitir el acceso simultáneo al micrófono por parte de una aplicación preinstalada que tenga un rol de Asistente y al menos una aplicación que capture con cualquier
AudioSource
, exceptoAudioSource.VOICE_COMMUNICATION
oAudioSource.CAMCORDER
. - [C-1-3] DEBE silenciar la captura de audio de cualquier otra aplicación, excepto un servicio de accesibilidad, mientras una aplicación realiza la captura con
AudioSource.VOICE_COMMUNICATION
oAudioSource.CAMCORDER
. Sin embargo, cuando una app realiza capturas a través deAudioSource.VOICE_COMMUNICATION
, otra app puede capturar la llamada de voz si es una app privilegiada (preinstalada) con el permisoCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Si dos o más aplicaciones están capturando de forma simultánea y ninguna tiene una IU en la parte superior, la que comenzó a capturar más recientemente recibe audio.
5.5. Reproducción de audio
Android incluye la compatibilidad para permitir que las apps 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 sin procesar
Si las implementaciones de dispositivos declaran android.hardware.audio.output
, hacen lo siguiente:
[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, punto flotante
- Canales: Mono, estéreo y configuraciones multicanal válidas con hasta 8 canales
- Tasas de muestreo (en Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100 y 48000 en los parámetros de configuración de canal anteriores
- 96,000 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
, hacen lo siguiente:
- [C-1-1] DEBE admitir las implementaciones de
EFFECT_TYPE_EQUALIZER
yEFFECT_TYPE_LOUDNESS_ENHANCER
que se pueden controlar a través de las subclases AudioEffectEqualizer
yLoudnessEnhancer
. - [C-1-2] DEBE admitir la implementación de la API del visualizador, que se puede controlar a través de la clase
Visualizer
. - [C-1-3] DEBE admitir la implementación de
EFFECT_TYPE_DYNAMICS_PROCESSING
que se puede controlar a través de la subclase AudioEffectDynamicsProcessing
.
Cómo iniciar nuevos requisitos
- [C-1-4] DEBE admitir efectos de audio con entrada y salida de números de punto flotante.
- [C-1-5] DEBE asegurarse de que los efectos de audio admitan varios canales hasta el recuento de canales del mezclador, también conocido como FCC_LIMIT.
Fin de los nuevos requisitos
- DEBE admitir las implementaciones de
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
,EFFECT_TYPE_PRESET_REVERB
yEFFECT_TYPE_VIRTUALIZER
que se pueden controlar a través de las subclasesAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
yVirtualizer
. - [C-SR-1] SE RECOMIENDA ENFATICAMENTE admitir efectos en punto flotante y multicanal.
5.5.3. Volumen de salida de audio
Implementaciones de dispositivos para la industria automotriz:
- DEBE permitir ajustar el volumen de audio por separado para cada transmisión de audio con el tipo de contenido o el uso según lo define AudioAttributes y el uso de audio para automóviles según se define públicamente en
android.car.CarAudioManager
.
5.5.4. Transferencia de audio
Si las implementaciones de dispositivos admiten la reproducción de transferencia de audio, hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE recortar el contenido de audio sin interrupciones que se reproduce entre dos clips con el mismo formato cuando lo especifica la API de AudioTrack sin interrupciones y el contenedor multimedia de MediaPlayer.
5.6. Latencia de audio
La latencia de audio es la demora que se produce cuando una señal de audio pasa por 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, usa las siguientes definiciones:
- latencia de salida. Es el intervalo entre el momento en que una aplicación escribe una trama de datos codificados en PCM y el momento en que el sonido correspondiente se presenta al entorno en un transductor integrado en el dispositivo o cuando la señal sale del dispositivo a través de un puerto y se puede observar de forma externa.
- latencia de salida fría. Es el tiempo que transcurre 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. Es la latencia de salida para los fotogramas posteriores, después de que el dispositivo reproduce audio.
- latencia de entrada. Es el intervalo entre el momento en que el entorno presenta un sonido al dispositivo en un transductor integrado o cuando la señal ingresa al dispositivo a través de un puerto y el momento en que una aplicación lee la trama correspondiente de datos codificados en PCM.
- entrada perdida. Es la parte inicial de un indicador de entrada que no se puede usar o que no está disponible.
- latencia de entrada fría. Es el tiempo que transcurre entre el inicio de la transmisión y el momento en que se recibe el primer fotograma válido, cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
latencia de entrada continua. La latencia de entrada para los fotogramas posteriores, mientras el dispositivo captura audio.
latencia de ida y vuelta continua. Es 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 app procese la señal y mitigue la diferencia de fase entre las transmisiones de entrada y salida.
API de cola de búfer PCM de OpenSL ES El conjunto de APIs de OpenSL ES relacionadas con PCM en el NDK de Android
API de audio nativo de AAudio. Es el conjunto de APIs de AAudio dentro del NDK de Android.
Marca de tiempo. Es un par que consta de una posición de fotogramas relativa dentro de una transmisión y la hora estimada en la que ese fotograma ingresa o sale de la canalización de procesamiento de audio en el extremo asociado. Consulta también AudioTimestamp.
error. Una interrupción temporal o un valor de muestra incorrecto en la señal de audio, que suele deberse a una falta de búfer para la salida, un desbordamiento de búfer para la entrada o cualquier otra fuente de ruido digital o analógico.
desviación absoluta media. Es el promedio del valor absoluto de las desviaciones de la media para un conjunto de valores.
Latencia de toque para tono. Es el tiempo que transcurre entre el momento en que se presiona la pantalla y el momento en que se escucha un tono generado como resultado de esa presión en la bocina.
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 que muestran AudioTrack.getTimestamp y
AAudioStream_getTimestamp
es precisa dentro de un margen de +/- 2 ms. [C-1-2] Latencia de salida en frío de 500 milisegundos o menos
[C-1-3] Abrir un flujo de salida con
AAudioStreamBuilder_openStream()
DEBE tardar menos de 1,000 milisegundos.
Si las implementaciones de dispositivos declaran android.hardware.audio.output
, se RECOMIENDA URGENTEMENTE 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 de la bocina.
- [C-SR-2] Latencia de toque para tono de 80 milisegundos o menos.
- [C-SR-4] La marca de tiempo de salida que devuelven AudioTrack.getTimestamp y
AAudioStream_getTimestamp
es precisa dentro de un margen de +/- 1 ms.
Cómo iniciar nuevos requisitos
- [C-SR-4] Se RECOMIENDA FUERTEMENTE que las latencias de ida y vuelta calculadas en función de las marcas de tiempo de entrada y salida que muestra
AAudioStream_getTimestamp
se encuentren dentro de los 30 ms de la latencia de ida y vuelta medida paraAAUDIO_PERFORMANCE_MODE_NONE
yAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
en bocinas y auriculares con cable y sin cable.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos cumplen con los requisitos anteriores, después de cualquier calibración inicial, cuando se usa la API de audio nativa de AAudio, para la latencia de salida continua y la latencia de salida en frío en al menos un dispositivo de salida de audio compatible, deben cumplir con los siguientes requisitos:
- [C-SR-5] SE RECOMIENDA CONFIDENTEMENTE informar audio de baja latencia declarando la marca de función
android.hardware.audio.low_latency
. - [C-SR-6] SE RECOMIENDA ALTAMENTE cumplir con los requisitos de audio de baja latencia a través de la API de AAudio.
- [C-SR-7] SE RECOMIENDA ENFATICAMENTE que, para las transmisiones que muestran
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
desdeAAudioStream_getPerformanceMode()
, el valor que muestraAAudioStream_getFramesPerBurst()
sea menor o igual que el valor que muestraandroid.media.AudioManager.getProperty(String)
para la clave de propiedadAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Si las implementaciones de dispositivos no cumplen con los requisitos de audio de baja latencia a través de la API de audio nativa de AAudio, sucede lo siguiente:
- [C-2-1] NO DEBE informar compatibilidad con audio de baja latencia.
Si las implementaciones de dispositivos incluyen android.hardware.microphone
, DEBEN cumplir con estos requisitos de audio de entrada:
- [C-3-1] Limita el error en las marcas de tiempo de entrada, como las muestra AudioRecord.getTimestamp o
AAudioStream_getTimestamp
, a +/- 2 ms. Aquí, "Error" se refiere a la desviación del valor correcto. - [C-3-2] Latencia de entrada en frío de 500 milisegundos o menos
- [C-3-3] Abrir un flujo de entrada con
AAudioStreamBuilder_openStream()
DEBE tardar menos de 1,000 milisegundos.
Si las implementaciones de dispositivos incluyen android.hardware.microphone
, se RECOMIENDA URGENTEMENTE que cumplan con estos requisitos de audio de entrada:
[C-SR-8] Latencia de entrada en frío de 100 milisegundos o menos a través de la ruta de datos del micrófono.
[C-SR-11] Limita el error en las marcas de tiempo de entrada, como las muestra AudioRecord.getTimestamp o
AAudioStream_getTimestamp
, a +/- 1 ms.
Si las implementaciones de dispositivos declaran android.hardware.audio.output
y android.hardware.microphone
, hacen lo siguiente:
- [C-SR-12] SE RECOMIENDA ENFATICAMENTE tener una latencia de ida y vuelta continua promedio de 50 milisegundos o menos en 5 mediciones, con una desviación absoluta promedio inferior a 10 ms, en al menos una ruta compatible.
5.7. Protocolos de red
Las implementaciones de dispositivos DEBEN admitir los protocolos de red multimedia 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 una implementación de dispositivo debe admitir, la implementación del dispositivo debe cumplir con los siguientes requisitos:
[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 contenido multimedia correspondientes, como se muestra en la siguiente tabla de formatos de segmentos de contenido multimedia, según el protocolo de borrador de transmisión HTTP en vivo, versión 7.
[C-1-3] DEBE admitir los formatos de carga útil de RTSP correspondientes, como se muestra en la siguiente tabla de RTSP. Para ver las excepciones, consulta las notas al pie de la tabla en la sección 5.1.
Formatos de segmentos de medios
Formatos de segmentos | Referencias | Compatibilidad con códecs obligatorios |
---|---|---|
Flujo de transporte MPEG-2 | ISO 13818 |
Códecs de video:
y MPEG-2. Códecs de audio:
|
AAC con enmarcado ADTS y etiquetas ID3 | ISO 13818-7 | Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes. |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Nombre del perfil | Referencias | Compatibilidad con códecs obligatorios |
---|---|---|
H264 AVC | RFC 6184 | Consulta la sección 5.1.8 para obtener detalles sobre el AVC H264. |
MP4A-LATM | RFC 6416 | Consulta la sección 5.1.3 para obtener detalles sobre el AAC y sus variantes. |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
Consulta la sección 5.1.8 para obtener más información sobre H263. |
H263-2000 | RFC 4629 | Consulta la sección 5.1.8 para obtener más información sobre H263. |
AMR | RFC 4867 | Consulta la sección 5.1.3 para obtener más información sobre AMR-NB. |
AMR-WB | RFC 4867 | Consulta la sección 5.1.3 para obtener más información sobre AMR-WB. |
MP4V-ES | RFC 6416 | Consulta la sección 5.1.8 para obtener detalles sobre MPEG-4 SP. |
mpeg4-generic | RFC 3640 | Consulta la sección 5.1.3 para obtener detalles sobre el AAC y sus variantes. |
MP2T | RFC 2250 | Consulta MPEG-2 Transport Stream en HTTP Live Streaming para obtener más información. |
5.8. Secure Media
Si las implementaciones de dispositivos admiten una salida de video segura y son compatibles con superficies seguras, hacen lo siguiente:
- [C-1-1] DEBE declarar compatibilidad con
Display.FLAG_SECURE
.
Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE
y con el protocolo de pantalla inalámbrica, hacen lo siguiente:
- [C-2-1] DEBE proteger el vínculo con un mecanismo criptográficamente sólido, 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 compatibilidad con Display.FLAG_SECURE
y con pantallas externas con cable, hacen lo siguiente:
- [C-3-1] DEBE admitir HDCP 1.2 o versiones posteriores para todas las pantallas externas conectadas a través de un puerto con cable al que el usuario pueda acceder.
5.9. Interfaz digital para instrumentos musicales (MIDI)
Si las implementaciones de dispositivos informan la compatibilidad con la función android.software.midi
a través de la clase android.content.pm.PackageManager
, hacen lo siguiente:
[C-1-1] DEBEN admitir MIDI a través de todos los transportes de hardware compatibles con MIDI para los que proporcionan conectividad genérica no MIDI, en los que dichos transportes son los siguientes:
- Modo host USB, sección 7.7
- MIDI a través de Bluetooth LE que actúa en el rol central, sección 7.4.3
[C-1-2] DEBE admitir el transporte de software MIDI entre apps (dispositivos MIDI virtuales)
[C-1-3] DEBE incluir libamidi.so (compatibilidad nativa con MIDI)
DEBE admitir MIDI en modo periférico USB (sección 7.7).
5.10. Audio profesional
Si las implementaciones de dispositivos informan compatibilidad con la función android.hardware.audio.pro
a través de la clase android.content.pm.PackageManager, hacen lo siguiente:
- [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, de 25 milisegundos o menos en, al menos, una ruta de acceso compatible.
- [C-1-3] DEBEN incluir puertos USB compatibles con 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] DEBEN cumplir con las latencias y los requisitos de audio USB con la API de audio nativo de AAudio y
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] DEBE tener una latencia de salida fría de 200 milisegundos o menos.
- [C-1-7] DEBE tener una latencia de entrada fría de 200 milisegundos o menos.
[C-1-8] DEBE tener una latencia promedio de toque para tono de 80 milisegundos o menos en al menos 5 mediciones en la ruta de datos de la bocina al micrófono.
[C-SR-1] SE RECOMIENDA ENFATICAMENTE cumplir con las latencias definidas en el artículo 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 de la bocina al micrófono.
[C-SR-2] SE RECOMIENDA ENFATICAMENTE que se cumplan los requisitos de audio profesional para latencia de audio de ida y vuelta continua, latencia de entrada en frío y latencia de salida en frío, y los requisitos de audio USB con la API de audio nativo de AAudio en la ruta de acceso MMAP.
[C-SR-3] SE RECOMIENDA ENFATICAMENTE proporcionar un nivel de rendimiento de la CPU constante mientras el audio está activo y la carga de la CPU varía. Esto se debe probar con la app para Android SynthMark. SynthMark usa un sintetizador de software que se ejecuta en un framework de audio simulado que mide el rendimiento del sistema. Consulta la documentación de SynthMark para obtener una explicación de las comparativas. La app de SynthMark se debe ejecutar con la opción "Prueba automática" y obtener los siguientes resultados:
- voicemark.90 >= 32 voces
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms
DEBE minimizar la imprecisión y la deriva del reloj de audio en relación con la hora estándar.
DEBE minimizar la deriva del reloj de audio en relación con el
CLOCK_MONOTONIC
de la CPU cuando ambos están activos.DEBE minimizar la latencia de audio en los transductores integrados en el 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 el jitter en los tiempos de entrada de la devolución de llamada de finalización del búfer de audio, ya que esto afecta el porcentaje utilizable del ancho de banda completo de la CPU por parte de la devolución de llamada.
DEBE proporcionar cero fallas de audio en condiciones de uso normales con la latencia informada.
DEBE proporcionar una diferencia de latencia entre canales de cero.
DEBE minimizar la latencia promedio de MIDI en todos los transportes.
DEBE minimizar la variabilidad de la latencia de 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 integrados en el dispositivo, incluido el período inmediatamente después del inicio en frío.
DEBE proporcionar una diferencia de reloj de audio cero entre los lados de entrada y salida de los extremos correspondientes, cuando ambos están activos. Algunos ejemplos de extremos correspondientes son el micrófono y la bocina integrados en el dispositivo, o la entrada y salida del conector de audio.
DEBE controlar las devoluciones de llamada de finalización del búfer de audio para los lados de entrada y salida de los extremos correspondientes en el mismo subproceso cuando ambos estén activos y entrar a la devolución de llamada de salida inmediatamente después de la devolución de la devolución de llamada de entrada. O bien, si no es posible controlar las devoluciones de llamada en el mismo subproceso, ingresa 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 un tiempo coherente de los lados de entrada y salida.
DEBE minimizar la diferencia de fase entre el almacenamiento en búfer de audio de HAL para los lados de entrada y salida de los extremos correspondientes.
DEBE minimizar la latencia táctil.
DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).
Si las implementaciones de dispositivos cumplen con todos los requisitos anteriores, sucede lo siguiente:
- [C-SR-4] SE RECOMIENDA ENFATICAMENTE informar la compatibilidad con la función
android.hardware.audio.pro
a través de la claseandroid.content.pm.PackageManager
.
Si las implementaciones de dispositivos incluyen un conector de audio de 3.5 mm de 4 conductores, deben cumplir con los siguientes requisitos:
[C-2-1] DEBE tener una latencia de audio de ida y vuelta continua promedio, como se define en la sección 5.6 Latencia de audio, de 20 milisegundos o menos, en 5 mediciones con una desviación absoluta promedio inferior a 5 milisegundos en la ruta de acceso del conector de audio con un Dongle de bucle de retorno de audio.
[C-SR-5] SE RECOMIENDA ENFATICAMENTE cumplir con la sección Especificaciones del dispositivo móvil (conector) de la Especificación de auriculares de audio con cable (v1.1).
Si las implementaciones de dispositivos omiten un conector de audio de 3.5 mm de 4 conductores y, en su lugar, incluyen puertos USB compatibles con el modo host USB, sucede lo siguiente:
- [C-3-1] DEBE implementar la clase de audio USB.
- [C-3-2] DEBE tener una latencia de audio de ida y vuelta continua promedio de 25 milisegundos o menos, en 5 mediciones con una desviación absoluta promedio inferior a 5 milisegundos en el puerto de modo host USB con la clase de audio USB. (Esto se puede medir con un adaptador USB a 3.5 mm y una llave de Audio Loopback, o con una interfaz de audio USB con cables de conexión que conecten las entradas a las salidas).
- [C-SR-6] SE RECOMIENDA ENFATICAMENTE que admitan E/S simultáneas de hasta 8 canales en cada dirección, una tasa de muestreo de 96 kHz y una profundidad de 24 o 32 bits cuando se usan con periféricos de audio USB que también admitan estos requisitos.
- [C-SR-7] SE RECOMIENDA ENFATICAMENTE que cumplas con este grupo de requisitos con la API de audio nativo de AAudio a través de la ruta de acceso MMAP.
Si las implementaciones de dispositivos incluyen un puerto HDMI, deben cumplir con los siguientes requisitos:
- DEBE admitir la salida en estéreo y ocho canales con una profundidad de 20 bits 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 compatibilidad con 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 parámetro de configuración preestablecido de grabación SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
Si las implementaciones de dispositivos intentan admitir fuentes de audio sin procesar y ponerlas a disposición de apps de terceros, deben cumplir con los siguientes requisitos:
[C-1-1] DEBE informar la compatibilidad a través de la propiedad
android.media.AudioManager
PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] DEBEN presentar características de amplitud en relación con la frecuencia aproximadamente planas en el rango de frecuencia media: específicamente, ±10 dB de 100 Hz a 7,000 Hz para cada micrófono que se use para grabar la fuente de audio sin procesar.
[C-1-3] DEBEN mostrar niveles de amplitud en el rango de frecuencia baja: específicamente de ±20 dB de 5 z a 100 Hz en comparación con el rango de frecuencia media de cada micrófono que se usa para grabar la fuente de audio sin procesar.
[C-1-4] DEBEN mostrar niveles de amplitud en el rango de frecuencia alta: específicamente, de ±30 dB de 7000 Hz a 22 KHz en comparación con el rango de frecuencia media de cada micrófono que se usa para grabar la fuente de audio sin procesar.
[C-1-5] DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz que se reproduce a un nivel de presión sonora (SPL) de 94 dB genere una respuesta con un RMS de 520 para muestras de 16 bits (o -36 dB de escala completa para muestras de punto flotante o precisión doble) para cada micrófono que se use para grabar la fuente de audio sin procesar.
[C-1-6] DEBE tener una relación señal/ruido (SNR) de 60 dB o más para cada micrófono que se use para grabar la fuente de audio sin procesar. (mientras que la relación señal/ruido se mide como la diferencia entre 94 dB SPL y el SPL equivalente del 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 SPL de 90 dB en cada micrófono que se use para grabar la fuente de audio sin procesar.
[C-1-8] NO DEBE tener ningún otro procesamiento de señal (p.ej., control de ganancia automático, filtro de paso alto o cancelación de eco) en la ruta de acceso, excepto un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:
- [C-1-9] Si hay algún procesamiento de señal presente en la arquitectura por algún motivo, DEBE inhabilitarse y, de manera efectiva, no debe introducir demoras ni latencia adicional en la ruta de la señal.
- [C-1-10] Si bien el multiplicador de nivel puede estar en la ruta, NO DEBE introducir demoras ni latencia en la ruta de la señal.
Todas las mediciones de SPL se realizan directamente al lado del micrófono en prueba. En el caso de varias configuraciones de micrófono, 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, hacen lo siguiente:
- [C-2-1] DEBE mostrar
null
para el método de la API deAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
para indicar correctamente la falta de compatibilidad. - [C-SR-1] aún se RECOMIENDA ALTAMENTE que satisfaga la mayor cantidad posible de requisitos de la ruta de señal de la fuente de grabación sin procesar.
5.12. Video HDR
Android 13 admite las tecnologías HDR como se describe en un próximo documento.
Formato de píxeles
Si un decodificador de video anuncia compatibilidad con COLOR_FormatYUVP010, sucede lo siguiente:
[C-1-1] DEBE admitir el formato P010 para la lectura de la CPU (ImageReader, MediaImage, ByteBuffer). En Android 13, se relaja P010 para permitir un paso arbitrario para los planos Y y UV.
[C-1-2] La GPU DEBE poder muestrear el búfer de salida P010 (cuando se asigna con el uso de GPU_SAMPLING). Esto permite la composición de la GPU y la asignación de tonos personalizados por parte de las apps.
Si un decodificador de video anuncia compatibilidad con COLOR_Format32bitABGR2101010, hace lo siguiente:
- [C-2-1] DEBE admitir el formato RGBA_1010102 para la superficie de salida y ser legible por la CPU (salida de ByteBuffer).
Si un codificador de video anuncia compatibilidad con COLOR_FormatYUVP010, hace lo siguiente:
- [C-3-1] DEBE admitir el formato P010 para la superficie de entrada y la entrada que se puede escribir en la CPU (ImageWriter, MediaImage, ByteBuffer).
Si un codificador de video anuncia compatibilidad con COLOR_Format32bitABGR2101010, hace lo siguiente:
- [C-4-1] DEBE admitir el formato RGBA_1010102 para la superficie de entrada y la entrada que se puede escribir en la CPU (ImageWriter, ByteBuffer). Nota: NO es necesario convertir entre varias curvas de transferencia para los codificadores.
Requisitos para la captura de HDR
Para todos los codificadores de video que admiten perfiles HDR, las implementaciones de dispositivos deben cumplir con los siguientes requisitos:
[C-5-1] NO DEBE suponer que los metadatos HDR son precisos. Por ejemplo, el fotograma codificado podría tener píxeles más allá del nivel de luminancia máxima, o el histograma podría no ser representativo del fotograma.
DEBEN agregar metadatos dinámicos de HDR para generar metadatos estáticos de HDR adecuados para las transmisiones codificadas y deben generarlos al final de cada sesión de codificación.
Si las implementaciones de dispositivos admiten la captura HDR con las APIs de CamcorderProfile, hacen lo siguiente:
[C-6-1] DEBE admitir la captura de HDR a través de las APIs de Camera2.
[C-6-2] DEBE admitir al menos un codificador de video con aceleración de hardware para cada tecnología HDR compatible.
[C-6-3] DEBE admitir (como mínimo) la captura HLG.
[C-6-4] DEBE admitir la escritura de metadatos HDR (si corresponde a la tecnología HDR) en el archivo de video capturado. En el caso de AV1, HEVC y DolbyVision, esto significa incluir los metadatos en el flujo de bits codificado.
[C-6-5] DEBE admitir P010 y COLOR_FormatYUVP010.
[C-6-6] DEBE admitir la asignación de tonos de HDR a SDR en el decodificador predeterminado con aceleración de hardware para el perfil capturado. En otras palabras, si un dispositivo puede capturar HDR10+ HEVC, el decodificador HEVC predeterminado DEBE poder decodificar la transmisión capturada en SDR.
Requisitos de edición HDR
Si las implementaciones de dispositivos incluyen codificadores de video que admiten la edición HDR, hacen lo siguiente:
- DEBE usar una latencia mínima para generar los metadatos HDR cuando no estén presentes y DEBE controlar de forma fluida las situaciones en las que los metadatos están presentes para algunos fotogramas y no para otros. Estos metadatos DEBEN ser precisos (por ejemplo, representar la luminancia máxima y el histograma reales del fotograma).
Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing
, esos códecs hacen lo siguiente:
[C-7-1] DEBE admitir al menos un perfil HDR.
[C-7-2] DEBEN admitir
FEATURE_HdrEditing
para todos los perfiles HDR que anuncie ese códec. En otras palabras, DEBEN admitir la generación de metadatos HDR cuando no estén presentes para todos los perfiles HDR compatibles que usen metadatos HDR.[C-7-3] DEBE admitir los siguientes formatos de entrada de codificador de video que preserven por completo la señal decodificación HDR:
- RGBA_1010102 (ya está en la curva de transferencia objetivo) para la superficie de entrada y el ByteBuffer, y DEBE anunciar la compatibilidad con COLOR_Format32bitABGR2101010.
Si la implementación del dispositivo incluye códecs que admiten FEATURE_HdrEditing, el dispositivo hace lo siguiente:
- [C-7-4] DEBE anunciar la compatibilidad con la extensión EXT_YUV_target de OpenGL.
6. Compatibilidad de las herramientas y opciones para desarrolladores
6.1. Herramientas para desarrolladores
Implementaciones de dispositivos:
- [C-0-1] DEBEN admitir las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.
-
- [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y los comandos de shell proporcionados en el AOSP, que pueden usar los desarrolladores de apps, incluida
dumpsys
.cmd stats
- [C-0-11] DEBE admitir el comando de shell
cmd testharness
. Es POSIBLE que las implementaciones de dispositivos que se actualizan desde una versión anterior de Android sin un bloque de datos persistente estén exentas de C-0-11. - [C-0-3] NO DEBE alterar el formato ni el contenido de los eventos del sistema del dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados a través del 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 de shell
cmd stats
y la clase de API del sistemaStatsManager
.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] DEBE tener el daemon de adb 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 compatibilidad con adb seguro. El adb seguro habilita adb en hosts autenticados conocidos.
- [C-0-6] DEBE proporcionar un mecanismo que permita que adb se conecte desde una máquina anfitrión. Más precisamente:
Si las implementaciones de dispositivos sin un puerto USB admiten el modo periférico, hacen lo siguiente:
- [C-3-1] DEBE implementar adb a través de una red de área local (como Ethernet o Wi-Fi).
- [C-3-2] DEBEN proporcionar controladores para Windows 7, 8 y 10, lo que permite que los desarrolladores se conecten al dispositivo con el protocolo ADB.
Si las implementaciones de dispositivos admiten conexiones adb a una máquina anfitrión a través de Wi-Fi o Ethernet, hacen lo siguiente:
- [C-4-1] DEBE tener el método
AdbManager#isAdbWifiSupported()
que muestratrue
.
Si las implementaciones de dispositivos admiten conexiones adb a una máquina host a través de Wi-Fi o Ethernet, y, además, incluyen al menos una cámara, hacen lo siguiente:
- [C-5-1] DEBE tener el método
AdbManager#isAdbWifiQrSupported()
que muestratrue
.
- [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y los comandos de shell proporcionados en el AOSP, que pueden usar los desarrolladores de apps, incluida
Servicio de Dalvik Debug Monitor (ddms)
- [C-0-7] DEBE admitir todas las funciones de ddms como se documenta en el SDK de Android. Como ddms usa adb, la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario haya activado el puente de depuración de Android, como se indicó anteriormente.
-
- [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 al que el usuario pueda acceder para activarlo.
-
- [C-SR-1] SE RECOMIENDA EXPONER un objeto binario
/system/bin/perfetto
al usuario de shell cuya línea de comandos cumpla con la documentación de perfetto. - [C-SR-2] SE RECOMIENDA ENFATICAMENTE que el objeto binario de 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 ENFATICAMENTE que el binario de Perfetto escriba como resultado un seguimiento de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [C-SR-4] SE RECOMIENDA ENFATICAMENTE que proporciones, a través del objeto binario de perfetto, al menos las fuentes de datos que se describen en la documentación de perfetto.
- [C-SR-1] SE RECOMIENDA EXPONER un objeto binario
-
- [C-0-12] DEBE escribir un átomo
LMK_KILL_OCCURRED_FIELD_NUMBER
en el registro de statsd cuando el Low Memory Killer cancele una app.
- [C-0-12] DEBE escribir un átomo
Modo de agente de prueba Si las implementaciones de dispositivos admiten el comando de shell
cmd testharness
y ejecutancmd testharness enable
, hacen lo siguiente:- [C-2-1] DEBE mostrar
true
paraActivityManager.isRunningInUserTestHarness()
- [C-2-2] DEBES implementar el modo de agente de prueba como se describe en la documentación del modo de agente de prueba.
- [C-2-1] DEBE mostrar
Información de trabajo de la GPU
Implementaciones de dispositivos:
- [C-0-13] DEBE implementar el comando de shell
dumpsys gpu --gpuwork
para mostrar los datos de trabajo agregados de la GPU que devuelve el punto de seguimiento del kernelpower/gpu_work_period
, o no mostrar datos si el punto de seguimiento no es compatible. La implementación de AOSP esframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] DEBE implementar el comando de shell
Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o versiones posteriores a través de las marcas de función android.hardware.vulkan.version
, hacen lo siguiente:
- [C-1-1] DEBE proporcionar una indicación para que el desarrollador de la app habilite o inhabilite las capas de depuración de la GPU.
- [C-1-2] Cuando las capas de depuración de la GPU están habilitadas, DEBEN enumerar las capas en las bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte de la plataforma o del paquete de la aplicación) que se encuentran en el directorio base de las aplicaciones depurables para admitir los métodos de la API vkEnumerateInstanceLayerProperties() y vkCreateInstance().
6.2. Opciones para desarrolladores
Android incluye compatibilidad para que los desarrolladores configuren parámetros de configuración relacionados con el desarrollo de aplicaciones.
Las implementaciones de dispositivos DEBEN proporcionar una experiencia coherente para las opciones para desarrolladores, y deben cumplir con los siguientes requisitos:
- [C-0-1] DEBE respetar el intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar la configuración relacionada con el desarrollo de la aplicación. La implementación de Android upstream oculta el menú de Opciones para desarrolladores de forma predeterminada y permite que los usuarios inicien las Opciones para desarrolladores después de presionar siete (7) veces el elemento de menú Configuración > Acerca del dispositivo > Número de compilación.
- [C-0-2] DEBE ocultar las Opciones para desarrolladores de forma predeterminada.
- [C-0-3] DEBE proporcionar un mecanismo claro que no dé un tratamiento preferencial a una app de terceros en comparación con otra para habilitar las Opciones para desarrolladores. DEBES proporcionar un documento o sitio web visible para el público que describa cómo habilitar las opciones para desarrolladores. 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 se habilitan las Opciones para desarrolladores y la seguridad del usuario es un problema.
- PUEDE limitar temporalmente el acceso al menú de opciones para desarrolladores ocultando o inhabilitando visualmente el menú para evitar distracciones en situaciones en las que la seguridad del usuario es un problema.
7. Compatibilidad de hardware
Si un dispositivo incluye un componente de hardware en particular que tiene una API correspondiente para desarrolladores externos, haz lo siguiente:
- [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 del SDK interactúa con un componente de hardware que se indica como opcional y la implementación del dispositivo no tiene ese componente, haz lo siguiente:
- [C-0-2] Aún DEBEN presentarse las definiciones de clases completas (como se documenta en el SDK) para las APIs de los componentes.
- [C-0-3] Los comportamientos de la API DEBEN implementarse como no-ops de alguna manera razonable.
- [C-0-4] Los métodos de la API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
- [C-0-5] Los métodos de la API DEBEN mostrar implementaciones de no operación de clases en las que la documentación del SDK no permite valores nulos.
- [C-0-6] Los métodos de la API NO DEBEN generar excepciones que no estén documentadas en la documentación del SDK.
- [C-0-7] Las implementaciones de dispositivos DEBEN informar de forma coherente información de configuración de hardware precisa a través de los métodos
getSystemAvailableFeatures()
yhasSystemFeature(String)
en la clase android.content.pm.PackageManager para la misma huella de compilación.
Un ejemplo típico de una situación en la que se aplican estos requisitos es la API de telefonía: Incluso en dispositivos que no son teléfonos, estas APIs deben implementarse como no operaciones razonables.
7.1. Pantalla y gráficos
Android incluye funciones que ajustan automáticamente los recursos de la aplicación y los diseños de la IU de forma adecuada para el dispositivo para garantizar que las aplicaciones de terceros se ejecuten bien en una variedad de configuraciones de hardware.
variedad de pantallas y configuraciones de hardware. Una pantalla compatible con Android es una pantalla que implementa todos los comportamientos y las APIs que se describen en Android Developers - Screen compatibility overview, esta sección (7.1) y sus subsecciones, así como cualquier comportamiento adicional específico del tipo de dispositivo que se documenta en la sección 2 de este CDD.
En las pantallas compatibles con Android en las que se pueden ejecutar todas las aplicaciones de terceros compatibles con Android, las implementaciones de dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.
Cómo iniciar nuevos requisitos
Implementaciones de dispositivos:
- [C-0-1] DEBE renderizar aplicaciones de terceros solo en pantallas compatibles con Android de forma predeterminada.
Fin de los nuevos requisitos
Las unidades a las que hacen referencia los requisitos de esta sección se definen de la siguiente manera:
- tamaño diagonal físico. Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
puntos por pulgada (dpi)de densidad. Es la cantidad de píxeles que abarca un tramo lineal horizontal o vertical de 1", expresado en píxeles por pulgada (ppi o dpi). Cuando se enumeran los valores dedpippi y dpi, los dpi horizontales y verticales deben estar dentro del rango indicado.- relación de aspecto. Es la proporción de los píxeles de la dimensión más larga a la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480 x 854 píxeles sería 854/480 = 1.779, o aproximadamente "16:9".
- píxeles independientes de la densidad (dp)
Launidad de píxeles virtual A se normaliza a unapantalla de 160 dpicon una densidad de pantalla de 160. Para una densidad d y una cantidad de píxeles p, la cantidad de píxeles independientes de la densidad dp se calcula de la siguiente manera:pixels = dps * (density/160)dp = (160 / d) * p .
7.1.1. Configuración de la pantalla
7.1.1.1. Tamaño y forma de la pantalla
El framework de IU de Android admite una variedad de tamaños de diseño de pantalla lógicos diferentes y permite que las aplicaciones consulten el tamaño del diseño de pantalla de la configuración actual a través de Configuration.screenLayout
con SCREENLAYOUT_SIZE_MASK
y Configuration.smallestScreenWidthDp
.
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 de pantalla correctas de píxeles independientes de la densidad (dp) lógicas, como se indica a continuación:- Los dispositivos con
Configuration.uiMode
establecido como cualquier valor que no sea UI_MODE_TYPE_WATCH y que informen un tamañosmall
paraConfiguration.screenLayout
DEBEN tener al menos 426 dp x 320 dp. - Los dispositivos que informan un tamaño
normal
paraConfiguration.screenLayout
DEBEN tener al menos 480 dp x 320 dp. - Los dispositivos que informan un tamaño
large
paraConfiguration.screenLayout
DEBEN tener al menos 640 dp x 480 dp. - Los dispositivos que informan un tamaño
xlarge
paraConfiguration.screenLayout
DEBEN tener al menos 960 dp x 720 dp.
- Los dispositivos con
[C-0-2] DEBE respetar correctamente la compatibilidad declarada de las aplicaciones con los 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.PUEDEN tener pantallas compatibles con Android con esquinas redondeadas.
Si las implementaciones de dispositivos admiten pantallas compatibles con la configuración de tamaño UI_MODE_TYPE_NORMAL
y incluyen pantallas
físicas compatibles con Android con esquinas redondeadas para renderizar estas pantallas, hacen lo siguiente:
[C-1-1] DEBEN asegurarse de que se cumpla al menos uno de los siguientes requisitos para cada una de esas pantallas:
- El radio de las esquinas redondeadas es menor o igual que 38 dp.
- Cuando
un cuadro de 1518 de dp por1518 de dp está anclado en cada esquina de la pantalla lógica, al menos un pixel de cada cuadro es visible en la pantalla.
DEBE incluir indicaciones visuales para el usuario para cambiar al modo de visualización con las esquinas rectangulares.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos solo son capaces de configurar el teclado NO_KEYS
y tienen la intención de informar la compatibilidad con la configuración del modo de IU UI_MODE_TYPE_NORMAL
, deben hacer lo siguiente:
- [C-4-1] DEBE tener un tamaño de diseño, sin incluir los recortes de la pantalla, de al menos 596 dp × 384 dp o superior.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos incluyen pantallas compatibles con Android que son plegables o incluyen una bisagra plegable entre varios paneles de pantalla y las ponen a disposición para renderizar apps de terceros, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBE implementar la versión estable más reciente disponible de la API de extensiones o la versión estable de la API de Sidecar que usará la biblioteca de Jetpack de Window Manager.
Si las implementaciones de dispositivos incluyen pantallas compatibles con Android que son plegables o incluyen una bisagra plegable entre varios paneles de pantalla, y si la bisagra o el pliegue cruzan una ventana de aplicación de pantalla completa, deben cumplir con lo siguiente:
- [C-3-1] DEBEN informar la posición, los límites y el estado de la bisagra o el plegado a la aplicación a través de extensiones o APIs de Sidecar.
Para obtener detalles sobre la implementación correcta de las APIs de Sidecar o de extensión, consulta la documentación pública de Jetpack de Window Manager.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos incluyen una o más áreas de visualización compatibles con Android que son plegables, o incluyen una bisagra plegable entre varias áreas de panel de visualización compatibles con Android y ponen esas áreas de visualización a disposición de las aplicaciones, deben cumplir con los siguientes requisitos:
- [C-4-1] DEBE implementar la versión correcta del nivel de API de las extensiones de Window Manager como se describe en Extensiones de WindowManager.
Fin de los nuevos requisitos
7.1.1.2. Relación de aspecto de la pantalla
Si bien no hay restricciones para la relación de aspecto de la pantalla física de las pantallas compatibles con Android, la relación de aspecto de la pantalla lógica en la que se renderizan las apps de terceros, que se puede obtener de los valores de altura y ancho informados a través de las APIs de view.Display
y de Configuración, DEBE cumplir con los siguientes requisitos:
[C-0-1] Las implementaciones de dispositivos con
Configuration.uiMode
establecido enUI_MODE_TYPE_NORMAL
DEBEN tener un valor de relación de aspecto menor o igual a 1.86 (aproximadamente 16:9), a menos que la app cumpla con una de las siguientes condiciones:- La app declaró que admite una relación de aspecto de pantalla más grande a través del valor de metadatos
android.max_aspect
. - La app declara que se puede cambiar de tamaño a través del atributo android:resizeableActivity.
- La app está orientada al nivel de API 24 o superior y no declara un
android:maxAspectRatio
que restringiría la relación de aspecto permitida.
- La app declaró que admite una relación de aspecto de pantalla más grande a través del valor de metadatos
[C-0-3] Las implementaciones de dispositivos con
Configuration.uiMode
establecido comoUI_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 framework de la IU de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a segmentar los recursos de la aplicación.
Implementaciones de dispositivos:
- [C-0-1]
De forma predeterminada, las implementaciones de dispositivosdeben informarsolouna de las densidades del framework de Android que se enumeran enDisplayMetrics
a través de la API deDENSITY_DEVICE_STABLE
, y este valor debe ser un valor estático para cada pantalla física.NO DEBE cambiar en ningún momento. Sin embargo,Sin embargo, el dispositivo PUEDE informar unadensidad arbitrariadistintaDisplayMetrics.density
según los cambios de configuración de la pantalla que realice el usuario (por ejemplo, el tamaño de la pantalla) después del inicio inicial.
- Las implementaciones de dispositivos DEBEN definir la densidad estándar del framework de Android que esté numéricamente más cerca de 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 framework de Android estándar que está numéricamente más cerca de la densidad física genera un tamaño de pantalla menor que el más pequeño compatible admitido (ancho de 320 dp), las implementaciones de dispositivos DEBEN informar la siguiente densidad más baja del framework de Android estándar.
Cómo iniciar nuevos requisitos
- DEBE definir la densidad estándar del framework de Android que esté numéricamente más cerca de la densidad física de la pantalla o un valor que se asigne a las mismas mediciones de campo de visión angular equivalentes de un dispositivo de mano.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos proporcionan
una indicación visual para cambiar el tamaño de visualización del dispositivo , deben cumplir con los siguientes requisitos:
- [C-1-1]
El tamaño de la pantalla NO DEBE escalarse más de 1.5 veces laDENSITY_DEVICE_STABLE
densidad nativani producir una dimensión de pantalla mínima efectiva menor que 320 dp (equivalente al calificador de recursos sw320dp), lo que ocurra primero. - [C-1-2]
El tamaño de la pantalla NO DEBE escalarseNO DEBE escalar la pantalla menor que 0.85 veces laDENSITY_DEVICE_STABLE
densidad nativa. - Para garantizar una buena usabilidad y tamaños de fuente coherentes, se RECOMIENDA que se proporcione la siguiente escala de opciones de visualización nativa (siempre que se cumplan los límites especificados anteriormente).
- Pequeña: 0.85x
- Predeterminado: 1x (escala de pantalla nativa)
- Grande: 1.15x
- Mayor: 1.3x
- Mayor: 1.45x
7.1.2. Métricas de Display
Si las implementaciones de dispositivos incluyen pantallas compatibles con Android o salida de video a pantallas compatibles con Android, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar valores correctos para todas las métricas de visualización compatibles con Android definidas en la API de
android.util.DisplayMetrics
.
Si las implementaciones de dispositivos no incluyen una pantalla incorporada o una salida de video, hacen lo siguiente:
- [C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android, como se define en la API de
android.util.DisplayMetrics
, para elview.Display
predeterminado emulado.
7.1.3. Orientación de pantalla
Implementaciones de dispositivos:
- [C-0-1] DEBEN informar qué orientaciones de pantalla admiten (
android.hardware.screen.portrait
oandroid.hardware.screen.landscape
) y DEBEN informar al menos una orientación compatible. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como una televisión o una laptop, SOLO DEBE informarandroid.hardware.screen.landscape
. - [C-0-2] DEBE informar el valor correcto de la orientación actual del dispositivo cada vez que se consulte a través de
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
o de otras APIs.
Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla, hacen lo siguiente:
- [C-1-1] DEBE admitir la orientación dinámica de las aplicaciones a la orientación de la pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación para una orientación de pantalla específica.
- [C-1-2] NO DEBE cambiar el tamaño ni la densidad de la pantalla informados cuando se cambia la orientación.
- PUEDE seleccionar la orientación vertical u horizontal como predeterminada.
7.1.4. Aceleración de gráficos 2D y 3D
OpenGL ES 7.1.4.1
Implementaciones de dispositivos:
- [C-0-1] DEBE identificar correctamente las versiones compatibles de OpenGL ES (1.1, 2.0, 3.0, 3.1 y 3.2) a través de las APIs administradas (como a través del método
GLES10.getString()
) y las APIs nativas. - [C-0-2] DEBE incluir la compatibilidad con todas las APIs administradas y las APIs nativas correspondientes para cada versión de OpenGL ES que se identificó como compatible.
Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:
- [C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, como se indica y detalla en la documentación del SDK de Android.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que admitan OpenGL ES 3.1.
- DEBE ser compatible con OpenGL ES 3.2.
Las pruebas de dEQP de OpenGL ES se dividen en varias listas de pruebas, cada una con una fecha o un número de versión asociados. Se encuentran en el árbol de fuentes de Android en external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
. Un dispositivo que admite OpenGL ES en un nivel informado por el usuario indica que puede aprobar las pruebas de dEQP en todas las listas de pruebas de este nivel y anteriores.
Si las implementaciones de dispositivos admiten alguna de las versiones de OpenGL ES, hacen lo siguiente:
- [C-2-1] DEBEN informar a través de las APIs administradas y nativas de OpenGL ES cualquier otra extensión de OpenGL ES que hayan implementado y, a la inversa, NO DEBEN informar cadenas de extensión que no admitan.
- [C-2-2] DEBE admitir las extensiones
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
yEGL_ANDROID_GLES_layers
. - [C-2-3] DEBE informar la versión máxima de las pruebas de dEQP de OpenGL ES que se admite a través de la marca de función
android.software.opengles.deqp.level
. - [C-2-4] DEBE admitir, al menos, la versión 132383489 (a partir del 1 de marzo de 2020), como se informa en la marca de función
android.software.opengles.deqp.level
. - [C-2-5] DEBEN aprobar todas las pruebas de dEQP de OpenGL ES en las listas de pruebas entre la versión 132383489 y la versión especificada en la marca de función
android.software.opengles.deqp.level
, para cada versión de OpenGL ES compatible. - [C-SR-2] SE RECOMIENDA URGENTEMENTE admitir las extensiones
EGL_KHR_partial_update
yOES_EGL_image_external
. DEBE informar con precisión a través del método
getString()
cualquier formato de compresión de texturas que admita, que suele ser específico del proveedor.DEBE admitir las extensiones
EGL_IMG_context_priority
yEGL_EXT_protected_content
.
Si las implementaciones de dispositivos declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2, hacen lo siguiente:
- [C-3-1] DEBE exportar los símbolos de función correspondientes para estas versiones, además de los símbolos de función de OpenGL ES 2.0 en la biblioteca libGLESv2.so.
- [C-SR-3] SE RECOMIENDA URGENTEMENTE admitir la extensión
OES_EGL_image_external_essl3
.
Si las implementaciones de dispositivos admiten OpenGL ES 3.2, hacen lo siguiente:
- [C-4-1] DEBE admitir el Android Extension Pack para OpenGL ES en su totalidad.
Si las implementaciones de dispositivos admiten el Android Extension Pack de OpenGL ES por completo, hacen lo siguiente:
- [C-5-1] DEBE identificar la compatibilidad a través de la marca de función
android.hardware.opengles.aep
.
Si las implementaciones de dispositivos exponen compatibilidad con la extensión EGL_KHR_mutable_render_buffer
, hacen lo siguiente:
- [C-6-1] También DEBE admitir la extensión
EGL_ANDROID_front_buffer_auto_refresh
.
Vulkan 7.1.4.2
Android incluye compatibilidad con Vulkan, una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento.
Si las implementaciones de dispositivos admiten OpenGL ES 3.1, hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas compatibilidad con Vulkan 1.3.
- [C-4-1] NO DEBE admitir una versión de variante de Vulkan (es decir, la parte de variante de la versión principal de Vulkan DEBE ser cero).
Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que se incluya compatibilidad con Vulkan 1.3.
Las pruebas de dEQP de Vulkan se dividen en varias listas de pruebas, cada una con una fecha o versión asociada. Se encuentran en el árbol de fuentes de Android en external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
. Un dispositivo que admite Vulkan en un nivel informado por el usuario indica que puede aprobar las pruebas de dEQP en todas las listas de pruebas de este nivel y anteriores.
Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.0 o versiones posteriores, hacen lo siguiente:
- [C-1-1] DEBE informar el valor entero correcto con las marcas de función
android.hardware.vulkan.level
yandroid.hardware.vulkan.version
. - [C-1-2] DEBE enumerar, al menos, un
VkPhysicalDevice
para la API nativa de VulkanvkEnumeratePhysicalDevices()
. - [C-1-3] DEBE implementar por completo las APIs de
Vulkan 1.0y Vulkan 1.1 para cadaVkPhysicalDevice
enumerado. - [C-1-4] DEBE enumerar las capas contenidas en bibliotecas nativas nombradas como
libVkLayer*.so
en el directorio de bibliotecas nativas del paquete de la aplicación a través de las APIs nativas de VulkanvkEnumerateInstanceLayerProperties()
yvkEnumerateDeviceLayerProperties()
. - [C-1-5] NO DEBE enumerar las capas que proporcionan las bibliotecas fuera del paquete de la aplicación ni proporcionar otras formas de rastrear o interceptar la API de Vulkan, a menos que la aplicación tenga el atributo
android:debuggable
configurado comotrue
o los metadatoscom.android.graphics.injectLayers.enable
configurados comotrue
. - [C-1-6] DEBEN informar todas las cadenas de extensión que admiten a través de las APIs nativas de Vulkan y, a la inversa, NO DEBEN informar 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 de dEQP de Vulkan compatibles a través de la marca de función
android.software.vulkan.deqp.level
. - [C-1-9] DEBE admitir, al menos, la versión
132317953
(a partir del 1 de marzo de 2019), como se informa en la marca de funciónandroid.software.vulkan.deqp.level
. - [C-1-10] DEBEN aprobarse todas las pruebas de dEQP de Vulkan en las listas de pruebas entre la versión
132317953
y la versión especificada en la marca de funciónandroid.software.vulkan.deqp.level
. - [C-1-11] NO DEBE enumerar la compatibilidad con las extensiones VK_KHR_video_queue, VK_KHR_video_decode_queue ni VK_KHR_video_encode_queue.
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE admitir las extensiones
VK_KHR_driver_properties
yVK_GOOGLE_display_timing
.
- DEBE admitir
VkPhysicalDeviceProtectedMemoryFeatures
yVK_EXT_global_priority
.
- [C-1-12] NO DEBE enumerar la compatibilidad con la extensión VK_KHR_performance_query.
- [C-1-13] DEBEN satisfacer los requisitos especificados en el perfil de Android Baseline 2021.
- [C-SR-4] Se RECOMIENDA ALTAMENTE que satisfaga los requisitos especificados en el perfil de Baseline de Android 2022.
Cómo iniciar nuevos requisitos
[C-SR-5] SE RECOMIENDA URGENTEMENTE admitir
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
yVK_EXT_global_priority
.[C-SR-6] SE RECOMIENDA ENFATICAMENTE usar
SkiaVk
con HWUI.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos no incluyen compatibilidad con Vulkan 1.0, sucede lo siguiente:
- [C-2-1] NO DEBE declarar ninguna de las marcas de función de Vulkan (p.ej.,
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] NO DEBE enumerar ningún
VkPhysicalDevice
para la API nativa de VulkanvkEnumeratePhysicalDevices()
.
Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.1 y declaran cualquiera de las marcas de función de Vulkan descritas aquí , hacen lo siguiente:
- [C-3-1] DEBE exponer compatibilidad con el semáforo externo
SYNC_FD
y los tipos de control y la extensiónVK_ANDROID_external_memory_android_hardware_buffer
.
Cómo iniciar nuevos requisitos
- [C-SR-7] SE RECOMIENDA ENFATICAMENTE que la extensión
VK_KHR_external_fence_fd
esté disponible para aplicaciones de terceros y que la aplicación pueda exportar y, también, importar la carga útil de la cerca desde los descriptores de archivos POSIX, como se describe aquí.
Fin de los nuevos requisitos
RenderScript 7.1.4.3
- [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 la aplicación, la actividad, la ventana o la vista mediante el uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas directas a la API.
Implementaciones de dispositivos:
- [C-0-1] DEBE habilitar la aceleración de hardware de forma predeterminada y DEBE inhabilitarla si el desarrollador lo solicita configurando android:hardwareAccelerated="false" o inhabilitando la aceleración de hardware directamente a través de las APIs de View de Android.
- [C-0-2] DEBE mostrar un comportamiento coherente con la documentación del SDK de Android sobre la aceleración de hardware.
Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas de OpenGL ES aceleradas por hardware como destinos de renderización en una jerarquía de IU.
Implementaciones de dispositivos:
- [C-0-3] DEBE admitir la API de TextureView y DEBE mostrar un comportamiento coherente con la implementación de Android upstream.
7.1.4.5 Pantallas de gama amplia
Si las implementaciones de dispositivos reclaman compatibilidad con pantallas de amplia gama a través de Configuration.isScreenWideColorGamut()
, hacen lo siguiente:
- [C-1-1] DEBE tener una pantalla calibrada en color.
- [C-1-2] DEBE tener una pantalla cuyo gamut cubra por completo el gamut de colores sRGB en el espacio xyY de CIE 1931.
- [C-1-3] DEBE tener una pantalla cuya gama tenga un área de al menos el 90% de DCI-P3 en el espacio xyY de CIE 1931.
- [C-1-4] DEBE admitir OpenGL ES 3.1 o 3.2 y notificarlo correctamente.
- [C-1-5] DEBE anunciar la compatibilidad con las extensiones
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
yEGL_EXT_gl_colorspace_display_p3_passthrough
. - [C-SR-1] SE RECOMIENDA URGENTEMENTE que admitan
GL_EXT_sRGB
.
Por el contrario, si las implementaciones de dispositivos no admiten pantallas de amplia gama, sucede lo siguiente:
- [C-2-1] DEBE cubrir el 100% o más de sRGB en el espacio xyY de CIE 1931, aunque la gama de colores de la pantalla no esté definida.
7.1.5. Modo de compatibilidad de aplicaciones heredadas
Android especifica un "modo de compatibilidad" en el que el framework funciona en un modo equivalente de tamaño de pantalla "normal" (ancho de 320 dp) para el beneficio de las aplicaciones heredadas que no se desarrollaron para versiones anteriores de Android que son anteriores a la independencia del tamaño de la pantalla.
7.1.6. Tecnología de la pantalla
La plataforma de Android incluye APIs que permiten que las aplicaciones rendericen gráficos enriquecidos en una pantalla compatible con Android. Los dispositivos DEBEN admitir todas estas APIs como las define el SDK de Android, a menos que se permita específicamente en este documento.
Todas las pantallas compatibles con Android de una implementación de dispositivo deben cumplir con los siguientes requisitos:
- [C-0-1] DEBE ser capaz de renderizar gráficos en color de 16 bits.
- DEBE admitir pantallas capaces de mostrar 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) de entre 0.9 y 1.15. Es decir, la relación de aspecto de píxeles DEBE ser casi cuadrada (1.0) con una tolerancia de entre el 10 y el 15%.
7.1.7. Pantallas secundarias
Android incluye compatibilidad con pantallas secundarias compatibles con Android para habilitar las capacidades de uso compartido de contenido multimedia y las APIs para desarrolladores para acceder a pantallas externas.
Si las implementaciones de dispositivos admiten una pantalla externa a través de una conexión adicional de pantalla con cable, inalámbrica o incorporada, cumplen con los siguientes requisitos:
- [C-1-1] DEBE implementar el servicio y la API del sistema
DisplayManager
como se describe en la documentación del SDK de Android.
7.2. Dispositivos de entrada
Implementaciones de dispositivos:
- [C-0-1] DEBE incluir un mecanismo de entrada, como una pantalla táctil o una navegación sin tacto, para navegar entre los elementos de la IU.
7.2.1. Teclado
Si las implementaciones de dispositivos incluyen compatibilidad con aplicaciones de Editor de métodos de entrada (IME) de terceros, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE declarar la marca de función
android.software.input_methods
. - [C-1-2] DEBEN implementar completamente
Input Management Framework
- [C-1-3] DEBEN tener un teclado en software preinstalado.
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 teclas).
- DEBE incluir implementaciones adicionales del teclado en pantalla.
- PUEDE incluir un teclado de hardware.
7.2.2. Navegación no táctil
Android incluye compatibilidad con el pad direccional, la bola de seguimiento y la rueda como mecanismos para la navegación sin tacto.
Implementaciones de dispositivos:
- [C-0-1] DEBE informar el valor correcto para android.content.res.Configuration.navigation.
Si las implementaciones de dispositivos carecen de navegaciones sin tacto, sucede lo siguiente:
- [C-1-1] DEBE proporcionar un mecanismo alternativo razonable de interfaz de usuario para la selección y edición de texto, compatible con los motores de administración de entradas. La implementación de código abierto de Android upstream incluye un mecanismo de selección adecuado para usar con dispositivos que no tienen entradas de navegación no táctiles.
7.2.3. Teclas de navegación
Las funciones Inicio, Recientes y Atrás, que suelen proporcionarse 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 una indicación visual para el usuario para iniciar aplicaciones instaladas que tengan una actividad con el
<intent-filter>
establecido conACTION=MAIN
yCATEGORY=LAUNCHER
oCATEGORY=LEANBACK_LAUNCHER
para implementaciones de dispositivos de TV. La función Inicio DEBE ser el mecanismo para esta indicación visual para el usuario. - DEBE proporcionar botones para las funciones Recientes y Atrás.
Si se proporcionan las funciones Inicio, Recientes o Atrás, estas tienen las siguientes características:
- [C-1-1] DEBE ser accesible con una sola acción (p.ej., presionar, hacer doble clic o realizar un gesto) cuando se pueda acceder a cualquiera de ellos.
- [C-1-2] DEBEN proporcionar una indicación clara de qué acción única activarí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 lista para usar son ejemplos de una indicación de este tipo.
Implementaciones de dispositivos:
[C-SR-1] SE RECOMIENDA NO proporcionar el mecanismo de entrada para la función de menú, ya que dejó de estar disponible a favor de la barra de acciones desde Android 4.0.
[C-SR-2] SE RECOMIENDA ENFATICAMENTE que todas las funciones de navegación sean cancelables. "Cancelable" se define como la capacidad del usuario de evitar que se ejecute la función de navegación (p.ej., ir a la pantalla principal, volver atrás, etc.) si no se suelta el deslizamiento después de un umbral determinado.
Si las implementaciones de dispositivos proporcionan la función de menú, hacen lo siguiente:
- [C-2-1] DEBE mostrar el botón de opciones de la acción cada vez que la ventana emergente del menú ampliado de la acción no esté vacía y la barra de acción esté visible.
- [C-2-2] NO DEBE modificar la posición de la ventana emergente de acciones adicionales que se muestra cuando se selecciona el botón de acciones adicionales en la barra de acciones, pero PUEDE renderizar la ventana emergente de acciones adicionales en una posición modificada en la pantalla cuando se muestra seleccionando la función de menú.
Si las implementaciones de dispositivos no proporcionan la función de menú, para la retrocompatibilidad, hacen lo siguiente:
- [C-3-1] DEBE hacer que la función de menú esté disponible para las aplicaciones cuando
targetSdkVersion
sea inferior a 10, ya sea a través de un botón físico, una tecla de software o gestos. Se debe poder acceder a esta función de menú, a menos que esté oculta junto con otras funciones de navegación.
Si las implementaciones de dispositivos proporcionan la función de asistencia, hacen lo siguiente:
- [C-4-1] DEBE permitir el acceso a la función de asistencia con una sola acción (p.ej., presionar, hacer doble clic o hacer un gesto) cuando se puede acceder a otras teclas de navegación.
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE usar la función de mantener presionado la pantalla en la pantalla principal como esta interacción designada.
Si las implementaciones de dispositivos usan una parte distinta de la pantalla para mostrar las teclas de navegación, hacen lo siguiente:
- [C-5-1] Las teclas de navegación DEBEN usar una parte distinta de la pantalla, que no esté disponible para las aplicaciones, y NO DEBEN ocultar ni interferir de ninguna manera con la parte de la pantalla disponible para las aplicaciones.
- [C-5-2] DEBE poner a disposición una parte de la pantalla para las aplicaciones que cumplan con los requisitos definidos en la sección 7.1.1.
- [C-5-3] DEBE respetar las marcas establecidas por la app a través del método de la API de
View.setSystemUiVisibility()
para que esta parte distinta de la pantalla (también conocida como barra de navegación) se oculte 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, haz lo siguiente:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
SOLO se DEBE usar para informar el área de reconocimiento de gestos de Home. - [C-6-2] Los gestos que comienzan dentro de un rectángulo de exclusión, como lo proporciona la aplicación en primer plano a través de
View#setSystemGestureExclusionRects()
, pero fuera deWindowInsets#getMandatorySystemGestureInsets()
, NO DEBEN interceptarse para la función de navegación, siempre y cuando el rectángulo de exclusión esté permitido dentro del límite de exclusión máximo, como se especifica en la documentación deView#setSystemGestureExclusionRects()
. - [C-6-3] DEBE enviar a la app en primer plano un evento
MotionEvent.ACTION_CANCEL
una vez que se comiencen a interceptar los toques para un gesto del sistema, si a la app en primer plano se le envió previamente un eventoMotionEvent.ACTION_DOWN
. - [C-6-4] DEBE proporcionar una indicación visual para el usuario para cambiar a una navegación en pantalla basada en botones (por ejemplo, en Configuración).
- DEBE proporcionar la función de inicio como un deslizamiento hacia arriba desde el borde inferior de la orientación actual de la pantalla.
- DEBE proporcionar la función Recientes como un deslizamiento hacia arriba y mantener 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 los rectángulos de exclusión que proporciona la aplicación en primer plano a través deView#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, haz lo siguiente:
- [C-7-1] La función de navegación DEBE ser Atrás y debe proporcionarse como un deslizamiento desde los bordes izquierdo y derecho de la orientación actual de la pantalla.
- [C-7-2] Si se proporcionan paneles del sistema deslizables personalizados en los bordes izquierdo o derecho, DEBEN colocarse en el tercio superior de la pantalla con una indicación visual clara y persistente de que arrastrar hacia adentro invocaría los paneles mencionados anteriormente y, por lo tanto, no Atrás. Un usuario PUEDE configurar un panel del sistema de modo que se ubique debajo del tercio superior de los bordes de la pantalla, pero el panel del sistema NO DEBE ocupar más de 1/3 de los bordes.
- [C-7-3] Cuando la app en primer plano tiene configuradas las marcas View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, el deslizamiento desde los bordes DEBE comportarse como se implementa en AOSP, que se documenta en el SDK.
- [C-7-4] Cuando la app en primer plano tiene configuradas las marcas View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT o WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, los paneles del sistema deslizables personalizados DEBEN ocultarse hasta que el usuario muestre o aclare las barras del sistema (también conocidas como barra de navegación y barra de estado) como se implementa en AOSP.
Si se proporciona la función de navegación hacia atrás y el usuario cancela el gesto de atrás, sucederá lo siguiente:
- [C-8-1] SE DEBE llamar a
OnBackInvokedCallback.onBackCancelled()
. - [C-8-2] NO SE DEBE llamar a
OnBackInvokedCallback.onBackInvoked()
. - [C-8-3] NO SE DEBE enviar el evento KEYCODE_BACK.
Si se proporciona la función de navegación hacia atrás, pero la aplicación en primer plano NO tiene un OnBackInvokedCallback
registrado, sucede lo siguiente:
- El sistema DEBE proporcionar una animación para la aplicación en primer plano que sugiera que el usuario retrocede, como se proporciona en AOSP.
Si las implementaciones de dispositivos admiten la API del sistema setNavBarMode
para permitir que cualquier app del sistema con permiso android.permission.STATUS_BAR
configure el modo de la barra de navegación, hacen lo siguiente:
- [C-9-1] DEBE admitir íconos aptos para niños o navegación basada en botones, como se proporciona en el código de AOSP.
7.2.4. Entrada táctil
Android incluye compatibilidad con una variedad de sistemas de entrada de punteros, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basadas en pantallas táctiles se asocian con una pantalla de modo que el usuario tenga la impresión de manipular directamente los elementos en la pantalla. Dado que el usuario toca directamente la pantalla, el sistema no requiere ninguna indicación adicional para indicar los objetos que se manipulan.
Implementaciones de dispositivos:
- DEBE tener algún tipo de sistema de entrada de puntero (ya sea táctil o similar a un mouse).
- DEBE admitir punteros con seguimiento completamente independiente.
Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor) en una pantalla principal compatible con Android, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar
TOUCHSCREEN_FINGER
para el campo de la APIConfiguration.touchscreen
. - [C-1-2] DEBE informar las marcas de funciones
android.hardware.touchscreen
yandroid.hardware.faketouch
.
Si las implementaciones de dispositivos incluyen una pantalla táctil que puede hacer un seguimiento de más de un toque en una pantalla principal compatible con Android, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBEN informar las marcas de función adecuadas
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
yandroid.hardware.touchscreen.multitouch.jazzhand
que correspondan al tipo de pantalla táctil específica del dispositivo.
Si las implementaciones de dispositivos dependen de un dispositivo de entrada externo, como un mouse o una bola de seguimiento (es decir, no se toca directamente la pantalla) para ingresar en una pantalla principal compatible con Android y cumplen con los requisitos de toques falsos de la sección 7.2.5, deben cumplir con los siguientes requisitos:
- [C-3-1] NO DEBE informar ninguna marca de función que comience con
android.hardware.touchscreen
. - [C-3-2] DEBE informar solo
android.hardware.faketouch
. - [C-3-3] DEBE informar
TOUCHSCREEN_NOTOUCH
para el campo de APIConfiguration.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 mouse o un control remoto que controla un cursor en pantalla se aproxima al toque, pero requiere que el usuario primero apunte o enfoque y, luego, haga clic. Muchos dispositivos de entrada, como el mouse, el panel táctil, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el panel táctil multitáctil, pueden admitir interacciones táctiles falsas. Android incluye la constante de función android.hardware.faketouch, que corresponde a un dispositivo de entrada no táctil (basado en punteros) de alta fidelidad, como un mouse o un panel táctil que puede emular de forma adecuada la entrada táctil (incluida la compatibilidad con gestos básicos) y que indica que el dispositivo admite un subconjunto emulado de la funcionalidad de la pantalla táctil.
Si las implementaciones de dispositivos no incluyen una pantalla táctil, pero incluyen otro sistema de entrada de puntero que desean poner a disposición, deben cumplir con los siguientes requisitos:
- DEBE declarar la compatibilidad con la marca de función
android.hardware.faketouch
.
Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch
, hacen lo siguiente:
- [C-1-1] DEBE informar las posiciones absolutas de la pantalla X e Y de la ubicación del puntero 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 se produce en el puntero cuando se mueve hacia abajo o hacia arriba en la pantalla.
- [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios emular el toque en un objeto en la pantalla.
- [C-1-4] DEBE admitir el puntero hacia abajo, el puntero hacia arriba, el puntero hacia abajo y, luego, el 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 el doble toque en un objeto en la pantalla.
- [C-1-5] DEBE admitir el puntero hacia abajo en un punto arbitrario de la pantalla, el movimiento del puntero a cualquier otro punto arbitrario de la pantalla, seguido de un puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
- [C-1-6] DEBE admitir el puntero hacia abajo y, luego, permitir que los usuarios muevan rápidamente el objeto a una posición diferente en la pantalla y, luego, el puntero hacia arriba en la pantalla, lo que permite que los usuarios lancen un objeto en la pantalla.
Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct
, hacen lo siguiente:
- [C-2-1] DEBE declarar la compatibilidad con
android.hardware.faketouch
. - [C-2-2] DEBE admitir el seguimiento distinto de dos o más entradas de puntero independientes.
Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.jazzhand
, hacen lo siguiente:
- [C-3-1] DEBE declarar compatibilidad con
android.hardware.faketouch
. - [C-3-2] DEBE admitir el seguimiento distinto de 5 (seguimiento de una mano de dedos) o más entradas de puntero de forma completamente independiente.
7.2.6. Compatibilidad con controles de juegos
7.2.6.1. Asignaciones de botones
Implementaciones de dispositivos:
- [C-1-1] DEBE ser capaz de asignar eventos HID a las constantes
InputEvent
correspondientes, como se indica en las tablas que aparecen a continuación. La implementación de Android upstream satisface este requisito.
Si las implementaciones de dispositivos incorporan un controlador o se envían con un controlador independiente en la caja que proporcionaría medios para ingresar todos los eventos que se enumeran en las siguientes tablas, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBE declarar la marca de función
android.hardware.gamepad
.
Botón | Uso de HID2 | Botón de Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
Pad direccional hacia arriba1 Pad direccional hacia abajo1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Pad direccional izquierdo1 Pad direccional derecho1 |
0x01 0x00393 | AXIS_HAT_X4 |
Botón del hombro izquierdo1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
Botón de hombro derecho1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
Hacer clic en el joystick izquierdo1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Presiona el joystick derecho1. | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
Atrás1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Los usos de HID anteriores deben declararse dentro de una AC de mando de juegos (0x01 0x0005).
3 Este uso debe tener un valor mínimo lógico de 0, un máximo lógico de 7, un valor 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 manecillas del reloj lejos del eje vertical. Por ejemplo, un valor lógico de 0 representa que no hay rotación y que se presiona el botón hacia arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionan las teclas hacia arriba y hacia la izquierda.
Controles analógicos1 | Uso de HID | Botón de Android |
---|---|---|
Gatillo izquierdo | 0x02 0x00C5 | AXIS_LTRIGGER |
Activador derecho | 0x02 0x00C4 | AXIS_RTRIGGER |
Joystick izquierdo | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
Joystick derecho | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7. Control remoto
Consulta la Sección 2.3.1 para conocer los requisitos específicos de los dispositivos.
7.3. Sensores
Si las implementaciones de dispositivos incluyen un tipo de sensor en 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 en 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 mostrar una lista precisa de los sensores compatibles a través de
SensorManager.getSensorList()
y métodos similares. - [C-0-3] DEBE comportarse de manera razonable para todas las demás APIs de sensores (por ejemplo, devolviendo
true
ofalse
según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamando a objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etcétera).
Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos, hacen lo siguiente:
- [C-1-1] DEBE informar todas las mediciones del sensor con los valores relevantes del Sistema Internacional de Unidades (métrica) para cada tipo de sensor, como se define en la documentación del SDK de Android.
- [C-1-2] DEBE informar los datos del sensor con una latencia máxima de 100 milisegundos + 2 × sample_time en el caso de una transmisión de sensor con una latencia máxima solicitada de 0 ms cuando el procesador de la aplicación está activo. Esta demora no incluye ninguna demora de filtrado.
- [C-1-3] DEBE informar la primera muestra del sensor en un plazo de 400 milisegundos + 2 * sample_time desde que se activa el sensor. Es aceptable que esta muestra tenga una exactitud de 0.
- [C-1-4] Para que cualquier API que indique la documentación del SDK de Android sea un sensor continuo, las implementaciones de dispositivos DEBEN proporcionar continuamente muestras de datos periódicos que DEBEN tener un jitter inferior al 3%, donde el jitter 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 impida que la CPU del dispositivo entre en un estado de suspensión o se active desde 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 sincroniza con el reloj SystemClock.elapsedRealtimeNano().
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que el error de sincronización de la marca de tiempo sea inferior a 100 milisegundos y DEBE ser inferior a 1 milisegundo.
- Cuando se activan varios sensores, el consumo de energía NO DEBE superar la suma del consumo de energía informado del sensor individual.
La lista anterior no es exhaustiva. Se debe considerar como fuente de autoridad el comportamiento documentado del SDK de Android y la documentación de código abierto de Android sobre sensores.
Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que tiene una API correspondiente para desarrolladores externos, hacen lo siguiente:
- [C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores y, luego, informar el valor a través del método de la API
Sensor.getResolution()
.
Algunos tipos de sensores son compuestos, lo que significa que se pueden obtener a partir de datos proporcionados por uno o más sensores. (entre los ejemplos, se incluyen el sensor de orientación y el sensor de aceleración lineal).
Implementaciones de dispositivos:
- DEBEN implementar estos tipos de sensores, cuando incluyan los sensores físicos previos como se describe en tipos de sensores.
Si las implementaciones de dispositivos incluyen un sensor compuesto, tienen las siguientes características:
- [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 en particular que tiene una API correspondiente para desarrolladores externos y el sensor solo informa un valor, las implementaciones de dispositivos hacen lo siguiente:
- [C-3-1] DEBE establecer la resolución en 1 para el sensor y, luego, informar el valor a través del método de la API
Sensor.getResolution()
.
Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor está expuesto a desarrolladores externos, estos deben hacer lo siguiente:
- [C-4-1] NO DEBE incluir ningún parámetro de calibración fijo determinado por la fábrica en los datos proporcionados.
Si las implementaciones de dispositivos incluyen una combinación de acelerómetro de 3 ejes, un sensor de giroscopio de 3 ejes o un sensor de magnetómetro, se consideran lo siguiente:
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que el acelerómetro, el giroscopio y el magnetómetro tengan una posición relativa fija, de modo que, si el dispositivo es transformable (p.ej., plegable), los ejes del sensor permanezcan alineados y sean coherentes con el sistema de coordenadas del sensor en todos los estados de transformación posibles del dispositivo.
7.3.1. Acelerómetro
Implementaciones de dispositivos:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un acelerómetro de 3 ejes.
Si las implementaciones de dispositivos incluyen un acelerómetro, tienen las siguientes características:
- [C-1-1] DEBE poder informar eventos hasta una frecuencia de, al menos, 50 Hz.
- [C-1-3] DEBEN cumplir con el sistema de coordenadas del sensor de Android como se detalla en las APIs de Android.
- [C-1-4] DEBE ser capaz de medir desde la caída libre hasta cuatro veces la gravedad(4 g) o más en cualquier eje.
- [C-1-5] DEBEN tener una resolución de al menos 12 bits.
- [C-1-6] DEBE tener una desviación estándar no superior a 0.05 m/s^2, en la que la desviación estándar se debe calcular por eje en muestras recopiladas durante un período de al menos 3 segundos con la tasa de muestreo más rápida.
- DEBE informar eventos de hasta 200 Hz como mínimo.
- DEBE tener una resolución de al menos 16 bits.
- DEBEN calibrarse durante el uso si las características cambian durante el ciclo de vida y se compensan, y deben conservar los parámetros de compensación entre los reinicios del dispositivo.
- DEBE tener compensación de temperatura.
Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, tienen las siguientes características:
- [C-2-1] DEBE implementar y generar informes sobre el sensor
TYPE_ACCELEROMETER
. - [C-SR-4] SE RECOMIENDA URGENTEMENTE implementar el sensor compuesto
TYPE_SIGNIFICANT_MOTION
. - [C-SR-5] SE RECOMIENDA URGENTEMENTE implementar y generar informes del sensor
TYPE_ACCELEROMETER_UNCALIBRATED
. Se RECOMIENDA ALTAMENTE que los dispositivos Android cumplan con este requisito para que puedan actualizarse a la versión futura de la plataforma en la que esto podría ser OBLIGATORIO. - DEBE implementar los sensores compuestos
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
yTYPE_STEP_COUNTER
como se describe en el documento del SDK de Android.
Si las implementaciones de dispositivos incluyen un acelerómetro con menos de 3 ejes, sucede lo siguiente:
- [C-3-1] DEBE implementar y generar informes sobre el sensor
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] SE RECOMIENDA_CON_MUCHÍSIMA_INSISTENCIA implementar y generar informes del sensor
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y se implementan cualquiera de los sensores compuestos TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
, TYPE_STEP_COUNTER
, haz lo siguiente:
- [C-4-1] La suma de su consumo de energía SIEMPRE DEBE ser inferior a 4 mW.
- DEBEN ser inferiores a 2 mW y 0.5 mW cuando el dispositivo está en condiciones dinámicas o estáticas.
Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor de giroscopio de 3 ejes, hacen lo siguiente:
- [C-5-1] DEBEN implementar los sensores compuestos
TYPE_GRAVITY
yTYPE_LINEAR_ACCELERATION
. - [C-SR-7] SE RECOMIENDA URGENTEMENTE implementar el sensor compuesto
TYPE_GAME_ROTATION_VECTOR
.
Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, un sensor de giroscopio de 3 ejes y un sensor de magnetómetro, hacen lo siguiente:
- [C-6-1] DEBE implementar un sensor compuesto
TYPE_ROTATION_VECTOR
.
7.3.2. Magnetómetro
Implementaciones de dispositivos:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un magnetómetro de 3 ejes (brújula).
Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, tienen las siguientes características:
- [C-1-1] DEBE implementar el sensor
TYPE_MAGNETIC_FIELD
. - [C-1-2] DEBE poder informar eventos hasta una frecuencia de al menos 10 Hz y DEBE informar eventos hasta al menos 50 Hz.
- [C-1-3] DEBEN cumplir con el sistema de coordenadas del sensor de Android como se detalla en las APIs de Android.
- [C-1-4] DEBE ser capaz de medir entre -900 µT y +900 µT en cada eje antes de saturarse.
- [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, si se coloca 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 más densa que 0.6 µT.
- [C-1-7] DEBE admitir la calibración y compensación en línea del sesgo de hierro duro y preservar los parámetros de compensación entre los reinicios del dispositivo.
- [C-1-8] DEBE aplicarse la compensación de hierro blando. La calibración se puede realizar durante el uso o la producción del dispositivo.
- [C-1-9] DEBE tener una desviación estándar, calculada por eje en las muestras recopiladas durante un período de al menos 3 segundos a la tasa de muestreo más rápida, no superior a 1.5 µT. DEBE tener una desviación estándar no superior 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, hacen lo siguiente:
- [C-2-1] DEBE implementar un sensor compuesto
TYPE_ROTATION_VECTOR
.
Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes y un acelerómetro, hacen lo siguiente:
- PUEDE implementar el sensor
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro y un sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR
, hacen lo siguiente:
- [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 ENFATICAMENTE que incluyas un receptor GPS/GNSS.
Si las implementaciones de dispositivos incluyen un receptor de GPS/GNSS y reportan la función a las aplicaciones a través de la marca de función android.hardware.location.gps
, hacen lo siguiente:
- [C-1-1] DEBE admitir salidas de ubicación a una velocidad de al menos 1 Hz cuando se solicite a través de
LocationManager#requestLocationUpdate
. - [C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, multitrayecto insignificante, HDOP inferior a 2) en un plazo de 10 segundos (tiempo rápido para la primera corrección), cuando esté conectado a una conexión a Internet de 0.5 Mbps o una velocidad de datos más rápida. Por lo general, este requisito se cumple con el uso de alguna forma de técnica de GPS/GNSS asistida o prevista para minimizar el tiempo de bloqueo del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y la efemerida o el reloj satelital).
- [C-1-6] Después de realizar ese cálculo de ubicación, las implementaciones de dispositivos DEBEN determinar su ubicación, en cielo abierto, en un plazo de 5 segundos, cuando se reinician las solicitudes de ubicación, hasta una hora después del cálculo de ubicación inicial, incluso cuando la solicitud posterior se realiza sin una conexión de datos o después de un ciclo de encendido.
En condiciones de cielo abierto después de determinar la ubicación, mientras esté detenido o se mueva con menos de 1 metro por segundo cuadrado de aceleración:
- [C-1-3] DEBEN poder determinar la ubicación dentro de un radio de 20 metros y la velocidad dentro de un radio de 0.5 metros por segundo, al menos, el 95% del tiempo.
- [C-1-4] DEBE realizar un seguimiento y generar informes de forma simultánea a través de
GnssStatus.Callback
de al menos 8 satélites de una constelación. - DEBE poder hacer un seguimiento simultáneo de al menos 24 satélites, de varias constelaciones (p.ej., GPS + al menos uno de Glonass, Beidou o Galileo).
[C-SR-2] SE RECOMIENDA URGENTEMENTE que se sigan proporcionando resultados de ubicación normales de GPS/GNSS a través de las APIs del proveedor de ubicación de GNSS durante una llamada telefónica de emergencia.
[C-SR-3] SE RECOMIENDA ENFATICAMENTE informar las mediciones de GNSS de todas las constelaciones a las que se les hace un seguimiento (como se informa en los mensajes de GnssStatus), a excepción de SBAS.
[C-SR-4] SE RECOMIENDA ENFATICAMENTE informar la AGC y la frecuencia de medición del GNSS.
[C-SR-5] SE RECOMIENDA ENFATICAMENTE 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 ENFATICAMENTE informar las mediciones de GNSS en cuanto se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.
[C-SR-7] SE RECOMIENDA ENFATICAMENTE informar las pseudorangos y las tasas de pseudorangos del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras se está inmóvil o se mueve con menos de 0.2 metros por segundo cuadrado de aceleración, son suficientes para calcular la posición dentro de 20 metros y la velocidad dentro de 0.2 metros por segundo, al menos el 95% del tiempo.
7.3.4. Giroscopio
Implementaciones de dispositivos:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un sensor de giroscopio.
Si las implementaciones de dispositivos incluyen un giroscopio, tienen las siguientes características:
- [C-1-1] DEBE poder informar eventos hasta una frecuencia de, al menos, 50 Hz.
- [C-1-4] DEBE tener una resolución de 12 bits o más.
- [C-1-5] DEBEN tener compensación de temperatura.
- [C-1-6] DEBEN calibrarse y compensarse durante el uso, y preservar los parámetros de compensación entre los reinicios del dispositivo.
- [C-1-7] DEBE tener una variación no superior a 1e-7 rad^2 / s^2 por Hz (variación por Hz o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero DEBE estar restringida por este valor. En otras palabras, si mides la varianza del giroscopio a una tasa de muestreo de 1 Hz, NO DEBE ser mayor que 1e-7 rad^2/s^2.
- [C-SR-2] SE RECOMIENDA ENFÉCTIVAMENTE que el error de calibración sea inferior a 0.01 rad/s cuando el dispositivo está inmóvil a temperatura ambiente.
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE que tengan una resolución de 16 bits o más.
- DEBE informar eventos de hasta 200 Hz como mínimo.
Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, tienen las siguientes características:
- [C-2-1] DEBE implementar el sensor
TYPE_GYROSCOPE
. - [C-SR-4] Se recomienda implementar el sensor
TYPE_GYROSCOPE_UNCALIBRATED
.
Si las implementaciones de dispositivos incluyen un giroscopio con menos de 3 ejes, sucede lo siguiente:
- [C-3-1] DEBE implementar y generar informes sobre el sensor
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] SE RECOMIENDA URGENTEMENTE implementar y generar informes del sensor
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, un sensor de acelerómetro y un sensor de magnetómetro, hacen lo siguiente:
- [C-4-1] DEBE implementar un sensor compuesto
TYPE_ROTATION_VECTOR
.
Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor de giroscopio de 3 ejes, hacen lo siguiente:
- [C-5-1] DEBEN implementar los sensores compuestos
TYPE_GRAVITY
yTYPE_LINEAR_ACCELERATION
. - [C-SR-6] SE RECOMIENDA URGENTEMENTE implementar el sensor compuesto
TYPE_GAME_ROTATION_VECTOR
.
7.3.5. Barómetro
Implementaciones de dispositivos:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que incluyas un barómetro (sensor de presión atmosférica ambiental).
Si las implementaciones de dispositivos incluyen un barómetro, hacen lo siguiente:
- [C-1-1] DEBE implementar y generar informes sobre el sensor
TYPE_PRESSURE
. - [C-1-2] DEBE poder entregar eventos a 5 Hz o más.
- [C-1-3] DEBEN tener compensación de temperatura.
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que se puedan informar mediciones de presión en el rango de 300 hPa a 1100 hPa.
- DEBE tener una precisión absoluta de 1 hPa.
- DEBE tener una precisión relativa de 0.12 hPa en un rango de 20 hPa (equivalente a una precisión de aproximadamente 1 m en un cambio de aproximadamente 200 m sobre el nivel del mar).
7.3.6. Termómetro
Si las implementaciones de dispositivos incluyen un termómetro ambiente (sensor de temperatura), hacen lo siguiente:
- [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 o cabina del vehículo) desde la que 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, sucede lo siguiente:
- [C-2-1] NO DEBE definir
SENSOR_TYPE_AMBIENT_TEMPERATURE
para el sensor de temperatura.
Si las implementaciones de dispositivos incluyen un sensor para supervisar la temperatura de la piel, hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA URGENTEMENTE que admitas la API de PowerManager.getThermalHeadroom.
7.3.7. Fotómetro
- Las implementaciones de dispositivos PUEDEN incluir un fotómetro (sensor de luz ambiente).
7.3.8. Sensor de proximidad
- Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad.
Si las implementaciones de dispositivos incluyen un sensor de proximidad y solo informan una lectura binaria de "cerca" o "lejos", hacen lo siguiente:
- [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 el objetivo principal de este tipo de sensor es detectar un teléfono que el usuario está usando. Si las implementaciones de dispositivos incluyen un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API.
- [C-1-2] DEBEN tener 1 bit de precisión o más.
- [C-1-3] DEBE usar 0 centímetros como la lectura cercana y 5 centímetros como la lectura lejana.
- [C-1-4] DEBE informar un rango y una 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 apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE identificar la capability a través de la marca de función
android.hardware.sensor.hifi_sensors
.
Si las implementaciones de dispositivos declaran android.hardware.sensor.hifi_sensors
, hacen lo siguiente:
[C-2-1] DEBE tener un sensor
TYPE_ACCELEROMETER
que cumpla con los siguientes requisitos:- DEBE tener un rango de medición de al menos -8 g y +8 g, y se RECOMIENDA ENFATICAMENTE que tenga un rango de medición de al menos -16 g y +16 g.
- DEBE tener una resolución de medición de al menos 2,048 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 no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 3,000 eventos del sensor.
- DEBE tener un consumo de energía por lotes no superior a 3 mW.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE 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 caminata aleatoria de aceleración inferior a 30 μg √Hz probada a temperatura ambiente.
- DEBE tener un cambio de sesgo en relación con la temperatura de ≤ ± 1 mg/°C.
- DEBE tener una no linealidad de la línea de mejor ajuste de ≤ 0.5% y un cambio de sensibilidad en función de la temperatura de ≤ 0.03%/°C.
- DEBE tener una sensibilidad en los ejes cruzados inferior al 2.5 % y una variación de sensibilidad en los ejes cruzados inferior al 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 queTYPE_ACCELEROMETER
.[C-2-3] DEBE tener un sensor
TYPE_GYROSCOPE
que cumpla con los siguientes requisitos:- DEBE tener un rango de medición de al menos -1,000 y +1,000 dps.
- DEBE tener una resolución de medición de al menos 16 LSB/dps.
- DEBE tener una frecuencia de medición mínima de 12.5 Hz o 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 ENFATICAMENTE 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 caminata aleatoria de tasa inferior a 0.001 °/s √Hz probada a temperatura ambiente.
- DEBE tener un cambio de sesgo en función de la temperatura de ≤ +/- 0.05 °/ s / °C.
- DEBE tener un cambio de sensibilidad en función de la temperatura de ≤ 0.02% / °C.
- DEBE tener una no linealidad de la 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 el rango de temperatura de 10 a 40 °C cuando el dispositivo está inmóvil.
- DEBE tener una sensibilidad a la gravedad inferior a 0.1°/s/g.
- DEBE tener una sensibilidad en los ejes cruzados inferior al 4.0 % y una variación de sensibilidad en los ejes cruzados inferior al 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 queTYPE_GYROSCOPE
.[C-2-5] DEBE tener un sensor
TYPE_GEOMAGNETIC_FIELD
que cumpla con los siguientes requisitos:- DEBEN tener un rango de medición de al menos -900 y +900 μT.
- DEBE tener una resolución de medición de al menos 5 LSB/uT.
- DEBEN tener una frecuencia de medición mínima de 5 Hz o menos.
- DEBEN tener una frecuencia de medición máxima de 50 Hz o superior.
- 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 queTYPE_GEOMAGNETIC_FIELD
y, además, cumplir con lo siguiente:- DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 600 eventos del sensor.
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE tener un espectro de ruido blanco de 1 Hz a al menos 10 Hz cuando la tasa de informes es de 50 Hz o superior.
[C-2-7] DEBE tener un sensor
TYPE_PRESSURE
que cumpla con los siguientes requisitos:- DEBE tener un rango de medición de al menos 300 y 1100 hPa.
- DEBE tener una resolución de medición de al menos 80 LSB/hPa.
- DEBEN tener una frecuencia de medición mínima de 1 Hz o menos.
- DEBEN tener una frecuencia de medición máxima de 10 Hz o superior.
- DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
- DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 300 eventos del sensor.
- DEBE tener un consumo de energía por lotes no superior 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 cumpla con los siguientes requisitos:- DEBE tener un consumo de energía no superior 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 cumpla con los siguientes requisitos:- DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 100 eventos del sensor.
- DEBE tener un consumo de energía no superior 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 superior a 4 mW.
[C-2-11] DEBE tener un sensor
TYPE_STEP_COUNTER
que cumpla con los siguientes requisitos:- DEBE tener un consumo de energía no superior 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 cumpla con los siguientes requisitos:- DEBE tener un consumo de energía no superior 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 evento del mismo evento físico que informan el acelerómetro, el giroscopio y el magnetómetro DEBEN estar dentro de un rango de 2.5 milisegundos entre sí. La marca de tiempo del evento del mismo evento físico que informan el acelerómetro y el giroscopio DEBE estar dentro de 0.25 milisegundos entre sí.
[C-2-14] DEBEN 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 en un plazo de 5 milisegundos a partir del momento en que los datos están disponibles en cualquiera de los sensores físicos anteriores a la aplicación.
[C-2-16] NO DEBE tener un consumo de energía superior a 0.5 mW cuando el dispositivo está estático y 2.0 mW cuando el dispositivo está en movimiento cuando se habilita cualquier combinación de los siguientes sensores:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] PUEDE tener un sensor
TYPE_PROXIMITY
, pero, si está presente, DEBE tener una capacidad mínima de búfer de 100 eventos del sensor.
Ten en cuenta que todos los requisitos de consumo de energía de esta sección no incluyen el consumo de energía del procesador de aplicaciones. Incluye la energía que consume toda la cadena de sensores: el sensor, cualquier circuito de soporte, cualquier sistema de procesamiento de sensores dedicado, etcétera.
Si las implementaciones de dispositivos incluyen compatibilidad directa con sensores, tienen las siguientes características:
- [C-3-1] DEBE declarar correctamente la compatibilidad con los tipos de canales directos y el nivel de tasas de informes directos a través de las APIs de
isDirectChannelTypeSupported
ygetHighestDirectReportRateLevel
. - [C-3-2] DEBE admitir al menos uno de los dos tipos de canales directos del sensor para todos los sensores que declaren compatibilidad con el canal directo del sensor.
- DEBE admitir informes de eventos a través del canal directo del sensor para el sensor principal (variante sin activación) de los siguientes tipos:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Sensores biométricos
Para obtener más información sobre la medición de la seguridad del desbloqueo biométrico, consulta la documentación de medición de la seguridad biométrica.
Si las implementaciones de dispositivos incluyen una pantalla de bloqueo segura, tienen las siguientes características:
- DEBE incluir un sensor biométrico
Los sensores biométricos se pueden clasificar como clase 3 (antes seguro), clase 2 (antes no seguro) o clase 1 (antes conveniencia) según sus tasas de aceptación de falsificación y suplantación de identidad, y la seguridad de la canalización 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 deben cumplir con requisitos adicionales, como se detalla a continuación, si desean clasificarse como clase 1, clase 2 o clase 3. Tanto los datos biométricos de clase 2 como los 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, hacen lo siguiente:
- [C-4-1] DEBE cumplir con los requisitos de los métodos 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 Authenticators y cualquier combinación de esta. Por el contrario, NO DEBE respetar ni reconocer constantes de números enteros que se pasen a los métodos canAuthenticate(int) y setAllowedAuthenticators(int), excepto las que se documenten como constantes públicas en Authenticators y cualquier combinación de ellas.
- [C-4-3] DEBE implementar la acción ACTION_BIOMETRIC_ENROLL en dispositivos que tengan biometría de clase 3 o clase 2. Esta acción SOLO DEBE presentar los puntos de entrada de inscripción para la biometría de clase 3 o clase 2.
Si las implementaciones de dispositivos admiten la biometría pasiva, tienen las siguientes características:
- [C-5-1] DEBE requerir, de forma predeterminada, un paso de confirmación adicional (p.ej., presionar un botón).
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que se establezca un parámetro de configuración para permitir que los usuarios anulen la preferencia de la aplicación y siempre requieran el paso de confirmación correspondiente.
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que la acción de confirmación esté protegida de modo que un compromiso del sistema operativo o del kernel 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 (GPIO) de uso general solo de entrada de un elemento seguro (SE) que no se puede activar de ninguna otra manera que no sea presionando un botón físico.
- [C-5-2] Además, DEBE implementar un flujo de autenticación implícito (sin paso de confirmación) que corresponda a setConfirmationRequired(boolean), que las aplicaciones pueden configurar para usar en los flujos de acceso.
Si las implementaciones de dispositivos tienen varios sensores biométricos, deben cumplir con los siguientes requisitos:
Cómo iniciar nuevos requisitos
[C-7-1] Cuando un dato biométrico está bloqueado (es decir, está inhabilitado hasta que el usuario lo desbloquea con la autenticación principal) o bloqueado por un período determinado (es decir, el dato biométrico está inhabilitado temporalmente hasta que el usuario espera un intervalo de tiempo) debido a demasiados intentos fallidos, también se deben bloquear todos los demás datos biométricos de una clase biométrica inferior. En el caso del bloqueo por tiempo limitado, el tiempo de retirada para la verificación biométrica DEBE ser el tiempo de retirada máximo de todas las biometrías en el bloqueo por tiempo limitado.
[C-SR-12] SE RECOMIENDA ENFATICAMENTE que, cuando un dato biométrico esté bloqueado (es decir, el dato biométrico esté inhabilitado hasta que el usuario lo desbloquee con la autenticación principal) o bloqueado por un período determinado (es decir, el dato biométrico esté inhabilitado temporalmente hasta que el usuario espere un intervalo de tiempo) debido a demasiados intentos fallidos, también se bloqueen todos los demás datos biométricos de la misma clase. En el caso del bloqueo por tiempo limitado, se RECOMIENDA ENFÉMTICAMENTE que el tiempo de retirada para la verificación biométrica sea el tiempo de retirada máximo de todas las biometrías en el bloqueo por tiempo limitado.
[C-7-2] DEBEN solicitarle al usuario la autenticación principal recomendada (p. ej., PIN, patrón o contraseña) para restablecer el contador de bloqueo de un dato biométrico bloqueado. Es POSIBLE que se permita que los datos biométricos de clase 3 restablezcan el contador de bloqueo de un dato biométrico bloqueado de la misma clase o inferior. Los datos biométricos de clase 2 o clase 1 NO DEBEN permitir completar una operación de bloqueo de restablecimiento para ningún dato biométrico.
Fin de los nuevos requisitos
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE que se requiera que se confirme solo un dato biométrico por autenticación (p.ej., si los sensores de huellas dactilares y de rostro están disponibles en el dispositivo, 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 las aplicaciones de terceros, deben cumplir con los siguientes requisitos:
- [C-6-1] DEBEN cumplir con los requisitos de la clase 3, como se define en esta sección a continuación.
- [C-6-2] DEBE presentar solo biometría de clase 3 cuando la autenticación requiera BIOMETRIC_STRONG o se invoque la autenticación con un CryptoObject.
Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 1 (antes Conveniencia), deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0.002%.
- [C-1-2] DEBEN divulgar que este modo puede ser menos seguro que un PIN, un patrón o una contraseña seguros, y enumerar claramente los riesgos de habilitarlo, si los porcentajes de aceptación de falsificaciones y de impostores son superiores al 7%, según lo miden los protocolos de prueba de biometría de Android.
- [C-1-9] DEBE solicitarle al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) después de no más de veinte intentos falsos y no menos de noventa segundos de tiempo de resguardo para la verificación biométrica, en el que un intento falso es uno con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con una biométrica registrada.
- [C-SR-4] SE RECOMIENDA URGENTEMENTE reducir la cantidad total de pruebas falsas para la verificación biométrica especificada en [C-1-9] si los porcentajes de aceptación de falsificaciones y suplantación de identidad son superiores al 7%, según lo miden los protocolos de prueba de biometría de Android.
- [C-1-3] DEBE limitar la tasa de intentos de verificación biométrica, en los que una prueba falsa es aquella que tiene una calidad de captura adecuada (
BIOMETRIC_ACQUIRED_GOOD
) que no coincide con una biométrica registrada. - [C-SR-5] SE RECOMIENDA ENFATICAMENTE que se limite la frecuencia de los intentos durante al menos 30 segundos después de cinco intentos falsos de verificación biométrica para la cantidad máxima de intentos falsos por [C-1-9], en los que un intento falso es uno con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con una biométrica registrada.
- [C-SR-6] SE RECOMIENDA ENFATICAMENTE que toda la lógica de limitación de frecuencia esté en TEE.
[C-1-10] DEBE inhabilitar la biometría una vez que se active por primera vez la retirada de la autenticación principal, como se describe en [C-0-2] de la sección 9.11.
[C-1-11] DEBE tener una tasa de aceptación de falsificación y falsificación no superior al 30%, con (1) una tasa de aceptación de falsificación y falsificación para las especies de instrumento de ataque de presentación (PAI) de nivel A no superior al 30% y (2) una tasa de aceptación de falsificación y falsificación de especies de PAI de nivel B no superior al 40%, según lo miden los protocolos de prueba de biometría de Android.
[C-1-4] DEBE evitar que se agreguen datos biométricos nuevos sin establecer primero una cadena de confianza, lo que implica que el usuario debe confirmar la credencial existente o agregar una nueva (PIN, patrón o contraseña) del dispositivo que esté protegida por el TEE. La implementación del proyecto de código abierto de Android proporciona el mecanismo en el framework para hacerlo.
[C-1-5] DEBEN quitar por completo todos los datos biométricos identificables de un usuario cuando se quita su cuenta (incluso mediante un restablecimiento de la configuración de fábrica).
[C-1-6] DEBE respetar la marca individual de ese dato biométrico (es decir,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
oDevicePolicymanager.KEYGUARD_DISABLE_IRIS
).[C-1-7] DEBEN solicitarle al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 24 horas o menos. Nota: Los dispositivos que se actualizan desde Android 9 o versiones anteriores DEBEN solicitarle al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 72 horas o menos.
[C-1-8] DEBE solicitarle al usuario la autenticación principal recomendada (p. ej., PIN, patrón o contraseña) o la biométrica de clase 3 (SEGURA) después de una de las siguientes situaciones:
- un tiempo de espera de inactividad de 4 horas
- 3 intentos fallidos de autenticación biométrica
- El tiempo de espera de inactividad y el recuento de autenticación fallida se restablecen después de una confirmación correcta de las credenciales del dispositivo. Nota: Es POSIBLE que los dispositivos que se actualizan desde Android 9 o versiones anteriores estén exentos de C-1-8.
[C-SR-7] SE RECOMIENDA ENFATICAMENTE usar la lógica del framework que proporciona el Proyecto de código abierto de Android para aplicar las restricciones especificadas en [C-1-7] y [C-1-8] para dispositivos nuevos.
[C-SR-8] SE RECOMIENDA ENFÉCTIVAMENTE tener una tasa de rechazo falsa inferior al 10%, como se mide en el dispositivo.
[C-SR-9] SE RECOMIENDA ENFATICAMENTE tener una latencia inferior a 1 segundo, medida desde el momento en que se detecta la información biométrica hasta que se desbloquea la pantalla, para cada dato biométrico registrado.
Cómo iniciar nuevos requisitos
[C-1-12] DEBE tener una tasa de aceptación de falsificación y suplantación no superior al 40% por tipo de instrumento de ataque de presentación (PAI), según lo mida el Protocolo de prueba de biometría de Android.
[C-SR-13] SE RECOMIENDA ENFATICAMENTE que tengas una tasa de aceptación de falsificación y robo de identidad no superior al 30% por tipo de instrumento de ataque de presentación (PAI), como se mide en los protocolos de prueba de biometría de Android.
[C-SR-14] SE RECOMIENDA URGENTEMENTE divulgar la clase biométrica del sensor biométrico y los riesgos correspondientes de habilitarlo.
[C-SR-17] SE RECOMIENDA URGENTEMENTE implementar las nuevas interfaces de AIDL (como
IFace.aidl
yIFingerprint.aidl
).
Fin de los nuevos requisitos
Si las implementaciones de dispositivos desean tratar un sensor biométrico como clase 2 (antes no seguro), deben cumplir con los siguientes requisitos:
[C-2-1] DEBEN cumplir con todos los requisitos de la clase 1 anteriores.
[C-2-2] DEBE tener una tasa de aceptación de falsificación y robo de identidad no superior al 20%, con (1) una tasa de aceptación de falsificación y robo de identidad para las especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 20% y (2) una tasa de aceptación de falsificación y robo de identidad de las especies de PAI de nivel B no superior al 30%, según se mide en los protocolos de prueba de biometría de Android.
Cómo iniciar nuevos requisitos
- [C-SR-15] SE RECOMIENDA ENFÉCTIVAMENTE que tengas una tasa de aceptación de falsificación y falsificación no superior al 20% por tipo de instrumento de ataque de presentación (PAI), según lo mida el Protocolo de prueba de biometría de Android.
Fin de los nuevos requisitos
- [C-2-3] DEBE realizar la coincidencia biométrica en un entorno de ejecución aislado fuera del espacio del usuario o del kernel de Android, como el entorno de ejecución confiable (TEE),
oen un chip con un canal seguro al entorno de ejecución aislado o en una máquina virtual protegida que cumpla con los requisitos de la Sección 9.17. - [C-2-4] DEBEN tener todos los datos identificables encriptados y autenticados de manera criptográfica, de modo que no se puedan adquirir, leer ni alterar fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado, como se documenta en los lineamientos de implementación en el sitio del proyecto de código abierto de Android o una máquina virtual protegida controlada por un hipervisor que cumpla con los requisitos del artículo 9.17.
- [C-2-5] En el caso de los datos biométricos basados en la cámara, mientras se realiza la autenticación o inscripción basada en datos biométricos, ocurre lo siguiente:
- DEBEN operar la cámara en un modo que evite que los fotogramas de la cámara se lean o alteren fuera del entorno de ejecución aislado o un chip con un canal seguro al entorno de ejecución aislado o una máquina virtual protegida controlada por un hipervisor que cumpla con los requisitos del artículo 9.17.
- En el caso de las soluciones de una sola cámara RGB, los fotogramas de la cámara PUEDEN ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa de la inscripción, pero NO DEBEN ser alterables.
- [C-2-6] NO DEBE permitir que las aplicaciones de terceros distingan entre inscripciones biométricas individuales.
- [C-2-7] NO DEBE permitir el acceso no encriptado a datos biométricos identificables ni a ningún dato derivado de ellos (como incorporaciones) al procesador de aplicaciones fuera del contexto del TEE o la máquina virtual protegida controlada por el hipervisor que cumpla con los requisitos del artículo 9.17. Los dispositivos que se actualizan desde Android 9 o versiones anteriores no están exentos de C-2-7.
[C-2-8] DEBE tener una canalización de procesamiento segura de modo que una vulneración del sistema operativo o del kernel no pueda permitir que se inyecten datos directamente para autenticarse como el usuario de forma falsa. Nota: Si las implementaciones de dispositivos ya se lanzaron en Android 9 o versiones anteriores y no pueden cumplir con el requisito C-2-8 a través de una actualización de software del sistema, es POSIBLE que se eximan del requisito.
[C-SR-10] SE RECOMIENDA ENFATICAMENTE que se incluya la detección de estado activo para todas las modalidades biométricas y la detección de atención para la biometría facial.
[C-2-9] DEBE poner el sensor biométrico a disposición de las aplicaciones de terceros.
Si las implementaciones de dispositivos desean tratar un sensor biométrico como clase 3 (antes seguro), deben cumplir con los siguientes requisitos:
- [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 con copia de seguridad en hardware.
- [C-3-3] DEBE tener una tasa de aceptación de falsificación y falsificación no superior al 7%, con (1) una tasa de aceptación de falsificación y falsificación para las especies de instrumentos de ataque de presentación (PAI) de nivel A no superior al 7% y (2) una tasa de aceptación de falsificación y falsificación de especies de PAI de nivel B no superior al 20%, según lo miden los protocolos de prueba de biometría de Android.
- [C-3-4] DEBE solicitarle al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 72 horas o menos.
- [C-3-5] SE DEBE volver a generar el ID de autenticador para todos los datos biométricos de clase 3 compatibles con el dispositivo si alguno de ellos se vuelve a inscribir.
- [C-3-6] Se deben habilitar las claves del almacén de claves con respaldo biométrico para las aplicaciones de terceros.
Cómo iniciar nuevos requisitos
- [C-SR-16] SE RECOMIENDA ENFATICAMENTE que tengas una tasa de aceptación de falsificación y robo de identidad no superior al 7% por tipo de instrumento de ataque de presentación (PAI), según lo mida el Protocolo de prueba de biometría de Android.
Fin de los nuevos requisitos
Si las implementaciones de dispositivos contienen un sensor de huellas dactilares ubicado debajo de la pantalla (UDFPS), hacen lo siguiente:
- [C-SR-11] SE RECOMIENDA ENFATICAMENTE evitar que el área táctil de la UDFPS interfiera con la navegación de 3 botones (que algunos usuarios podrían necesitar por motivos de accesibilidad).
7.3.11. Sensor de pose
Implementaciones de dispositivos:
- PUEDE admitir un sensor de pose con 6 grados de libertad.
Si las implementaciones de dispositivos admiten el sensor de pose con 6 grados de libertad, hacen lo siguiente:
- [C-1-1] DEBE implementar y generar informes sobre el sensor
TYPE_POSE_6DOF
. - [C-1-2] DEBE ser más preciso que el vector de rotación solo.
7.3.12. Sensor de ángulo de bisagra
Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra, hacen lo siguiente:
- [C-1-1] DEBEN implementar y generar informes sobre
TYPE_HINGLE_ANGLE
. - [C-1-2] DEBE admitir al menos dos lecturas entre 0 y 360 grados (inclusive, es decir, incluidos 0 y 360 grados).
- [C-1-3] DEBE mostrar un sensor de activación para
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.15.4 (UWB)
Si las implementaciones de dispositivos incluyen compatibilidad con 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, hacen lo siguiente:
Cómo iniciar nuevos requisitos
- [C-1-2] DEBE informar la marca de función de hardware
android.hardware.uwb
. - [C-1-3] DEBE admitir todos los siguientes conjuntos de parámetros de configuración (combinaciones predefinidas de parámetros de FIRA UCI) definidos en la implementación de AOSP.
CONFIG_ID_1
: RangoSTATIC STS DS-TWR
de unidifusión definido por FiRa, modo diferido, intervalo de rango de 240 ms.CONFIG_ID_2
: RangoSTATIC STS DS-TWR
de uno a muchos definido por FiRa, modo diferido, intervalo de rango de 200 ms. Caso de uso típico: un teléfono inteligente interactúa con muchos dispositivos inteligentes.CONFIG_ID_3
: Igual queCONFIG_ID_1
, excepto que no se informan los datos del ángulo de llegada (AoA).CONFIG_ID_4
: Igual queCONFIG_ID_1
, excepto que el modo de seguridad de P-STS está habilitado.CONFIG_ID_5
: Igual queCONFIG_ID_2
, excepto que el modo de seguridad de P-STS está habilitado.CONFIG_ID_6
: Igual queCONFIG_ID_3
, excepto que el modo de seguridad de P-STS está habilitado.CONFIG_ID_7
: Igual queCONFIG_ID_2
, excepto que está habilitado el modo de clave de control individual de P-STS.
- [C-1-4] DEBE proporcionar una indicación visual para que el usuario pueda activar o desactivar el estado de la radio UWB.
- [C-1-5] DEBEN aplicar que las apps que usan radio UWB tengan el permiso
UWB_RANGING
(en el grupo de permisosNEARBY_DEVICES
).
Pasar las pruebas de certificación y conformidad relevantes definidas por las organizaciones de estándares, como FIRA, CCC y CSA, ayuda a garantizar que 802.1.15.4 funcione correctamente.
Fin de los nuevos requisitos
7.4. Conectividad de datos
7.4.1. Telefonía
El término "telefonía", tal como lo usan las APIs de Android y este documento, hace referencia específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS , o la configuración de datos móviles a través de una red móvil (p.ej., GSM, CDMA, LTE, NR). Un dispositivo compatible con "Telefonía" puede ofrecer algunos o todos los servicios de llamadas, mensajes y datos según corresponda al producto.
a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no tener conmutación de paquetes,para Android se consideran independientes de cualquier conectividad de datos que se pueda implementar con la misma red. En otras palabras,las APIs y la funcionalidad de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si usan una red móvil para la conectividad de datos.
- ES POSIBLE usar Android 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, tienen las siguientes características:
- [C-1-1] DEBE declarar la marca de función
android.hardware.telephony
y otras marcas de subfunción según la tecnología. - [C-1-2] DEBEN implementar la compatibilidad total con la API de esa tecnología.
- DEBE permitir todos los tipos de servicios de telefonía celular disponibles (2G, 3G, 4G, 5G, etc.) durante las llamadas de emergencia (independientemente de los tipos de red que establezca
SetAllowedNetworkTypeBitmap()
).
Si las implementaciones de dispositivos no incluyen hardware de telefonía, sucede lo siguiente:
- [C-2-1] DEBEN implementar las APIs completas como no-ops.
Si las implementaciones de dispositivos admiten eUICC o eSIM/SIM incorporadas y, además, incluyen un mecanismo propietario para que la funcionalidad de eSIM esté disponible para desarrolladores externos, deben cumplir con los siguientes requisitos:
- [C-3-1] DEBE declarar la marca de función
android.hardware.telephony.euicc
.
Si las implementaciones de dispositivos no establecen la propiedad del sistema ro.telephony.iwlan\_operation\_mode
como "heredada", sucede lo siguiente:
- [C-4-1] NO DEBE informar "NETWORK_TYPE_IWLAN" a través de NetworkRegistrationInfo#getAccessNetworkTechnology() cuando NetworkRegistrationInfo#getTransportType() se informa como "TRANSPORT_TYPE_WWAN" para la misma instancia de NetworkRegistrationInfo.
Si las implementaciones de dispositivos admiten un solo registro de subsistema multimedia IP (IMS) para las funciones de servicio de telefonía multimedia (MMTEL) y de servicio de comunicación enriquecida (RCS) y se espera que cumplan con los requisitos de los operadores de telefonía celular en relación con el uso de un solo registro de IMS para todo el tráfico de señalización de IMS, deben cumplir con lo siguiente:
- [C-5-1] DEBES declarar la marca de función
android.hardware.telephony.ims
y proporcionar una implementación completa de la API de ImsService para MMTEL y la API de User Capability Exchange de RCS. - [C-5-2] DEBES declarar la marca de función
android.hardware.telephony.ims.singlereg
y proporcionar una implementación completa de la API de SipTransport, la API de GbaService, las indicaciones de portador dedicadas con el HAL de IRadio 1.6 y el aprovisionamiento a través del servidor de configuración automática (ACS) o algún otro mecanismo de aprovisionamiento propietario con la API de configuración de IMS.
Si las implementaciones de dispositivos informan la función android.hardware.telephony
, haz lo siguiente:
- [C-6-1]
SmsManager#sendTextMessage
ySmsManager#sendMultipartTextMessage
DEBEN generar las llamadas correspondientes aCarrierMessagingService
para proporcionar la funcionalidad de mensajería de texto.SmsManager#sendMultimediaMessage
ySmsManager#downloadMultimediaMessage
DEBEN generar las llamadas correspondientes aCarrierMessagingService
para proporcionar la funcionalidad de mensajería multimedia. - [C-6-2] La aplicación designada por
android.provider.Telephony.Sms#getDefaultSmsPackage
DEBE usar las APIs de SmsManager cuando envíe y reciba mensajes SMS y MMS. La implementación de referencia de AOSP en paquetes, apps o Mensajes cumple con este requisito. - [C-6-3] La aplicación que responde a
Intent#ACTION_DIAL
DEBE admitir la entrada de códigos de marcado arbitrarios con el formato*#*#CODE#*#*
y activar una transmisiónTelephonyManager#ACTION_SECRET_CODE
correspondiente. - [C-6-4] La aplicación que responde a
Intent#ACTION_DIAL
DEBE usarVoicemailContract.Voicemails#TRANSCRIPTION
para mostrar la transcripción del buzón de voz visual a los usuarios si admite transcripciones de este tipo. - [C-6-5] DEBE representar todos los SubscriptionInfo con UUIDs de grupo equivalentes como una sola suscripción en todos los indicadores visibles para el usuario que muestren y controlen la información de la tarjeta SIM. Algunos ejemplos de tales indicaciones visuales incluyen interfaces de configuración que coinciden con
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
oEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] NO DEBE mostrar ni permitir el control de ningún SubscriptionInfo con un UUID de grupo no nulo y un bit oportunista en ningún elemento visual visible para el usuario que permita la configuración o el control de la configuración de la tarjeta SIM.
Si las implementaciones de dispositivos informan la función android.hardware.telephony
y proporcionan una barra de estado del sistema, haz lo siguiente:
- [C-7-1] DEBE seleccionar una suscripción activa representativa para un UUID de grupo determinado para mostrarle al usuario cualquier indicación que proporcione información sobre el estado de la SIM. Algunos ejemplos de tales indicaciones visuales incluyen el ícono de señal celular de la barra de estado o la tarjeta de configuración rápida.
- [C-SR-1] SE RECOMIENDA ENFÉMTICAMENTE que la suscripción representativa sea la suscripción de datos activa, a menos que el dispositivo esté en una llamada de voz, durante la cual SE RECOMIENDA ENFÉMTICAMENTE que la suscripción representativa sea la suscripción de voz activa.
Si las implementaciones de dispositivos informan la función android.hardware.telephony
, haz lo siguiente:
- [C-6-7] DEBE ser capaz de abrir y usar de forma simultánea la cantidad máxima de canales lógicos (20 en total) para cada UICC según ETSI TS 102 221.
- [C-6-8] NO DEBE aplicarse ninguno de los siguientes comportamientos a las apps de operadores activos (como lo designa
TelephonyManager#getCarrierServicePackageName
) automáticamente ni sin la confirmación explícita del usuario:- Cómo revocar o limitar el acceso a la red
- Cómo revocar permisos
- Restringe la ejecución de apps en primer o segundo plano más allá de las funciones de administración de energía existentes incluidas en AOSP.
- Inhabilita o desinstala la app
Si las implementaciones de dispositivos informan la función android.hardware.telephony
y todas las suscripciones activas no oportunistas que comparten un UUID de grupo están inhabilitadas, se quitan físicamente del dispositivo o se marcan como oportunistas, el dispositivo hace lo siguiente:
- [C-8-1] DEBE inhabilitar automáticamente todas las suscripciones oportunistas activas restantes en el mismo grupo.
Si las implementaciones de dispositivos incluyen telefonía GSM, pero no telefonía CDMA, sucede lo siguiente:
- [C-9-1] NO DEBE declarar
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] DEBE generar un
IllegalArgumentException
cuando se intente establecer cualquier tipo de red 3GPP2 en las máscaras de bits de tipo de red preferidas o permitidas. - [C-9-3] DEBE mostrar una cadena vacía de
TelephonyManager#getMeid
.
Si las implementaciones de dispositivos admiten eUICC con varios puertos y perfiles, hacen lo siguiente:
- [C-10-1] DEBE declarar la marca de función
android.hardware.telephony.euicc.mep
.
7.4.1.1. Compatibilidad con el bloqueo de números
Si las implementaciones de dispositivos informan la función android.hardware.telephony.calling
, hacen lo siguiente:
- [C-1-1] DEBE incluir compatibilidad con el bloqueo de números.
- [C-1-2] DEBE implementar por completo
BlockedNumberContract
y la API correspondiente, como se describe en la documentación del SDK. [C-1-3] DEBE bloquear todas las llamadas y los mensajes de un número de teléfono en 'BlockedNumberProvider' sin ninguna interacción con las apps. La única excepción es cuando se levanta temporalmente el bloqueo de números, como se describe en la documentación del SDK.
[C-1-4] DEBE escribir en el proveedor de registros de llamadas de la plataforma para una llamada bloqueada y DEBE filtrar las llamadas con
BLOCKED_TYPE
de la vista predeterminada del registro de llamadas en la app de marcador preinstalada.[C-1-5] NO DEBE escribirle al Proveedor de telefonía para un mensaje bloqueado.
[C-1-6] DEBE implementar una IU de administración de números bloqueados, que se abre con el intent que muestra 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 de Android supone que el usuario principal tiene el control total de los servicios de telefonía, una sola instancia, en el dispositivo. TODA la IU relacionada con el bloqueo DEBE ocultarse para los usuarios secundarios, y la lista de bloqueos DEBE respetarse.
DEBE migrar los números bloqueados al proveedor cuando un dispositivo se actualiza a Android 7.0.
DEBE proporcionar una indicación visual para el usuario para mostrar las llamadas bloqueadas en la app de marcado preinstalada.
7.4.1.2. API de Telecom
Si las implementaciones de dispositivos informan android.hardware.telephony.calling
, hacen lo siguiente:
- [C-1-1] DEBE admitir las APIs de
ConnectionService
que se describen en el SDK. - [C-1-2] DEBE mostrar una nueva llamada entrante y proporcionar indicaciones visuales para que el usuario acepte o rechace la llamada entrante cuando esté en una llamada en curso que realice una app de terceros que no admita la función de poner en espera especificada a través de
CAPABILITY_SUPPORT_HOLD
. - [C-1-3] DEBE tener una aplicación que implemente InCallService.
[C-SR-1] SE RECOMIENDA ENFATICAMENTE notificar al usuario que, si responde una llamada entrante, se descartará una llamada en curso.
La implementación de AOSP cumple con estos requisitos mediante una notificación de atención que le indica al usuario que, si contesta una llamada entrante, se descartará la otra.
[C-SR-2] SE RECOMIENDA ENFATICAMENTE que se cargue previamente la app de dialer predeterminada que muestra una entrada del registro de llamadas y el nombre de una app de terceros en su registro de llamadas cuando la app de terceros establece la clave adicional
EXTRA_LOG_SELF_MANAGED_CALLS
en suPhoneAccount
comotrue
.[C-SR-3] SE RECOMIENDA ENFATICAMENTE que se controlen los eventos
KEYCODE_MEDIA_PLAY_PAUSE
yKEYCODE_HEADSETHOOK
de los auriculares de audio para las APIs deandroid.telecom
de la siguiente manera:- Llama a
Connection.onDisconnect()
cuando se detecte una presión breve del evento de tecla durante una llamada en curso. - Llama a
Connection.onAnswer()
cuando se detecte una presión breve del evento de tecla durante una llamada entrante. - Llama a
Connection.onReject()
cuando se detecta una presión prolongada del evento de tecla durante una llamada entrante. - Activa o desactiva el estado de silenciamiento de
CallAudioState
.
- Llama a
7.4.1.3. Aligeramiento de la señal de mantenimiento NAT-T celular
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con la descarga de keepalive celular.
Si las implementaciones de dispositivos incluyen compatibilidad con la descarga de keepalive celular y exponen la funcionalidad a apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE admitir la API de SocketKeepAlive.
- [C-1-2] DEBE admitir al menos un intervalo de tiempo de actividad simultáneo a través de la red celular.
- [C-1-3] DEBE admitir tantas ranuras de mantenimiento de la conexión celular simultáneas como admita el HAL de radio celular.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE admitir al menos tres ranuras de mantenimiento de la conexión celular por instancia de radio.
Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de keepalive de red móvil, hacen lo siguiente:
- [C-2-1] DEBE mostrar ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con una o más formas de 802.11.
Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 y exponen la funcionalidad a una aplicación de terceros, hacen lo siguiente:
- [C-1-1] DEBE implementar la API de Android correspondiente.
- [C-1-2] DEBE informar la marca 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 multicast (mDNS) y NO DEBE filtrar paquetes mDNS (224.0.0.251 o ff02::fb) en cualquier momento de la operación, incluso cuando la pantalla no está en un estado activo, a menos que sea necesario descartar o filtrar estos paquetes para mantenerse dentro de los rangos de consumo de energía que exigen los requisitos reglamentarios aplicables al mercado objetivo.
En el caso de las implementaciones de dispositivos Android TV, incluso en estados de energía en espera. - [C-1-5] NO DEBE tratar la llamada al método de la API de
WifiManager.enableNetwork()
como una indicación suficiente para cambiar elNetwork
activo actualmente que se usa de forma predeterminada para el tráfico de la aplicación y que muestran los métodos de la API deConnectivityManager
, comogetActiveNetwork
yregisterDefaultNetworkCallback
. En otras palabras, solo PUEDEN inhabilitar el acceso a Internet que proporciona cualquier otro proveedor de red (p.ej., datos móviles) si validan correctamente que la red Wi-Fi proporciona acceso a Internet. - [C-1-6] SE RECOMIENDA ENFATICAMENTE que, cuando se llame al método de la API de
ConnectivityManager.reportNetworkConnectivity()
, se vuelva a evaluar el acceso a Internet en elNetwork
y, una vez que la evaluación determine que elNetwork
actual ya no proporciona acceso a Internet, se cambie a cualquier otra red disponible (p.ej., 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 los fotogramas de solicitud de sondeo, una vez al comienzo de cada análisis, mientras el STA está desconectado.
- [C-1-8] DEBE usar una dirección MAC coherente (NO DEBE aleatorizar la dirección MAC a la mitad de un análisis).
- [C-1-9] DEBE iterar el número de secuencia de la solicitud de sondeo de forma normal (secuencial) entre las solicitudes de sondeo en un análisis.
- [C-1-10] DEBE aleatorizar el número de secuencia de la solicitud de sondeo entre la última solicitud de sondeo de un análisis y la primera solicitud de sondeo del siguiente análisis.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE aleatorizar la dirección MAC de origen que se usa para toda la comunicación de STA con un punto de acceso (AP) durante la asociación y la asociación.
- El dispositivo DEBE usar una dirección MAC aleatoria diferente para cada SSID (FQDN para Passpoint) con el que se comunica.
- El dispositivo DEBE proporcionarle al usuario una opción para controlar la aleatoriedad por SSID (FQDN para Passpoint) con opciones no aleatorizadas y aleatorizadas, y DEBE configurar el modo predeterminado para que las nuevas configuraciones de Wi-Fi sean aleatorizadas.
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE usar un BSSID aleatorio para cualquier AP que se cree.
- La dirección MAC DEBE ser aleatoria y persistir por SSID que usa el AP.
- ES POSIBLE que el DISPOSITIVO le proporcione al usuario una opción para inhabilitar esta función. Si se proporciona una opción de este tipo, la aleatoriedad DEBE estar habilitada de forma predeterminada.
Si las implementaciones de dispositivos incluyen compatibilidad con el modo de ahorro de energía de Wi-Fi, como se define en el estándar IEEE 802.11, deben cumplir con los siguientes requisitos:
- DEBE desactivar el modo de ahorro de energía de Wi-Fi cada vez que una app adquiere el bloqueo
WIFI_MODE_FULL_HIGH_PERF
oWIFI_MODE_FULL_LOW_LATENCY
a través de las APIs deWifiManager.createWifiLock()
yWifiManager.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 el dispositivo está en el modo de bloqueo de latencia baja de Wi-Fi (
WIFI_MODE_FULL_LOW_LATENCY
) DEBE ser menor que la latencia durante el modo de bloqueo de alto rendimiento de Wi-Fi (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] SE RECOMIENDA ENFATICAMENTE minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere un bloqueo de baja latencia (
WIFI_MODE_FULL_LOW_LATENCY
) y se aplica.
Si las implementaciones de dispositivos admiten Wi-Fi y lo usan para el escaneo de ubicación, hacen lo siguiente:
- [C-2-1] DEBE proporcionar una indicación visual para el usuario para habilitar o inhabilitar el valor leído a través del método de API
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. Wi-Fi directo
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con Wi-Fi Direct (Wi-Fi entre pares).
Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Direct, tienen las siguientes características:
- [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 de forma simultánea.
- [C-SR-1] SE RECOMIENDA ENFÉCTIVAMENTE aleatorizar la dirección MAC de origen para todas las conexiones Wi-Fi Direct recién formadas.
7.4.2.2. Configuración de vínculo directo con túnel Wi-Fi
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con la configuración de vínculo directo con túnel Wi-Fi (TDLS), como se describe en la documentación del SDK de Android.
Si las implementaciones de dispositivos incluyen compatibilidad con TDLS y la API de WiFiManager habilita TDLS, hacen lo siguiente:
- [C-1-1] DEBE declarar la compatibilidad con TDLS a través de
WifiManager.isTdlsSupported
. - DEBE usar TDLS solo cuando sea posible Y beneficioso.
- DEBE tener alguna heurística y NO usar TDLS cuando su rendimiento sea peor que pasar por el punto de acceso Wi-Fi.
7.4.2.3. Reconocimiento de Wi-Fi
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con Reconocimiento de Wi-Fi.
Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y exponen la funcionalidad a apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE implementar las APIs de
WifiAwareManager
como se describe en la documentación del SDK. - [C-1-2] DEBE declarar la marca de función
android.hardware.wifi.aware
. - [C-1-3] DEBE admitir operaciones de Wi-Fi y Wi-Fi Aware de forma simultánea.
- [C-1-4] DEBE aleatorizar la dirección de la interfaz de administración de Wi-Fi Aware en intervalos de no más de 30 minutos y cada vez que Wi-Fi Aware esté habilitado, a menos que haya una operación de rango Aware en curso o una ruta de datos Aware activa (no se espera que se realice la aleatorización mientras la ruta de datos esté activa).
Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y Wi-Fi Location como se describe en la Sección 7.4.2.5 y exponen estas funciones a apps de terceros, deben cumplir con los siguientes requisitos:
- [C-2-1] DEBE implementar las APIs de descubrimiento orientadas a la ubicación: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm y onServiceDiscoveredWithinRange.
7.4.2.4. Wi-Fi Passpoint
Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 (Wi-Fi), tienen las siguientes características:
- [C-1-1] DEBE incluir compatibilidad con Wi-Fi Passpoint.
- [C-1-2] DEBE implementar las APIs de
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 la selección de redes, como el servicio de anuncios genéricos (GAS) y el protocolo de consulta de red de acceso (ANQP).
- [C-1-4] DEBE declarar la marca de función
android.hardware.wifi.passpoint
. - [C-1-5] DEBE seguir la implementación de AOSP para descubrir, hacer coincidir y asociarse a redes de Passpoint.
- [C-1-6] DEBE admitir al menos el siguiente subconjunto de protocolos de aprovisionamiento de dispositivos, como se define en el Passpoint R2 de Wi-Fi Alliance: 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 de usuario del aprovisionamiento a través del selector de Wi-Fi.
- [C-1-9] DEBE mantener la configuración de Passpoint persistente en todos los reinicios.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE admitir la función de aceptación de los términos y condiciones.
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que admitas la función de información sobre lugares.
Si se proporciona un interruptor de control de usuario de inhabilitación global de Passpoint, las implementaciones hacen lo siguiente:
- [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:
- DEBE incluir compatibilidad con la Ubicación Wi-Fi.
Si las implementaciones de dispositivos incluyen compatibilidad con la Ubicación Wi-Fi y exponen la funcionalidad a apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE implementar las APIs de
WifiRttManager
como se describe en la documentación del SDK. - [C-1-2] DEBE declarar la marca de función
android.hardware.wifi.rtt
. - [C-1-3] DEBE aleatorizar la dirección MAC de origen para cada ráfaga de RTT que se ejecute 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 (como se calcula con la función de distribución acumulativa).
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que se informe con precisión dentro de un radio de 1.5 metros con un ancho de banda de 80 MHz en el percentil 68 (como se calcula con la función de distribución acumulada).
7.4.2.6. Transferencia de keepalive de Wi-Fi
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con la descarga de la función de mantenimiento de la conexión Wi-Fi.
Si las implementaciones de dispositivos incluyen compatibilidad con la descarga de la función de mantenimiento de la conexión Wi-Fi y exponen la funcionalidad a apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE admitir la API de SocketKeepAlive.
- [C-1-2] DEBE admitir al menos tres ranuras de mantenimiento de la conexión simultáneas a través de Wi-Fi.
Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de la función de mantenimiento de la conexión Wi-Fi, hacen lo siguiente:
- [C-2-1] DEBE mostrar
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (protocolo de aprovisionamiento de dispositivos)
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con Wi-Fi Easy Connect (DPP).
Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Easy Connect y exponen la funcionalidad a apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE tener el método WifiManager#isEasyConnectSupported() que devuelve
true
.
7.4.2.8. Validación del certificado del servidor Wi-Fi empresarial
Si no se valida el certificado del servidor Wi-Fi o no se configura el nombre de dominio del servidor Wi-Fi, las implementaciones de dispositivos hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA NO proporcionarle al usuario la opción de agregar manualmente una red Wi-Fi empresarial en la app de Configuración.
7.4.2.9. Confianza en el primer uso (TOFU)
Si las implementaciones de dispositivos admiten la confianza en el primer uso (TOFU) y permiten que el usuario defina configuraciones de WPA/WPA2/WPA3-Enterprise, hacen lo siguiente:
- [C-4-1] DEBE proporcionarle al usuario una opción para seleccionar el uso de TOFU.
7.4.3. Bluetooth
Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth, hacen lo siguiente:
- DEBE admitir códecs de audio avanzados y códecs de audio Bluetooth (p.ej., LDAC)
Si las implementaciones de dispositivos admiten HFP, A2DP y AVRCP, hacen lo siguiente:
- DEBE admitir al menos 5 dispositivos conectados en total.
Si las implementaciones de dispositivos declaran la función android.hardware.vr.high_performance
, hacen lo siguiente:
- [C-1-1] DEBE admitir Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE.
Android incluye compatibilidad con Bluetooth y Bluetooth de bajo consumo.
Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo, hacen lo siguiente:
- [C-2-1] DEBES declarar las funciones de la plataforma relevantes (
android.hardware.bluetooth
yandroid.hardware.bluetooth_le
, respectivamente) e implementar las APIs de la plataforma. - DEBE implementar los perfiles de Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP, etc., según corresponda al dispositivo.
Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo (BLE), tienen las siguientes características:
- [C-3-1] DEBE declarar la función de hardware
android.hardware.bluetooth_le
. - [C-3-2] DEBEN habilitar las APIs de Bluetooth basadas en GATT (perfil de atributos genéricos) como se describe en la documentación del SDK y en android.bluetooth.
- [C-3-3] DEBE informar el valor correcto para
BluetoothAdapter.isOffloadedFilteringSupported()
para indicar si se implementó la lógica de filtrado para las clases de la API de ScanFilter. - [C-3-4] DEBE informar el valor correcto para
BluetoothAdapter.isMultipleAdvertisementSupported()
para indicar si se admite la publicidad de bajo consumo. [C-3-5] DEBE implementar un tiempo de espera de la dirección privada resolvable (RPA) de no más de 15 minutos y rotar la dirección al final del tiempo de espera para proteger la privacidad del usuario cuando el dispositivo usa activamente BLE para la búsqueda o la publicidad. Para evitar ataques de sincronización, los intervalos de tiempo de espera también DEBEN ser aleatorios entre 5 y 15 minutos.
DEBE admitir la transferencia de la lógica de filtrado al chipset Bluetooth cuando se implemente la API de ScanFilter.
DEBE admitir la transferencia del análisis por lotes al conjunto de chips Bluetooth.
DEBE admitir varios anuncios con al menos 4 posiciones.
Si las implementaciones de dispositivos admiten Bluetooth LE y lo usan para el escaneo de ubicación, hacen lo siguiente:
- [C-4-1] DEBE proporcionar una indicación visual para el usuario para habilitar o inhabilitar el valor leído a través de la API de System
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth LE y el perfil de audífonos, como se describe en Compatibilidad con audio de audífonos a través de Bluetooth LE, hacen lo siguiente:
- [C-5-1] DEBE mostrar
true
para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo, hacen lo siguiente:
- [C-6-1] DEBE restringir el acceso a cualquier metadato de Bluetooth (como los resultados de la búsqueda) que se pueda usar para obtener la ubicación del dispositivo, a menos que la app solicitante pase correctamente una verificación de permisos de
android.permission.ACCESS_FINE_LOCATION
según su estado actual en primer o segundo plano.
Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth o Bluetooth de bajo consumo, y el manifiesto de la app no incluye una declaración del desarrollador que indique que no se obtiene la ubicación de Bluetooth, se debe hacer lo siguiente:
- [C-6-2] DEBE restringir el acceso a Bluetooth detrás de
android.permission.ACCESS_FINE_LOCATION
.
Si las implementaciones de dispositivos muestran true
para la API de BluetoothAdapter.isLeAudioSupported()
, hacen lo siguiente:
- [C-7-1] DEBE admitir clientes unicast.
- [C-7-2] DEBE admitir PHY de 2M.
- [C-7-3] DEBE admitir publicidad extendida de LE.
- [C-7-4] DEBE admitir al menos 2 conexiones de CIS en un CIG.
- [C-7-5] DEBEN habilitarse el cliente unicast de BAP, el coordinador de conjuntos de CSIP, el servidor MCP, el controlador de VCP y el servidor CCP de forma simultánea.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que habilites el cliente unicast de HAP.
Si las implementaciones de dispositivos muestran true
para la API de BluetoothAdapter.isLeAudioBroadcastSourceSupported()
, hacen lo siguiente:
- [C-8-1] DEBE admitir al menos 2 vínculos BIS en un BIG.
- [C-8-2] DEBES habilitar la fuente de transmisión de BAP y el asistente de transmisión de BAP simultáneamente.
- [C-8-3] DEBE admitir publicidad periódica de LE.
Si las implementaciones de dispositivos muestran true
para la API de BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
, hacen lo siguiente:
- [C-9-1] DEBE admitir PAST (transferencia de sincronización de anuncios periódica).
- [C-9-2] DEBE admitir la publicidad periódica de LE.
Si las implementaciones de dispositivos declaran FEATURE_BLUETOOTH_LE
, hacen lo siguiente:
- [C-10-1] DEBEN tener mediciones de RSSI dentro de +/-9 dB para el 95% de las mediciones a 1 m de distancia de un dispositivo de referencia que transmite a
ADVERTISE_TX_POWER_HIGH
en un entorno de línea de visión. [C-10-2] DEBEN incluir correcciones de Rx/Tx para reducir las desviaciones por canal, de modo que las mediciones en cada uno de los 3 canales, en cada una de las antenas (si se usan varias), estén dentro de +/-3 dB entre sí para el 95% de las mediciones.
[C-SR-2] SE RECOMIENDA ENFATICAMENTE medir y compensar el desplazamiento de Rx para garantizar que el RSSI promedio de BLE sea de -60 dBm ± 10 dB a 1 m de distancia de un dispositivo de referencia que transmite a
ADVERTISE_TX_POWER_HIGH
, en el que los dispositivos están orientados de modo que se encuentren en "planos paralelos" con pantallas orientadas en la misma dirección.[C-SR-3] SE RECOMIENDA ENFATICAMENTE medir y compensar el desplazamiento de Tx para garantizar que el RSSI promedio de BLE sea de -60 dBm ± 10 dB cuando se realiza una búsqueda desde un dispositivo de referencia ubicado a 1 m de distancia y que transmite a
ADVERTISE_TX_POWER_HIGH
, donde los dispositivos están orientados de modo que se encuentren en "planos paralelos" con pantallas orientadas en la misma dirección.Se movieron los requisitos [C-10-3] y [C-10-4] a 2.2.1. Hardware.
- [C-10-3] DEBE medir y compensar el desplazamiento de Rx para garantizar que el RSSI promedio de BLE sea de -55 dBm ± 10 dB a 1 m de distancia de un dispositivo de referencia que transmite a
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] DEBE medir y compensar el desplazamiento de Tx para garantizar que el RSSI promedio de BLE sea de -55 dBm ± 10 dB cuando se escanea desde un dispositivo de referencia ubicado a 1 m de distancia y que transmite a
ADVERTISE_TX_POWER_HIGH
.
SE RECOMIENDA URGENTEMENTE que sigas los pasos de configuración de medición que se especifican en Requisitos de calibración de presencias.
Si las implementaciones de dispositivos admiten la versión 5.0 de Bluetooth, tienen las siguientes características:
- [C-SR-4] SE RECOMIENDA ENFATICAMENTE que proporcionen asistencia para lo siguiente:
- PHY LE 2M
- PHY del códec LE
- Extensión publicitaria de LE
- Publicidad periódica
- Al menos 10 conjuntos de anuncios
- Al menos 8 conexiones simultáneas de LE Cada conexión puede estar en cualquiera de los roles de topología de conexión.
- Privacidad de la capa de vínculo LE
- Un tamaño de "lista de resolución" de al menos 8 entradas
7.4.4. Comunicación de campo cercano
Implementaciones de dispositivos:
- DEBE incluir un transceptor y el hardware relacionado para la comunicación de campo cercano (NFC).
- [C-0-1] DEBEN implementar las APIs de
android.nfc.NdefMessage
yandroid.nfc.NdefRecord
, incluso si no incluyen compatibilidad con NFC o declaran la funciónandroid.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 apps de terceros, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar la función
android.hardware.nfc
desde el métodoandroid.content.pm.PackageManager.hasSystemFeature()
. - DEBEN ser capaces de leer y escribir mensajes NDEF a través de los siguientes estándares de NFC:
- [C-1-2] DEBE ser capaz de actuar como lector/escritor de NFC Forum (según se define en la especificación técnica de NFC Forum NFCForum-TS-DigitalProtocol-1.0) a través de los siguientes estándares de NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Tipos de etiquetas del NFC Forum 1, 2, 3, 4 y 5 (definidos por el NFC Forum)
[C-SR-1] SE RECOMIENDA ENFATICAMENTE que el dispositivo sea capaz de leer y escribir mensajes NDEF, así como datos sin procesar, a través de los siguientes estándares de NFC. Ten en cuenta que, mientras que los estándares de NFC se indican como MUY RECOMENDADOS, se planea que la definición de compatibilidad de una versión futura cambie estos a OBLIGATORIOS. Estos estándares son opcionales en esta versión, pero serán obligatorios en versiones futuras. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan esta versión de Android cumplan con estos requisitos ahora para que puedan actualizar a las versiones futuras de la plataforma.
[C-1-13] DEBE sondear todas las tecnologías compatibles mientras está en modo de descubrimiento de NFC.
DEBE estar en modo de descubrimiento de 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 con códigos de barras NFC Thinfilm.
Ten en cuenta que los vínculos disponibles públicamente no están disponibles para las especificaciones de JIS, ISO y NFC Forum mencionadas anteriormente.
Android incluye compatibilidad con el modo de emulación de tarjeta de host (HCE) de NFC.
Si las implementaciones de dispositivos incluyen un chipset de controlador NFC capaz de HCE (para NfcA o NfcB) y admiten el enrutamiento de ID de aplicación (AID), hacen lo siguiente:
- [C-2-1] DEBE informar la constante de función
android.hardware.nfc.hce
. - [C-2-2] DEBE admitir las APIs de NFC HCE como se define en el SDK de Android.
Si las implementaciones de dispositivos incluyen un chipset de controlador NFC capaz de HCE para NfcF y, además, implementan la función para aplicaciones de terceros, hacen lo siguiente:
- [C-3-1] DEBE informar la constante de función
android.hardware.nfc.hcef
. - [C-3-2] DEBE implementar las APIs de emulación de tarjetas NfcF como se define en el SDK de Android.
Si las implementaciones de dispositivos incluyen compatibilidad general con NFC como se describe en esta sección y admiten tecnologías MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF en MIFARE Classic) en el rol de lector/escritor, cumplen con los siguientes requisitos:
- [C-4-1] DEBE implementar las APIs de Android correspondientes según lo documenta el SDK de Android.
- [C-4-2] DEBE informar la función
com.nxp.mifare
del métodoandroid.content.pm.PackageManager.hasSystemFeature
(). Ten en cuenta que esta no es una función estándar de Android y, por lo tanto, no aparece como una constante en la claseandroid.content.pm.PackageManager
.
7.4.5. Protocolos y APIs de redes
7.4.5.1. Capacidad de red mínima
Implementaciones de dispositivos:
- [C-0-1] DEBE incluir compatibilidad con una o más formas de redes de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos capaz de alcanzar 200 Kbit/s o más. Algunos ejemplos de tecnologías que satisfacen este requisito son EDGE, HSPA, EV-DO, 802.11g, Ethernet y PAN de Bluetooth.
- TAMBIÉN DEBE incluir compatibilidad con al menos un estándar de datos inalámbricos común, como 802.11 (Wi-Fi), cuando un estándar de red física (como Ethernet) es la conexión de datos principal.
- PUEDE implementar más de una forma de conectividad de datos.
7.4.5.2. IPv6
Implementaciones de dispositivos:
- [C-0-2] DEBE incluir una pila de redes IPv6 y admitir la comunicación IPv6 con las APIs administradas, como
java.net.Socket
yjava.net.URLConnection
, así como las APIs nativas, como los socketsAF_INET6
. - [C-0-3] DEBE habilitar IPv6 de forma predeterminada.
- DEBEN garantizar que la comunicación IPv6 sea tan confiable como la IPv4, por ejemplo:
- [C-0-4] DEBE mantener la conectividad IPv6 en modo de suspensión.
- [C-0-5] La limitación de velocidad NO DEBE hacer que el dispositivo pierda la conectividad IPv6 en ninguna red compatible con IPv6 que use duraciones de RA de al menos 180 segundos.
- DEBEN garantizar que la comunicación IPv6 sea tan confiable como la IPv4, por ejemplo:
- [C-0-6] DEBE proporcionar a las aplicaciones de terceros conectividad IPv6 directa a la red cuando se conecten a una red IPv6, sin ningún tipo de traducción de direcciones o puertos que se realice de forma local en el dispositivo. Tanto las APIs administradas, como
Socket#getLocalAddress
oSocket#getLocalPort
, como las APIs de NDK, comogetsockname()
oIPV6_PKTINFO
, DEBEN mostrar la dirección IP y el puerto que se usan realmente para enviar y recibir paquetes en la red, y se pueden ver como la IP de origen y el puerto para los 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, hacen lo siguiente:
- [C-1-1] DEBE admitir la operación de pila doble y solo IPv6 en Wi-Fi.
Si las implementaciones de dispositivos admiten Ethernet, tienen las siguientes características:
- [C-2-1] DEBE admitir la operación de pila doble y solo IPv6 en Ethernet.
Si las implementaciones de dispositivos admiten datos móviles, hacen lo siguiente:
- [C-3-1] DEBE admitir el funcionamiento de IPv6 (solo IPv6 y, posiblemente, pila doble) en redes móviles.
Si las implementaciones de dispositivos admiten más de un tipo de red (p.ej., Wi-Fi y datos móviles), hacen lo siguiente:
- [C-4-1] DEBE cumplir simultáneamente con los requisitos anteriores en cada red cuando el dispositivo está conectado a más de un tipo de red.
7.4.5.3. Portales cautivos
Un portal cautivo es una red que requiere acceso para obtener acceso a Internet.
Si las implementaciones de dispositivos proporcionan una implementación completa de android.webkit.Webview API
, hacen lo siguiente:
- [C-1-1] DEBE proporcionar una aplicación de portal cautivo para controlar el intent
ACTION_CAPTIVE_PORTAL_SIGN_IN
y mostrar la página de acceso del portal cautivo. Para ello, debe enviar ese intent cuando se llame a la API del sistemaConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] DEBE realizar la detección de portales cautivos y admitir el acceso a través de la aplicación del portal cautivo cuando el dispositivo está conectado a cualquier tipo de red, incluida la red celular o móvil, Wi-Fi, Ethernet o Bluetooth.
- [C-1-3] DEBE admitir el acceso a portales cautivos con DNS de texto simple cuando el dispositivo está configurado para usar el modo estricto de DNS privado.
- [C-1-4] DEBE usar DNS encriptado según la documentación del SDK para
android.net.LinkProperties.getPrivateDnsServerName
yandroid.net.LinkProperties.isPrivateDnsActive
para todo el tráfico de red que no se comunique de forma explícita con el portal cautivo. - [C-1-5] DEBE garantizar que, mientras el usuario accede a un portal cautivo, la red predeterminada que usan las aplicaciones (como la que muestra
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
y que usan de forma predeterminada las APIs de redes de Java, como java.net.Socket, y las APIs nativas, como connect()) sea 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 “true”.
7.4.7. Ahorro de datos
Si las implementaciones de dispositivos incluyen una conexión con medición, tienen las siguientes características:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE proporcionar el modo de ahorro de datos.
Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos, hacen lo siguiente:
- [C-1-1] DEBE admitir todas las APIs de la clase
ConnectivityManager
como se describe en la documentación del SDK.
Si las implementaciones de dispositivos no proporcionan el modo Ahorro de datos, sucede lo siguiente:
- [C-2-1] DEBE mostrar el valor
RESTRICT_BACKGROUND_STATUS_DISABLED
paraConnectivityManager.getRestrictBackgroundStatus()
. - [C-2-2] NO DEBE transmitir
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.
7.4.8. Elementos seguros
Si las implementaciones de dispositivos admiten elementos seguros compatibles con la API de Open Mobile y los ponen a disposición de apps de terceros, hacen lo siguiente:
[C-1-1] DEBE enumerar los lectores de elementos seguros disponibles a través de la API de
android.se.omapi.SEService.getReaders()
.[C-1-2] DEBES declarar las marcas de función correctas a través de
android.hardware.se.omapi.uicc
para el dispositivo con elementos seguros basados en UICC,android.hardware.se.omapi.ese
para el dispositivo con elementos seguros basados en eSE yandroid.hardware.se.omapi.sd
para el dispositivo con elementos seguros basados en SD.
7.4.9. UWB
Si las implementaciones de dispositivos incluyen compatibilidad con 802.1.15.4 y exponen la funcionalidad a una aplicación de terceros, hacen lo siguiente:
- [C-1-1] DEBE implementar la API de Android correspondiente en android.uwb.
- [C-1-2] DEBE informar la marca de función de hardware android.hardware.uwb.
- [C-1-3] DEBE admitir todos los perfiles de UWB relevantes definidos en la implementación de Android.
- [C-1-4] DEBE proporcionar una indicación visual para que el usuario pueda activar o desactivar el estado de la radio UWB.
- [C-1-5] SE DEBE aplicar que las apps que usan radio UWB tengan el permiso UWB_RANGING (en el grupo de permisos NEARBY_DEVICES).
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que se aprueben las pruebas de certificación y de cumplimiento relevantes definidas por las organizaciones de estándares, incluidas FIRA, CCC y CSA.
- [C-1-6] DEBE garantizar que las mediciones de distancia estén dentro de +/-15 cm para el 95% de las mediciones en el entorno de línea de visión a 1 m de distancia en una cámara no reflectante.
- [C-1-7] DEBE garantizar que la mediana de las mediciones de distancia a 1 m del dispositivo de referencia esté dentro de [0.75 m, 1.25 m], donde la distancia de la verdad de referencia se mide desde el borde superior del DUT.
con la parte superior hacia arriba y con una inclinación de 45 grados. - [C-SR-2] SE RECOMIENDA URGENTEMENTE que sigas los pasos de configuración de medición especificados en los Requisitos de calibración de presencia.
7.5. Cámaras
Si las implementaciones de dispositivos incluyen al menos una cámara, hacen lo siguiente:
- [C-1-1] DEBE declarar la marca de función
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 que produce el sensor de cámara de mayor resolución en el dispositivo, mientras la cámara está abierta para la vista previa básica y la captura de imágenes fijas.
- [C-1-3] DEBE garantizar que la aplicación de cámara preinstalada predeterminada que controla los intents
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
oMediaStore.ACTION_VIDEO_CAPTURE
sea responsable de quitar la ubicación del usuario en los metadatos de la imagen antes de enviarla a la aplicación receptora cuando esta no tengaACCESS_FINE_LOCATION
.
Si las implementaciones de dispositivos admiten la capacidad de salida HDR de 10 bits, hacen lo siguiente:
- [C-2-1] DEBE admitir al menos el perfil HDR HLG para cada dispositivo de cámara que admita una salida de 10 bits.
- [C-2-2] DEBE admitir una salida de 10 bits para la cámara principal posterior o frontal.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE admitir la salida de 10 bits para ambas cámaras principales.
- [C-2-3] DEBE admitir los mismos perfiles de HDR para todas las cámaras secundarias físicas compatibles con BACKWARD_COMPATIBLE de una cámara lógica y la cámara lógica en sí.
En el caso de los dispositivos de cámara lógica que admiten HDR de 10 bits que implementan la API de android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
, sucede lo siguiente:
- [C-3-1] DEBE admitir el cambio entre todas las cámaras físicas retrocompatibles a través del control
CONTROL_ZOOM_RATIO
en la cámara lógica.
7.5.1. Cámara posterior
Una cámara posterior es una cámara que se encuentra en el lado del dispositivo opuesto a la pantalla; es decir, captura imágenes de escenas en el extremo opuesto del dispositivo, como una cámara tradicional.
Cómo iniciar nuevos requisitos
Una cámara posterior es una cámara orientada al mundo que captura imágenes de escenas en el extremo opuesto del dispositivo, como una cámara tradicional. En los dispositivos de mano, es una cámara ubicada en el lado del dispositivo opuesto a la pantalla.
Fin de los nuevos requisitos
Implementaciones de dispositivos:
- DEBE incluir una cámara posterior.
Si las implementaciones de dispositivos incluyen al menos una cámara posterior, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar la marca de función
android.hardware.camera
yandroid.hardware.camera.any
. - [C-1-2] DEBEN tener una resolución de al menos 2 megapíxeles.
- DEBE tener el enfoque automático de hardware o software implementado en el controlador de la cámara (transparente para el software de la aplicación).
- PUEDEN tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
- PUEDE incluir un flash.
Si la cámara incluye un flash, haz lo siguiente:
- [C-2-1] La lámpara del flash NO DEBE estar encendida mientras se registró una instancia de
android.hardware.Camera.PreviewCallback
en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado el flash de forma explícita habilitando los atributosFLASH_MODE_AUTO
oFLASH_MODE_ON
de un objetoCamera.Parameters
. Ten en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema integrada en el dispositivo, sino solo a las aplicaciones de terceros que usanCamera.PreviewCallback
.
7.5.2. Cámara frontal
Una cámara frontal es una cámara que se encuentra en el mismo lado del dispositivo que la pantalla, es decir, una cámara que se usa normalmente para capturar imágenes del usuario, como en videoconferencias y aplicaciones similares.
Cómo iniciar nuevos requisitos
Una cámara frontal es una cámara orientada al usuario que, por lo general, se usa para capturar imágenes del usuario, como en videoconferencias y aplicaciones similares. En dispositivos de mano, es una cámara ubicada en el mismo lado del dispositivo que la pantalla.
Fin de los nuevos requisitos
Implementaciones de dispositivos:
- PUEDE incluir una cámara frontal.
Si las implementaciones de dispositivos incluyen al menos una cámara frontal, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar la marca de función
android.hardware.camera.any
yandroid.hardware.camera.front
. - [C-1-2] DEBEN tener una resolución de al menos VGA (640 × 480 píxeles).
- [C-1-3] NO DEBE usar una cámara frontal como la predeterminada de la API de Camera y NO DEBE configurar la API para que trate una cámara frontal como la cámara posterior predeterminada, incluso si es la única cámara del dispositivo.
- [C-1-4] La vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación que especifica la aplicación cuando esta solicitó de forma explícita 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 duplicarse a lo largo del eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicite de forma explícita que la pantalla de la cámara se rote mediante una llamada al métodoandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] NO DEBE duplicar las imágenes estáticas capturadas finales ni las transmisiones de video que se devuelven a las devoluciones de llamada de la aplicación o se confirman en el almacenamiento de contenido multimedia.
- [C-1-6] DEBE duplicar la imagen que muestra la vista posterior de la misma manera que el flujo de imágenes de vista previa de la cámara.
- PUEDEN incluir funciones (como enfoque automático, flash, etc.) disponibles para cámaras posteriores, como se describe en la sección 7.5.1.
Si el usuario puede rotar las implementaciones de dispositivos (por ejemplo, automaticamente a través de un acelerómetro o de forma manual a través de la entrada del usuario), haz lo siguiente:
- [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
Cómo iniciar nuevos requisitos
Una cámara externa es una cámara que se puede conectar o desconectar físicamente de la implementación del dispositivo en cualquier momento y puede orientarse en cualquier dirección, como las cámaras USB.
Fin de los nuevos requisitos
Implementaciones de dispositivos:
- PUEDE incluir compatibilidad con una cámara externa que no necesariamente está siempre conectada.
Si las implementaciones de dispositivos incluyen compatibilidad con una cámara externa, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE declarar las marcas de funciones de la plataforma
android.hardware.camera.external
yandroid.hardware camera.any
. - [C-1-2] DEBE admitir la 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 aprobar las pruebas de CTS de la cámara con un dispositivo de cámara externa físico conectado. Los detalles de las pruebas de CTS de la cámara están disponibles en source.android.com.
- DEBE admitir compresiones de video, como MJPEG, para permitir la transferencia de transmisiones sin codificar de alta calidad (es decir, transmisiones de imágenes sin procesar o comprimidas de forma independiente).
- PUEDE admitir varias cámaras.
- PUEDE admitir codificación de video basada en la cámara.
Si se admite la codificación de video basada en la cámara, haz lo siguiente:
- [C-2-1] La implementación del dispositivo DEBE poder acceder a una transmisión simultánea sin codificar o MJPEG (QVGA o una resolución superior).
7.5.4. Comportamiento de la API de Camera
Android incluye dos paquetes de API para acceder a la cámara. La API más reciente de android.hardware.camera2 expone el control de la cámara de nivel inferior a la app, incluidos flujos de transmisión o ráfaga eficientes sin copia y controles por fotograma de exposición, ganancia, ganancias de balance de blancos, conversión de colores, reducción de ruido, nitidez y mucho más.
El paquete de API anterior, android.hardware.Camera
, está marcado como obsoleto en Android 5.0, pero aún debería estar disponible para que las apps lo usen. Las implementaciones de dispositivos Android DEBEN garantizar la compatibilidad continua de la API, como se describe en esta sección y en el SDK de Android.
Todas las funciones que son comunes entre la clase android.hardware.Camera obsoleta y el paquete más reciente android.hardware.camera2 DEBEN tener un rendimiento y una calidad equivalentes en ambas APIs. Por ejemplo, con una configuración equivalente, la velocidad y la precisión del enfoque automático deben ser idénticas, y la calidad de las imágenes capturadas debe ser la misma. Las funciones que dependen de las diferentes semánticas de las dos APIs no es necesario que tengan la misma velocidad o calidad, pero DEBEN coincidir lo más cerca posible.
Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs 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 los datos de vista previa proporcionados a las devoluciones de llamada de la aplicación cuando una aplicación nunca llamó aandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] DEBE estar en el formato de codificación NV21 cuando una aplicación registra una instancia de
android.hardware.Camera.PreviewCallback
y el sistema llama al métodoonPreviewFrame()
y el formato de vista previa es YCbCr_420_SP, los datos en el byte[] que se pasa aonPreviewFrame()
. Es decir, NV21 DEBE ser el valor predeterminado. - [C-0-3] DEBE admitir el formato YV12 (como se indica en la constante
android.graphics.ImageFormat.YV12
) para las vistas previas de la cámara, tanto para la cámara frontal como para la posterior, enandroid.hardware.Camera
. (El codificador de video y la cámara de hardware pueden usar cualquier formato de píxeles 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
yandroid.hardware.ImageFormat.JPEG
como salidas a través de la API deandroid.media.ImageReader
para dispositivosandroid.hardware.camera2
que anuncien la funciónREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
enandroid.request.availableCapabilities
. - [C-0-5] SIEMPRE DEBES implementar la API de Camera completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático de hardware o alguna otra función. Por ejemplo, las cámaras que no tienen enfoque automático DEBEN llamar a cualquier instancia registrada de
android.hardware.Camera.AutoFocusCallback
(aunque esto no sea relevante para una cámara sin enfoque automático). Ten 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 aún deben ser "falsas", 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 claseandroid.hardware.camera2.CaptureRequest
. Por el contrario, las implementaciones de dispositivos NO DEBEN respetar ni reconocer constantes de cadenas que se pasen al métodoandroid.hardware.Camera.setParameters()
, excepto las documentadas como constantes enandroid.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 con técnicas de imágenes de alto rango dinámico (HDR) DEBEN admitir el parámetroCamera.SCENE_MODE_HDR
de la cámara. - [C-0-7] DEBE informar el nivel de compatibilidad adecuado con la propiedad
android.info.supportedHardwareLevel
como se describe en el SDK de Android y las marcas de funciones del framework adecuadas. - [C-0-8] También DEBE declarar sus capacidades individuales de la cámara de
android.hardware.camera2
a través de la propiedadandroid.request.availableCapabilities
y declarar las marcas de función adecuadas. DEBE definir la marca de función si alguno de sus dispositivos de cámara conectados admite la función. - [C-0-9] DEBE transmitir el intent
Camera.ACTION_NEW_PICTURE
cada vez que la cámara tome una foto nueva y se haya agregado la entrada de la foto a la tienda de contenido multimedia. - [C-0-10] DEBE transmitir el intent
Camera.ACTION_NEW_VIDEO
cada vez que la cámara grabe un video nuevo y se haya agregado la entrada de la foto a la tienda de contenido multimedia. - [C-0-11] DEBEN tener acceso a todas las cámaras a través de la API de
android.hardware.Camera
, que también es accesible a través de la API deandroid.hardware.camera2
. - [C-0-12] DEBEN garantizar que NO se altere el aspecto facial, lo que incluye, sin limitaciones, la alteración de la geometría facial, el tono de piel facial o el suavizado de la piel facial para cualquier API de
android.hardware.camera2
oandroid.hardware.Camera
. - [C-SR-1] En el caso de los dispositivos con varias cámaras RGB cercanas y orientadas en la misma dirección, se RECOMIENDA URGENTEMENTE admitir un dispositivo de cámara lógico que enumere la capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, que consta de todas las cámaras RGB orientadas en esa dirección como subdispositivos físicos.
Si las implementaciones de dispositivos proporcionan una API de cámara propietaria a las apps de terceros, hacen lo siguiente:
- [C-1-1] DEBE implementar una API de cámara de este tipo con la API de
android.hardware.camera2
. - PUEDE proporcionar etiquetas o extensiones de proveedores a la API de
android.hardware.camera2
.
7.5.5. Orientación de la cámara
Si las implementaciones de dispositivos tienen una cámara frontal o posterior, estas deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE estar orientado para que la dimensión larga de la cámara se alinee con la dimensión larga de la pantalla. Es decir, cuando el dispositivo se 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, a los dispositivos con orientación horizontal principal y a los dispositivos con orientación vertical principal.
Los dispositivos que cumplan con todos los siguientes criterios 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, este cambia de orientación principal vertical a orientación principal horizontal (o viceversa).
Cómo iniciar nuevos requisitos
- Implementaciones de dispositivos que el usuario no puede rotar, como dispositivos para la industria automotriz
Fin de los nuevos requisitos
7.6. Memoria y almacenamiento
7.6.1. Memoria y almacenamiento mínimos
Implementaciones de dispositivos:
- [C-0-1] DEBEN 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 en la ubicación predeterminada de "caché".
7.6.2. Almacenamiento compartido de la aplicación
Implementaciones de dispositivos:
- [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, que también se conoce como "almacenamiento externo compartido", "almacenamiento compartido de la aplicación" o por la ruta de acceso de Linux "/sdcard" en la que se activa.
- [C-0-2] DEBE configurarse con el almacenamiento compartido activado de forma predeterminada, es decir, "listo para usar", independientemente de si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (p.ej., una ranura para tarjeta digital segura).
- [C-0-3] DEBE activar el almacenamiento compartido de la aplicación directamente en la ruta de acceso de Linux
sdcard
o incluir un vínculo simbólico de Linux desdesdcard
hasta el punto de activación real. - [C-0-4] DEBE habilitar el almacenamiento con alcance de forma predeterminada para todas las apps que se orienten al nivel de API 29 o versiones posteriores, excepto en la siguiente situación:
- Cuando la app solicitó
android:requestLegacyExternalStorage="true"
en su manifiesto
- Cuando la app solicitó
- [C-0-5] DEBEN ocultar los metadatos de ubicación, como las etiquetas Exif de GPS, almacenados en archivos multimedia cuando se accede a esos archivos a través de
MediaStore
, excepto cuando la app que realiza la llamada tiene el permisoACCESS_MEDIA_LOCATION
.
Las implementaciones de dispositivos PUEDEN cumplir con los requisitos anteriores con cualquiera de las siguientes opciones:
- Almacenamiento extraíble al que el usuario pueda acceder, como una ranura para tarjeta Secure Digital (SD)
- Es una parte del almacenamiento interno (no extraíble) tal como se implementa en el Proyecto de código abierto de Android (AOSP).
Si las implementaciones de dispositivos usan almacenamiento extraíble para satisfacer los requisitos anteriores, deben cumplir con lo siguiente:
- [C-1-1] DEBE implementar una interfaz de usuario emergente o de notificación breve que le advierta al usuario cuando no haya un medio de almacenamiento insertado en la ranura.
- [C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (p.ej., una tarjeta SD) o mostrar en la caja y en el otro material disponible en el momento de la compra que el medio de almacenamiento se debe comprar por separado.
Si las implementaciones de dispositivos usan una parte del almacenamiento no extraíble para satisfacer los requisitos anteriores, hacen lo siguiente:
- DEBE usar la implementación de 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 con compatibilidad con el modo periférico USB, hacen lo siguiente:
- [C-3-1] DEBE proporcionar un mecanismo para acceder a los datos del 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 contenido multimedia de Android y
android.provider.MediaStore
. - PUEDE usar el almacenamiento masivo USB, pero DEBE usar el protocolo de transferencia de contenido multimedia para cumplir con este requisito.
Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y admiten el Protocolo de transferencia de contenido multimedia, hacen lo siguiente:
- DEBE ser compatible con el host de 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 móvil, a diferencia de la televisión, las implementaciones de dispositivos son las siguientes:
- [C-SR-1] SE RECOMIENDA ENFÉCTIVAMENTE implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlo accidentalmente puede provocar la pérdida o corrupción de datos.
Si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimiento de la batería o en otra cubierta protectora, las implementaciones del dispositivo son las siguientes:
- [C-SR-2] SE RECOMIENDA IMPLEMENTAR el almacenamiento adoptable.
7.7. USB
Si las implementaciones de dispositivos tienen un puerto USB, tienen las siguientes características:
- DEBE admitir el modo periférico USB y el modo host USB.
- DEBE admitir la inhabilitación de la señalización de datos a través de USB.
7.7.1. Modo periférico USB
Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo periférico, haz lo siguiente:
- [C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB tipo A o tipo C estándar.
- [C-1-2] DEBE informar el valor correcto de
iSerialNumber
en el descriptor de dispositivo estándar USB a través deandroid.os.Build.SERIAL
. - [C-1-3] DEBEN detectar los cargadores de 1.5 A y 3.0 A según el estándar de resistores tipo C y DEBEN detectar cambios en el anuncio si son compatibles con USB tipo C.
- [C-SR-1] El puerto DEBE usar un factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENFÉMTICAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
- [C-SR-2] El puerto DEBE estar ubicado en la parte inferior del dispositivo (según la orientación natural) o habilitar la rotación de pantalla de software para todas las apps (incluida la pantalla principal) para que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. Se RECOMIENDA ENFATICAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
- [C-SR-3] DEBE implementar la compatibilidad para extraer una corriente de 1.5 A durante el chirp y el tráfico HS, como se especifica en la especificación de carga de batería USB, revisión 1.2. Se RECOMIENDA ENFÉMTICAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
- [C-SR-4] SE RECOMIENDA NO admitir métodos de carga propietarios que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o alteren los roles de sink o fuente, ya que esto puede generar 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 indica como "RECOMENDADO", en versiones futuras de Android, es posible que exijamos que todos los dispositivos tipo C admitan la interoperabilidad completa con los cargadores tipo C estándar.
- [C-SR-5] SE RECOMIENDA URGENTEMENTE admitir la entrega de energía para los datos y el cambio de roles de energía cuando admiten USB tipo C y el modo host USB.
- DEBE admitir la entrega de energía para la carga de alto voltaje y la compatibilidad con modos alternativos, como la salida de pantalla.
- DEBE implementar la API y la especificación de Android Open Accessory (AOA) como se documenta en la documentación del SDK de Android.
Si las implementaciones de dispositivos incluyen un puerto USB y la especificación de AOA, hacen lo siguiente:
- [C-2-1] DEBE declarar la compatibilidad con la función de hardware
android.hardware.usb.accessory
. - [C-2-2] La clase de almacenamiento masivo en USB DEBE incluir la cadena "android" al final de la cadena
iInterface
de la descripción de la interfaz del almacenamiento masivo en USB.
7.7.2. Modo host USB
Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo host, tienen las siguientes características:
- [C-1-1] DEBE implementar la API de host USB de Android como se documenta en el SDK de Android y DEBE declarar la compatibilidad con la función de hardware
android.hardware.usb.host
. - [C-1-2] DEBEN implementar compatibilidad para conectar periféricos USB estándar. En otras palabras, DEBEN hacer lo siguiente:
- Tener un puerto tipo C integrado en el dispositivo o enviarlo con cables que adapten un puerto propietario integrado en el dispositivo a un puerto USB tipo C estándar (dispositivo USB tipo C)
- Tener un puerto tipo A integrado en el dispositivo o enviar con cables que adapten un puerto propietario integrado en el dispositivo a un puerto USB tipo A estándar
- Tener un puerto micro-AB integrado en el dispositivo, que DEBE enviarse con un cable que se adapte a un puerto tipo A estándar
- [C-1-3] NO DEBE enviarse con un adaptador que convierta puertos USB tipo A o micro-AB en un puerto tipo C (receptáculo).
- [C-SR-1] SE RECOMIENDA URGENTEMENTE 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 en modo host y anunciar una corriente de fuente de al menos 1.5 A, como se especifica en la sección de parámetros de terminación de la especificación de la versión 1.2 del cable y conector USB tipo C para conectores USB tipo C o usar el rango de corriente de salida del puerto descendente de carga (CDP) como se especifica en las especificaciones de carga de baterías USB, versión 1.2 para conectores Micro-AB.
- DEBEN implementar y admitir los estándares USB tipo C.
Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y la clase de audio USB, hacen lo siguiente:
- [C-2-1] DEBE ser compatible con la clase HID USB.
- [C-2-2] DEBE admitir la detección y asignación de los siguientes campos de datos HID especificados en las tablas de uso de HID USB y la solicitud de uso de comandos por voz a las constantes
KeyEvent
como se indica a continuación:- ID de uso de la página de uso (0xC) (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Página de uso (0xC) ID de uso (0x0E9):
KEYCODE_VOLUME_UP
- ID de uso de la página de uso (0xC) (0x0EA):
KEYCODE_VOLUME_DOWN
- ID de uso de la página de uso (0xC) (0x0CF):
KEYCODE_VOICE_ASSIST
- ID de uso de la página de uso (0xC) (0x0CD):
Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y el framework de acceso al almacenamiento (SAF), hacen lo siguiente:
- [C-3-1] DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia multimedia) conectado de forma remota y permitir el acceso a su contenido a través de los intents
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
yACTION_CREATE_DOCUMENT
. .
Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y USB tipo C, tienen las siguientes características:
- [C-4-1] DEBE implementar la funcionalidad de puerto de doble función como se define en la especificación USB tipo C (sección 4.5.1.3.3). En el caso de los puertos de doble rol, en los dispositivos que incluyen un conector de audio de 3.5 mm, la detección de la unidad de USB (modo host) PUEDE estar desactivada de forma predeterminada, pero el usuario DEBE poder habilitarla.
- [C-SR-2] SE RECOMIENDA ALTAMENTE que admita DisplayPort, DEBE admitir velocidades de datos SuperSpeed USB y SE RECOMIENDA ALTAMENTE que admita Power Delivery para el intercambio de roles de datos y energía.
- [C-SR-3] SE RECOMIENDA NO admitir el modo de accesorio de adaptador de audio como se describe en el Apéndice A de la Especificación de cables y conectores 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, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar la constante de función
android.hardware.microphone
. - [C-1-2] DEBEN cumplir con los requisitos de grabación de audio de la sección 5.4.
- [C-1-3] DEBEN cumplir con los requisitos de latencia de audio de la sección 5.6.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE 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, sucede lo siguiente:
- [C-2-1] NO DEBE informar la constante de función
android.hardware.microphone
. - [C-2-2] DEBE implementar la API de grabación de audio, al menos como no-ops, según la sección 7.
7.8.2. Salida de audio
Si las implementaciones de dispositivos incluyen una bocina o un puerto de salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 4 conductores de 3.5 mm o un puerto de modo host USB con clase de audio USB, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE informar la constante de función
android.hardware.audio.output
. - [C-1-2] DEBEN cumplir con los requisitos de reproducción de audio de la sección 5.5.
- [C-1-3] DEBEN cumplir con los requisitos de latencia de audio de la sección 5.6.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE admitir la reproducción de ultrasonido cercano, como se describe en la sección 7.8.3.
Si las implementaciones de dispositivos no incluyen una bocina o un puerto de salida de audio, sucede lo siguiente:
- [C-2-1] NO DEBE informar la función
android.hardware.audio.output
. - [C-2-2] DEBEN implementar las APIs relacionadas con la salida de audio como no-ops como mínimo.
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 la salida de audio a través de protocolos basados en radio, como Bluetooth, Wi-Fi o red celular, no califica como la inclusión de un "puerto de salida".
7.8.2.1. Puertos de audio analógicos
Para ser compatibles con los auriculares y otros accesorios de audio que usan el conector de audio de 3.5 mm en el ecosistema de Android, si las implementaciones de dispositivos incluyen uno o más puertos de audio analógico, deben cumplir con los siguientes requisitos:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que al menos uno de los puertos de audio sea un conector de audio de 4 conductores de 3.5 mm.
Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm de 4 conductores, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono.
- [C-1-2] DEBEN admitir conectores de audio TRRS con el orden de asignación de pines CTIA.
- [C-1-3] DEBE admitir la detección y la asignación a los códigos de teclas para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de masa en el enchufe de audio:
- 70 ohmios o menos:
KEYCODE_HEADSETHOOK
- 210-290 ohm:
KEYCODE_VOLUME_UP
- 360-680 ohm:
KEYCODE_VOLUME_DOWN
- 70 ohmios o menos:
- [C-1-4] DEBE activar
ACTION_HEADSET_PLUG
cuando se inserta 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 generar al menos 150 mV ± 10% de voltaje de salida en una impedancia de bocina de 32 ohmios.
- [C-1-6] DEBE tener un voltaje de polarización del micrófono entre 1.8 V y 2.9 V.
- [C-1-7] DEBE detectar y asignar al código de tecla el siguiente rango de impedancia equivalente entre el micrófono y los conductores de masa en el enchufe de audio:
- 110-180 ohmios:
KEYCODE_VOICE_ASSIST
- 110-180 ohmios:
- [C-SR-2] SE RECOMIENDA URGENTEMENTE admitir enchufes de audio con el orden de pines OMTP.
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE que admitan la grabación de audio desde auriculares estéreo con micrófono.
Si las implementaciones de dispositivos tienen un conector de audio de 4 conductores de 3.5 mm y admiten un micrófono, y transmiten el android.intent.action.HEADSET_PLUG
con el micrófono de valor adicional establecido como 1, hacen lo siguiente:
- [C-2-1] DEBE admitir la detección de micrófono en el accesorio de audio conectado.
7.8.2.2. Puertos de audio digital
Consulta el artículo 2.2.1 para conocer los requisitos específicos de los dispositivos.
7.8.3. Ultrasonido de proximidad
El audio cercano al ultrasonido es la banda de 18.5 kHz a 20 kHz.
Implementaciones de dispositivos:
- DEBEN informar correctamente la compatibilidad con la función de audio de ultrasonido cercano a través de la API de AudioManager.getProperty de la siguiente manera:
Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
es “verdadero”, las fuentes de audio VOICE_RECOGNITION
y UNPROCESSED
DEBEN cumplir con los siguientes requisitos:
- [C-1-1] La respuesta de potencia promedio del micrófono en la banda de 18.5 kHz a 20 kHz NO DEBE ser superior a 15 dB por debajo de la respuesta a 2 kHz.
- [C-1-2] La relación señal a ruido sin ponderar del micrófono de 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS DEBE ser de al menos 50 dB.
Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
es “verdadero”, haz lo siguiente:
- [C-2-1] La respuesta promedio del altavoz en el rango de 18.5 kHz a 20 kHz DEBE ser de al menos 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 las transmisiones de entrada y salida en dispositivos de mano, como se define por cero fallas medidas durante una prueba de un minuto por ruta. Prueba con la "Prueba de errores automatizada" de OboeTester.
La prueba requiere una llave de bucle invertido de audio, que se usa directamente en un conector de 3.5 mm o en combinación con un adaptador USB-C a 3.5 mm. DEBEN probarse todos los puertos de salida de audio.
Actualmente, OboeTester admite rutas de AAudio, por lo que se DEBEN probar las siguientes combinaciones para detectar fallas con AAudio:
Modo de rendimiento | Uso compartido | Tasa de muestreo de salida | En Chans | Out Chans |
---|---|---|---|---|
LOW_LATENCY | EXCLUSIVO | SIN ESPECIFICAR | 1 | 2 |
LOW_LATENCY | EXCLUSIVO | SIN ESPECIFICAR | 2 | 1 |
LOW_LATENCY | COMPARTIDO | SIN ESPECIFICAR | 1 | 2 |
LOW_LATENCY | COMPARTIDO | SIN ESPECIFICAR | 2 | 1 |
NINGUNO | COMPARTIDO | 48000 | 1 | 2 |
NINGUNO | COMPARTIDO | 48000 | 2 | 1 |
NINGUNO | COMPARTIDO | 44100 | 1 | 2 |
NINGUNO | COMPARTIDO | 44100 | 2 | 1 |
NINGUNO | COMPARTIDO | 16000 | 1 | 2 |
NINGUNO | COMPARTIDO | 16000 | 2 | 1 |
Una transmisión confiable DEBE cumplir con los siguientes criterios de relación señal/ruido (SNR) y distorsión armónica total (THD) para un tono sinusoidal de 2000 Hz.
Transductor | THD | SNR |
---|---|---|
bocina principal integrada, medida con un micrófono de referencia externo | < 3.0% | >= 50 dB |
micrófono principal incorporado, medido con una bocina de referencia externa | < 3.0% | >= 50 dB |
conectores analógicos integrados de 3.5 mm, probados con un adaptador de bucle invertido | < 1% | >= 60 dB |
Adaptadores USB incluidos con el teléfono, probados con un adaptador de bucle invertido | < 1.0% | >= 60 dB |
7.9. Realidad virtual
Android incluye APIs y herramientas para compilar aplicaciones de "realidad virtual" (RV), incluidas experiencias de RV móvil de alta calidad. Las implementaciones de dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.
7.9.1. Modo de realidad virtual
Android incluye compatibilidad con el modo de RV, una función que controla la renderización estereoscópica de las notificaciones y que inhabilita los componentes de la IU del sistema monocular mientras una aplicación de RV tiene el enfoque del usuario.
7.9.2. Modo de realidad virtual: Alto rendimiento
Si las implementaciones de dispositivos admiten el modo de RV, hacen lo siguiente:
- [C-1-1] DEBE tener al menos 2 núcleos físicos.
- [C-1-2] DEBE declarar la función
android.hardware.vr.high_performance
. - [C-1-3] DEBE admitir el modo de rendimiento sostenido.
- [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
- [C-1-5] DEBE admitir
android.hardware.vulkan.level
0. - DEBE admitir
android.hardware.vulkan.level
1 o una versión posterior. - [C-1-6] DEBES 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
yEGL_EXT_image_gl_colorspace
, y exponer las extensiones en la lista de extensiones de EGL disponibles. - [C-1-8] DEBES 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 de GL disponibles. - [C-SR-1] SE RECOMIENDA ENFATICAMENTE 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 de GL disponibles. - [C-SR-2] SE RECOMIENDA URGENTEMENTE que admitan Vulkan 1.1.
- [C-SR-3] SE RECOMIENDA URGENTEMENTE implementar
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
yVK_KHR_shared_presentable_image
, y exponerlos en la lista de extensiones de Vulkan disponibles. - [C-SR-4] SE RECOMIENDA ENFATICAMENTE exponer al menos una familia de colas de Vulkan en la que
flags
contengaVK_QUEUE_GRAPHICS_BIT
yVK_QUEUE_COMPUTE_BIT
, yqueueCount
sea de 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 renderización alterna de ojos del contenido de VR a 60 fps con dos contextos de renderización se muestre sin artefactos de seccionamientos visibles.
- [C-1-9] DEBE implementar la compatibilidad con las marcas
AHardwareBuffer
AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
yAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
, como se describe en el NDK. - [C-1-10] DEBE implementar la compatibilidad con
AHardwareBuffer
con cualquier combinación de las marcas de usoAHARDWAREBUFFER_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
yAHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] SE RECOMIENDA URGENTEMENTE admitir la asignación de
AHardwareBuffer
con más de una capa y las marcas y formatos especificados en C-1-10. - [C-1-11] DEBE admitir la decodificación de H.264 de al menos 3,840 x 2,160 a 30 fps, comprimido a un promedio de 40 Mbps (equivalente a 4 instancias de 1,920 x 1,080 a 30 fps y 10 Mbps o 2 instancias de 1,920 x 1,080 a 60 fps y 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 de
HardwarePropertiesManager.getDeviceTemperatures
y mostrar valores precisos de la temperatura de la piel. - [C-1-14] DEBE tener una pantalla incorporada, y su resolución DEBE ser de al menos 1,920 x 1,080.
- [C-SR-6] SE RECOMIENDA ENFATICAMENTE que tengas una resolución de pantalla de al menos 2560 × 1440.
- [C-1-15] La pantalla DEBE actualizarse a al menos 60 Hz mientras está en modo VR.
- [C-1-17] La pantalla DEBE admitir un modo de baja persistencia con una persistencia de ≤ 5 milisegundos, y la persistencia se define como la cantidad de tiempo durante la cual un píxel emite luz.
- [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE sección 7.4.3.
- [C-1-19] DEBE admitir y registrar correctamente 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 URGENTEMENTE admitir el tipo de canal directo
TYPE_HARDWARE_BUFFER
para todos los tipos de canales directos mencionados anteriormente. - [C-1-21] DEBE cumplir con los requisitos relacionados con el giroscopio, el acelerómetro y el magnetómetro para
android.hardware.hifi_sensors
, como se especifica en la sección 7.3.9. - [C-SR-8] SE RECOMIENDA URGENTEMENTE admitir la función
android.hardware.sensor.hifi_sensors
. - [C-1-22] DEBE tener una latencia de extremo a extremo de movimiento a fotones no superior a 28 milisegundos.
- [C-SR-9] SE RECOMIENDA ENFÉCTIVAMENTE que la latencia de extremo a extremo de movimiento a fotones no sea superior a 20 milisegundos.
- [C-1-23] DEBE tener una relación de primer fotograma, que es la relación entre el brillo de los píxeles en el primer fotograma después de una transición de negro a blanco y el brillo de los píxeles blancos en estado estable, de al menos el 85%.
- [C-SR-10] SE RECOMIENDA ENFATICAMENTE que tengan una relación de primer fotograma de al menos el 90%.
- PUEDE proporcionar un núcleo exclusivo a la aplicación en primer plano y PUEDE admitir la API de
Process.getExclusiveCores
para mostrar los números de los núcleos de CPU que son exclusivos de la aplicación en primer plano.
Si se admite el núcleo exclusivo, este hace lo siguiente:
- [C-2-1] NO DEBE permitir que se ejecuten otros procesos de espacio de usuario (excepto los controladores de dispositivos que usa la aplicación), pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.
7.10. Tecnología háptica
Cómo iniciar nuevos requisitos
Los dispositivos diseñados para llevarse en la mano o para usar en el cuerpo pueden incluir un actuador táctil de uso general, disponible para las aplicaciones con fines que incluyen llamar la atención a través de tonos de llamada, alarmas, notificaciones y comentarios táctiles generales.
Si las implementaciones de dispositivos NO incluyen un actuador táctil de uso general, hacen lo siguiente:
- [7.10/C] DEBE mostrar un valor falso para
Vibrator.hasVibrator()
.
Si las implementaciones de dispositivos incluyen al menos un actuador táctil de uso general, deben cumplir con los siguientes requisitos:
- [C-1-1] DEBE mostrar verdadero para
Vibrator.hasVibrator()
. - NO DEBE usar un actuador táctil (vibrador) de masa rotativa excéntrica (ERM).
- DEBE implementar todas las constantes públicas para la haptics clara en
android.view.HapticFeedbackConstants
, es decir, (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
yGESTURE_END
). - DEBE implementar todas las constantes públicas para la haptics clara en
android.os.VibrationEffect
, es decir, (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
yEFFECT_DOUBLE_CLICK
) y todas las constantesPRIMITIVE_*
públicas posibles para la haptics enriquecida enandroid.os.VibrationEffect.Composition
, es decir, (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Algunas de estas primitivas, comoLOW_TICK
ySPIN
, solo pueden ser posibles si el vibrador puede admitir frecuencias relativamente bajas. - DEBE seguir las instrucciones para asignar constantes públicas en
android.view.HapticFeedbackConstants
a las constantesandroid.os.VibrationEffect
recomendadas, con las relaciones de amplitud correspondientes. - DEBE usar estas asignaciones de constantes táctiles vinculadas.
- DEBEN seguir la evaluación de calidad para las APIs de
createOneShot()
ycreateWaveform()
. - DEBE verificar que el resultado de la API pública de
android.os.Vibrator.hasAmplitudeControl()
refleje correctamente las capacidades del vibrador. - DEBE verificar las capacidades de escalabilidad de amplitud ejecutando
android.os.Vibrator.hasAmplitudeControl()
.
Si las implementaciones de dispositivos siguen la asignación de constantes táctiles, hacen lo siguiente:
- DEBE verificar el estado de la implementación ejecutando las APIs de
android.os.Vibrator.areAllEffectsSupported()
yandroid.os.Vibrator.arePrimitivesSupported()
. - DEBE realizar una evaluación de calidad para las constantes táctiles.
- DEBE verificar y actualizar, si es necesario, la configuración de resguardo para primitivas no admitidas, como se describe en la guía de implementación para constantes.
- DEBE proporcionar compatibilidad con resguardo para mitigar el riesgo de fallas, como se describe aquí.
Fin de los nuevos requisitos
Consulta el artículo 2.2.1 para conocer los requisitos específicos de los dispositivos.
7.11. Clase de rendimiento de los medios
La clase de rendimiento multimedia de la implementación del dispositivo se puede obtener de la API de android.os.Build.VERSION_CODES.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 de 0 designa que el dispositivo no pertenece a una clase de rendimiento multimedia.
Si las implementaciones de dispositivos muestran un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, hacen lo siguiente:
[C-1-1] DEBE mostrar al menos un valor de
android.os.Build.VERSION_CODES.R
.[C-1-2] DEBE ser una implementación de dispositivo de mano.
[C-1-3] DEBEN cumplir con todos los requisitos de la "Clase de rendimiento del contenido multimedia" que se describen en la sección 2.2.7.
En otras palabras, la clase de rendimiento multimedia en Android T solo se define para dispositivos de mano en las versiones T, S o R.
Consulta la sección 2.2.7 para conocer los requisitos específicos del dispositivo.
8. Rendimiento y energía
Algunos criterios mínimos de rendimiento y energía son fundamentales para la experiencia del usuario y afectan las suposiciones de referencia que tendrían los desarrolladores cuando desarrollan una app.
8.1. Coherencia de la experiencia del usuario
Se puede proporcionar una interfaz de usuario fluida al usuario final si hay ciertos requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta coherentes para las aplicaciones y los juegos. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener requisitos medibles para la latencia de la interfaz de usuario y el cambio de tareas, como se describe en la sección 2.
8.2. Rendimiento de acceso a la E/S de archivos
Proporcionar un modelo de referencia común para un rendimiento de acceso a archivos coherente en el almacenamiento de datos privados de la aplicación (partición /data
) permite a los desarrolladores de apps establecer una expectativa adecuada que ayudaría a su diseño de 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: Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 10 MB.
- Rendimiento de las operaciones de escritura aleatorias: Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 4 KB.
- Rendimiento de lectura secuencial: Se mide leyendo un archivo de 256 MB con un búfer de escritura de 10 MB.
- Rendimiento de lectura aleatoria Se mide leyendo un archivo de 256 MB con 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 (p.ej., App Standby Bucket, Doze) o extienden las funciones para aplicar restricciones más estrictas que el bucket de App Standby RESTRINGIDO, sucede lo siguiente:
- [C-1-1] NO DEBE desviarse de la implementación de AOSP para el disparo, el mantenimiento, los algoritmos de activación y el uso de la configuración del sistema global o DeviceConfig de los modos de ahorro de energía de App Standby y Descanso.
- [C-1-2] NO DEBE desviarse de la implementación de AOSP para el uso de la configuración global o DeviceConfig para administrar la limitación de tareas, alarmas y redes para las apps en cada bucket de App Standby.
- [C-1-3] NO DEBE desviarse de la implementación de AOSP para la cantidad de intervalos App Standby que se usan para App Standby.
- [C-1-4] DEBE implementar buckets de App Standby y Descanso como se describe en Administración de energía.
- [C-1-5] DEBE mostrar
true
paraPowerManager.isPowerSaveMode()
cuando el dispositivo está en modo de ahorro de energía. - [C-1-6] DEBE proporcionar indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso, o de cualquier optimización de batería, y DEBE implementar el intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS para pedirle al usuario que permita que una app ignore las optimizaciones de batería.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE proporcionar indicaciones visuales para el usuario para habilitar y inhabilitar la función de ahorro de batería.
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE que se proporcione una indicación visual para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.
Si las implementaciones de dispositivos extienden las funciones de administración de energía que se incluyen en AOSP y esa extensión aplica restricciones más estrictas que el bucket de App Standby poco frecuente, consulta la sección 3.5.1.
Además de los modos de ahorro de energía, las implementaciones de dispositivos Android PUEDEN implementar cualquiera de los 4 estados de energía de suspensión o todos ellos, según se define en la Interfaz avanzada de configuración y energía (ACPI).
Si las implementaciones de dispositivos implementan estados de energía S4 como los define el ACPI, hacen lo siguiente:
- [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 (p.ej., cerrando una tapa que forma parte físicamente del dispositivo o apagando un vehículo o una televisión) y antes de que el usuario vuelva a activar el dispositivo (p.ej., 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 como los define la ACPI, hacen lo siguiente:
[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 (p.ej., la pantalla o la CPU).
Por el contrario, DEBEN 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 en ejecución a través dePARTIAL_WAKE_LOCK
, el dispositivo NO DEBE entrar en el 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 apps de terceros implementan a través de JobScheduler o se entrega Firebase Cloud Messaging a apps de terceros, el dispositivo DEBE salir del estado S3, a menos que el usuario lo haya puesto en un estado inactivo. Estos no son ejemplos exhaustivos, y AOSP implementa indicadores de activación extensos que activan un despertar desde este estado.
8.4. Contabilización del consumo de energía
Una contabilización y generación de informes más precisa del consumo de energía le proporciona al desarrollador de apps los incentivos y las herramientas para optimizar el patrón de uso de energía de la aplicación.
Implementaciones de dispositivos:
- [C-SR-1] SE RECOMIENDA ENFÉCTIVAMENTE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del proyecto de código abierto de Android.
- [C-SR-2] SE RECOMIENDA ENFATICAMENTE informar todos los valores de consumo de energía en miliamperes por hora (mAh).
- [C-SR-3] SE RECOMIENDA ENFATICAMENTE informar el consumo de energía de la CPU por UID de cada proceso.
El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo de kernel
uid_cputime
. - [C-SR-4] SE RECOMIENDA ENFATICAMENTE que el desarrollador de la app haga que este consumo de energía esté disponible a través del comando de shell
adb shell dumpsys batterystats
. - DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo de energía del componente de hardware a una aplicación.
8.5. Rendimiento coherente
El rendimiento puede fluctuar considerablemente en las apps de alto rendimiento de larga duración, ya sea debido a las otras apps que se ejecutan en segundo plano o a la limitación de la CPU debido a los límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea capaz, la aplicación en primer plano superior pueda solicitar que el sistema optimice la asignación de los recursos para abordar esas fluctuaciones.
Implementaciones de dispositivos:
[C-0-1] DEBE informar la compatibilidad con el modo de rendimiento sostenido con precisión a través del método de la API de
PowerManager.isSustainedPerformanceModeSupported()
.DEBE admitir el modo de rendimiento sostenido.
Si las implementaciones de dispositivos informan compatibilidad con el modo de rendimiento sostenido, hacen lo siguiente:
- [C-1-1] DEBE proporcionarle a la aplicación en primer plano un nivel de rendimiento coherente durante al menos 30 minutos, cuando la app lo solicite.
- [C-1-2] DEBE respetar la API de
Window.setSustainedPerformanceMode()
y otras APIs relacionadas.
Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, tienen las siguientes características:
- DEBE proporcionar al menos un núcleo exclusivo que la aplicación en primer plano superior pueda reservar.
Si las implementaciones de dispositivos admiten reservar un núcleo exclusivo para la aplicación en primer plano, hacen lo siguiente:
- [C-2-1] DEBE informar a través del método de la API de
Process.getExclusiveCores()
los números de ID de los núcleos exclusivos que puede reservar la aplicación en primer plano superior. - [C-2-2] NO DEBE permitir ningún proceso de espacio de usuario, excepto los controladores de dispositivos que usa la aplicación para ejecutarse 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, sucede lo siguiente:
- [C-3-1] DEBE mostrar una lista vacía a través del método de la API
Process.getExclusiveCores()
.
9. Compatibilidad de modelos de seguridad
Implementaciones de dispositivos:
[C-0-1] DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, como se define en el documento de referencia de seguridad y permisos de las APIs en la documentación para desarrolladores de Android.
[C-0-2] DEBE admitir la instalación de aplicaciones con firma propia sin requerir permisos ni certificados adicionales de terceros o autoridades.
Si las implementaciones de dispositivos declaran la función android.hardware.security.model.compatible
, hacen lo siguiente:
- [C-1-1] DEBE admitir los requisitos que se indican 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 aplicar cada permiso y rol definido como se describe en la documentación del SDK. No se pueden omitir, alterar 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
dePROTECTION_FLAG_PRIVILEGED
SOLO DEBEN otorgarse a las apps preinstaladas en las rutas de acceso privilegiadas de la imagen del sistema (así como a los archivos APEX) y estar dentro del subconjunto de los permisos de la lista de entidades permitidas de forma explícita para cada app. La implementación de AOSP cumple con este requisito leyendo y respetando los permisos de la lista de entidades permitidas de cada app de los archivos en la ruta de accesoetc/permissions/
y usando la ruta de accesosystem/priv-app
como la ruta de acceso privilegiada.
Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución.
Las aplicaciones con targetSdkVersion
> 22 los solicitan durante el tiempo de ejecución.
Implementaciones de dispositivos:
- [C-0-3] DEBE mostrar una interfaz dedicada para que el usuario decida si otorgar 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 solo una implementación de ambas interfaces de usuario.
[C-0-5] NO DEBE otorgar ningún permiso de tiempo de ejecución a las apps, a menos que se cumpla una de las siguientes condiciones:
- Se instalan en el momento del envío del dispositivo Y
Se puede obtener el consentimiento del usuario antes de que la aplicación use el permiso.
O
Los permisos del entorno de ejecución se otorgan mediante la política de otorgamiento de permisos predeterminada o por tener un rol de la plataforma.
[C-0-6] DEBE otorgar el permiso
android.permission.RECOVER_KEYSTORE
solo a las apps del sistema que registren un agente de recuperación protegido de forma adecuada. Un Agente de recuperación protegido de forma adecuada se define como un agente de software integrado 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 de Key Vault de Google Cloud para evitar ataques de fuerza bruta en el factor de conocimiento de la pantalla de bloqueo.
Implementaciones de dispositivos:
[C-0-7] DEBE cumplir con las propiedades del permiso de ubicación de Android cuando una app solicite datos de ubicación o actividad física a través de la API estándar de Android o un mecanismo propietario. Estos datos incluyen, entre otros, los siguientes:
- La ubicación del dispositivo (p. ej., latitud y longitud), como se describe en la sección 9.8.8
- Información que se puede usar para determinar o estimar la ubicación del dispositivo (p.ej., SSID, BSSID, ID de celda o ubicación de la red a la que está conectado el dispositivo).
- La actividad física del usuario o la clasificación de la actividad física
Específicamente, las implementaciones de dispositivos tienen las siguientes características:
- [C-0-8] DEBEN obtener el consentimiento del usuario para permitir que una app acceda a los datos de ubicación o actividad física.
- [C-0-9] DEBE otorgar un permiso de tiempo de ejecución SOLO a la app que tenga permisos suficientes, como se describe en el SDK.
Por ejemplo, TelephonyManager#getServiceState requiere
android.permission.ACCESS_FINE_LOCATION
).
Las únicas excepciones a las propiedades de permisos de ubicación de Android anteriores son para las apps que no acceden a la ubicación para obtener o identificar la ubicación del usuario; específicamente:
- Cuando las apps tienen el permiso
RADIO_SCAN_WITHOUT_LOCATION
. - Para la configuración del dispositivo, en la que las apps del sistema tienen el permiso
NETWORK_SETTINGS
oNETWORK_SETUP_WIZARD
.
Los permisos se pueden marcar como restringidos para alterar su comportamiento.
[C-0-10] Los permisos marcados con la marca
hardRestricted
NO DEBEN otorgarse a una app, a menos que se cumplan las siguientes condiciones:- Un archivo APK de la app está en la partición del sistema.
- El usuario asigna un rol asociado con los permisos
hardRestricted
a una app. - El instalador otorga el
hardRestricted
a una app. - Se le otorga el permiso
hardRestricted
a una app en una versión anterior de Android.
[C-0-11] Las apps que tienen un permiso
softRestricted
DEBEN obtener solo acceso limitado y NO DEBEN obtener acceso completo hasta que se incluyan en la lista de entidades permitidas, como se describe en el SDK, donde se define el acceso completo y limitado para cada permisosoftRestricted
(por ejemplo,READ_EXTERNAL_STORAGE
).[C-0-12] NO DEBE proporcionar ninguna función ni API personalizada para omitir las restricciones de permisos definidas en las APIs de setPermissionPolicy y setPermissionGrantState.
[C-0-13] DEBEN usar las APIs de AppOpsManager para registrar y hacer un seguimiento de cada acceso programático a los datos protegidos por permisos peligrosos de las actividades y los servicios de Android.
[C-0-14] SOLO se deben asignar roles a aplicaciones con funciones que cumplan con los requisitos del rol.
[C-0-15] NO DEBE definir roles que sean duplicados o que superen la funcionalidad de los roles definidos por la plataforma.
Si los dispositivos informan android.software.managed_users
, sucede lo siguiente:
- [C-1-1] El administrador NO DEBE otorgar los siguientes permisos de forma silenciosa:
- Ubicación (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Cámara (CAMERA)
- Micrófono (RECORD_AUDIO)
- Sensor corporal (BODY_SENSORS)
- Actividad física (ACTIVITY_RECOGNITION)
Si las implementaciones de dispositivos proporcionan una indicación visual para que el usuario elija qué apps pueden dibujar sobre otras con una actividad que controla el intent ACTION_MANAGE_OVERLAY_PERMISSION
, hacen lo siguiente:
- [C-2-1] DEBE garantizar que todas las actividades con filtros de intents para el intent
ACTION_MANAGE_OVERLAY_PERMISSION
tengan la misma pantalla de IU, independientemente de la app que inicie o de la información que proporcione.
Si las implementaciones de dispositivos informan android.software.device_admin, hacen lo siguiente:
- [C-3-1] DEBE mostrar una renuncia de responsabilidad durante la configuración del dispositivo completamente administrado (configuración del propietario del dispositivo) que indique que el administrador de TI podrá permitir que las apps controlen la configuración del teléfono, incluidos el micrófono, la cámara y la ubicación, con opciones para que el usuario continúe con la configuración o salga de ella, a MENOS que el administrador haya inhabilitado el control de permisos en el dispositivo.
Si las implementaciones de dispositivos preinstalan paquetes que contienen alguno de los roles de System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence o System Visual Intelligence, los paquetes hacen lo siguiente:
- [C-4-1] DEBEN cumplir con todos los requisitos que se describen para las implementaciones de dispositivos en las secciones
"9.8.6 Captura de contenido""9.8.6 Datos ambientales y a nivel del SO y 9.8.15 Implementaciones de APIs en zona de pruebas".
- [C-4-2] NO DEBE tener el permiso android.permission.INTERNET. Esto es más estricto que la RECOMENDACIÓN FUERTE que se indica en la sección 9.8.6.
- [C-4-3] NO DEBE vincularse a otras apps, excepto a las siguientes apps del sistema: Bluetooth, Contactos, Media, Telefonía, SystemUI y componentes que proporcionan APIs de Internet. Esto es más estricto que lo que se RECOMIENDA ENFATICAMENTE en el artículo 9.8.6.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos incluyen una aplicación predeterminada para admitir VoiceInteractionService
, hacen lo siguiente:
- [C-5-1] NO DEBE otorgar
ACCESS_FINE_LOCATION
como la opción predeterminada para esa aplicación.
Fin de los nuevos requisitos
9.2. Aislamiento de UID y procesos
Implementaciones de dispositivos:
- [C-0-1] DEBE admitir el modelo de zona de pruebas de la aplicación para Android, en el que cada aplicación se ejecuta como un UID de estilo Unix único y en un proceso independiente.
- [C-0-2] DEBE admitir la ejecución de varias aplicaciones como el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas y compiladas correctamente, como se define en la referencia de seguridad y permisos.
9.3. Permisos del sistema de archivos
Implementaciones de dispositivos:
- [C-0-1] DEBE admitir el modelo de permisos de acceso a archivos de Android como se define en la referencia de seguridad y permisos.
9.4. Entornos de ejecución alternativos
Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de seguridad y permisos de Android, incluso si incluyen entornos de ejecución que ejecutan aplicaciones con algún otro software o tecnología que no sea el formato ejecutable de Dalvik o el código nativo. En otras palabras:
[C-0-1] Los tiempos de ejecución alternativos DEBEN ser aplicaciones para Android y cumplir con el modelo de seguridad estándar de Android, como se describe en la sección 9.
[C-0-2] Los tiempos de ejecución alternativos NO DEBEN tener acceso a recursos protegidos por permisos que no se solicitaron 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 usen funciones protegidas por permisos de Android restringidos a las 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 usan un tiempo de ejecución alternativo NO DEBEN volver a usar la zona de pruebas de ninguna otra app 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 con acceso a las zonas de pruebas correspondientes a otras aplicaciones para Android, ni otorgarlo ni recibirlo.
[C-0-6] Los tiempos de ejecución alternativos NO DEBEN iniciarse con privilegios del superusuario (root) ni otorgarlos a otras aplicaciones, ni otorgarles privilegios a otras aplicaciones.
[C-0-7] Cuando se incluyen los archivos
.apk
de tiempos de ejecución alternativos en la imagen del sistema de las implementaciones de dispositivos, DEBEN firmarse con una clave distinta de la que se usa para firmar otras aplicaciones incluidas con las implementaciones de dispositivos.[C-0-8] Cuando se instalan aplicaciones, los entornos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que usa la aplicación.
[C-0-9] Cuando una aplicación necesita usar un recurso de dispositivo para el que hay un permiso de Android correspondiente (como la cámara, el GPS, etcétera), el entorno de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.
[C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, el entorno de ejecución DEBE enumerar todos los permisos que tiene el entorno de ejecución cuando se instala cualquier aplicación que lo use.
Los tiempos de ejecución alternativos DEBEN instalar apps a través de
PackageManager
en zonas de pruebas de Android separadas (IDs de usuario de Linux, etcétera).Los entornos de ejecución alternativos PUEDEN proporcionar una sola zona de pruebas de Android que comparten todas las aplicaciones que usan el entorno de ejecución alternativo.
9.5. Compatibilidad con varios usuarios
Android incluye compatibilidad con varios usuarios y proporciona compatibilidad con el aislamiento completo de usuarios y la clonación de perfiles de usuario con aislamiento parcial(es decir, un solo perfil de usuario adicional de tipo android.os.usertype.profile.CLONE
).
- Las implementaciones de dispositivos PUEDEN, pero NO DEBEN, habilitar el modo multiusuario si usan medios extraíbles para el almacenamiento externo principal.
Si las implementaciones de dispositivos incluyen compatibilidad con varios usuarios, deben cumplir con los siguientes requisitos:
- [C-1-2] Para cada usuario, DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, como se define en el documento de referencia de seguridad y permisos de las APIs.
- [C-1-3] DEBEN tener directorios de almacenamiento de aplicaciones compartidos (también conocidos como
/sdcard
) separados y aislados para cada instancia de usuario. - [C-1-4] DEBEN garantizar que las aplicaciones que pertenecen a un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer ni escribir en los archivos que pertenecen a ningún otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
- [C-1-5] DEBE encriptar el contenido de la tarjeta SD cuando se habilita el modo multiusuario con una clave almacenada solo en medios no extraíbles a los que solo pueda acceder el sistema si las implementaciones de dispositivos usan medios extraíbles para las APIs de almacenamiento externo. Como esto hará que una PC host no pueda leer el contenido multimedia, las implementaciones de dispositivos deberán cambiar a MTP o a un sistema similar para proporcionar a las PCs host acceso a los datos del usuario actual.
Si las implementaciones de dispositivos incluyen compatibilidad con varios usuarios, para todos los usuarios, excepto los creados específicamente para ejecutar instancias dobles de la misma app, sucede lo siguiente:
- [C-2-1] DEBEN tener directorios de almacenamiento de aplicaciones compartidos (también conocidos como /sdcard) separados y aislados para cada instancia de usuario.
- [C-2-2] DEBE garantizar que las aplicaciones que son propiedad de un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer ni escribir en los archivos que pertenecen a cualquier otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
Las implementaciones de dispositivos PUEDEN crear un solo perfil de usuario adicional de tipo android.os.usertype.profile.CLONE
para el usuario principal (y solo para el usuario principal) con el fin de ejecutar instancias dobles de la misma app. Estas instancias dobles comparten almacenamiento parcialmente aislado, se presentan al usuario final en el selector al mismo tiempo y aparecen en la misma vista de elementos recientes.
Por ejemplo, se podría usar para admitir que el usuario instale dos instancias separadas de una sola app en un dispositivo con doble SIM.
Si las implementaciones de dispositivos crean el perfil de usuario adicional que se analizó anteriormente, hacen lo siguiente:
- [C-3-1] SOLO DEBE proporcionar acceso al almacenamiento o a los datos a los que ya se puede acceder desde el perfil de usuario superior o que son propiedad directa de este perfil de usuario adicional.
- [C-3-2] NO DEBE tener este perfil de trabajo.
- [C-3-3] DEBEN tener directorios de datos de apps privados aislados de la cuenta de usuario superior.
- [C-3-4] NO DEBE permitir que se cree el perfil de usuario adicional si hay un propietario del dispositivo aprovisionado (consulta la sección 3.9.1) ni permitir que se aprovisione un propietario del dispositivo sin quitar primero el perfil de usuario adicional.
Cómo iniciar nuevos requisitos
Si las implementaciones de dispositivos crean el perfil de usuario adicional que se analizó anteriormente, hacen lo siguiente:
- [C-4-5] DEBEN distinguirse visualmente los íconos de la aplicación de instancia doble cuando se presentan a los usuarios.
- [C-4-6] DEBE proporcionar una indicación visual para el usuario para borrar todos los datos del perfil clonado.
- [C-4-7] DEBEN desinstalar todas las apps de Clone, borrar los directorios de datos privados de la app y su contenido, y borrar los datos del perfil de Clone cuando el usuario elija borrar todos los datos del perfil de Clone.
- DEBE solicitarle al usuario que borre todos los datos del perfil clonado cuando se borre la última app clonada.
- [C-4-8] DEBE informar al usuario que los datos de la app se borrarán cuando se desinstale la aplicación clonada o proporcionarles una opción para que los conserven cuando se desinstale la aplicación del dispositivo.
- [C-4-9] DEBEN borrar los directorios de datos privados de la app y su contenido cuando el usuario elige borrar los datos durante la desinstalación.
[C-4-1] DEBE permitir que las aplicaciones del usuario principal del dispositivo controlen los siguientes intents que se originan en el perfil adicional:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] DEBE heredar todas las restricciones de usuario de la política del dispositivo y las restricciones no de usuario seleccionadas(lista a continuación) aplicadas al usuario principal del dispositivo a este perfil de usuario adicional.
[C-4-3] SOLO debe permitir escribir contactos desde este perfil adicional a través de los siguientes intents:
[C-4-4] NO DEBE tener sincronizaciones de contactos en ejecución para las aplicaciones que se ejecutan en este perfil de usuario adicional.
- [C-4-14] DEBE tener una administración de permisos y almacenamiento independientes para las aplicaciones que se ejecutan en este perfil adicional.
- [C-4-5] SOLO se DEBEN permitir aplicaciones en el perfil adicional que tengan una actividad de selector para acceder a los contactos a los que ya se puede acceder desde el perfil de usuario principal.
Fin de los nuevos requisitos
9.6. Advertencia sobre SMS premium
Android incluye compatibilidad para advertir a los usuarios sobre cualquier mensaje SMS premium saliente. Los SMS premium son mensajes de texto que se envían a un servicio registrado con un operador que puede generar un cargo para el usuario.
Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony
, hacen lo siguiente:
- [C-1-1] DEBE advertir a los usuarios antes de enviar un mensaje SMS a números
identificados por expresiones regulares definidas en el archivo
/data/misc/sms/codes.xml
del dispositivo. El Proyecto de código abierto de Android upstream proporciona una implementación que satisface este requisito.
9.7. Funciones de seguridad
Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad en el kernel y la plataforma, como se describe a continuación.
La zona de pruebas de Android incluye funciones que usan el sistema de control de acceso obligatorio (MAC) de Security-Enhanced Linux (SELinux), la zona de pruebas de seccomp y otras funciones de seguridad en el kernel de Linux. Implementaciones de dispositivos:
- [C-0-1] DEBE mantener la compatibilidad con las aplicaciones existentes, incluso cuando se implemente SELinux o cualquier otra función de seguridad debajo del framework de Android.
- [C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta una violación de seguridad y la función de seguridad implementada debajo del framework de Android la bloquea correctamente, pero PUEDE tener una interfaz de usuario visible cuando se produce una violación de seguridad desbloqueada que genera un exploit exitoso.
- [C-0-3] NO DEBE permitir que el usuario o el desarrollador de la app configuren SELinux ni ninguna otra función de seguridad implementada debajo del framework de Android.
- [C-0-4] NO DEBE permitir que una aplicación que pueda afectar a otra a través de una API (como una API de administración de dispositivos) configure una política que rompa la compatibilidad.
- [C-0-5] DEBE dividir el framework multimedia en varios procesos para que sea posible otorgar acceso más limitado a cada proceso, como se describe en el sitio del Proyecto de código abierto de Android.
- [C-0-6] DEBE implementar un mecanismo de zona de pruebas de aplicaciones del kernel que permita filtrar las llamadas del sistema con una política configurable desde programas de varios subprocesos. El Proyecto de código abierto de Android upstream cumple con este requisito habilitando seccomp-BPF con sincronización de grupos de subprocesos (TSYNC), como se describe en la sección Configuración del kernel de source.android.com.
Las funciones de integridad del kernel y autoprotección son fundamentales para la seguridad de Android. Implementaciones de dispositivos:
- [C-0-7] DEBE implementar mecanismos de protección contra desbordamientos de búfer de pila del kernel.
CC_STACKPROTECTOR_REGULAR
yCONFIG_CC_STACKPROTECTOR_STRONG
son ejemplos de esos mecanismos. - [C-0-8] DEBEN implementar protecciones estrictas de memoria del kernel en las que el código ejecutable sea de solo lectura, los datos de solo lectura no sean ejecutables ni escribibles, y los datos escribibles no sean ejecutables (p.ej.,
CONFIG_DEBUG_RODATA
oCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] DEBEN implementar la verificación de límites de tamaño de objetos estáticos y dinámicos de copias entre el espacio de usuario y el espacio del kernel (p.ej.,
CONFIG_HARDENED_USERCOPY
) en dispositivos que se envían originalmente con el nivel de API 28 o superior. - [C-0-10] NO DEBE ejecutar memoria de espacio de usuario cuando se ejecuta en el modo de kernel (p.ej., PXN de hardware o emulado a través de
CONFIG_CPU_SW_DOMAIN_PAN
oCONFIG_ARM64_SW_TTBR0_PAN
) en dispositivos que se envían originalmente con el nivel de API 28 o versiones posteriores. - [C-0-11] NO DEBE leer ni escribir memoria de espacio de usuario en el kernel fuera de las APIs de acceso normales de copia de usuario (p.ej., PAN de hardware o emulado a través de
CONFIG_CPU_SW_DOMAIN_PAN
oCONFIG_ARM64_SW_TTBR0_PAN
) en dispositivos que se envían originalmente con el nivel de API 28 o superior. - [C-0-12] DEBE implementar el aislamiento de la tabla de páginas del kernel si el hardware es vulnerable a CVE-2017-5754 en todos los dispositivos que se envían originalmente con el nivel de API 28 o versiones posteriores (p.ej.,
CONFIG_PAGE_TABLE_ISOLATION
oCONFIG_UNMAP_KERNEL_AT_EL0
). [C-0-13] DEBE implementar el endurecimiento de la predicción de ramas si el hardware es vulnerable a CVE-2017-5715 en todos los dispositivos que se envían originalmente con el nivel de API 28 o versiones posteriores (p.ej.,
CONFIG_HARDEN_BRANCH_PREDICTOR
).[C-SR-1] SE RECOMIENDA ENFÉCTIVAMENTE que los datos del kernel que se escriben solo durante la inicialización se marquen como de solo lectura después de la inicialización (p.ej.,
__ro_after_init
).[C-SR-2] SE RECOMIENDA ENFATICAMENTE aleatorizar el diseño del código y la memoria del kernel, y evitar exposiciones que comprometan la aleatorización (p.ej.,
CONFIG_RANDOMIZE_BASE
con entropía del bootloader a través de/chosen/kaslr-seed Device Tree node
oEFI_RNG_PROTOCOL
).[C-SR-3] SE RECOMIENDA ENFATICAMENTE habilitar la integridad del flujo de control (CFI) en el kernel para proporcionar protección adicional contra los ataques de reutilización de código (p.ej.,
CONFIG_CFI_CLANG
yCONFIG_SHADOW_CALL_STACK
).[C-SR-4] SE RECOMIENDA NO inhabilitar la integridad del flujo de control (CFI), la pila de llamadas en sombra (SCS) ni la limpieza de desbordamiento de números enteros (IntSan) en los componentes que la tienen habilitada.
[C-SR-5] SE RECOMIENDA ENFATICAMENTE habilitar CFI, SCS e IntSan para cualquier componente adicional del espacio de usuario sensible a la seguridad, como se explica en CFI y IntSan.
[C-SR-6] SE RECOMIENDA ENFATICAMENTE que habilites la inicialización de la pila en el kernel para evitar el uso de variables locales no inicializadas (
CONFIG_INIT_STACK_ALL
oCONFIG_INIT_STACK_ALL_ZERO
). Además, las implementaciones de dispositivos NO DEBEN suponer el valor que usa el compilador para inicializar las variables locales.[C-SR-7] SE RECOMIENDA ENFATICAMENTE que habilites la inicialización del montón en el kernel para evitar el uso de asignaciones de montón no inicializadas (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) y NO DEBES suponer el valor que usa el kernel para inicializar esas asignaciones.
Si las implementaciones de dispositivos usan un kernel de Linux que es compatible con SELinux, hacen lo siguiente:
- [C-1-1] DEBE implementar SELinux.
- [C-1-2] DEBE configurar SELinux en el modo de aplicación global.
- [C-1-3] DEBEN configurar todos los dominios en modo de aplicación forzosa. No se permiten dominios de modo permisivo, incluidos los dominios específicos de un dispositivo o proveedor.
- [C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas de neverallow presentes en la carpeta system/sepolicy proporcionada en el Proyecto de código abierto de Android (AOSP) upstream, y la política DEBE compilarse con todas las reglas de neverallow presentes, tanto para los dominios de SELinux de AOSP como para los dominios específicos del dispositivo o el proveedor.
- [C-1-5] DEBEN ejecutar aplicaciones de terceros segmentadas para el nivel de API 28 o versiones posteriores en zonas de pruebas de SELinux por aplicación con restricciones de SELinux por app en el directorio de datos privados de cada aplicación.
- DEBE retener la política predeterminada de SELinux proporcionada en la carpeta system/sepolicy del Proyecto de código abierto de Android upstream y solo agregar más a esta política para su propia configuración específica del dispositivo.
Si las implementaciones de dispositivos usan un kernel que no es Linux o Linux sin SELinux, hacen lo siguiente:
- [C-2-1] DEBE usar un sistema de control de acceso obligatorio que sea equivalente a SELinux.
Si las implementaciones de dispositivos usan dispositivos de E/S capaces de DMA, hacen lo siguiente:
- [C-SR-9] SE RECOMIENDA ENFATICAMENTE que se aísle cada dispositivo de E/S capaz de DMA con un IOMMU (p.ej., el SMMU de ARM).
Android contiene varias funciones de defensa en profundidad que son fundamentales para la seguridad del dispositivo. Además, Android se enfoca en reducir las clases clave de errores comunes que contribuyen a la baja calidad y seguridad.
Para reducir los errores de memoria, las implementaciones de dispositivos hacen lo siguiente:
- [C-SR-10] SE RECOMIENDA ENFATICAMENTE que se prueben con herramientas de detección de errores de memoria del espacio de usuario, como MTE para dispositivos ARMv9, HWASan para dispositivos ARMv8 y versiones posteriores, o ASan para otros tipos de dispositivos.
- [C-SR-11] SE RECOMIENDA ENFATICAMENTE que se prueben con herramientas de detección de errores de memoria del kernel, como KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS para dispositivos ARMv9, CONFIG_KASAN_SW_TAGS para dispositivos ARMv8 o CONFIG_KASAN_GENERIC para otros tipos de dispositivos).
- [C-SR-12] SE RECOMIENDA ENFATICAMENTE que uses herramientas de detección de errores de memoria en producción, como MTE, GWP-ASan y KFENCE.
Si las implementaciones de dispositivos usan un TEE basado en Arm TrustZone, hacen lo siguiente:
- [C-SR-13] SE RECOMIENDA ENFATICAMENTE usar un protocolo estándar para el uso compartido de memoria entre Android y el TEE, como Arm Firmware Framework para Armv8-A (FF-A).
- [C-SR-14] SE RECOMIENDA ENFATICAMENTE que se restrinja el acceso de las aplicaciones de confianza solo a la memoria que se compartió de forma explícita con ellas a través del protocolo anterior. Si el dispositivo es compatible con el nivel de excepción S-EL2 de Arm, el administrador de particiones seguras debe aplicarlo. De lo contrario, el SO de TEE debería aplicarlo.
Cómo iniciar nuevos requisitos
Una tecnología de seguridad de la memoria es una tecnología que mitiga al menos las siguientes clases de errores con una probabilidad alta (> 90%) en aplicaciones que usan la opción de manifiesto android:memtagMode
:
- desbordamiento del búfer del montón
- uso después de la liberación
- liberación doble
- liberación libre (sin un puntero no malloc)
Implementaciones de dispositivos:
- [C-SR-15] SE RECOMIENDA CONFIGURAR
ro.arm64.memtag.bootctl_supported
.
Si las implementaciones de dispositivos establecen la propiedad del sistema ro.arm64.memtag.bootctl_supported
como verdadera, hacen lo siguiente:
[C-3-1] DEBE permitir que la propiedad del sistema
arm64.memtag.bootctl
acepte una lista de los siguientes valores separados por comas, con el efecto deseado aplicado en el siguiente reinicio:memtag
: Se habilitó una tecnología de seguridad de la memoria como se definió anteriormente.memtag-once
: Una tecnología de seguridad de la memoria, como se definió anteriormente, se habilita de forma transitoria y se inhabilita automáticamente al próximo reinicio.memtag-off
: Se inhabilitó una tecnología de seguridad de la memoria como se definió anteriormente.
[C-3-2] DEBE permitir que el usuario de la shell establezca
arm64.memtag.bootctl
.[C-3-3] DEBE permitir que cualquier proceso lea
arm64.memtag.bootctl
.[C-3-4] DEBE establecer
arm64.memtag.bootctl
en el estado solicitado actualmente durante el inicio. También DEBE actualizar la propiedad si la implementación del dispositivo permite modificar el estado sin cambiar la propiedad del sistema.[C-SR-16] SE RECOMIENDA ENFATICAMENTE que muestres una configuración de desarrollador que establezca memtag-once y reinicie el dispositivo. Con un bootloader compatible, el Proyecto de código abierto de Android cumple con los requisitos anteriores a través del protocolo de bootloader MTE.
- [C-SR-17] SE RECOMIENDA ENFATICAMENTE que se muestre un parámetro de configuración en el menú de configuración de seguridad que permita al usuario habilitar
memtag
.
Fin de los nuevos requisitos
9.8. Privacidad
9.8.1. Historial de uso
Android almacena el historial de las elecciones del usuario y lo administra a través de UsageStatsManager.
Implementaciones de dispositivos:
- [C-0-1] DEBE mantener un período de retención razonable de ese historial de usuario.
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE mantener el período de retención de 14 días como se configuró de forma predeterminada en la implementación de AOSP.
Android almacena los eventos del sistema con los identificadores StatsLog
y administra ese historial a través de StatsManager
y la API de IncidentManager
del sistema.
Implementaciones de dispositivos:
- [C-0-2] SOLO DEBE incluir los campos marcados con
DEST_AUTOMATIC
en el informe de incidentes creado por la claseIncidentManager
de la API del sistema. - [C-0-3] NO DEBES usar los identificadores de eventos del sistema para registrar ningún otro evento que no se describa en los documentos del SDK de
StatsLog
. Si se registran eventos del sistema adicionales, PUEDEN usar un identificador de átomo diferente en el rango de 100,000 a 200,000.
9.8.2. Grabando
Implementaciones de dispositivos:
- [C-0-1] NO DEBEN precargar ni distribuir componentes de software listos para usar que envíen información privada del usuario (p.ej., pulsaciones de teclas, texto que se muestra en la pantalla, informe de errores) fuera del dispositivo sin su consentimiento ni borrar notificaciones en curso.
- [C-0-2] DEBEN mostrar una advertencia para el usuario y obtener su consentimiento explícito para capturar cualquier información sensible que se muestre en la pantalla del usuario
, que incluya exactamente el mismo mensaje que AOSPcada vez quese inicie una sesión para capturar la transmisión o la grabación de pantalla, que estéhabilitada.MediaProjection.createVirtualDisplay()
VirtualDeviceManager.createVirtualDisplay()
NO DEBEN proporcionar a los usuarios una indicación visual para inhabilitar la visualización futura del consentimiento del usuario. - [C-0-3] DEBE tener una notificación continua para el usuario mientras la transmisión o grabación de pantalla está habilitada. AOSP cumple con este requisito mostrando un ícono de notificación en curso en la barra de estado.
Cómo iniciar nuevos requisitos
[C-SR-1] SE RECOMIENDA ENFATICAMENTE que se muestre una advertencia para el usuario que sea exactamente el mismo mensaje que se implementa en AOSP, pero que SE PUEDE ALTERAR, siempre y cuando el mensaje le advierta claramente al usuario que se está capturando información sensible en su pantalla.
[C-0-4] NO DEBE proporcionarles a los usuarios una indicación visual para inhabilitar las solicitudes futuras de consentimiento del usuario para capturar la pantalla, a menos que la sesión se inicie con una app del sistema a la que el usuario le permitió
associate()
con el perfil de dispositivoandroid.app.role.COMPANION_DEVICE_APP_STREAMING
oandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
.Fin de los nuevos requisitos
Si las implementaciones de dispositivos incluyen funciones en el sistema que
capturan el contenido que se muestra en la pantalla o graban la transmisión de audio
que se reproduce en el dispositivo de otra manera que no sea a través de la API del sistema ContentCaptureService
, o
otros medios propietarios descritos en la
Sección 9.8.6 Datos ambientales y a nivel del SO, cumplen con los siguientes requisitos:
- [C-1-1] DEBE tener una notificación continua para el usuario cada vez que esta funcionalidad esté habilitada y esté capturando o grabando de forma activa.
Si las implementaciones de dispositivos incluyen un componente habilitado de forma predeterminada, capaz de grabar audio ambiental o grabar el audio que se reproduce en el dispositivo para inferir información útil sobre el contexto del usuario, hacen lo siguiente:
- [C-2-1] NO DEBE almacenar en el almacenamiento persistente en el dispositivo ni transmitir desde el dispositivo el audio sin procesar grabado ni ningún formato que se pueda volver a convertir en el audio original o en un facsímil cercano, excepto con el consentimiento explícito del usuario.
Un “indicador de micrófono” hace referencia a una vista en pantalla que el usuario puede ver constantemente y que no se puede ocultar, y que los usuarios entienden como un micrófono en uso(a través de un texto, un color, un ícono o alguna combinación únicos).
Un “indicador de cámara” hace referencia a una vista en pantalla que el usuario puede ver constantemente y que no se puede ocultar, y que los usuarios entienden como una cámara en uso (a través de un texto, un color, un ícono o alguna combinación únicos).
Después de que se muestra el primer segundo, un indicador puede cambiar visualmente, por ejemplo, hacerse más pequeño, y no es necesario que se muestre como se presentó y entendió originalmente.
El indicador de micrófono se puede combinar con un indicador de cámara que se muestre de forma activa, siempre que el texto, los íconos o los colores le indiquen al usuario que comenzó a usar el micrófono.
El indicador de la cámara se puede combinar con un indicador de micrófono que se muestre de forma activa, siempre que el texto, los íconos o los colores le indiquen al usuario que comenzó a usar la cámara.
Si las implementaciones de dispositivos declaran android.hardware.microphone
, hacen lo siguiente:
- [C-SR-1] SE RECOMIENDA ENFATICAMENTE que se muestre el indicador de micrófono cuando una app accede a datos de audio del micrófono, pero no cuando solo
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
o las apps que tengan los roles mencionados en la sección 9.1 Permisos con identificador de CDD [C-3-X] acceden al micrófono. . - [C-SR-2] SE RECOMIENDA ENFATICAMENTE que muestres la lista de apps recientes y activas que usan el micrófono como se muestra en
PermissionManager.getIndicatorAppOpUsageData()
, junto con cualquier mensaje de atribución asociado con ellas. - [C-SR-3] SE RECOMIENDA NO OCULTAR el indicador de micrófono para las apps del sistema que tienen interfaces de usuario visibles o interacción directa con el usuario.
Si las implementaciones de dispositivos declaran android.hardware.camera.any
, hacen lo siguiente:
- [C-SR-4] SE RECOMIENDA ENFATICAMENTE que se muestre el indicador de cámara cuando una app accede a datos de cámara en vivo, pero no cuando solo las apps que tienen los roles mencionados en el artículo 9.1 Permisos con identificador de CDD [C-3-X] acceden a la cámara.
- [C-SR-5] SE RECOMIENDA MUY FUERTEMENTE que muestres las apps recientes y activas con la cámara como se muestra en
PermissionManager.getIndicatorAppOpUsageData()
, junto con los mensajes de atribución asociados con ellas. - [C-SR-6] SE RECOMIENDA NO OCULTAR el indicador de la cámara para las apps del sistema que tienen interfaces de usuario visibles o interacción directa del usuario.
9.8.3. Conectividad
Si las implementaciones de dispositivos tienen un puerto USB con compatibilidad con el modo periférico USB, hacen lo siguiente:
- [C-1-1] DEBE presentar una interfaz de usuario que solicite el consentimiento del usuario antes de permitir el acceso al contenido del almacenamiento compartido a través del puerto USB.
9.8.4. Tráfico de red
Implementaciones de dispositivos:
- [C-0-1] DEBEN preinstalar los mismos certificados raíz para el almacén de la AC (autoridad certificadora) de confianza del sistema como se proporciona en el proyecto de código abierto de Android upstream.
- [C-0-2] DEBE enviarse con un almacén de AC raíz del usuario vacío.
- [C-0-3] DEBE mostrar una advertencia al usuario que indique que se puede supervisar el tráfico de red cuando se agrega una AC raíz del usuario.
Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones del dispositivo hacen lo siguiente:
- [C-1-1] DEBE mostrar una advertencia al usuario que indique lo siguiente:
- Es posible que se supervise ese tráfico de red.
- Ese tráfico de red se enruta a través de la aplicación de VPN específica que proporciona la VPN.
Si las implementaciones de dispositivos tienen un mecanismo, habilitado de forma predeterminada, que enruta el tráfico de datos de red a través de un servidor proxy o una puerta de enlace de VPN (por ejemplo, cargando previamente un servicio de VPN con android.permission.CONTROL_VPN
otorgado), hacen lo siguiente:
- [C-2-1] DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de políticas de dispositivos habilite esa VPN a través de
DevicePolicyManager.setAlwaysOnVpnPackage()
, en cuyo caso el usuario no necesita proporcionar un consentimiento independiente, pero DEBE recibir una notificación.
Si las implementaciones de dispositivos implementan una indicación visual para el usuario para activar la función "VPN siempre activada" de una app de VPN de terceros, deben cumplir con los siguientes requisitos:
- [C-3-1] DEBE inhabilitar esta indicación visual para el usuario en las apps que no admiten el servicio de VPN siempre activada en el archivo
AndroidManifest.xml
configurando el atributoSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
comofalse
.
9.8.5. Identificadores de dispositivos
Implementaciones de dispositivos:
- [C-0-1] DEBE evitar el acceso al número de serie del dispositivo y, cuando corresponda, al IMEI/MEID, al número de serie de la SIM y a la Identidad internacional de suscriptor móvil (IMSI) desde una app, a menos que cumpla con uno de los siguientes requisitos:
- es una app del operador firmada que verifican los fabricantes de dispositivos.
- Se le otorgó el permiso
READ_PRIVILEGED_PHONE_STATE
. - tiene privilegios de operador, como se define en Privilegios de operador de UICC.
- es el propietario del dispositivo o del perfil al que se le otorgó el permiso
READ_PHONE_STATE
. - (Solo para el número de serie de la SIM o el ICCID) tiene el requisito de las reglamentaciones locales de que la app detecte cambios en la identidad del suscriptor.
9.8.6. Captura de contenido y Búsqueda de appsDatos ambientales y a nivel del SO
Android, a través de las APIs del sistema , admite un mecanismo para que las implementaciones de dispositivos capturen los siguientes ContentCaptureService
, AugmentedAutofillService
, AppSearchGlobalManager.query
o por otros medios propietariosinteracciones de datos de la aplicación entre las aplicaciones y el usuario
datos sensibles:
- Texto y elementos gráficos renderizados en pantalla, incluidos, sin limitaciones, notificaciones y datos de asistencia a través de la API de
AssistStructure
- Datos multimedia, como audio o video, que el dispositivo graba o reproduce
- Eventos de entrada (p. ej., teclas, mouse, gestos, voz, video y accesibilidad)
Cómo iniciar nuevos requisitos
- Cualquier pantalla o cualquier otro dato que se envíe a través de
AugmentedAutofillService
al sistema - Cualquier pantalla o cualquier otro dato al que se pueda acceder a través de la API de
Content Capture
- Cualquier pantalla o cualquier otro dato al que se pueda acceder a través de la API de
FieldClassificationService
- Cualquier dato de la aplicación que se pase al sistema a través de la API de
AppSearchManager
y al que se pueda acceder a través deAppSearchGlobalManager.query
Fin de los nuevos requisitos
- Cualquier otro evento que una aplicación proporcione al sistema a través de la API de
Content Capture
o la API deAppSearchManager
, una API propietaria y de Android con capacidades similares
- Cualquier texto o cualquier otro dato que se envíe a través de
TextClassifier API
al System TextClassifier, es decir, al servicio del sistema para comprender el significado del texto, así como generar acciones futuras previstas en función del texto - Datos indexados por la implementación de AppSearch de la plataforma, incluidos, entre otros, texto, gráficos, datos multimedia y otros datos similares
Cómo iniciar nuevos requisitos
- Datos de audio obtenidos como resultado del uso de
SpeechRecognizer#onDeviceSpeechRecognizer()
por parte de la implementación del reconocedor de voz - Datos de audio obtenidos en segundo plano (de forma continua) a través de
AudioRecord
,SoundTrigger
o de otras APIs de audio, y que no generan un indicador visible para el usuario - Datos de la cámara obtenidos en segundo plano (de forma continua) a través de CameraManager o otras APIs de la cámara, y que no generan un indicador visible para el usuario
Fin de los nuevos requisitos
Si las implementaciones de dispositivos capturan alguno de los datos anteriores, hacen lo siguiente:
- [C-1-1] DEBEN encriptar todos esos datos cuando se almacenan en el dispositivo. Esta encriptación PUEDE realizarse con la encriptación basada en archivos de Android o cualquiera de los algoritmos de cifrado que se enumeran como versión 26 o posterior de la API que se describe en el SDK de Cipher.
- [C-1-2] NO DEBE crear copias de seguridad de datos sin procesar o encriptados con métodos de copia de seguridad de Android ni con ningún otro método de copia de seguridad.
- [C-1-3] SOLO DEBE enviar todos esos datos
y el registrodesde el dispositivo con un mecanismo que preserve la privacidad, excepto con el consentimiento explícito del usuario cada vez que se compartan los datos. El mecanismo que preserva la privacidad se define como "aquellos que solo permiten el análisis agregado y evitan la coincidencia de eventos registrados o resultados derivados con usuarios individuales" para evitar que se puedan inspeccionar los datos por usuario (p.ej., implementados con una tecnología de privacidad diferencial, comoRAPPOR
). - [C-1-4] NO DEBEN asociar esos datos con ninguna identidad del usuario (como
Account
) en el dispositivo, excepto con el consentimiento explícito del usuario cada vez que se asocien los datos. - [C-1-5] NO DEBEN compartir esos datos con otros componentes del SO que no cumplan con los requisitos que se describen en la sección actual (9.8.6
Captura de contenidoDatos a nivel del SO y del entorno), excepto con el consentimiento explícito del usuario cada vez que se compartan. A menos que esa funcionalidad se compile como una API del SDK de Android (AmbientContext
,HotwordDetectionService
). - [C-1-6] DEBE proporcionar indicaciones visuales para el usuario para borrar los datos que la
implementacióndeContentCaptureService
o los medios propios recopilansicuando los datos se almacenan de cualquier forma en el dispositivo. Si el usuario decide borrar los datos, DEBE quitar todos los datos históricos recopilados. - [C-1-7] DEBE proporcionar una indicación visual para que el usuario inhabilite la visualización de los datos recopilados a través de AppSearch o medios propios en la plataforma de Android, p.ej., el selector.
- [C-SR-1] SE RECOMIENDA ENFÉCTIVAMENTE NO solicitar el permiso de INTERNET.
- [C-SR-2] SE RECOMIENDA ENFÉCTIVAMENTE que solo accedas a Internet a través de APIs estructuradas respaldadas por implementaciones de código abierto disponibles públicamente.
Cómo iniciar nuevos requisitos
- [C-SR-4] SE RECOMIENDA ENFATICAMENTE que se implementen con la API del SDK de Android o un repositorio de código abierto similar propiedad del OEM, o bien que se realicen en una implementación con zona de pruebas (consulta 9.8.15 Implementaciones de APIs con zona de pruebas).
Fin de los nuevos requisitos
Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema ContentCaptureService
, AppSearchManager.index
o cualquier servicio propietario que capture los datos como se describió anteriormente, hacen lo siguiente:
- [C-2-1] NO DEBE permitir que los usuarios reemplacen los servicios por una aplicación o un servicio que el usuario pueda instalar y solo DEBE permitir que los servicios preinstalados capturen esos datos.
- [C-2-2] NO DEBE permitir que ninguna app que no sea el mecanismo de servicios preinstalados pueda capturar esos datos.
- [C-2-3] DEBE proporcionar indicaciones visuales para el usuario para inhabilitar los servicios.
- [C-2-4] NO DEBE omitir la indicación visual para el usuario para administrar los permisos de Android que tienen los servicios y seguir el modelo de permisos de Android como se describe en la Sección 9.1. Permiso.
[C-SR-3] SE RECOMIENDA URGENTEMENTE que mantengas los servicios separados de otros componentes del sistema(p.ej., no vincules el servicio ni compartas los IDs de proceso), excepto en los siguientes casos:
- Telefonía, Contactos, IU del sistema y contenido multimedia
Android, a través de SpeechRecognizer#onDeviceSpeechRecognizer()
, proporciona la capacidad de realizar el reconocimiento de voz en el dispositivo, sin involucrar la red.
Cualquier implementación de SpeechRecognizer integrado en el dispositivo DEBE seguir las políticas que se describen en esta sección.
9.8.7. Acceso al portapapeles
Implementaciones de dispositivos:
[C-0-1] NO DEBE mostrar datos recortados del portapapeles (p.ej., a través de la API de
ClipboardManager
) a menos que la app de terceros sea el IME predeterminado o la app que está enfocada actualmente.[C-0-2] DEBEN borrar los