A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

Se usó la API de Cloud Translation para traducir esta página.

Definición de compatibilidad de Android 11

1. Introducción

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

El uso de “DEBE”, “NO DEBE”, “SE REQUIERE”, “DEBERÁ”, “NO DEBERÁ”, “DEBERÍA”, “NO DEBERÍA”, “RECOMENDADO”, “PUEDE” y “OPCIONAL” se realiza según el estándar de IETF definido en RFC2119.

Según se usa en este documento, un "implementador de dispositivos" o "implementador" es una persona u organización que desarrolla una solución de hardware o software que ejecuta Android 11. Una "implementación del dispositivo" o "implementación" es la solución de hardware o software que se desarrolla.

Para que se consideren compatibles con Android 11, 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 descritas en la sección 10 no se pronuncien, sean 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 ENCARECIDAMENTE 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 algunos componentes se pueden reemplazar hipotéticamente por implementaciones alternativas, se RECOMIENDA ENCARECIDAMENTE 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 vinculados 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 los casos en que esta Definición de compatibilidad o el Conjunto de pruebas de compatibilidad no coincidan con la documentación del SDK, se considerará que la documentación del SDK es la fuente autorizada. Todos los detalles técnicos que se proporcionan en los recursos vinculados a lo largo de este documento se consideran, por inclusión, como parte de esta Definición de Compatibilidad.

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

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

Todos los demás requisitos, que se aplican 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 a los requisitos de tipo MUST.

El ID se asigna solo para los requisitos de MUST.
Los requisitos ALTAMENTE RECOMENDADOS se marcan como [SR], pero no se les asigna un ID.
El ID consta de : ID de tipo de dispositivo - ID de condición - ID de requisito (p.ej., C-0-1).

Cada ID se define de la siguiente manera:

ID de tipo de dispositivo (obtén más información en 2. Tipos de dispositivos)
- C: Core (requisitos que se aplican a cualquier implementación de dispositivos Android)
- H: Dispositivo de mano Android
- T: Dispositivo Android Television
- R.: Implementación de Android Automotive
- W: Implementación de Android Watch
- Pestaña: Implementación de tablet Android
ID de condición
- Cuando el requisito es incondicional, este ID se establece en 0.
- Cuando el requisito es condicional, se asigna 1 a la primera 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 se incrementa en 1 dentro de la misma sección y la misma condición.

1.1.3. ID de requisito en la sección 2

El ID de requisito en la Sección 2 comienza con el ID de sección correspondiente seguido del ID de requisito que se describió anteriormente.

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

2. Tipos de dispositivos

Si bien 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, existen 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 demás secciones de esta Definición de compatibilidad.

2.1 Configuraciones del dispositivo

Para conocer las principales diferencias en la configuración de hardware según el tipo de dispositivo, consulta los requisitos específicos del dispositivo que se indican a continuación en esta sección.

2.2. Requisitos para dispositivos portátiles

Un dispositivo Android portátil hace referencia a una implementación de un dispositivo Android que se suele usar sosteniéndolo con la mano, como un reproductor de MP3, un teléfono o una tablet.

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

Tener una fuente de alimentación que proporcione movilidad, como una batería
Tener un tamaño de pantalla diagonal física de entre 3.3 pulgadas (o 2.5 pulgadas para dispositivos que se lanzaron en un nivel de API anterior a Android 11) y 8 pulgadas

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

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

2.2.1. Hardware

Implementaciones de dispositivos portátiles:

[7.1.1.1/H-0-1] DEBE tener al menos una pantalla compatible con Android que cumpla con todos los requisitos descritos en este documento.
[7.1.1.3/H-SR] SE RECOMIENDA ENCARECIDAMENTE proporcionar a los usuarios una opción para cambiar el tamaño de la pantalla (densidad de pantalla).

Si las implementaciones de dispositivos portátiles admiten la rotación de pantalla por software, deben cumplir con 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 2 pulgadas en los bordes cortos y 2.7 pulgadas en los bordes largos. Los dispositivos que se lanzaron con un nivel de API anterior al de este documento están exentos de este requisito.

Si las implementaciones de dispositivos portátiles no admiten la rotación de pantalla por software, deben cumplir con 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 2.7 pulgadas en los bordes cortos. Los dispositivos que se lanzaron con un nivel de API anterior al de este documento están exentos de este requisito.

Si las implementaciones de dispositivos portátiles afirman que admiten pantallas de alto rango dinámico a través de Configuration.isScreenHdr() , deben cumplir con lo siguiente:

[7.1.4.5/H-1-1] DEBE 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 y VK_EXT_hdr_metadata.

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles declaran compatibilidad a través de una propiedad del sistema graphics.gpu.profiler.support, deben cumplir con lo siguiente:

[7.1.4.6/H-1-1] DEBE informar como resultado un registro de protobuf que cumpla con el esquema de los contadores de GPU y las etapas de renderización de GPU definidos en la documentación de Perfetto.
[7.1.4.6/H-1-2] DEBE informar valores conformes para los contadores de GPU del dispositivo según el proto del paquete de registro del contador de GPU.
[7.1.4.6/H-1-3] DEBE informar valores conformes para los RenderStages de la GPU del dispositivo según el proto de paquete de registro de 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 se implementa en el código fuente abierto de Android upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los activadores o los umbrales en los que se activa el modo de compatibilidad, y NO DEBEN alterar el comportamiento del modo de compatibilidad en sí.
[7.2.1/H-0-1] DEBE incluir compatibilidad con aplicaciones de Editor de método de entrada (IME) de terceros.
[7.2.3/H-0-3] DEBE 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.3/H-0-2] DEBE enviar el evento de presión normal y el de presión prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano. El sistema NO DEBE consumir estos eventos, y se PUEDEN activar fuera del dispositivo Android (p.ej., un teclado de hardware externo conectado al dispositivo Android).
[7.2.4/H-0-1] DEBE admitir la entrada de pantalla táctil.
[7.2.4/H-SR] SE RECOMIENDA ENCARECIDAMENTE iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService, o una actividad que controle ACTION_ASSIST al mantener presionado KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no controla esos eventos de mantener presionado.
[7.3.1/H-SR] SE RECOMIENDA ENCARECIDAMENTE que incluyan un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos portátiles incluyen un acelerómetro de 3 ejes, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos portátiles incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, deben cumplir con lo siguiente:

[7.3.3/H-2-1] DEBE informar las mediciones de GNSS tan pronto como se encuentren, incluso si aún no se informó una ubicación calculada a partir del GPS o GNSS.
[7.3.3/H-2-2] DEBE informar las seudoranges y las velocidades de seudoranges del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras el dispositivo está estacionario o se mueve con una aceleración inferior a 0.2 metros por segundo al cuadrado, son suficientes para calcular la posición con una precisión de 20 metros y la velocidad con una precisión 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, deben cumplir con los siguientes requisitos:

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

Implementaciones de dispositivos portátiles que pueden realizar una llamada de voz y mostrar 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] Se RECOMIENDA admitir el sensor de posición con 6 grados de libertad.
[7.4.3/H] DEBE incluir compatibilidad con Bluetooth y Bluetooth LE.

Si las implementaciones de dispositivos portátiles incluyen una conexión medida, deben cumplir con los siguientes requisitos:

[7.4.7/H-1-1] DEBE proporcionar el modo de Ahorro de datos.

Si las implementaciones de dispositivos portátiles incluyen un dispositivo de cámara lógica que enumera las capacidades con CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, deben cumplir con lo siguiente:

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

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles declaran compatibilidad solo con una ABI de 32 bits, se deben cumplir los siguientes requisitos:

[7.6.1/H-1-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 416 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta qHD (p.ej., FWVGA).
[7.6.1/H-2-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 592 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta HD+ (p.ej., HD, WSVGA).
[7.6.1/H-3-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 896 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta FHD (p.ej., WSXGA+).
[7.6.1/H-4-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1344 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta QHD (p.ej., QWXGA).

Si las implementaciones de dispositivos portátiles declaran compatibilidad con cualquier ABI de 64 bits (con o sin cualquier ABI de 32 bits), se deben cumplir los siguientes requisitos:

[7.6.1/H-5-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 816 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta qHD (p.ej., FWVGA).
[7.6.1/H-6-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 944 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta HD+ (p.ej., HD, WSVGA).
[7.6.1/H-7-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,280 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta FHD (p.ej., WSXGA+).
[7.6.1/H-8-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,824 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta QHD (p.ej., QWXGA).

Ten en cuenta que la "memoria disponible para el kernel y el espacio del usuario" que se menciona más arriba se refiere al espacio de memoria que se proporciona además de la memoria que ya está dedicada a los componentes de hardware, como la radio, el video, etcétera, que no están bajo el control del kernel en las implementaciones del dispositivo.

Si las implementaciones de dispositivos portátiles incluyen menos de 1 GB de memoria disponible para el kernel y el espacio del usuario, deben cumplir con 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 del usuario, deben cumplir con 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.

Implementaciones de dispositivos portátiles:

[7.6.2/H-0-1] NO DEBE proporcionar un almacenamiento compartido de la aplicación inferior a 1 GiB.
[7.7.1/H] DEBE incluir un puerto USB que admita el modo de periférico.

Si las implementaciones de dispositivos portátiles incluyen un puerto USB que admite el modo periférico, deben cumplir con 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 que admite el modo de host, deben cumplir con 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 son capaces de cumplir con todos los requisitos de rendimiento para admitir el modo de RV y lo incluyen, deben cumplir con lo siguiente:

[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 y que las aplicaciones de RV puedan habilitar a través de android.app.Activity#setVrModeEnabled.

Si las implementaciones de dispositivos portátiles incluyen uno o más puertos USB-C en modo host y se 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 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: Presión breve Salida: Reproducir o pausar
		Reproducción de contenido multimedia	Entrada: Mantén presionado Salida: Inicia el comando por voz Envía: `android.speech.action.VOICE_SEARCH_HANDS_FREE` si el dispositivo está bloqueado o la pantalla está apagada. De lo contrario, envía `android.speech.RecognizerIntent.ACTION_WEB_SEARCH`.
		Llamada entrante	Entrada: Presión breve Salida: Aceptar llamada
		Llamada entrante	Entrada: Mantén presionado Salida: Rechazar llamada
		Llamada en curso	Entrada: Presión breve Salida: Finalizar llamada
		Llamada en curso	Entrada: Mantén presionado Salida: Silenciar o activar el micrófono
B	Página de uso de HID: 0x0C Uso de HID: 0x0E9 Tecla del kernel: `KEY_VOLUMEUP` Tecla de Android: `VOLUME_UP`	Reproducción de contenido multimedia, Llamada en curso	Entrada: Presión breve o prolongada Salida: Aumenta el volumen del sistema o de los auriculares
C	Página de uso de HID: 0x0C Uso de HID: 0x0EA Tecla del kernel: `KEY_VOLUMEDOWN` Tecla de Android: `VOLUME_DOWN`	Reproducción de contenido multimedia, Llamada en curso	Entrada: Presión breve o prolongada Salida: Disminuye el volumen del sistema o de los auriculares
D	Página de uso de HID: 0x0C Uso de HID: 0x0CF Tecla del kernel: `KEY_VOICECOMMAND` Tecla de Android: `KEYCODE_VOICE_ASSIST`	Todos. Se puede activar en cualquier instancia.	Entrada: Presión breve o prolongada Salida: Inicia el comando por voz

[7.8.2.2/H-1-2] DEBE activar ACTION_HEADSET_PLUG cuando se inserte un conector, pero solo después de que se hayan enumerado correctamente las interfaces y los extremos de audio USB para identificar el tipo de terminal conectado.

Cuando se detectan los tipos de terminal de audio USB 0x0302, sucede lo siguiente:

[7.8.2.2/H-2-1] DEBE transmitir el Intent ACTION_HEADSET_PLUG con el extra "microphone" establecido en 0.

Cuando se detectan los tipos de terminal de audio USB 0x0402, sucede lo siguiente:

[7.8.2.2/H-3-1] DEBE transmitir el Intent ACTION_HEADSET_PLUG con el extra "microphone" establecido en 1.

Cuando se llama a la API AudioManager.getDevices() 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 role 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 role isSink() si el campo de tipo de terminal de audio USB es 0x0402.
[7.8.2.2/H-4-3] DEBE incluir un dispositivo de tipo AudioDeviceInfo.TYPE_USB_HEADSET y role 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 role 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 role 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 role 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 role isSource() si el campo de tipo de terminal de audio USB es 0x400.
[7.8.2.2/H-SR] Se RECOMIENDAN ENCARECIDAMENTE al conectar un periférico de audio USB-C para realizar la enumeración de los descriptores USB, identificar los tipos de terminales y transmitir el Intent ACTION_HEADSET_PLUG en menos de 1, 000 milisegundos.

Si las implementaciones de dispositivos portátiles incluyen al menos un actuador háptico, deben cumplir con lo siguiente:

[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE NO usar un actuador háptico (vibrador) de masa rotatoria excéntrica(ERM).
[7.10/H]* DEBE colocar el actuador cerca de la ubicación en la que el dispositivo se suele sostener o tocar con las manos.
[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE implementar todas las constantes públicas para la retroalimentación háptica 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-SR]* SE RECOMIENDA ENCARECIDAMENTE implementar todas las constantes públicas para la háptica clara en android.os.VibrationEffect, es decir, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK y EFFECT_DOUBLE_CLICK) y todas las constantes públicas para la háptica enriquecida en android.os.VibrationEffect.Composition, es decir, (PRIMITIVE_CLICK y PRIMITIVE_TICK).
[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE usar estas asignaciones de constantes hápticas vinculadas.
[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE seguir la evaluación de calidad para las APIs de createOneShot() y createWaveform().
[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE verificar las capacidades de escalabilidad de amplitud ejecutando android.os.Vibrator.hasAmplitudeControl().

El actuador resonante lineal (LRA) es un sistema de resorte de masa única que tiene una frecuencia resonante dominante en la que la masa se desplaza en la dirección del movimiento deseado.

Si las implementaciones de dispositivos portátiles incluyen al menos un actuador resonante lineal, deben cumplir con lo siguiente:

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

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

[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE que la frecuencia de resonancia del LRA del eje X sea inferior a 200 Hz.

Si las implementaciones de dispositivos portátiles siguen la asignación de constantes hápticas, sucede lo siguiente:

[7.10/H-SR]* Se RECOMIENDA ENCARECIDAMENTE realizar una evaluación de calidad para las constantes hápticas.

2.2.2. Multimedia

Las implementaciones de dispositivos portátiles DEBEN admitir los siguientes formatos de codificación y decodificación de audio, y ponerlos a disposición de 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:

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

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

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

2.2.3. Software

Implementaciones de dispositivos portátiles:

[3.2.3.1/H-0-1] DEBE tener una aplicación que controle los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE y ACTION_CREATE_DOCUMENT como se describe en los documentos del SDK, y proporcionar la capacidad de acceso del usuario a los datos del proveedor de documentos con la API de DocumentsProvider.
[3.2.3.1/H-0-2]* DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.
[3.2.3.1/H-SR] Se RECOMIENDA ENCARECIDAMENTE precargar una aplicación de correo electrónico que pueda controlar intents de 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] SE RECOMIENDA ENCARECIDAMENTE implementar un selector predeterminado que admita la fijación en la app de accesos directos, widgets y widgetFeatures.
[3.8.1/H-SR] SE RECOMIENDA ENCARECIDAMENTE implementar un selector predeterminado que proporcione acceso rápido a los accesos directos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager.
[3.8.1/H-SR] SE RECOMIENDA ENCARECIDAMENTE incluir una app de selector predeterminada que muestre insignias para los íconos de apps.
[3.8.2/H-SR] SE RECOMIENDA ENCARECIDAMENTE que admitan widgets de apps de terceros.
[3.8.3/H-0-1] DEBE permitir que las apps de terceros notifiquen a los usuarios sobre eventos importantes a través de las clases de API Notification y NotificationManager.
[3.8.3/H-0-2] DEBE admitir notificaciones enriquecidas.
[3.8.3/H-0-3] DEBE admitir notificaciones emergentes.
[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 recursos para el usuario, como botones de acción o el panel de control implementado en el AOSP.
[3.8.3/H-0-5] DEBE mostrar las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el panel de notificaciones.
[3.8.3/H-SR] SE RECOMIENDA ENCARECIDAMENTE mostrar la primera opción proporcionada a través de RemoteInput.Builder setChoices() en la sombra de la notificación sin interacción adicional del usuario.
[3.8.3/H-SR] Se RECOMIENDA ENCARECIDAMENTE 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] Se RECOMIENDA ENCARECIDAMENTE mostrar acciones para las que Notification.Action.Builder.setContextual se establece como true en línea con las respuestas que muestra Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR] Se RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.

Si las implementaciones de dispositivos portátiles admiten la acción de Asistencia, deben cumplir con lo siguiente:

[3.8.4/H-SR] SE RECOMIENDA ENCARECIDAMENTE usar la presión prolongada en 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 implementa VoiceInteractionService o una actividad que controla el intent ACTION_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 no conversacionales, deben cumplir con lo siguiente:

[3.8.4/H-1-1]* DEBE mostrar las notificaciones de conversaciones antes que las notificaciones que no son de conversaciones, con la excepción de las notificaciones de servicios en primer plano en curso y las notificaciones con importance:high.

Si las implementaciones de dispositivos portátiles Android admiten una pantalla de bloqueo, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos portátiles admiten una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:

[3.9/H-1-1] DEBE implementar el rango completo de políticas de administración de dispositivos definidas en la documentación del SDK de Android.
[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, excepto cuando el dispositivo esté configurado de modo que se informe a sí mismo como un dispositivo con poca RAM o de modo que asigne el almacenamiento interno (no extraíble) como almacenamiento compartido.

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 del dispositivo, entonces:

[3.8.16/H-1-1] DEBE declarar la marca de función android.software.controls y establecerla en true.
[3.8.16/H-1-2] DEBE proporcionar una opción para el usuario que le permita 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 y Control.
[3.8.16/H-1-3] DEBE proporcionar acceso a esta opción para el usuario en un máximo de tres interacciones desde un selector predeterminado.
[3.8.16/H-1-4] DEBE renderizar con precisión en esta interfaz 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 de Control.

Por el contrario, si las implementaciones de dispositivos portátiles no implementan estos controles, sucede lo siguiente:

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

Implementaciones de dispositivos portátiles:

[3.10/H-0-1] DEBE admitir servicios de accesibilidad de terceros.
[3.10/H-SR] SE RECOMIENDA ENCARECIDAMENTE precargar los 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 admitidos por el motor de texto a voz preinstalado) o que la superen, tal 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] SE RECOMIENDA ENCARECIDAMENTE incluir un motor de TTS que admita los idiomas disponibles en el dispositivo.
[3.13/H-SR] Se RECOMIENDA ENCARECIDAMENTE incluir un componente de IU de Configuración rápida.

Si las implementaciones de dispositivos portátiles Android declaran compatibilidad con FEATURE_BLUETOOTH o FEATURE_WIFI, deben cumplir con 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 la pantalla principal 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, se deben cumplir los siguientes requisitos:

[7.2.3/H-0-1] El área de gestos de la función de navegación DEBE tener un ancho inferior a 40 dp en cada lado. El área de gesto DEBE tener un ancho de 24 dp de forma predeterminada.

2.2.4. Rendimiento y potencia

[8.1/H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas inconsistente o la demora en renderizar fotogramas NO DEBEN ocurrir más de 5 veces por segundo y DEBEN ser inferiores a 1 vez por segundo.
[8.1/H-0-2] Latencia de la interfaz de usuario. Las implementaciones de dispositivos DEBEN garantizar una experiencia del usuario con baja latencia desplazándose por una lista de 10,000 entradas de lista, según lo define el Conjunto de pruebas de compatibilidad (CTS) de Android, en menos de 36 s.
[8.1/H-0-3] Cambio de tareas. Cuando se hayan iniciado varias aplicaciones, el reinicio de una aplicación que ya se está ejecutando después de que se haya iniciado DEBE tardar menos de 1 segundo.

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en el AOSP o extienden las funciones que se incluyen en el AOSP, deben cumplir con lo siguiente:

[8.3/H-1-1] DEBE proporcionar al usuario la posibilidad de habilitar y, también, inhabilitar la función de ahorro de batería.
[8.3/H-1-2] DEBE proporcionar al usuario la posibilidad de 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 de corriente para cada componente de hardware y la descarga aproximada de la batería 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] DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
[8.4/H-0-3] DEBE informar el consumo de energía de la CPU por 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 poner este uso de energía a disposición del desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.
[8.4/H] SE DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

Si las implementaciones de dispositivos portátiles incluyen una pantalla o salida de video, deben cumplir con lo siguiente:

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

2.2.5. Modelo de seguridad

Implementaciones de dispositivos portátiles:

[9.1/H-0-1] DEBE 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 que permita otorgar o revocar el acceso a dichas apps en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementaciones de dispositivos portátiles (* no aplicable a tablets):

[9.11/H-0-2]* DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
[9.11/H-0-3]* DEBE tener implementaciones de los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles con el sistema de Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito a través de 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 manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android 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 realice en hardware seguro. Las claves de firma de la 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 la implementación de un dispositivo ya se lanzó en una versión anterior de Android, dicho dispositivo está exento del requisito de tener un almacén de claves respaldado por un entorno de ejecución aislado y admitir la 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, es decir, un tiempo de transición del estado desbloqueado al bloqueado, de 15 segundos o menos.
[9.11/H-1-2] DEBE proporcionar al usuario la posibilidad de ocultar las notificaciones y, además, 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.

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] DEBE admitir perfiles restringidos, una función que permite a los propietarios del dispositivo 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 posibilidad 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, deben hacer lo siguiente:

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

2.2.6. Compatibilidad de las herramientas y opciones para desarrolladores

Implementaciones de dispositivos portátiles (* no aplicable a tablets):

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

Implementaciones de dispositivos portátiles (* no aplicable a tablets):

Perfetto
- [6.1/H-0-2]* DEBE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [6.1/H-0-3]* El ejecutable 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 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 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 registro de Perfetto DEBE estar habilitado de forma predeterminada (propiedad del sistema persist.traced.enable).

2.2.7 Clase de rendimiento del contenido multimedia manual

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

2.2.7.1. Contenido multimedia

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R 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 por 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() y VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-2] DEBE admitir 6 instancias de sesiones de decodificador de video por hardware (AVC o HEVC) en cualquier combinación de códecs que se ejecuten de forma simultánea con una resolución de 720 p a 30 FPS.
[5.1/H-1-3] DEBE anunciar la cantidad máxima de sesiones de codificador de video por 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() y VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-4] DEBE admitir 6 instancias de sesiones de codificador de video por hardware (AVC o HEVC) en cualquier combinación de códecs que se ejecuten de forma simultánea con una resolución de 720 p a 30 FPS.
[5.1/H-1-5] DEBE anunciar la cantidad máxima de sesiones de codificador y decodificador de video por 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() y VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-6] DEBE admitir 6 instancias de decodificador de video por hardware y sesiones de codificador de video por hardware (AVC o HEVC) en cualquier combinación de códecs que se ejecuten de forma simultánea con una resolución de 720 p a 30 FPS.
[5.1/H-1-7] DEBE tener una latencia de inicialización del códec de 65 ms o menos para una sesión de codificación de video de 1080p o menos para todos los codificadores de video por hardware (excepto el códec Dolby Vision) cuando están bajo 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 por hardware junto con la inicialización de la grabación de audio y video en 1080p.
[5.1/H-1-8] DEBE tener una latencia de inicialización del códec de 50 ms o menos para una sesión de codificación de audio con una tasa de bits de 128 kbps o inferior para todos los codificadores de audio cuando están bajo carga.Aquí, la carga 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 la grabación de audio y video de 1080p.
[5.3/H-1-1] NO DEBE descartar más de 1 fotograma en 10 segundos (es decir, menos del 0.333% de fotogramas descartados) en una sesión de video de 1080p a 30 FPS bajo carga. La carga se define como una sesión de transcodificación simultánea de solo video de 1080 p a 720 p que usa códecs de video por hardware, así como una reproducción de audio AAC de 128 kbps.
[5.3/H-1-2] NO DEBE descartar más de 1 fotograma en 10 segundos durante un cambio de resolución de video en una sesión de video de 30 FPS bajo carga. La carga se define como una sesión de transcodificación simultánea de solo video de 1080 p a 720 p que usa códecs de video por hardware, así como una reproducción de audio AAC de 128 Kbps.
[5.6/H-1-1] DEBE tener una latencia de toque a tono inferior a 100 milisegundos con la prueba de toque a tono de OboeTester o la prueba de toque a tono de CTS Verifier.

2.2.7.2. Cámara

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucede lo siguiente:

[7.5/H-1-1] DEBE tener una cámara posterior principal con una resolución de al menos 12 megapíxeles que admita la captura de video en 4K a 30 FPS. La cámara posterior principal es la que tiene el ID de cámara más bajo.
[7.5/H-1-2] DEBE tener una cámara frontal principal con una resolución de al menos 4 megapíxeles que admita la captura de video a 1080p y 30 FPS. La cámara frontal principal es la que tiene el ID de cámara más bajo.
[7.5/H-1-3] DEBE admitir la propiedad android.info.supportedHardwareLevel como FULL o mejor para la cámara principal trasera y LIMITED o mejor 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 JPEG de camera2 < 1,000 ms para una resolución de 1080p, según se mide con la prueba PerformanceTest de CTS Camera en condiciones de iluminación de ITS (3,000 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) < 600 ms según lo medido por el PerformanceTest de la cámara del CTS en condiciones de iluminación del ITS (3,000 K) para ambas cámaras principales.

2.2.7.3. Hardware

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, sucede lo siguiente:

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

2.2.7.4. Rendimiento

Si las implementaciones de dispositivos portátiles devuelven android.os.Build.VERSION_CODES.R 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 100 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 200 MB/s.
[8.2/H-1-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 25 MB/s.

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 medios digitales, películas, juegos, apps o TV en vivo para los usuarios que se encuentran a unos tres metros de distancia (una "interfaz de usuario de 10 pies" o "de sillón").

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

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

Los requisitos adicionales que se describen en el resto de esta sección son específicos para las implementaciones de dispositivos Android TV.

2.3.1. Hardware

Implementaciones de dispositivos de televisión:

[7.2.2/T-0-1] DEBE admitir el pad direccional.
[7.2.3/T-0-1] DEBE proporcionar las funciones de Inicio y Atrás.
[7.2.3/T-0-2] DEBE enviar el evento de presión normal y el de presión 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 controles de juegos y declarar el parámetro de función android.hardware.gamepad.
[7.2.7/T] DEBE proporcionar un control remoto desde el que los usuarios puedan acceder a la navegación sin contacto y a las entradas de las teclas de navegación principales.

Si las implementaciones de dispositivos de televisión incluyen un giroscopio de 3 ejes, deben cumplir con lo siguiente:

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

Implementaciones de dispositivos de televisión:

[7.4.3/T-0-1] DEBE admitir Bluetooth y Bluetooth LE.
[7.6.1/T-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").

Si las implementaciones de dispositivos de televisión incluyen un puerto USB que admite el modo de host, deben cumplir con 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 del usuario DEBE ser de al menos 896 MB si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes

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 del usuario DEBE ser de al menos 1,280 MB si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes

Implementaciones de dispositivos de televisión:

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

2.3.2. Multimedia

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

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

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

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

Implementaciones de dispositivos de televisión:

[5.2.2/T-SR] Se RECOMIENDA ENCARECIDAMENTE 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 televisión 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 televisión DEBEN admitir la decodificación MPEG-2, como se detalla en la Sección 5.3.1, a velocidades de fotogramas de video y resoluciones estándar hasta las siguientes (inclusive):

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

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación H.264, como se detalla en la sección 5.3.4, a velocidades de fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

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

Las implementaciones de dispositivos de televisión con decodificadores de hardware H.265 DEBEN admitir la decodificación H.265, como se detalla en la Sección 5.3.5, a velocidades de fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

[5.3.5/T-1-1] HD 1080p a 60 fotogramas por segundo con el nivel 4.1 del perfil principal

Si las implementaciones de dispositivos de televisión con decodificadores de hardware H.265 admiten la decodificación H.265 y el perfil de decodificación UHD, deben cumplir con lo siguiente:

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

Las implementaciones de dispositivos de televisión DEBEN admitir la decodificación de VP8, como se detalla en la Sección 5.3.6, a velocidades de fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

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

Las implementaciones de dispositivos de televisión con decodificadores de hardware VP9 DEBEN admitir la decodificación de VP9, como se detalla en la Sección 5.3.7, a velocidades de fotogramas y resoluciones de video estándar hasta las siguientes (inclusive):

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

Si las implementaciones de dispositivos de televisión con decodificadores por hardware de VP9 admiten la decodificación de VP9 y el perfil de decodificación UHD, deben cumplir con 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-2-1] SE RECOMIENDA ENCARECIDAMENTE que admitan el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil 2 (profundidad de color de 10 bits).

Implementaciones de dispositivos de televisión:

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

Si las implementaciones de dispositivos de televisión no tienen una pantalla integrada, sino que admiten una pantalla externa conectada a través de HDMI, deben cumplir con los siguientes requisitos:

[5.8/T-0-1] DEBE establecer 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] SE RECOMIENDA ENCARECIDAMENTE proporcionar un selector de frecuencia de actualización de 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.

[5.8/T-1-1] DEBE admitir HDCP 2.2.

Si las implementaciones de dispositivos de televisión no admiten la decodificación UHD, pero sí una pantalla externa conectada a través de HDMI, deben cumplir con los siguientes requisitos:

[5.8/T-2-1] DEBE admitir HDCP 1.4

2.3.3. Software

Implementaciones de dispositivos de televisión:

[3/T-0-1] DEBE declarar las funciones android.software.leanback y android.hardware.type.television.
[3.2.3.1/T-0-1] DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones 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 Television admiten una pantalla de bloqueo,deben cumplir con los siguientes requisitos:

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

Implementaciones de dispositivos de televisión:

[3.8.14/T-SR] Se RECOMIENDA ENCARECIDAMENTE que admitan el modo de pantalla en pantalla (PIP) en multiventana.
[3.10/T-0-1] DEBE admitir servicios de accesibilidad de terceros.
[3.10/T-SR] SE RECOMIENDA ENCARECIDAMENTE precargar los 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 admitidos por el motor de texto a voz preinstalado) o que la superen, tal como se proporciona en el proyecto de código abierto de TalkBack.

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

[3.11/T-SR] SE RECOMIENDA ENCARECIDAMENTE incluir 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 televisión:

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

2.3.4. Rendimiento y potencia

[8.1/T-0-1] Latencia de fotogramas coherente. La latencia de fotogramas inconsistente o la demora en renderizar fotogramas NO DEBEN ocurrir más de 5 veces por segundo y DEBEN ser inferiores a 1 vez por segundo.
[8.2/T-0-1] DEBE garantizar un rendimiento de escritura secuencial de al menos 5 MB/s.
[8.2/T-0-2] DEBE garantizar un rendimiento de escritura aleatoria de al menos 0.5 MB/s.
[8.2/T-0-3] DEBE garantizar un rendimiento de lectura secuencial de al menos 15 MB/s.
[8.2/T-0-4] DEBE garantizar un rendimiento de lectura aleatoria de al menos 3.5 MB/s.

Si las implementaciones de dispositivos de televisión incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en el AOSP o extienden las funciones que se incluyen en el AOSP, deben cumplir con lo siguiente:

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

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

[8.3/T-1-2] DEBE registrar el dispositivo como un dispositivo sin batería, como se describe en Cómo admitir dispositivos sin batería.

Si las implementaciones de dispositivos de televisión tienen una batería, deben cumplir con lo siguiente:

[8.3/T-1-3] DEBE proporcionar al usuario la posibilidad de 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 televisión:

[8.4/T-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería 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] SE DEBEN registrar todos los valores de consumo de energía en miliamperios por 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] SE DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.
[8.4/T-0-4] DEBE poner este uso de energía a disposición del 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 televisión:

[9.11/T-0-1] DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
[9.11/T-0-2] DEBE tener implementaciones de los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash MD5, SHA1 y de la familia SHA-2 para admitir correctamente los algoritmos compatibles con el sistema de Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito a través de 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 manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android 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 realice en hardware seguro. Las claves de firma de la 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.

Si las implementaciones de dispositivos de televisión 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 bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos o menos.

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

[9.5/T-2-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios del dispositivo 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 posibilidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

Si las implementaciones de dispositivos de televisión incluyen varios usuarios y declaran el parámetro de configuración android.hardware.telephony, deben hacer lo siguiente:

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

2.3.6. Compatibilidad de las herramientas y opciones para desarrolladores

Implementaciones de dispositivos de televisión:

Perfetto
- [6.1/T-0-1] DEBE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [6.1/T-0-2] El ejecutable 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 ejecutable 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.

2.4. Requisitos del reloj

Un dispositivo Android Watch hace referencia a una implementación de dispositivo Android que se puede usar en el cuerpo, tal vez en la muñeca.

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

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 incluyen en el resto de esta sección son específicos para 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 un tamaño diagonal físico de entre 1.1 y 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 se encuentre en UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] DEBE admitir la entrada táctil.
[7.3.1/W-SR] Se RECOMIENDA ENCARECIDAMENTE que incluyan un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos Watch incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, deben cumplir con lo siguiente:

[7.3.3/W-1-1] DEBE informar las mediciones de GNSS tan pronto como se encuentren, incluso si aún no se informó una ubicación calculada a partir del GPS o GNSS.
[7.3.3/W-1-2] DEBE informar las seudoranges y las tasas de seudoranges del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras el dispositivo está estacionario o se mueve con una aceleración inferior a 0.2 metros por segundo al cuadrado, son suficientes para calcular la posición con una precisión de 20 metros y la velocidad con una precisión de 0.2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos Watch incluyen un giroscopio de 3 ejes, deben cumplir con lo siguiente:

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

Mira las implementaciones de dispositivos:

[7.4.3/W-0-1] DEBE admitir 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 del usuario.
[7.8.1/W-0-1] DEBE incluir un micrófono.
[7.8.2/W] PUEDE tener salida de audio.

2.4.2. Multimedia

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 aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.

Mira las implementaciones de dispositivos:

[3.8.4/W-SR] SE RECOMIENDA ENCARECIDAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.

Implementaciones de dispositivos Wear 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] SE RECOMIENDA ENCARECIDAMENTE precargar los 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 admitidos por el motor de texto a voz preinstalado) o que la superen, tal como se proporciona en el proyecto de código abierto de TalkBack.

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

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

2.4.4. Rendimiento y potencia

Si las implementaciones de dispositivos Watch incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en el AOSP o extienden las funciones que se incluyen en el AOSP, deben cumplir con lo siguiente:

[8.3/W-SR] SE RECOMIENDA ENCARECIDAMENTE proporcionar a los usuarios la posibilidad de mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.
[8.3/W-SR] SE RECOMIENDA ENCARECIDAMENTE que se proporcione al usuario la posibilidad de habilitar y, luego, inhabilitar 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 de corriente para cada componente de hardware y la descarga aproximada de la batería 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] DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
[8.4/W-0-3] DEBE informar el consumo de energía de la CPU por 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 poner este uso de energía a disposición del desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.
[8.4/W] SE DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

2.4.5. Modelo de seguridad

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

[9.5/W-1-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios del dispositivo 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 posibilidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

Si las implementaciones de dispositivos Watch incluyen varios usuarios y declaran el parámetro de configuración android.hardware.telephony, deben hacer lo siguiente:

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

2.5. Requisitos para la industria automotriz

La implementación de Android Automotive hace referencia a una consola central del vehículo que ejecuta Android como sistema operativo para parte o la totalidad de la funcionalidad del sistema o 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.

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

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

2.5.1. Hardware

Implementaciones de dispositivos para automóviles:

[7.1.1.1/A-0-1] DEBE tener una pantalla de al menos 6 pulgadas de tamaño diagonal físico.
[7.1.1.1/A-0-2] DEBE tener un diseño de tamaño de pantalla de al menos 750 dp x 480 dp.
[7.2.3/A-0-1] DEBE proporcionar la función de inicio y PUEDE proporcionar las funciones de atrás y recientes.
[7.2.3/A-0-2] DEBE enviar el evento de presión normal y el de presión prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
[7.3/A-0-1] DEBE implementar y registrar GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED y PARKING_BRAKE_ON.
[7.3/A-0-2] El valor de la marca NIGHT_MODE DEBE ser coherente con el modo claro/oscuro del panel y DEBE basarse en la entrada del sensor de luz ambiental. Es POSIBLE que el sensor de luz ambiente subyacente sea el mismo que el del fotómetro.
[7.3/A-0-3] Se DEBE proporcionar el campo de información adicional del sensor TYPE_SENSOR_PLACEMENT como parte de SensorAdditionalInfo para cada sensor proporcionado.
[7.3/A-0-1] El MAY debe estimar la ubicación por medio de la combinación de GPS/GNSS con sensores adicionales. Si la ubicación se calcula a ciegas, se RECOMIENDA ENCARECIDAMENTE implementar y registrar los tipos de sensores o los IDs de propiedades del vehículo correspondientes que se usen.
[7.3/A-0-2] La ubicación solicitada a través de LocationManager#requestLocationUpdates() NO DEBE correlacionarse con el mapa.

Si las implementaciones de dispositivos para automóviles incluyen un acelerómetro de 3 ejes, deben cumplir con los siguientes requisitos:

[7.3.1/A-1-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.
[7.3.1/A-1-2] DEBE cumplir con el sistema de coordenadas del sensor del automóvil de Android.

Si las implementaciones de dispositivos para automóviles incluyen un giroscopio de 3 ejes, deben cumplir con los siguientes requisitos:

[7.3.4/A-2-1] DEBE poder informar eventos con una frecuencia de al menos 100 Hz.
[7.3.4/A-2-2] TAMBIÉN debe implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED.
[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] SE RECOMIENDA ENCARECIDAMENTE configurar el rango de medición del giroscopio en +/-250 dps para maximizar la resolución posible.

Si las implementaciones de dispositivos para automóviles incluyen un receptor de GPS/GNSS, pero no incluyen conectividad de datos basada en redes celulares, deben cumplir con lo siguiente:

[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 4 días o más en un plazo de 60 segundos.
[7.3.3/A-3-2] DEBE cumplir con los criterios de tiempo hasta 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, las 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, ya sea con predicciones de órbita del GNSS calculadas en el receptor o con la última ubicación conocida del vehículo junto con la capacidad de realizar una estimación a ciegas durante al menos 60 segundos con una precisión de posición que satisfaga 7.3.3/C-1-3, o bien con una combinación de ambos.

Implementaciones de dispositivos para automóviles:

[7.4.3/A-0-1] DEBE admitir Bluetooth y DEBERÍA admitir Bluetooth LE.
[7.4.3/A-0-2] Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles de Bluetooth:
- Llamadas telefónicas a través del perfil 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).
- Compartir contactos con el perfil de acceso a la agenda telefónica (PBAP)
[7.4.3/A-SR] Se RECOMIENDA ENCARECIDAMENTE que admitan el perfil de acceso a mensajes (MAP).
[7.4.5/A] DEBE incluir compatibilidad con la conectividad de datos basada en redes celulares.
[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.

Una cámara de vista exterior es una cámara que capta imágenes de escenas fuera de la implementación del dispositivo, como una cámara para el tablero.

Implementaciones de dispositivos para automóviles:

DEBE incluir una o más cámaras con vista exterior.

Si las implementaciones de dispositivos para automóviles incluyen una cámara con vista exterior, para esa cámara, deben cumplir con lo siguiente:

[7.5/A-1-1] NO DEBE tener cámaras con vista exterior accesibles 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] Se RECOMIENDA ENCARECIDAMENTE no rotar ni duplicar horizontalmente la vista previa de la cámara.
[7.5.5/A-SR] Se RECOMIENDA ENCARECIDAMENTE que se orienten de modo que la dimensión larga de la cámara se alinee con el horizonte.
[7.5/A-SR] Se RECOMIENDA ENCARECIDAMENTE que tengan una resolución de al menos 1.3 megapíxeles.
DEBE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
DEBE admitir el framework de sincronización de Android.
PUEDE tener enfoque automático por hardware o por software implementado en el controlador de la cámara.

Implementaciones de dispositivos para automóviles:

[7.6.1/A-0-1] DEBE tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación (también conocida como partición "/data").
[7.6.1/A] DEBE formatear la partición de datos para ofrecer un mejor rendimiento y una mayor durabilidad en el almacenamiento flash, por ejemplo, con el sistema de archivos f2fs.

Si las implementaciones de dispositivos para automóviles proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble, deben cumplir con lo siguiente:

[7.6.1/A-SR] Se RECOMIENDA ENCARECIDAMENTE que se reduzca la sobrecarga de E/S en las operaciones que se realizan en el almacenamiento externo, por ejemplo, usando SDCardFS.

Si las implementaciones de dispositivos para automóviles son de 32 bits, haz lo siguiente:

[7.6.1/A-1-1] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 512 MB si se usa alguna de las siguientes densidades:
- 280 dpi o menos en pantallas pequeñas o normales
- ldpi o inferior en pantallas muy grandes
- mdpi o inferior en pantallas grandes
[7.6.1/A-1-2] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 608 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 muy grandes
[7.6.1/A-1-3] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 896 MB si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes
[7.6.1/A-1-4] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,344 MB si se usa alguna de las siguientes densidades:
- 560 DPI o más en pantallas pequeñas o normales
- 400 DPI o más en pantallas grandes
- xhdpi o superior en pantallas extra grandes

Si las implementaciones de dispositivos para automóviles son de 64 bits, haz lo siguiente:

[7.6.1/A-2-1] La memoria disponible para el kernel y el espacio del 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 muy grandes
- mdpi o inferior en pantallas grandes
[7.6.1/A-2-2] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 944 MB 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 muy grandes
[7.6.1/A-2-3] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,280 MB si se usa alguna de las siguientes densidades:
- 400 DPI o más en pantallas pequeñas o normales
- xhdpi o superior en pantallas grandes
- tvdpi o superior en pantallas muy grandes
[7.6.1/A-2-4] La memoria disponible para el kernel y el espacio del usuario DEBE ser de al menos 1,824 MB si se usa alguna de las siguientes densidades:
- 560 DPI o más en pantallas pequeñas o normales
- 400 DPI o más en pantallas grandes
- xhdpi o superior en pantallas extra grandes

Implementaciones de dispositivos para automóviles:

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

Implementaciones de dispositivos para automóviles:

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

Implementaciones de dispositivos para automóviles:

[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 automóviles 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 automóviles DEBEN admitir los siguientes formatos de codificación de video y ponerlos a disposición de las aplicaciones de terceros:

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

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

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

SE RECOMIENDA ENCARECIDAMENTE que las implementaciones de dispositivos para automóviles admitan la siguiente decodificación de video:

[5.3/A-SR] H.265 HEVC

2.5.3. Software

Implementaciones de dispositivos para automóviles:

[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 para automóviles proporcionan una API propietaria con android.car.CarPropertyManager y android.car.VehiclePropertyIds, deben cumplir con los siguientes requisitos:

[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 usen estas propiedades.
[3/A-1-2] NO DEBE replicar una propiedad del vehículo que ya exista en el SDK.

Implementaciones de dispositivos para automóviles:

[3.2.1/A-0-1] DEBE admitir y aplicar todas las constantes de permisos según se documenta en la página de referencia de permisos de Automotive.
[3.2.3.1/A-0-1] DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.
[3.4.1/A-0-1] DEBE proporcionar una implementación completa de la API de android.webkit.Webview.
[3.8.3/A-0-1] DEBE mostrar notificaciones que usen la API de Notification.CarExtender cuando lo soliciten aplicaciones de terceros.
[3.8.4/A-SR] Se recomienda encarecidamente implementar un asistente en el dispositivo para controlar la acción de asistencia.

Si las implementaciones de dispositivos para automóviles incluyen un botón de presionar para hablar, deben cumplir con lo siguiente:

[3.8.4/A-1-1] DEBE usar una presión breve del botón de presionar para hablar 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 automóviles:

[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 PLAY 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 la interfaz de usuario por aplicación para reducir los controles.

Implementaciones de dispositivos para automóviles:

[3.14/A-0-1] DEBE incluir un framework de IU para admitir apps de terceros que usen las APIs de medios, 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 de medios mientras conduce.
[3.14/A-0-3] DEBE admitir la acción de Intent implícito CAR_INTENT_ACTION_MEDIA_TEMPLATE con el elemento adicional CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] DEBE proporcionar una ayuda visual para navegar a la actividad de preferencias de una aplicación de medios, pero SOLO DEBE habilitarla cuando no estén vigentes las restricciones de la UX para automóviles.
[3.14/A-0-5] DEBE mostrar los mensajes de error establecidos por las aplicaciones de medios y DEBE admitir los elementos adicionales opcionales ERROR_RESOLUTION_ACTION_LABEL y ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] DEBE admitir una opción 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 y CONTENT_STYLE_PLAYABLE_HINT cuando se muestre la jerarquía de MediaBrowser.

Si las implementaciones de dispositivos para automóviles incluyen una app de selector predeterminada, deben cumplir con los siguientes requisitos:

[3.14/A-1-1] DEBE incluir servicios de medios y abrirlos con el intent CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementaciones de dispositivos para automóviles:

[3.8/A] PUEDE restringir las solicitudes de la aplicación para ingresar al modo de pantalla completa, como se describe en immersive documentation.
[3.8/A] PUEDE mantener visibles la barra de estado y la barra de navegación 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 potencia

Implementaciones de dispositivos para automóviles:

[8.2/A-0-1] DEBE informar la cantidad de bytes leídos y escritos en el almacenamiento no volátil por cada UID del proceso, de modo que las estadísticas estén disponibles para los desarrolladores a través de la API del sistema android.car.storagemonitoring.CarStorageMonitoringManager. El Proyecto de código abierto de Android cumple con el requisito a través del módulo del kernel uid_sys_stats.
[8.3/A-1-3] DEBE admitir el Modo garaje.
[8.3/A] DEBE estar en modo de garaje durante al menos 15 minutos después de cada viaje, a menos que se cumpla una de las siguientes condiciones:
- La batería está agotada.
- No se programan trabajos inactivos.
- El conductor sale del modo Garage.
[8.4/A-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo de corriente para cada componente de hardware y el consumo aproximado de batería 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] DEBE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
[8.4/A-0-3] DEBE informar el consumo de energía de la CPU por 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] SE DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.
[8.4/A-0-4] DEBE poner este uso de energía a disposición del 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 para automóviles 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 encabezado ni que cambien a él, excepto para el aprovisionamiento del dispositivo.
[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 haya alcanzado la cantidad máxima de usuarios en un dispositivo.

Implementaciones de dispositivos para automóviles:

[9.11/A-0-1] DEBE realizar una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
[9.11/A-0-2] DEBE tener implementaciones de los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles del sistema Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y en niveles superiores. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito usando 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 manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android 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 realice en hardware seguro. Las claves de firma de la 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.

Implementaciones de dispositivos para automóviles:

[9.14/A-0-1] DEBE controlar el acceso a los mensajes de los subsistemas del vehículo del framework de Android, p.ej., agregar tipos y fuentes de mensajes permitidos a una lista de entidades permitidas.
[9.14/A-0-2] DEBE supervisar los ataques de denegación de servicio del framework de Android o de apps de terceros. Esto protege contra el software malicioso que inunda la red del vehículo con tráfico, lo que puede provocar un mal funcionamiento de los subsistemas del vehículo.

2.5.6. Compatibilidad de las herramientas y opciones para desarrolladores

Implementaciones de dispositivos para automóviles:

Perfetto
- [6.1/A-0-1] DEBE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [6.1/A-0-2] El archivo 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 archivo 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 archivo binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.

2.6. Requisitos de la tablet

Un dispositivo de tablet Android hace referencia a una implementación de dispositivo Android que suele cumplir con todos los siguientes criterios:

Se usa sosteniéndola con ambas manos.
No tiene una configuración convertible ni de tipo clamshell.
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 diagonal física de entre 7 y 18 pulgadas.

Las implementaciones de dispositivos tablet tienen requisitos similares a las implementaciones de dispositivos portátiles. Las excepciones se indican con un asterisco (*) en esa sección y se mencionan como referencia en esta sección.

2.6.1. Hardware

Tamaño de pantalla

[7.1.1.1/Tab-0-1] DEBE tener una pantalla de entre 7 y 18 pulgadas.

Giroscopio

Si las implementaciones de dispositivos Tablet incluyen un giroscopio de 3 ejes, deben cumplir con lo siguiente:

[7.3.4/Tab-1-1] DEBE poder medir los cambios de orientación 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 dispositivos portátiles no se aplican a las tablets.

Modo de periférico USB (sección 7.7.1)

Si las implementaciones de dispositivos tablet incluyen un puerto USB que admite el modo periférico, deben cumplir con lo siguiente:

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

Modo de realidad virtual (sección 7.9.1)

Alto rendimiento de realidad virtual (sección 7.9.2)

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

2.6.2. Modelo de seguridad

Claves y credenciales (sección 9.11)

Consulta la sección [9.11].

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

[9.5/T-1-1] DEBE admitir perfiles restringidos, una función que permite a los propietarios del dispositivo 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 posibilidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.

Si las implementaciones de dispositivos Tablet incluyen varios usuarios y declaran el parámetro de la función android.hardware.telephony, deben cumplir con lo siguiente:

[9.5/T-2-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de AOSP de los controles para habilitar o inhabilitar el acceso de otros usuarios 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 aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí.

3. Software

3.1. Compatibilidad de la API administrada

El entorno de ejecución de código de bytes de Dalvik administrado es el principal vehículo para las aplicaciones de 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] DEBE proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android o cualquier API decorada con el marcador “@SystemApi” en el código fuente de Android upstream.
[C-0-2] DEBE admitir o conservar todas las clases, los métodos y los elementos asociados marcados por la anotación TestApi (@TestApi).
[C-0-3] NO DEBE omitir ninguna API administrada, alterar las interfaces o firmas de las APIs, desviarse del comportamiento documentado ni incluir no-ops, excepto cuando se permita específicamente en esta Definición de Compatibilidad.
[C-0-4] DEBE mantener las APIs presentes y comportarse de manera razonable, incluso cuando se omitan 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 pertenecen al SDK, las cuales 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] DEBE incluirse con todas y cada una de las interfaces que no pertenecen al SDK en las mismas listas restringidas que se proporcionan a través de las marcas provisionales y de lista de bloqueo en la ruta de acceso prebuilts/runtime/appcompat/hiddenapi-flags.csv para la rama del nivel de API correspondiente en AOSP.
[C-0-7] DEBE admitir el mecanismo de actualización dinámica de configuración firmada para quitar interfaces que no pertenecen al SDK de una lista restringida incorporando la configuración firmada en cualquier APK, con las claves públicas existentes presentes en AOSP.

Sin embargo, no pueden hacer lo siguiente:
- MAY, si una API oculta está ausente o se implementa de manera diferente en la implementación del dispositivo, mueve la API oculta a la lista de bloqueo o omítela de todas las listas restringidas (es decir, gris claro, gris oscuro, negra).
- PUEDE: Si ya existe una API oculta en el AOSP, agrégala a cualquiera de las listas restringidas (es decir, gris claro, gris oscuro, negra).

3.1.1. Extensiones de Android

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

Implementaciones de dispositivos Android:

[C-0-1] DEBE precargar la implementación del AOSP de la biblioteca compartida ExtShared y los servicios ExtServices con versiones mayores o iguales que las versiones mínimas permitidas para cada nivel de API. Por ejemplo, las implementaciones de dispositivos con Android 7.0, que ejecutan el nivel de API 24, DEBEN incluir al menos la versión 1.
[C-0-2] SOLO DEBE devolver números de versión de extensión válidos que haya definido el AOSP.
[C-0-3] DEBE admitir todas las APIs definidas por las versiones de extensión que devuelve android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la misma manera que se admiten otras APIs administradas, según 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 deben hacer lo siguiente:

[C-0-1] NO DEBE colocar la biblioteca org.apache.http.legacy en la ruta de arranque.
[C-0-2] Se DEBE agregar la biblioteca org.apache.http.legacy a la ruta de clase de la aplicación solo cuando la app cumpla con una de las siguientes condiciones:
- Se segmenta para el nivel de API 28 o versiones anteriores.
- Declara en su manifiesto que necesita la biblioteca configurando el atributo android:name de <uses-library> en org.apache.http.legacy.

La implementación de AOSP cumple con estos requisitos.

3.2. Compatibilidad de API flexible

Además de las APIs administradas de la sección 3.1, Android también incluye una API “flexible” 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 tiempo de 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, tal 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 varias 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 las implementaciones de dispositivos DEBEN ajustarse.

Parámetro	Detalles
VERSION.RELEASE	Versión del sistema Android que se está ejecutando actualmente, en formato legible. Este campo DEBE tener uno de los valores de cadena definidos en 11.
VERSION.SDK	Es la versión del sistema Android que se está ejecutando actualmente, en un formato accesible para el código de la aplicación de terceros. En Android 11, este campo DEBE tener el valor de número entero 11_INT.
VERSION.SDK_INT	Es la versión del sistema Android que se está ejecutando actualmente, en un formato accesible para el código de la aplicación de terceros. En Android 11, este campo DEBE tener el valor de número entero 11_INT.
VERSION.INCREMENTAL	Es un valor elegido por el implementador del dispositivo que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible para el usuario. Este valor NO se debe volver a usar para diferentes compilaciones disponibles para los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de 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 elegido por el implementador del dispositivo que identifica el hardware interno específico que usa el dispositivo, en formato legible para humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SEGURIDAD	Es un valor que refleja el nombre de la marca asociada al dispositivo, tal como lo conocen los usuarios finales. DEBE estar en un formato legible para las personas 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	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	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	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	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	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 clave 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_-]+$”. El nombre del dispositivo NO DEBE cambiar durante la vida útil del producto.
FINGERPRINT	Es una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible. DEBE seguir esta plantilla: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por ejemplo: acme/myproduct/ mydevice:11/LMYXX/3359:userdebug/test-keys 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	Nombre del hardware (desde la línea de comandos del kernel o /proc). DEBE ser razonablemente legible. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ORGANIZADOR	Es una cadena que identifica de forma única el host en el que se compiló la compilación, en un formato legible. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
ID	Es un identificador elegido por el implementador 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 las 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.
MODELO.	Es un valor elegido por el implementador del dispositivo que contiene el nombre del dispositivo tal como lo conoce el usuario final. Este DEBE ser el mismo nombre con el que se comercializa y vende el dispositivo a los usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
PRODUCTO	Es un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre clave del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente está destinado a que lo vean los usuarios finales. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre del producto NO DEBE cambiar durante la vida útil del producto.
SERIAL	DEBE devolver "UNKNOWN".
ETIQUETAS	Es una lista de etiquetas separadas por comas que elige el implementador del dispositivo y que distinguen aún más la compilación. Las etiquetas DEBEN poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+”, y DEBEN tener uno de los valores correspondientes a las tres configuraciones típicas de firma de la plataforma de Android: release-keys, dev-keys y test-keys.
TIEMPO	Es un valor que representa la marca de tiempo de cuándo se produjo 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 tiempo de ejecución de Android: user, userdebug o eng.
USUARIO	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 la cadena vacía ("").
VERSION.SECURITY_PATCH	Es un valor que indica el nivel de parche de seguridad de una compilación. DEBE indicar que la compilación no es vulnerable de ninguna manera a ninguno de los problemas descritos hasta el Boletín público de seguridad de Android designado. DEBE tener el formato [AAAA-MM-DD], que coincida con una cadena definida y documentada en el Boletín público de seguridad de Android o en el Aviso de seguridad de Android, por ejemplo, "2015-11-01".
VERSION.BASE_OS	Es un valor que representa el parámetro FINGERPRINT de la compilación, que, de lo contrario, es idéntica a esta compilación, excepto por los parches proporcionados en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si no existe tal compilación, informar una cadena vacía ("").
BOOTLOADER	Es un valor elegido por el implementador del dispositivo que identifica la versión específica del bootloader interno que se usa en el dispositivo, en un formato legible para las personas. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion()	DEBE ser o devolver un valor elegido por 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. Si un dispositivo no tiene radio o módem internos, DEBE devolver NULL. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.
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 poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.

3.2.3. Compatibilidad de intents

3.2.3.1. Intents de aplicaciones comunes

Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidad 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] SE RECOMIENDA ENCARECIDAMENTE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para todos los patrones de filtros de intents públicos definidos por los siguientes intents de aplicaciones que se enumeran aquí y proporcionar cumplimiento, es decir, satisfacer las expectativas del desarrollador para estos intents de aplicaciones comunes como se describe en el SDK.

Consulta la Sección 2 para conocer los intents obligatorios de la aplicación 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 las aplicaciones de terceros anulen cada patrón de intents 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 su control. Esta prohibición incluye específicamente, sin limitaciones, la inhabilitación de la interfaz de usuario del “Selector” que permite al usuario seleccionar 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 para 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 intents 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 filtros de intents de una app, las implementaciones del dispositivo hacen lo siguiente:

[C-0-4] DEBE intentar validar los filtros de intents realizando los pasos de validación definidos en la especificación de Digital Asset Links tal como la 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.
PUEDE establecer filtros de intents de URI específicos como controladores de apps predeterminados para sus URI, si se verifican correctamente, pero otros filtros de URI candidatos no superan la verificación. Si una implementación de dispositivo hace esto, DEBE proporcionar al usuario anulaciones adecuadas por patrón de URI en el menú de configuración.
DEBE proporcionar al usuario controles de vínculos de app por app en la 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 la app para que una app se pueda abrir siempre, preguntar siempre o no abrirse nunca, 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 intents.
- [C-0-8] La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intents de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros de intents de URI candidatos superen 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 cumpla con patrones de intents nuevos o de intents de transmisión que usen una cadena de ACTION, CATEGORY o cualquier otra cadena clave en el espacio de nombres android. o com.android..
[C-0-2] Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que cumpla con patrones de intents nuevos o de intents de transmisión nuevos que usen una cadena de ACTION, CATEGORY o cualquier otra cadena clave en un espacio de paquetes 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 usen espacios de nombres asociados de forma clara y evidente con su propia organización. Esta prohibición es análoga a la que se especifica para las clases de lenguaje Java en la sección 3.6.

3.2.3.4. Intents de transmisión

Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intents que les notifiquen 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, ciertas intents de transmisión son condicionales según la compatibilidad del hardware. Si el dispositivo admite el hardware necesario, DEBE transmitir las intents y proporcionar el comportamiento en línea con la documentación del SDK.

3.2.3.5. Intents de la aplicación condicionales

Android incluye parámetros de configuración que les brindan a los usuarios una forma sencilla de seleccionar sus aplicaciones predeterminadas, por ejemplo, para la pantalla principal o los SMS.

Cuando sea pertinente, 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 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, significa que:

[C-1-1] DEBE satisfacer la intención android.settings.HOME_SETTINGS para mostrar un menú de configuración predeterminado de la app para la pantalla principal.

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

[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 permita cambiar la aplicación de SMS predeterminada.
[C-2-2] DEBE satisfacer la intención android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar un diálogo que permita al usuario cambiar la aplicación de Teléfono predeterminada.
- DEBE usar la IU de la app de Teléfono predeterminada seleccionada por el usuario para las llamadas entrantes y salientes, excepto para las llamadas de emergencia, que usarían la app de Teléfono preinstalada.
[C-2-3] DEBE satisfacer la intención android.telecom.action.CHANGE_PHONE_ACCOUNTS para proporcionar al usuario la posibilidad de configurar el objeto ConnectionServices asociado con el objeto PhoneAccounts, así como un objeto PhoneAccount predeterminado que el proveedor de servicios de telecomunicaciones usará para realizar llamadas salientes. La implementación del AOSP cumple con este requisito, ya que incluye un menú "Opción de cuentas de llamadas" en el menú de configuración "Llamadas".
[C-2-4] DEBE permitir android.telecom.CallRedirectionService para una app que tenga el rol android.app.role.CALL_REDIRECTION.
[C-2-5] DEBE proporcionar la opción para que el usuario elija una app que tenga el rol de 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] Se recomienda encarecidamente 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 marcador precargada que pueda controlar estos intents y proporcionar la respuesta como se describe en el SDK.

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

[C-3-1] DEBE respetar el intent android.settings.NFC_PAYMENT_SETTINGS para mostrar un menú de configuración predeterminado de la app 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 tarjeta predeterminado para una categoría determinada, como se describe en el SDK.

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

[C-4-1] DEBE cumplir con 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 admiten VoiceInteractionService y tienen más de una aplicación que usa esta API instalada a la vez, deben hacer lo siguiente:

[C-4-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 android.hardware.bluetooth, significa que:

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

Si las implementaciones de dispositivos admiten la función No molestar, deben cumplir con los siguientes requisitos:

[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 rechazar el acceso de la app a la configuración de la política de DND.

Si las implementaciones del dispositivo permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con lo siguiente:

[C-8-1] DEBE satisfacer la intención de android.settings.ACCESSIBILITY_SETTINGS para proporcionar un mecanismo accesible para el usuario que permita habilitar e inhabilitar 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, deben cumplir con los siguientes requisitos:

[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, deben hacer lo siguiente: * [C-10-1] 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, deben hacer 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 la compatibilidad con la cámara a través de android.hardware.camera.any, deben hacer lo siguiente:

[C-12-1] DEBE respetar la intención de android.media.action.STILL_IMAGE_CAMERA y android.media.action.STILL_IMAGE_CAMERA_SECURE, y debe iniciar la cámara en el modo de imagen fija, como se describe en el SDK.
[C-12-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.
[C-12-3] DEBE aceptar solo que las aplicaciones para Android preinstaladas controlen los siguientes intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE y MediaStore.ACTION_VIDEO_CAPTURE, como se describe en el documento del SDK.

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

[C-13-1] DEBE respetar la intención android.app.action.ADD_DEVICE_ADMIN de invocar una IU para guiar al usuario a través de la adición del administrador de dispositivos al sistema (o permitirle rechazarlo).
[C-13-2] DEBE satisfacer las intents android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, 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 satisfacer estas intents como se describe en el SDK aquí.

Si las implementaciones de dispositivos declaran el parámetro de configuración android.software.autofill, deben hacer lo siguiente:

[C-14-1] DEBE implementar por completo las APIs de AutofillService y AutofillManager, y cumplir con el intent android.settings.REQUEST_SET_AUTOFILL_SERVICE para mostrar un menú de configuración predeterminado de la app que permita habilitar y deshabilitar el autocompletado, y cambiar 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 hacer lo siguiente:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE proporcionar un mecanismo accesible para el usuario que permita 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 apps preinstaladas, acceda a las estadísticas de uso, deben hacer lo siguiente:

[C-15-1] DEBE tener una actividad que controle el patrón de intents android.settings.ACTION_USAGE_ACCESS_SETTINGS, pero DEBE implementarlo como una operación sin efecto, es decir, tener un comportamiento equivalente al que se produce cuando se rechaza el acceso del usuario.

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

[C-SR] Se recomienda encarecidamente que se respeten los intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA y android.speech.tts.engine.GET_SAMPLE_TEXT, y que se tenga una actividad para proporcionar el cumplimiento de estos intents, como se describe aquí en el SDK.

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

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

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, deben cumplir con 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 de forma similar a una actividad que se ejecuta en la pantalla principal.
[C-1-3] DEBE iniciar 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] DEBE destruir todas las actividades cuando se quita una pantalla con la marca Display.FLAG_PRIVATE.
[C-1-5] DEBE ocultar de forma segura el contenido en todas las pantallas cuando el dispositivo esté bloqueado con un bloqueo de pantalla seguro, a menos que la app habilite la opción para mostrarse sobre 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 del dispositivo permiten iniciar actividades de Android normales en pantallas secundarias y una pantalla secundaria tiene la marca android.view.Display.FLAG_PRIVATE, se aplican las siguientes condiciones:

[C-3-1] Solo el propietario de esa pantalla, el sistema y las actividades que ya se encuentran en esa pantalla DEBEN poder iniciarse en ella. Cualquier persona puede iniciar una pantalla que tenga el parámetro android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidad con la API nativa

La compatibilidad con código nativo es un desafío. Por este motivo, los implementadores de dispositivos deben hacer lo siguiente:

[SR] SE RECOMIENDA ENCARECIDAMENTE usar 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 aplicaciones

El código de bytes de Dalvik administrado puede llamar al código nativo proporcionado en el archivo .apk de la aplicación como un archivo .so ELF compilado para la arquitectura de hardware del dispositivo adecuada. Dado que el código nativo depende en gran medida de la tecnología del procesador subyacente, Android define varias interfaces binarias de aplicaciones (ABIs) 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, utilizando la semántica estándar de la interfaz nativa de Java (JNI).
[C-0-3] DEBE ser compatible con el código fuente (es decir, con el encabezado) y con el código binario (para la ABI) con cada biblioteca requerida en la siguiente lista.
[C-0-5] DEBE informar con precisión la interfaz binaria de 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 y android.os.Build.SUPPORTED_64_BIT_ABIS, cada uno de ellos una lista separada por comas de las ABI 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 (ya no es compatible como destino en el NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] DEBE poner a disposición de las apps que incluyen código nativo todas las siguientes bibliotecas, que proporcionan APIs nativas:
- libaaudio.so (compatibilidad con audio nativo de AAudio)
- libamidi.so (compatibilidad con MIDI nativo, si se reclama la función android.software.midi como se describe en la sección 5.9)
- libandroid.so (compatibilidad con actividades nativas de Android)
- libc (biblioteca C)
- libcamera2ndk.so
- libdl (vinculador dinámico)
- libEGL.so (administración de superficies OpenGL nativas)
- 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 las APIs de medios nativas)
- libm (biblioteca matemática)
- libneuralnetworks.so (API de Neural Networks)
- libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
- libOpenSLES.so (compatibilidad de audio con 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 mencionadas anteriormente.
[C-0-9] DEBE incluir en /vendor/etc/public.libraries.txt las bibliotecas adicionales que no son de AOSP y que se exponen directamente a las apps de terceros.
[C-0-10] NO DEBE exponer ninguna otra biblioteca nativa, implementada y proporcionada en AOSP como bibliotecas del sistema, a las apps de terceros que segmentan el nivel de API 24 o superior, ya que están reservadas.
[C-0-11] DEBE exportar todos los símbolos de función de OpenGL ES 3.1 y del Android Extension Pack, según se definen en el NDK, a través de la biblioteca libGLESv3.so. Ten en cuenta que, si bien TODOS los símbolos DEBEN estar presentes, la sección 7.1.4.1 describe con más detalle los requisitos para los casos en los que se espera la implementación completa de cada una de las funciones correspondientes.
[C-0-12] DEBE exportar símbolos de funciones para los símbolos de funciones principales de Vulkan 1.0, así como las extensiones VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 y VK_KHR_get_physical_device_properties2 a través de la biblioteca libvulkan.so. Ten en cuenta que, si bien TODOS los símbolos DEBEN estar presentes, la sección 7.1.4.2 describe con más detalle los requisitos para los casos en los que se espera la implementación completa de cada una de las funciones correspondientes.
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 más ABIs.

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

Si las implementaciones de dispositivos informan la compatibilidad con la ABI armeabi, deben cumplir con lo siguiente:

[C-3-1] TAMBIÉN DEBE admitir armeabi-v7a y registrar su compatibilidad, ya que armeabi solo se usa para la retrocompatibilidad con apps más antiguas.

Si las implementaciones de dispositivos informan la compatibilidad con la ABI armeabi-v7a, para las apps que usan esta ABI, se cumplen las siguientes condiciones:

[C-2-1] DEBE incluir las siguientes líneas en /proc/cpuinfo y NO DEBE alterar los valores en el mismo dispositivo, incluso cuando los lean otras ABIs.
- Features:, seguido de una lista de las funciones opcionales de CPU ARMv7 que admite el dispositivo.
- CPU architecture:, seguido de un número entero que describe la arquitectura ARM más alta compatible con el dispositivo (p.ej., "8" para dispositivos ARMv8).
[C-2-2] DEBE mantener siempre disponibles las siguientes operaciones, incluso en el caso de que la ABI se implemente en una arquitectura ARMv8, ya sea a través de la compatibilidad nativa de la CPU o a través de la emulación de software:
- Instrucciones SWP y SWPB
- Es la instrucción SETEND.
- 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, deben cumplir con lo siguiente:

[C-1-1] Se DEBE informar android.software.webview.
[C-1-2] DEBE usar la compilación del proyecto Chromium del proyecto de código abierto de Android upstream en la rama de Android 11 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 la palabra "Mobile" en la cadena del usuario-agente.
El componente WebView DEBE incluir compatibilidad con la mayor cantidad posible de funciones de HTML5 y, si admite la función, DEBE cumplir con la especificación de HTML5.
[C-1-3] 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 renderizador 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 en 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 a IndexedDB por sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.
ES POSIBLE que se envíe una cadena de usuario-agente personalizada en la aplicación del navegador independiente.
DEBE implementar la compatibilidad con la mayor cantidad posible de HTML5 en la aplicación de navegador independiente (ya sea que se base en la aplicación de navegador de WebKit upstream o en un reemplazo de terceros).

Sin embargo, si las implementaciones de dispositivos no incluyen una aplicación de navegador independiente, deben cumplir con lo siguiente:

[C-2-1] DEBE seguir admitiendo los patrones de intención pública 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] DEBE 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 garantice la compatibilidad del comportamiento de la API solo para las apps que seleccionen los implementadores del dispositivo.

El comportamiento de cada uno de los tipos de API (administrada, flexible, nativa y web) debe ser coherente 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 una intención estándar.
[C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etcétera).
[C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
Los dispositivos NO DEBEN alterar las limitaciones que se aplican a las aplicaciones en segundo plano. Más específicamente, para las apps en segundo plano:
- [C-0-4] DEBEN detener la ejecución de las devoluciones de llamada que registra la app para recibir resultados de GnssMeasurement y GnssNavigationMessage.
- [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 de LocationManager o el método de WifiManager.startScan().
- [C-0-6] Si la app se segmenta para el nivel de API 25 o superior, NO DEBE permitir el registro de receptores de emisión para las emisiones 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 de "signature" o "signatureOrSystem" protectionLevel o esté en la lista de exenciones.
- [C-0-7] Si la app se segmenta para el nivel de API 25 o superior, DEBE detener los servicios en segundo plano de la app, 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 sea visible para el usuario.
- [C-0-8] Si la app se orienta al nivel de API 25 o superior, DEBE liberar los bloqueos de activación que mantiene.
[C-0-9] Los dispositivos DEBEN devolver los siguientes proveedores de seguridad como los primeros siete valores del array del método Security.getProviders(), en el orden indicado y con los nombres (según los devuelve Provider.getName()) y las clases indicados, a menos que la app haya modificado la lista a través de insertProviderAt() o removeProvider(). Los dispositivos PUEDEN devolver proveedores adicionales después de la lista de proveedores especificada a continuación.
1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider: sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround: android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC: com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

La lista anterior no es exhaustiva. El Conjunto de pruebas de compatibilidad (CTS) prueba partes significativas de la plataforma para verificar la compatibilidad del 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 significativas del sistema.

3.5.1. Restricción de la aplicación

Si las implementaciones de dispositivos implementan un mecanismo propietario para restringir apps y ese mecanismo es más restrictivo que el segmento de App Standby poco frecuentes, deben hacer lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el usuario vea la lista de apps restringidas.
[C-1-2] DEBE proporcionar al usuario la posibilidad de activar o desactivar las restricciones en cada app.
[C-1-3] NO DEBE aplicar restricciones automáticamente sin evidencia de un comportamiento deficiente del sistema, pero PUEDE aplicar las restricciones en las apps cuando se detecte un comportamiento deficiente del sistema, como bloqueos de activación atascados, servicios de ejecución prolongada 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 como criterios otros que no estén relacionados exclusivamente con el estado del sistema, como la falta de popularidad de la app en el mercado.
[C-1-4] NO DEBE aplicar automáticamente restricciones de apps cuando un usuario las haya desactivado de forma manual y PUEDE sugerirle al usuario que las aplique.
[C-1-5] DEBE informar a los usuarios si las restricciones de la app se aplican automáticamente. Esta información SE DEBE proporcionar en un plazo de 24 horas a partir de la aplicación de las restricciones.
[C-1-6] DEBE devolver true para ActivityManager.isBackgroundRestricted() cuando la app restringida llame a esta API.
[C-1-7] NO DEBE restringir la app en primer plano superior que el usuario usa de forma explícita.
[C-1-8] DEBE suspender las restricciones en una app que se convierte en la app en primer plano principal cuando el usuario comienza a usar de forma explícita la app que solía estar restringida.

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

[C-0-1] NO DEBE modificar las APIs expuestas públicamente en la plataforma de Android cambiando las firmas de métodos o clases, ni quitando clases o campos de clases.
[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 en los espacios de nombres anteriores. Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide", como se usa en el código fuente de Android upstream.

Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero dichas 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 SE DEBE publicitar ni exponer de ninguna otra manera 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.* o 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] DEBE 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 mayor uso de memoria de esas APIs.

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

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

3.7. Compatibilidad con el entorno de ejecución

Implementaciones de dispositivos:

[C-0-1] DEBE admitir el formato completo Dalvik Executable (DEX) 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 ver las 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 fuzzing en varios modos de ejecución y arquitecturas de destino para garantizar la estabilidad del tiempo de ejecución. Consulta JFuzz y DexFuzz en el sitio web del Proyecto de código abierto de Android.

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

Diseño de pantalla	Densidad de la pantalla	Memoria mínima de la aplicación
Reloj Android	120 dpi (ldpi)	32 MB
	140 dpi (140 ppp)
	160 dpi (mdpi)
	180 DPI (180dpi)
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220 DPI)	36 MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi	48 MB
	400 DPI (400dpi)	56 MB
	420 DPI (420DPI)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi	112 MB
	640 dpi (xxxhdpi)	154 MB
Pequeño/normal	120 dpi (ldpi)	32 MB
	140 dpi (140 ppp)
	160 dpi (mdpi)
	180 DPI (180dpi)	48 MB
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220 DPI)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80 MB
	360 dpi	80 MB
	400 DPI (400dpi)	96 MB
	420 DPI (420DPI)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi	192 MB
	640 dpi (xxxhdpi)	256 MB
grande	120 dpi (ldpi)	32 MB
	140 dpi (140 ppp)	48 MB
	160 dpi (mdpi)	48 MB
	180 DPI (180dpi)	80 MB
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220 DPI)
	240 dpi (hdpi)
	280 dpi (280dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi	160 MB
	400 DPI (400dpi)	192 MB
	420 DPI (420DPI)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi	384 MB
	640 dpi (xxxhdpi)	512 MB
Extragrande	120 dpi (ldpi)	48 MB
	140 dpi (140 ppp)	80 MB
	160 dpi (mdpi)	80 MB
	180 DPI (180dpi)	96 MB
	200 DPI (200dpi)
	213 DPI (tvdpi)
	220 DPI (220 DPI)
	240 dpi (hdpi)
	280 dpi (280dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi	240 MB
	400 DPI (400dpi)	288 MB
	420 DPI (420DPI)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi	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 Launcher (pantalla principal) y admite aplicaciones de terceros para reemplazar el Launcher del dispositivo (pantalla principal).

Si las implementaciones de dispositivos permiten que las aplicaciones de terceros reemplacen la pantalla principal del dispositivo, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos incluyen un selector predeterminado que admite la fijación de accesos directos en la app, deben cumplir con lo siguiente:

[C-2-1] Se DEBE informar true para ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] DEBE tener una opción para el usuario que le pregunte antes de agregar un acceso directo solicitado por las apps a través del método de la API ShortcutManager.requestPinShortcut().
[C-2-3] DEBE admitir accesos directos fijos, y accesos directos dinámicos y estáticos, como se documenta en la página de accesos directos de la app.

Por el contrario, si las implementaciones de dispositivos no admiten la fijación de accesos directos en la app, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos incluyen un selector predeterminado que proporciona acceso rápido a los accesos directos adicionales que ofrecen las apps de terceros a través de la API de ShortcutManager, deben cumplir con lo siguiente:

[C-4-1] DEBE admitir todas las funciones de acceso directo documentadas (p.ej., accesos directos estáticos y dinámicos, fijación de accesos directos) y debe 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 apps, deben cumplir con los siguientes requisitos:

[C-5-1] DEBE respetar el método de la API de NotificationChannel.setShowBadge(). En otras palabras, muestra una sugerencia visual asociada con el ícono de la app si el valor se establece como true y no muestres ningún esquema de distintivos del ícono de la app cuando todos los canales de notificación de la app hayan establecido el valor como false.
PUEDE anular las insignias de íconos de la app con su esquema de insignias propietario cuando las aplicaciones de terceros indican que admiten el esquema de insignias propietario a través del uso de APIs propietarias, pero DEBE usar los recursos y los valores proporcionados a través de las APIs de insignias de notificación que se describen en el SDK , como las APIs de Notification.Builder.setNumber() y Notification.Builder.setBadgeIconType().

3.8.2. Widgets

Android admite widgets de apps de terceros definiendo un tipo de componente y una API y un 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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar la compatibilidad con la función de la plataforma android.software.app_widgets.
[C-1-2] DEBE incluir compatibilidad integrada con AppWidgets y exponer recursos de interfaz de usuario para agregar, configurar, ver y quitar AppWidgets directamente desde el Selector.
[C-1-3] DEBE ser capaz de renderizar widgets de 4 x 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 detalles.
Es POSIBLE que admita 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, deben cumplir con lo siguiente:

[C-2-1] DEBE informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] DEBE tener una opción para el usuario que le pregunte antes de agregar un acceso directo solicitado por las apps a través del método de la API 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., sombra de notificación, 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, deben cumplir con 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 la implementación de un 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 más en la sección 7.
[C-1-2] DEBE renderizar correctamente todos los recursos (íconos, archivos de animación, etcétera) proporcionados en las APIs o en la guía de estilo de íconos de la barra de estado o del sistema, aunque PUEDE proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de referencia de Android Open Source.
[C-1-3] DEBE cumplir y aplicar 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 que se documenta en el SDK.
[C-1-5] DEBE proporcionar una opción para que el usuario bloquee y modifique las notificaciones de una app de terceros específica en cada canal y nivel de paquete de la app.
[C-1-6] TAMBIÉN DEBE proporcionar una opción para que el usuario muestre los canales de notificación borrados.
[C-1-7] DEBE 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, DEBE mostrar todos los recursos, incluidos los íconos proporcionados a través de android.app.Person, en una conversación grupal que se configura a través de setGroupConversation.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que se muestre automáticamente una opción para que el usuario bloquee la notificación de una app de terceros específica en cada canal y a nivel del paquete de la app después de que el usuario descarte esa notificación varias veces.
DEBE admitir notificaciones enriquecidas.
SHOULD presentar algunas notificaciones de mayor prioridad como notificaciones de atención.
DEBE tener una opción para posponer las notificaciones.
La MAY solo puede administrar la visibilidad y el momento 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 conversaciones, que son notificaciones que usan MessagingStyle y proporcionan un ID de acceso directo de Person publicado.

Implementaciones de dispositivos:

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

Si las implementaciones del dispositivo admiten conversation notifications y la app proporciona los datos necesarios para bubbles, se cumplen las siguientes condiciones:

[C-SR] Se RECOMIENDA ENCARECIDAMENTE mostrar esta conversación como una burbuja. La implementación del 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, deben cumplir con lo siguiente:

[C-2-1] DEBE usar los recursos exactos que se proporcionan a través de la clase de API Notification.Style y sus subclases para los elementos de recursos presentados.
DEBE presentar todos y cada uno de los elementos de recursos (p.ej., ícono, título y texto de resumen) definidos en la clase de la API de Notification.Style y sus subclases.

Si las implementaciones de dispositivos admiten notificaciones de atención, se cumplen las siguientes condiciones:

[C-3-1] DEBE usar la vista y los recursos de la notificación de atención como se describen en la clase de la API de Notification.Builder cuando se presenten 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 detección 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] DEBE actualizar de forma correcta y oportuna las notificaciones en su totalidad a todos los servicios de escucha instalados y habilitados por el usuario, incluidos todos los metadatos adjuntos al objeto de notificación.
[C-0-2] DEBE respetar 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 la postergación establecida en la llamada a la API.

Si las implementaciones de dispositivos tienen una opción para posponer notificaciones, deben cumplir con lo siguiente:

[C-1-1] DEBE reflejar correctamente el estado de la notificación pospuesta a través de las APIs estándares, como NotificationListenerService.getSnoozedNotifications().
[C-1-2] DEBE hacer que esta opción 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)

Si las implementaciones de dispositivos admiten la función No molestar, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE mostrar las Reglas de No molestar automáticas creadas por las aplicaciones junto con las reglas creadas por el usuario y las reglas predefinidas cuando la implementación del dispositivo haya proporcionado un medio para que el usuario otorgue o rechace el acceso de las apps de terceros a la configuración de la política de DND.
[C-1-3] DEBE respetar los valores de suppressedVisualEffects que se pasan a través de NotificationManager.Policy y, si una app configuró alguna de las marcas SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEBE indicarle al usuario que los efectos visuales se suprimen en el menú de configuración del modo No molestar.

3.8.4. Buscar

Android incluye APIs que permiten a los desarrolladores incorporar la búsqueda en sus aplicaciones y exponer los datos de sus aplicaciones en la búsqueda global del sistema. En términos generales, esta funcionalidad consiste en una sola interfaz de usuario en todo el sistema que permite a los usuarios ingresar consultas, mostrar sugerencias a medida que escriben y mostrar resultados. Las APIs de Android permiten que los desarrolladores reutilicen esta interfaz para proporcionar búsquedas dentro de sus propias apps y suministrar resultados a la interfaz de usuario de búsqueda global común.

Las implementaciones de dispositivos Android DEBEN incluir la búsqueda global, una interfaz de usuario de búsqueda única, compartida y en todo el sistema, capaz de proporcionar sugerencias en tiempo real en respuesta a la entrada del usuario.

Si las implementaciones de dispositivos implementan la interfaz de búsqueda global, deben hacer lo siguiente:

[C-1-1] DEBE implementar las APIs que permiten que las aplicaciones de terceros agreguen sugerencias al cuadro de búsqueda cuando se ejecuta en el modo de búsqueda global.

Si no hay aplicaciones de terceros instaladas que utilicen la búsqueda global, haz lo siguiente:

El comportamiento predeterminado DEBE ser mostrar los resultados y las sugerencias del motor de búsqueda web.

Android también 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 Asistencia, deben cumplir con los siguientes requisitos:

[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 acceda al contexto, se mostrará una luz blanca alrededor de los bordes de la pantalla que cumpla o supere la duración y el brillo de la implementación del Proyecto de código abierto de Android.
- En el caso de la app de asistencia preinstalada, proporcionar una ayuda para el usuario a menos de dos navegaciones de distancia del menú de configuración predeterminado de la app de entrada de voz y asistencia, y solo compartir el contexto cuando el usuario invoca 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 controla el intent ACTION_ASSIST.

3.8.5. Alertas y mensajes Toast

Las aplicaciones pueden usar la API de Toast para mostrar cadenas cortas no modales al usuario final que desaparecen después de un breve período 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, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el usuario bloquee la visualización de ventanas de alerta de una app que usen TYPE_APPLICATION_OVERLAY . La implementación del AOSP cumple con este requisito, ya que tiene controles en la sombra de notificación.
[C-1-2] DEBE cumplir con la API de Toast y mostrar los mensajes Toast de 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 toda una actividad o aplicación.

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

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[C-1-1] NO DEBE alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones.
[C-1-2] DEBE admitir la familia de temas "Material" y NO DEBE alterar ninguno de los atributos del tema Material ni sus recursos expuestos a las aplicaciones.
[C-1-3] DEBE establecer la familia de fuentes "sans-serif" en Roboto versión 2.x para los idiomas que admite Roboto, o bien proporcionar una opción para que el usuario cambie la fuente que se usa para la familia de fuentes "sans-serif" a Roboto versión 2.x para los idiomas que admite Roboto.

Android también incluye una familia de temas "Predeterminado del dispositivo" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen 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 variante con barras del sistema translú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 habilitar una experiencia del 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 lo siguiente:

[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 emitidas por el sistema, a menos que el ícono indique un estado problemático o una app solicite una barra de estado clara con la marca SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
[C-2-2] Las implementaciones de dispositivos Android DEBEN cambiar el color de los íconos de estado del sistema a negro (para obtener más detalles, 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, una API y un ciclo de vida correspondientes que permiten que las aplicaciones expongan uno o más “fondos de pantalla animados” al usuario final. Los fondos animados son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como fondo de pantalla, detrás de otras aplicaciones.

Se considera que el hardware es capaz de ejecutar 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 provocan que los fondos de pantalla o las aplicaciones fallen, funcionen mal, consuman una cantidad excesiva de CPU o batería, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware no es capaz de ejecutar fondos de pantalla animados. Por ejemplo, algunos fondos de pantalla animados pueden usar un contexto de OpenGL 2.0 o 3.x para renderizar su contenido. Los fondos de pantalla animados no se ejecutarán de forma confiable en hardware que no admita varios contextos de OpenGL, ya que el uso de un contexto de OpenGL por parte del fondo de pantalla animado puede entrar en conflicto con otras aplicaciones que también usen un contexto de OpenGL.

Las implementaciones de dispositivos capaces de ejecutar fondos animados de forma confiable, como se describió anteriormente, DEBEN implementar fondos animados.

Si las implementaciones de dispositivos incluyen fondos animados, deben cumplir con lo siguiente:

[C-1-1] DEBE informar el parámetro de configuració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 información general, una interfaz de usuario a nivel del sistema para cambiar de tarea y mostrar las 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 la abandonó por última vez.

Las implementaciones de dispositivos que incluyen la tecla de navegación de la función de Recientes, como se detalla en la sección 7.2.3, PUEDEN alterar la interfaz.

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

[C-1-1] DEBE admitir al menos hasta 7 actividades mostradas.
DEBE mostrar al menos el título de 4 actividades a la vez.
[C-1-2] DEBE implementar el comportamiento de fijación de pantalla y proporcionar al usuario un menú de configuración para 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 elemento de cierre ("x"), pero PUEDE retrasar esto hasta que el usuario interactúe con las pantallas.
DEBE implementar un acceso directo para cambiar fácilmente a la actividad anterior.
DEBE activar la acción de cambio rápido entre las dos apps usadas más recientemente cuando se presiona dos veces la tecla de función de Recientes.
DEBE activar el modo multiventana de pantalla dividida, si se admite, cuando se mantenga presionada la tecla de funciones de Recientes.
PUEDE mostrar los elementos recientes afiliados como un grupo que se mueve junto.
[SR] Se RECOMIENDA ENCARECIDAMENTE usar la interfaz de usuario de Android ascendente (o una interfaz similar basada en miniaturas) para la pantalla de resumen.

3.8.9. Administración de entrada

Android incluye compatibilidad con la administración de entrada y con editores de métodos de entrada de terceros.

Si las implementaciones del dispositivo permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la función de plataforma android.software.input_methods y admitir las APIs de IME según se definen 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 está obsoleta desde Android 5.0 en favor de la plantilla de notificación de medios que permite que las aplicaciones de medios se integren con los controles de reproducción que se muestran en la pantalla de bloqueo.

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

Consulta la sección 3.2.3.5 para conocer la intención 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 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, deben cumplir con lo siguiente:

[C-1-1] DEBE poder renderizar estos caracteres de emoji en un glifo de color.
[C-1-2] DEBE incluir compatibilidad con lo siguiente:
- Fuente Roboto 2 con diferentes pesos: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para los idiomas disponibles en el dispositivo.
- Cobertura completa de Unicode 7.0 de los alfabetos latino, griego y cirílico, incluidos los rangos latino extendido A, B, C y D, y todos los glifos del bloque de símbolos de moneda de Unicode 7.0
DEBE admitir los emojis de tono de piel y de familias diversas, como se especifica en el Informe técnico núm. 51 de Unicode.

Si las implementaciones de dispositivos incluyen un IME, deben cumplir con lo siguiente:

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

Android incluye compatibilidad para renderizar fuentes de Myanmar. Birmania tiene varias fuentes que no cumplen con Unicode, conocidas comúnmente como “Zawgyi”, para renderizar los idiomas birmanos.

Si las implementaciones de dispositivos incluyen compatibilidad con birmano, deben cumplir con los siguientes requisitos:

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Multiventanas

Si las implementaciones de dispositivos tienen la capacidad de mostrar varias actividades al mismo tiempo, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar dichos modos multiventana de acuerdo con los comportamientos y las APIs de la aplicación 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 android:resizeableActivity que establece una app en el archivo AndroidManifest.xml, como se describe en este SDK.
[C-1-3] NO DEBE ofrecer el modo de pantalla dividida o de forma libre si la altura de la pantalla es inferior a 440 dp y el ancho de la pantalla es inferior a 440 dp.
[C-1-4] Una actividad NO DEBE cambiar de tamaño a uno inferior a 220 dp en los modos multiventana que no sean de pantalla en pantalla.
Las implementaciones de dispositivos con un tamaño de pantalla xlarge DEBEN admitir el modo de formato libre.

Si las implementaciones de dispositivos admiten el modo multiventana y el modo de pantalla dividida, deben cumplir con lo siguiente:

[C-2-1] DEBE cargar previamente un selector redimensionable como predeterminado.
[C-2-2] DEBE recortar la actividad anclada de una multiventana de pantalla dividida, pero DEBE mostrar parte de su contenido si la app de Launcher es la ventana enfocada.
[C-2-3] DEBE respetar los valores declarados de AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight de la aplicación de inicio de terceros y no anular estos valores durante la visualización de contenido de la actividad anclada.

Si las implementaciones de dispositivos admiten el modo multiventana y el modo multiventana de pantalla en pantalla, deben cumplir con lo siguiente:

[C-3-1] DEBE iniciar actividades en el modo multiventana de pantalla en pantalla cuando la app: * Se segmenta para el nivel de API 26 o superior y declara android:supportsPictureInPicture * Se segmenta para el nivel de API 25 o inferior y declara android:resizeableActivity y android:supportsPictureInPicture.
[C-3-2] DEBE exponer las acciones en su SystemUI según lo especificado por la actividad de PIP actual a través de la API de setActions().
[C-3-3] DEBE admitir relaciones de aspecto mayores o iguales a 1:2.39 y menores o iguales a 2.39:1, como se especifica en la actividad de PIP a través de la API de setAspectRatio().
[C-3-4] Se DEBE usar KeyEvent.KEYCODE_WINDOW para controlar la ventana de PIP. Si no se implementa el modo de PIP, la clave DEBE estar disponible para la actividad en primer plano.
[C-3-5] DEBE proporcionar una opción para que el usuario bloquee la visualización de una app en modo PIP. La implementación de AOSP cumple con este requisito, ya que tiene controles en la sombra de notificación.
[C-3-6] DEBE asignar el siguiente ancho y alto mínimos para la ventana de PIP cuando una aplicación no declara ningún valor para AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight:
- Los dispositivos con Configuration.uiMode establecido en un valor distinto de UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho y una altura mínimos de 108 dp.
- Los dispositivos con Configuration.uiMode establecido en UI_MODE_TYPE_TELEVISION DEBEN asignar un ancho mínimo de 240 dp y una altura mínima de 135 dp.

3.8.15. Corte de pantalla

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

Si las implementaciones de dispositivos incluyen cortes de pantalla, deben cumplir con los siguientes requisitos:

[C-1-5] NO DEBE tener recortes si la relación de aspecto del dispositivo es de 1.0 (1:1).
[C-1-2] NO DEBE tener más de un corte por borde.
[C-1-3] DEBE respetar las marcas de corte de pantalla establecidas por la app a través de la API de WindowManager.LayoutParams, como se describe en el SDK.
[C-1-4] DEBE informar los valores correctos para todas las métricas de corte 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 que los usuarios puedan ver el estado y realizar acciones rápidamente.

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

3.9. Administración del dispositivo

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

Si las implementaciones de dispositivos implementan el rango completo de políticas de administración de dispositivos definidas en la documentación del SDK de Android, cumplen con los siguientes requisitos:

[C-1-1] Se 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 Provisión del propietario del dispositivo

Si las implementaciones de dispositivos declaran android.software.device_admin, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir el registro de un cliente de Device Policy (DPC) como una app de propietario del dispositivo, como se describe a continuación:
- Cuando la implementación del dispositivo aún no tiene datos del usuario, hace lo siguiente:
  - [C-1-3] DEBE informar true para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-4] DEBE inscribir la aplicación del DPC como la app de propietario del dispositivo en respuesta a la acción de intent android.app.action.PROVISION_MANAGED_DEVICE.
  - [C-1-5] DEBE inscribir la aplicación del DPC como la app de propietario del dispositivo si este 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 de MIME MIME_TYPE_PROVISIONING_NFC.
- Cuando la implementación del dispositivo tiene datos del usuario, sucede lo siguiente:
  - [C-1-6] DEBE informar false para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-7] NO DEBE inscribir ninguna aplicación de DPC como app de propietario del dispositivo.
[C-1-2] DEBE requerir alguna acción afirmativa antes o durante el proceso de aprovisionamiento para dar el consentimiento para que la app se establezca como propietario del dispositivo. El consentimiento puede obtenerse a través de una acción del usuario o por algún medio programático, pero se DEBE mostrar un aviso de divulgación adecuado (como se menciona en AOSP) antes de que se inicie el aprovisionamiento del propietario del dispositivo. Además, el mecanismo de consentimiento programático del propietario del dispositivo que utilizan las empresas para el aprovisionamiento del propietario del dispositivo NO DEBE interferir en la experiencia lista para usar para el uso no empresarial.
[C-1-3] NO DEBE codificar de forma rígida el consentimiento ni impedir el uso de otras apps del propietario del dispositivo.

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

[C-2-1] DEBE tener un proceso para verificar que la app específica que se promociona pertenece a una solución legítima de administración de dispositivos empresariales y que ya se configuró en la solución propietaria para tener los derechos equivalentes a un "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".
PUEDE tener datos del usuario en el dispositivo antes de inscribir la aplicación del DPC como "Propietario del dispositivo".

3.9.1.2 Aprovisionamiento de perfiles administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar las APIs que permitan que una aplicación de Device Policy Controller (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 android.app.action.PROVISION_MANAGED_PROFILE) que experimentan los usuarios DEBE alinearse con la implementación de AOSP.
[C-1-3] DEBE proporcionar las siguientes opciones para el usuario en la Configuración para indicarle cuándo el controlador de políticas del dispositivo (DPC) inhabilitó una función del sistema en particular:
- Un ícono coherente o alguna otra ayuda para el usuario (por ejemplo, el ícono de información de AOSP upstream) para representar cuando un administrador del dispositivo restringe un parámetro de configuración en particular.
- Es un mensaje de explicación breve que proporciona el administrador del dispositivo a través de setShortSupportMessage.
- Ícono de la aplicación del DPC.

3.9.2 Compatibilidad con perfiles administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, deben cumplir con 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 la creación de 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 del AOSP) para indicar cuándo el usuario se encuentra dentro de una aplicación de perfil administrado.
[C-1-5] DEBE mostrar un mensaje emergente que indique que el usuario se encuentra en el perfil administrado cuando el dispositivo se active (ACTION_USER_PRESENT) y la aplicación en primer plano esté dentro del perfil administrado.
[C-1-6] Cuando exista un perfil administrado, DEBE mostrar una ayuda 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 Device Policy Controller lo habilita.
[C-1-7] Cuando existe un perfil administrado, DEBE exponer las siguientes opciones para el usuario principal y el perfil administrado:
- Contabilidad separada 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 perfil principal o administrado
- Administración independiente de las cuentas dentro del perfil administrado o del usuario principal
[C-1-8] DEBE garantizar que las aplicaciones de marcador, contactos y mensajería preinstaladas puedan buscar y consultar la información de la persona que llama desde el perfil administrado (si existe) junto con la del perfil principal, si el Device Policy Controller lo permite.
[C-1-9] DEBE garantizar que cumpla con todos los requisitos de seguridad aplicables para un dispositivo con varios usuarios habilitados (consulta la sección 9.5), aunque el perfil administrado no se considere otro usuario además del usuario principal.

Si las implementaciones del dispositivo declaran android.software.managed_users y android.software.secure_lock_screen, deben cumplir con 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 bloqueo de pantalla 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 principal, 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 devuelve getParentProfileInstance.
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 mostrar el mismo distintivo que se usa para indicar las aplicaciones del perfil administrado.

3.9.3 Asistencia para usuarios administrados

Si las implementaciones de dispositivos declaran android.software.managed_users, deben hacer lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el usuario cierre la sesión del usuario actual y vuelva al usuario principal en una sesión de varios usuarios cuando isLogoutEnabled devuelva true. Se DEBE poder acceder a la ayuda para el usuario desde la pantalla de bloqueo sin desbloquear el dispositivo.

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 hápticos y navegación con trackball o D-pad.

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con lo siguiente:

[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 adecuado a todas las implementaciones de AccessibilityService registradas, como se documenta en el SDK.
[C-1-4] DEBE agregar un botón en la barra de navegación del sistema que permita al usuario controlar el servicio de accesibilidad cuando los servicios de accesibilidad habilitados declaren AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Ten en cuenta que, para las implementaciones de dispositivos sin barra de navegación del sistema, este requisito no se aplica, pero las implementaciones de dispositivos DEBEN proporcionar una ayuda visual para que el usuario controle estos servicios de accesibilidad.

Si las implementaciones de dispositivos incluyen servicios de accesibilidad preinstalados, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE 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 inicial para que los usuarios habiliten los servicios de accesibilidad pertinentes, así como opciones para ajustar el tamaño de fuente, el tamaño de visualización y los gestos de ampliació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, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir las APIs del framework de TTS de Android.

Si las implementaciones de dispositivos admiten la instalación de motores de TTS externos, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE proporcionar una opción 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 TV (TIF) simplifica la entrega de contenido en vivo a los dispositivos Android TV. El TIF proporciona una API estándar para crear módulos de entrada que controlan dispositivos Android TV.

Si las implementaciones de dispositivos admiten TIF, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar la función de la plataforma android.software.live_tv.
[C-1-2] DEBE admitir todas las APIs de TIF de modo 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 Configuración rápida que permite acceder rápidamente 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 la Configuración rápida de terceros, deben cumplir con los siguientes requisitos:

[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 todos los mosaicos agregados por el usuario desde apps de terceros junto con los mosaicos de configuración rápida proporcionados por el sistema.

3.14. IU de medios

Si las implementaciones de dispositivos incluyen aplicaciones no activadas por voz (las Apps) que interactúan con aplicaciones de terceros a través de MediaBrowser o MediaSession, las Apps deben cumplir con los siguientes requisitos:

[C-1-2] DEBE mostrar claramente los íconos obtenidos a través de getIconBitmap() o getIconUri(), y los títulos obtenidos a través de getTitle(), como se describe en MediaDescription. Es posible que se acorten 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 muestre contenido proporcionado por esta aplicación de terceros.
[C-1-4] DEBE permitir que el usuario interactúe con toda la jerarquía de MediaBrowser. PUEDE restringir el acceso a parte de la jerarquía para cumplir con las reglamentaciones de seguridad (p.ej., distracción del conductor), pero NO DEBE dar un trato preferencial según el contenido o el proveedor de contenido.
[C-1-5] DEBE considerar el doble toque de KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3.15. Apps instantáneas

Las implementaciones de dispositivos DEBEN satisfacer los siguientes requisitos:

[C-0-1] Las Instant Apps SOLO DEBEN tener permisos que tengan el android:protectionLevel establecido en "instant".
[C-0-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 ACTION_SEND, ACTION_SENDTO o ACTION_SEND_MULTIPLE.
- El destino se expone de forma explícita con android:visibleToInstantApps
[C-0-3] Las apps instantáneas NO DEBEN interactuar de forma explícita con las apps instaladas, a menos que el componente se exponga a través de android:visibleToInstantApps.
[C-0-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.

Si las implementaciones de dispositivos admiten apps instantáneas, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE proporcionar las siguientes opciones para que el usuario interactúe con las Instant Apps. El AOSP cumple con los requisitos con la IU del sistema, la configuración y el Selector predeterminados.
[C-1-2] DEBE proporcionar una opción para que el usuario vea y borre las apps instantáneas almacenadas en caché de forma local para cada paquete de app individual.
[C-1-3] 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 al usuario DEBE incluir que las apps instantáneas no requieren instalación y proporcionar una opción que dirija al usuario a la pantalla de información de la aplicación en Configuración. En el caso de las Instant Apps que se inician a través de intents web, según se define con un intent con la acción establecida en Intent.ACTION_VIEW y con un esquema de "http" o "https", una ayuda adicional para el usuario DEBE permitir que el usuario no inicie la Instant App y que inicie el vínculo asociado con el navegador web configurado, si hay un navegador disponible en el dispositivo.
[C-1-4] DEBE permitir que se acceda a las Instant Apps en ejecución desde la función Recientes si esta función está disponible en el dispositivo.
[C-1-5] DEBE precargar uno o más componentes de aplicaciones o servicios con un controlador de intents para los intents que se enumeran en el SDK aquí y hacer que los intents sean visibles para las Instant Apps.

3.16. Sincronización de dispositivos complementarios

Android incluye compatibilidad con el 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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE declarar el parámetro de configuración FEATURE_COMPANION_DEVICE_SETUP .
[C-1-2] DEBE garantizar que las APIs del paquete android.companion estén completamente implementadas.
[C-1-3] DEBE proporcionar al usuario la posibilidad de seleccionar o confirmar que hay un dispositivo complementario presente y en funcionamiento.

3.17. Apps pesadas

Si las implementaciones de dispositivos declaran la función FEATURE_CANT_SAVE_STATE, deben cumplir con lo siguiente:

[C-1-1] DEBE tener solo una app instalada que especifique cantSaveState en ejecución en el sistema a la vez. Si el usuario sale de 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, en lugar de presionar el botón de atrás sin que queden actividades activas en el sistema), las implementaciones del dispositivo DEBEN priorizar esa app en la RAM, como lo hacen con otros elementos que se espera que sigan ejecutándose, como los servicios en primer plano. Mientras una app de este tipo se ejecuta en segundo plano, el sistema puede seguir aplicándole funciones de administración de energía, como limitar el acceso a la CPU y a la red.
[C-1-2] DEBE proporcionar una interfaz de usuario que permita elegir la app que no participará en el mecanismo normal de guardar y restablecer el estado una vez que el usuario inicie una segunda app declarada con el atributo cantSaveState.
[C-1-3] NO DEBE aplicar otros cambios en la política a las apps que especifican cantSaveState, como cambiar el rendimiento de la CPU o la prioridad 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 establecido por las apps y NO DEBE cambiar el comportamiento de la app en función de 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 los datos TAMBIÉN PUEDEN residir solo de forma local en el dispositivo. Los contactos que solo se almacenan en el dispositivo se denominan contactos locales.

Los RawContacts están "asociados con" o "almacenados en" una Account 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 los 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 los 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] SE RECOMIENDA ENCARECIDAMENTE no crear cuentas locales personalizadas.

Si las implementaciones del dispositivo usan una cuenta local personalizada, haz lo siguiente:

[C-1-1] ACCOUNT_NAME, de la cuenta local personalizada DEBE devolverse por ContactsContract.RawContacts.getLocalAccountName
[C-1-2] ACCOUNT_TYPE de la cuenta local personalizada DEBE devolver ContactsContract.RawContacts.getLocalAccountType
[C-1-3] Los contactos sin procesar que insertan las aplicaciones de terceros con la cuenta local predeterminada (es decir, estableciendo valores nulos para ACCOUNT_NAME y ACCOUNT_TYPE) SE DEBEN insertar en la cuenta local personalizada.
[C-1-4] Los contactos sin procesar insertados en la cuenta local personalizada NO se deben quitar cuando se agregan o quitan cuentas.
[C-1-5] Las operaciones de eliminación realizadas en la cuenta local personalizada DEBEN provocar que los contactos sin procesar se borren de inmediato (como si el parámetro CALLER_IS_SYNCADAPTER se hubiera establecido en verdadero), incluso si el parámetro CALLER\_IS\_SYNCADAPTER se hubiera establecido en falso o no se hubiera especificado.

4. Compatibilidad con el empaquetado de aplicaciones

Implementaciones de dispositivos:

[C-0-1] DEBE poder instalar y ejecutar archivos APK de Android tal como los genera la herramienta “aapt” incluida en el SDK oficial de Android.
Dado que el requisito anterior puede ser difícil de cumplir, se RECOMIENDA que las implementaciones de dispositivos usen el sistema de administración de paquetes de la implementación de referencia del AOSP.

Implementaciones de dispositivos:

[C-0-2] DEBE admitir la verificación de archivos “.apk” con 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 .apk, manifiesto de Android, código de bytes de Dalvik o código de bytes de RenderScript de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.
[C-0-4] NO DEBE permitir que las 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 aplicación de 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 el valor de android:targetSdkVersion establecido en 24 o menos.
- El usuario DEBE haberle otorgado permiso para instalar apps de fuentes desconocidas.
DEBE proporcionar una opción para el usuario que permita otorgar o revocar el permiso para instalar apps de fuentes desconocidas por aplicación, pero PUEDE optar por implementar esto como una operación nula y devolver RESULT_CANCELED para startActivityForResult() 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 a través de la API del sistema PackageManager.setHarmfulAppWarning al usuario antes de iniciar una actividad en una aplicación que la misma API del sistema PackageManager.setHarmfulAppWarning marcó como potencialmente dañina.
DEBE proporcionar una opción 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.
Si las implementaciones de dispositivos ya se lanzaron en una versión anterior de Android y no pueden cumplir con los requisitos [C-0-8] y [C-0-9] a través de una actualización de software del sistema, se PUEDEN eximir de estos requisitos.

5. Compatibilidad multimedia

Implementaciones de dispositivos:

[C-0-1] DEBE admitir los formatos de medios, codificadores, decodificadores, tipos de archivos y formatos de contenedores definidos en la sección 5.1 para cada códec declarado por MediaCodecList.
[C-0-2] SE DEBE declarar y registrar la compatibilidad con los codificadores y decodificadores disponibles para las 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 que se informan en su CamcorderProfile.

Implementaciones de dispositivos:

DEBE intentar lograr la latencia mínima del códec; en otras palabras,
- NO DEBE consumir ni almacenar búferes de entrada, y debe devolverlos solo una vez que se hayan procesado.
- NO DEBE conservar los búferes decodificados durante más tiempo del especificado por el estándar (p.ej., SPS).
- NO DEBE retener los búferes codificados más tiempo del que requiere la estructura del 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 Open Handset Alliance garantizan que estos códecs estén libres de patentes de terceros. Se recomienda a quienes deseen usar este código fuente en productos de hardware o software que las implementaciones de este código, incluso en software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes pertinentes.

5.1. Códecs de medios

5.1.1. Codificación de audio

Consulta más detalles en el artículo 5.1.3. Detalles de los códecs de audio.

Si las implementaciones de dispositivos declaran android.hardware.microphone, DEBEN admitir la codificación de los siguientes formatos de audio y ponerlos a disposición de 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] Frames de audio con 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 el artículo 5.1.3. Detalles de los códecs de audio.

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 AAC HE MPEG-4 (AAC+)
[C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ mejorado)
[C-1-4] AAC ELD (AAC mejorado de bajo retraso)
[C-1-11] xHE-AAC (perfil de HE-AAC extendido de ISO/IEC 23003-3, que incluye el perfil de Baseline de USAC y el perfil de control de rango dinámico de 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 los formatos de audio de alta resolución de hasta 24 bits, una frecuencia de muestreo de 192 kHz y 8 canales. Ten en cuenta que este requisito es solo para la decodificación y que se permite que un dispositivo realice un muestreo inferior y una reducción de la mezcla 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 reducción de mezcla (p.ej., una transmisión AAC 5.0 se debe decodificar en cinco canales de PCM, y una transmisión AAC 5.1 se debe decodificar en seis canales de PCM).
[C-2-2] Los metadatos de rango dinámico DEBEN definirse como se indica en "Control de rango dinámico (DRC)" en 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 y KEY_AAC_ENCODED_TARGET_LEVEL.
[SR] SE RECOMIENDA ENCARECIDAMENTE que todos los decodificadores de audio AAC cumplan con 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 sonoridad y DRC SE DEBEN interpretar y aplicar según el perfil de control de rango dinámico de DRC de MPEG-D nivel 1.
[C-3-2] El decodificador DEBE comportarse según la configuración establecida con las siguientes claves de android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL y KEY_AAC_DRC_EFFECT_TYPE.

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

MAY support loudness and dynamic range control using ISO/IEC 23003-4 Dynamic Range Control Profile.

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

Los metadatos de ISO/IEC 23003-4 DEBEN tener prioridad.

Todos los decodificadores de audio DEBEN admitir la salida de lo siguiente:

[C-6-1] Frames de audio con orden de bytes nativo de PCM de 16 bits a través de la API de android.media.MediaCodec.

5.1.3. Detalles de los códecs de audio

Formato/códec	Detalles	Tipos de archivo o formatos de contenedor que se admitirán
Perfil de AAC 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.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC sin procesar de ADTS (.aac, no se admite ADIF) MPEG-TS (.ts, no admite búsquedas, solo decodificación) Matroska (.mkv, solo decodificación)
Perfil MPEG-4 HE AAC (AAC+)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
Perfil MPEG-4 HE AACv2 (AAC+ mejorado)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC mejorado de bajo retraso)	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4 y .m4a)
USAC	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 7.35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4.75 a 12.2 kbps con muestreo a 8 kHz	3GPP (.3gp)
AMR-WB	9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz, como se define en AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (.3gp)
FLAC	Tanto para el codificador como para 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 procesamiento de datos de audio FLAC de 24 bits DEBE estar disponible con la configuración de audio de punto flotante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv, solo decodificación)
MP3	Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps	MP3 (.mp3) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv, solo decodificación)
MIDI	MIDI tipo 0 y 1. Versión 1 y 2 de DLS. XMF y Mobile XMF. Compatibilidad con los formatos de tono RTTTL/RTX, OTA y iMelody.	Tipo 0 y 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) WebM (.webm)
PCM/WAVE	El códec PCM DEBE admitir PCM lineal de 16 bits y 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 (el límite de las tasas depende del hardware). Se DEBEN admitir tasas de muestreo de 8 kHz a 192 kHz.	WAVE (.wav)
Opus	Decodificación: Compatibilidad con contenido mono, estéreo, 5.0 y 5.1 con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz. Codificación: Compatibilidad con contenido mono y estéreo con tasas de muestreo de 8,000, 12,000, 16,000, 24,000 y 48,000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, solo decodificación) Matroska (.mkv) WebM (.webm)

5.1.4. Codificación de imágenes

Consulta más detalles en el punto 5.1.6. Detalles de los códecs de imágenes

Las implementaciones de dispositivos DEBEN admitir la codificación de imágenes que se indica a continuación:

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

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

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

5.1.5. Decodificación de imágenes

Consulta más detalles en el punto 5.1.6. Detalles de los códecs de imágenes

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

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Sin procesar

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

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

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

5.1.6. Detalles de los códecs de imágenes

Formato/códec	Detalles	Tipos de archivo y formatos de contenedor 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) y HEIC (.heic)

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 de CodecCapabilities.
[SR] SE RECOMIENDA ENCARECIDAMENTE admitir el formato de color RGB888 para el modo Surface de entrada.
[C-1-3] DEBE admitir al menos uno de los formatos de color YUV420 8:8:8 planos o semipanos: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). Se RECOMIENDA ENCARECIDAMENTE que admitan ambos.

5.1.7. Códecs de video

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

Si las implementaciones de dispositivos incluyen un codificador o decodificador de video, deben cumplir con los siguientes requisitos:

[C-1-1] Los códecs de video DEBEN admitir tamaños de bytebuffer de entrada y salida que se adapten al fotograma comprimido y sin comprimir más grande posible, según lo dicten el estándar y la configuración, pero sin asignar recursos en exceso.
[C-1-2] Los codificadores y decodificadores de video DEBEN admitir formatos de color flexibles YUV420 8:8:8 (COLOR_FormatYUV420Flexible) a través de CodecCapabilities.
[C-1-3] Los codificadores y decodificadores de video DEBEN admitir al menos uno de los formatos de color YUV420 8:8:8 planar o semiplanar: COLOR_FormatYUV420PackedPlanar (equivalente a COLOR_FormatYUV420Planar) o COLOR_FormatYUV420PackedSemiPlanar (equivalente a COLOR_FormatYUV420SemiPlanar). Se RECOMIENDA ENCARECIDAMENTE que admitan ambos.
[SR] SE RECOMIENDA ENCARECIDAMENTE que los codificadores y decodificadores de video admitan al menos uno de los formatos de color YUV420 8:8:8 planos o semiplanos optimizados para hardware (YV12, NV12, NV21 o un formato equivalente optimizado por el proveedor).
[C-1-5] Los decodificadores de video que admiten un formato de alta profundidad de bits (más de 9 bits por canal) DEBEN admitir la salida de un formato equivalente de 8 bits si la aplicación lo solicita. Esto DEBE reflejarse en la compatibilidad con 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, deben cumplir con lo siguiente:

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

Si las implementaciones de dispositivos anuncian la compatibilidad con la actualización intra a través de FEATURE_IntraRefresh en la clase MediaCodecInfo.CodecCapabilities, deben cumplir con 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 del decodificador de video deben hacer lo siguiente:

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

5.1.8. Lista de códecs de video

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

5.1.9. Seguridad de códecs multimedia

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad de los códecs de medios, como se describe a continuación.

Android incluye compatibilidad con OMX, una API de aceleración multimedia multiplataforma, así como con Codec 2.0, una API de aceleración multimedia con una sobrecarga baja.

Si las implementaciones de dispositivos admiten contenido multimedia, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE proporcionar compatibilidad con códecs de medios 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 códec DEBE usar la API de OMX o Codec 2.0, sino que DEBE estar disponible la compatibilidad con al menos una de estas APIs, y la compatibilidad con las APIs disponibles DEBE incluir las protecciones de seguridad presentes.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE que incluyan compatibilidad con la API de Codec 2.0.

Si las implementaciones de dispositivos no admiten la API de Codec 2.0, deben hacer 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 medios (codificador o decodificador) que admita el dispositivo.
[C-2-2] Códecs cuyos nombres comienzan con "OMX.google." DEBE basarse en el código fuente del Proyecto de código abierto de Android.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que los códecs de software OMX se ejecuten en un proceso de códec que no tenga acceso a controladores de hardware que no sean asignadores de memoria.

Si las implementaciones de dispositivos admiten la API de Codec 2.0, deben cumplir con los siguientes requisitos:

[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 medios (codificador o decodificador) que admita el dispositivo.
[C-3-2] DEBE alojar los códecs de software de Codec 2.0 en el proceso de códecs de software tal como se proporciona en el Proyecto de código abierto de Android para permitir otorgar acceso a los códecs de software de forma más restringida.
[C-3-3] Códecs cuyos nombres comienzan con "c2.android." DEBE basarse en el código fuente del Proyecto de código abierto de Android.

5.1.10. Caracterización de códecs de medios

Si las implementaciones de dispositivos admiten códecs de medios, deben cumplir con los siguientes requisitos:

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

En particular:

[C-1-2] Códecs con nombres que comienzan con "OMX". DEBE usar las APIs de OMX y tener nombres que cumplan con los lineamientos de nomenclatura de OMX IL.
[C-1-3] Códecs con nombres que comienzan con "c2." DEBE usar la API de Codec 2.0 y tener nombres que cumplan con los lineamientos de nomenclatura de Codec 2.0 para Android.
[C-1-4] Códecs con nombres que comienzan con “OMX.google.” o “c2.android.” NO DEBE caracterizarse como proveedor ni como acelerado por hardware.
[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 que no sean asignadores y asignadores de memoria NO se deben caracterizar como solo de 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 basen en el código fuente de ese proyecto DEBEN caracterizarse como de proveedor.
[C-1-7] Los códecs que utilizan la 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 de medios DEBEN admitir esos formatos.

Si las implementaciones de dispositivos admiten códecs de video, se deben cumplir los siguientes requisitos:

[C-2-1] Todos los códecs de video DEBEN publicar datos de la velocidad de fotogramas alcanzable para los siguientes tamaños si el códec los admite:

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (codificador MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (otro)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (codificador MPEG4) 720 x 480 px (otros)	1408 x 1152 px (H263) 1280 x 720 px (otro)	1920 x 1080 px (que no sean MPEG4)	3840 x 2160 píxeles (HEVC, VP9)

[C-2-2] Los códecs de video que se caracterizan como acelerados por hardware DEBEN publicar información sobre los puntos de rendimiento. Cada uno DEBE enumerar todos los puntos de rendimiento estándar admitidos (que se indican en la API de PerformancePoint), a menos que estén cubiertos por otro punto de rendimiento estándar admitido.
Además, DEBEN publicar puntos de rendimiento extendidos si admiten un rendimiento de video sostenido que no sea uno de los estándares que se enumeran.

5.2. Codificación de video

Si las implementaciones de dispositivos admiten algún codificador de video y lo ponen a disposición de las apps de terceros, deben cumplir con lo siguiente:

NO DEBE ser, en dos ventanas deslizantes, más del 15% superior a la tasa de bits entre los intervalos de fotogramas clave (I-frame).
NO DEBE superar en más del 100% la tasa de bits en una ventana deslizante de 1 segundo.

Si las implementaciones de dispositivos incluyen una pantalla integrada con una longitud diagonal de al menos 2.5 pulgadas, un puerto de salida de video o declaran la compatibilidad con una cámara a través de la marca de función android.hardware.camera.any, deben cumplir con lo siguiente:

[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 las aplicaciones de terceros.
DEBE admitir los 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 los ponen a disposición de aplicaciones de terceros, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir velocidades 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 del fotograma en función de las marcas de tiempo de los búferes de entrada y asignar su depósito de bits en función de esa duración del fotograma.

Si las implementaciones de dispositivos admiten el codificador de video MPEG-4 SP y lo ponen a disposición de las apps de terceros, deben cumplir con los siguientes requisitos:

DEBE admitir velocidades de bits configurables de forma dinámica para el codificador compatible.

Si las implementaciones de dispositivos proporcionan codificadores de imágenes o video acelerados por hardware y admiten una o más cámaras de hardware conectadas o enchufables expuestas a través de las APIs de android.camera, se deben cumplir los siguientes requisitos:

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

5.2.1. H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y los ponen a disposición de apps de terceros, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el nivel 45 del perfil de Baseline.
DEBE admitir velocidades 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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil de Baseline nivel 3. Sin embargo, la compatibilidad con ASO (ordenamiento de segmentos arbitrario), FMO (ordenamiento 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 utilicen ASO, FMO ni RS para el perfil de Baseline.
[C-1-2] DEBE admitir los perfiles de codificación de video en SD (definición estándar) que se indican en la siguiente tabla.
DEBE admitir el perfil principal de nivel 4.
DEBE admitir los perfiles de codificación de video en HD (alta definición) como se indica en la siguiente tabla.

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

[C-2-1] DEBE admitir los perfiles de codificación que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 x 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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir los perfiles de codificación de video SD.
DEBE admitir los siguientes perfiles de codificación de video en HD (alta definición).
[C-1-2] DEBE admitir la escritura de archivos WebM de Matroska.
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 por Internet y de videoconferencia.

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

[C-2-1] DEBE admitir los perfiles de codificación que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
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, deben cumplir con los siguientes requisitos:

[C-1-2] DEBE admitir el perfil 0, nivel 3.
[C-1-1] DEBE admitir la escritura de archivos WebM de Matroska.
[C-1-3] DEBE generar datos de CodecPrivate.
DEBE admitir los perfiles de decodificación de HD, como se indica en la siguiente tabla.
Se RECOMIENDA ENCARECIDAMENTE [SR] admitir los perfiles de decodificación en HD como se indica en la siguiente tabla si hay un codificador de hardware.

	SD	HD: 720p	HD: 1080p	UHD
Resolución de video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
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, se deben cumplir los siguientes requisitos:

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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal de nivel 3.
DEBE admitir los perfiles de codificación en HD, como se indica en la siguiente tabla.
Se RECOMIENDA ENCARECIDAMENTE [SR] admitir los perfiles de codificación en HD, como se indica en la siguiente tabla, si hay un codificador de hardware.

	SD	HD: 720p	HD: 1080p	UHD
Resolución de video	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3. Decodificación de video

Si las implementaciones de dispositivos admiten los códecs VP8, VP9, H.264 o H.265, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir resolución de video dinámica y cambio de velocidad de fotogramas a través de las APIs de Android estándar 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 en el dispositivo.

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2, deben cumplir con los siguientes requisitos:

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

5.3.2. H.263

Si las implementaciones de dispositivos admiten decodificadores H.263, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir los niveles 30 y 45 del perfil de Baseline.

5.3.3. MPEG-4

Si las implementaciones de dispositivos incluyen 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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal de nivel 3.1 y el perfil de Baseline. La compatibilidad con ASO (ordenamiento de segmentos arbitrario), FMO (ordenamiento flexible de macrobloques) y RS (segmentos redundantes) es OPCIONAL.
[C-1-2] DEBE poder decodificar videos con los perfiles de SD (definición estándar) que se indican en la siguiente tabla y que estén codificados con el perfil básico y el perfil principal de nivel 3.1 (incluido 720p30).
DEBE poder decodificar videos con los perfiles de HD (alta definición) que se indican 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 del dispositivo deben hacer 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 en HD 1080p que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 x 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^televisores)
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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el perfil principal, nivel 3, nivel principal y los perfiles de decodificación de video SD, como se indica en la siguiente tabla.
DEBE admitir los perfiles de decodificación de HD, como se indica en la siguiente tabla.
[C-1-2] DEBE admitir los perfiles de decodificación en 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 del video, sucede lo siguiente:

[C-2-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones H.265 o VP9 de los perfiles 720, 1080 y UHD.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30/60 FPS (60 FPS^{Televisión 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, se deben cumplir los siguientes requisitos:

[C-3-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos de HDR requeridos de la aplicación, así como admitir la extracción y la salida de los metadatos de HDR requeridos del flujo de bits o del 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, deben cumplir con los siguientes requisitos:

[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 en HD que se indican en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución del video, sucede lo siguiente:

[C-2-1] Las implementaciones de dispositivos DEBEN admitir los perfiles de 720 p que se indican en la siguiente tabla.
[C-2-2] Las implementaciones de dispositivos DEBEN admitir los perfiles de 1080 p que se indican en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
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^televisores)	30 (60 fps^Television)
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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir los perfiles de decodificación de video SD que se indican en la siguiente tabla.
DEBE admitir los perfiles de decodificación de 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 de 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 del video, sucede lo siguiente:

[C-3-1] Las implementaciones de dispositivos DEBEN admitir al menos una de las decodificaciones de VP9 o H.265 de los perfiles 720, 1080 y UHD.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 píxeles
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 FPS (60 FPS^{Televisión con decodificación por hardware de VP9})	60 fps
Tasa de bits del video	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

Si las implementaciones de dispositivos afirman admitir VP9Profile2 o VP9Profile3 a través de las APIs de medios "CodecProfileLevel", se aplican las siguientes condiciones:

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 medios, deben cumplir con lo siguiente:

[C-4-1] Las implementaciones de dispositivos DEBEN aceptar los metadatos de HDR requeridos (KEY_HDR_STATIC_INFO para todos los perfiles de HDR, así como "KEY_HDR10_PLUS_INFO" para los perfiles de HDR10Plus) de la aplicación. También DEBEN admitir la extracción y la salida de los metadatos HDR requeridos del flujo de bits o del 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 , deben cumplir con 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 índice de seguimiento de las capas básicas retrocompatibles (si las hay) de modo que sea igual al índice de seguimiento de la capa combinada de Dolby Vision.

5.3.9. AV1

Si las implementaciones de dispositivos admiten el códec AV1, deben cumplir con los siguientes requisitos:

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

5.4. Grabación de audio

Si bien algunos de los requisitos que se describen en esta sección se indican como SHOULD desde Android 4.3, se prevé que la Definición de compatibilidad para versiones futuras los cambie a MUST. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos que se indican como SHOULD, ya que, 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, deben cumplir con lo siguiente:

[C-1-1] DEBE permitir la captura de contenido de audio sin procesar con las siguientes características:
- Formato: PCM lineal, 16 bits
- Tasas de muestreo: 8,000, 11,025, 16,000, 44,100 y 48,000 Hz
- Canales: Mono
DEBE permitir la captura de contenido de audio sin procesar con las siguientes características:
- Formato: PCM lineal, 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 misma cantidad de canales que micrófonos tiene el dispositivo
[C-1-2] DEBE capturar a tasas de muestreo superiores sin aumentar la resolución.
[C-1-3] DEBE incluir un filtro de suavizado adecuado cuando las frecuencias de muestreo mencionadas anteriormente se capturen con submuestreo.
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] DEBE cumplir con la API de MicrophoneInfo y completar correctamente la información de los micrófonos disponibles en el dispositivo a los que pueden acceder las aplicaciones de terceros a través de la API de AudioManager.getMicrophones(), y los micrófonos activos actualmente a los que pueden acceder las aplicaciones de terceros a través de las APIs de AudioRecord.getActiveMicrophones() y MediaRecorder.getActiveMicrophones(). Si las implementaciones del dispositivo permiten la captura de radio AM y calidad de DVD del contenido de audio sin procesar, deben cumplir con lo siguiente:
[C-2-1] DEBE capturar sin aumentar la muestra a una proporción superior a 16000:22050 o 44100:48000.
[C-2-2] DEBE incluir un filtro de suavizado adecuado para cualquier aumento o reducción de la muestra.

5.4.2. Captura para el reconocimiento de voz

Si las implementaciones de dispositivos declaran android.hardware.microphone, deben cumplir con lo siguiente:

[C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION en 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 grabe una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
[C-1-3] DEBE inhabilitar, de forma predeterminada, cualquier control de ganancia automático cuando se grabe una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
DEBE grabar el flujo de audio de reconocimiento de voz con características de amplitud versus frecuencia aproximadamente planas: específicamente, ±3 dB, de 100 Hz a 4,000 Hz.
DEBE grabar el flujo de audio de reconocimiento de voz con la sensibilidad de entrada configurada de modo que una fuente de nivel de potencia acústica (SPL) de 90 dB a 1,000 Hz produzca un valor RMS de 2,500 para muestras de 16 bits.
DEBE grabar el flujo de audio de reconocimiento de voz para que los niveles de amplitud de PCM realicen un seguimiento lineal de los cambios de SPL de entrada en un rango de al menos 30 dB, desde -18 dB hasta +12 dB re 90 dB SPL en el micrófono.
DEBE grabar el flujo de audio de reconocimiento de voz con una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.

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

[C-2-1] DEBE permitir que este efecto de audio se controle con la API de android.media.audiofx.NoiseSuppressor.
[C-2-2] Se 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 el desvío de 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, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX para que, cuando una aplicación use la API de android.media.AudioRecord para grabar desde esta fuente de audio, capture una combinación de todos los flujos de audio, excepto los 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, deben cumplir con lo siguiente:

DEBE implementar una tecnología de cancelación de eco acústico (AEC) optimizada para la comunicación por voz y aplicada a la ruta de captura cuando se captura con AudioSource.VOICE_COMMUNICATION.

Si la implementación del dispositivo proporciona un cancelador de eco acústico que se inserta en la ruta de audio de captura cuando se selecciona AudioSource.VOICE_COMMUNICATION, debe cumplir con lo siguiente:

[C-SR] Se RECOMIENDA ENCARECIDAMENTE declarar esto a través del método de la API de AcousticEchoCanceler AcousticEchoCanceler.isAvailable().
[C-SR] se RECOMIENDA_FUERTEMENTE permitir que este efecto de audio se controle con la API de AcousticEchoCanceler.
Se RECOMIENDA ENCARECIDAMENTE [C-SR] identificar de forma única cada implementación de tecnología de CAE 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 cualquier AudioSource.
[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, excepto AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER.
[C-1-3] DEBE silenciar la captura de audio para cualquier otra aplicación, excepto para un servicio de accesibilidad, mientras una aplicación esté capturando con AudioSource.VOICE_COMMUNICATION o AudioSource.CAMCORDER. Sin embargo, cuando una app captura contenido a través de AudioSource.VOICE_COMMUNICATION, otra app puede capturar la llamada de voz si es una app privilegiada (preinstalada) con el permiso CAPTURE_AUDIO_OUTPUT.
[C-1-4] Si dos o más aplicaciones capturan contenido de forma simultánea y ninguna tiene una IU en primer plano, la que inició la captura más recientemente recibe el audio.

5.4.6. Niveles de ganancia del micrófono

Si las implementaciones de dispositivos declaran android.hardware.microphone, deben cumplir con lo siguiente:

DEBE exhibir características de amplitud en función de la frecuencia aproximadamente planas en el rango de frecuencias medias: 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.
DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz reproducida a un nivel de presión acústica (SPL) de 90 dB produzca una respuesta con un valor RMS de 2,500 para muestras de 16 bits (o -22.35 dB a escala completa para muestras de punto flotante o doble precisión) para cada micrófono que se use para grabar la fuente de audio de reconocimiento de voz.
[C-SR] se RECOMIENDA ENCARECIDAMENTE que muestren niveles de amplitud en el rango de baja frecuencia, específicamente de ±20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencia media para cada micrófono que se use para grabar la fuente de audio de reconocimiento de voz.
[C-SR] se RECOMIENDA ENCARECIDAMENTE que muestren niveles de amplitud en el rango de alta frecuencia: específicamente, de ±30 dB desde 4,000 Hz hasta 22 kHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos que se usen para grabar la fuente de audio del reconocimiento de voz.

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, deben cumplir con 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, flotante
- Canales: Mono, estéreo, configuraciones multicanal válidas con hasta 8 canales
- Frecuencias de muestreo (en Hz):
  - 8,000, 11,025, 16,000, 22,050, 32,000, 44,100 y 48,000 en las configuraciones de canales mencionadas anteriormente
  - 96,000 en mono y estéreo
DEBE permitir la reproducción de contenido de audio sin procesar con las siguientes características:
- Tasas de muestreo: 24,000 y 48,000

5.5.2. Efectos de audio

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

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

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

5.5.3. Volumen de salida de audio

Implementaciones de dispositivos para automóviles:

DEBE permitir ajustar el volumen de audio por separado para cada transmisión de audio usando el tipo de contenido o el uso según lo definen AudioAttributes y el uso de audio del automóvil según se define públicamente en android.car.CarAudioManager.

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.

Para los fines de esta sección, usa las siguientes definiciones:

Latencia de salida. Es el intervalo entre el momento en que una aplicación escribe un fotograma 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 la señal sale del dispositivo a través de un puerto y se puede observar de forma externa.
Latencia de salida en frío. Es la latencia de salida del primer fotograma 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 en que una señal ingresa al dispositivo a través de un puerto y el momento en que una aplicación lee el fotograma correspondiente de datos codificados en PCM.
Entrada perdida. Es la parte inicial de un indicador de entrada que no se puede usar o no está disponible.
Latencia de entrada en frío. Es la suma del tiempo de entrada perdido y la latencia de entrada del primer fotograma, cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
Latencia de entrada continua. Es la latencia de entrada para los fotogramas posteriores mientras el dispositivo captura audio.
Jitter de salida en frío. Es la variabilidad entre las mediciones separadas de los valores de latencia de salida en frío.
Jitter de entrada en frío. Es la variabilidad entre las mediciones separadas de los valores de latencia de entrada en frío.
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 el indicador y mitigue la diferencia de fase entre los flujos de entrada y salida.
API de cola de búfer PCM de OpenSL ES Conjunto de APIs de OpenSL ES relacionadas con PCM dentro del NDK de Android.
API de audio nativa de AAudio Es el conjunto de APIs de AAudio dentro del NDK de Android.
Timestamp. Es un par que consta de una posición de fotograma 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.
glitch. Interrupción temporal o valor de muestra incorrecto en la señal de audio, que suele deberse a un desbordamiento inferior del búfer para la salida, un desbordamiento superior del búfer para la entrada o cualquier otra fuente de ruido digital o analógico.

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 tiene una precisión de +/- 2 ms.
[C-1-2] Latencia de salida en frío de 500 milisegundos o menos.

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

[C-SR] Latencia de salida en frío de 100 milisegundos o menos. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos nuevos y existentes que ejecuten esta versión de Android cumplan con estos requisitos ahora. En una versión futura de la plataforma en 2021, exigiremos que la latencia de salida en frío sea de 200 ms o menos.
[C-SR] Latencia de salida continua de 45 milisegundos o menos.
[C-SR] Minimiza la fluctuación de la salida en frío.
[C-SR] La marca de tiempo de salida que devuelven AudioTrack.getTimestamp y AAudioStream_getTimestamp tiene una precisión de +/- 1 ms.

Si las implementaciones del dispositivo cumplen con los requisitos anteriores, después de cualquier calibración inicial, cuando se usan las APIs de audio nativo de AAudio y la cola de búfer PCM de OpenSL ES, para la latencia de salida continua y la latencia de salida en frío en al menos un dispositivo de salida de audio compatible, se cumplen las siguientes condiciones:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE informar el audio de latencia baja declarando el parámetro de configuración android.hardware.audio.low_latency.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE cumplir con los requisitos de audio de baja latencia a través de la API de AAudio.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE asegurarse de que, para las transmisiones que devuelven AAUDIO_PERFORMANCE_MODE_LOW_LATENCY desde AAudioStream_getPerformanceMode(), el valor que devuelve AAudioStream_getFramesPerBurst() sea menor o igual que el valor que devuelve android.media.AudioManager.getProperty(String) para la clave de propiedad AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Si las implementaciones de dispositivos no cumplen con los requisitos de audio de baja latencia a través de las APIs de audio nativo de AAudio y la cola de búfer PCM de OpenSL ES, deben hacer lo siguiente:

[C-2-1] NO DEBE informar la compatibilidad con audio de baja latencia.

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

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

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

[C-SR] Latencia de entrada en frío de 100 milisegundos o menos Se RECOMIENDA ENCARECIDAMENTE que los dispositivos nuevos y existentes que ejecuten esta versión de Android cumplan con estos requisitos ahora. En una versión futura de la plataforma en 2021, exigiremos que la latencia de entrada en frío sea de 200 ms o menos como un requisito OBLIGATORIO.
[C-SR] Latencia de entrada continua de 30 milisegundos o menos
[C-SR] Latencia de ida y vuelta continua de 50 milisegundos o menos.
[C-SR] Minimiza la fluctuación de la entrada en frío.
[C-SR] Limita el error en las marcas de tiempo de entrada, según lo que devuelven AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

5.7. Protocolos de red

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

Si las implementaciones de dispositivos incluyen un decodificador de audio o video, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir todos los códecs y formatos de contenedor requeridos en la sección 5.1 a través de HTTP(S).
[C-1-2] DEBE admitir los formatos de segmentos de medios que se muestran en la siguiente tabla de formatos de segmentos de medios a través del protocolo de borrador de HTTP Live Streaming, versión 7.
[C-1-3] DEBE admitir el siguiente perfil de audio y video de RTP, y los códecs relacionados 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 obligatoria
MPEG-2 Transport Stream	ISO 13818	Códecs de video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sección 5.1.3 para obtener detalles sobre H264 AVC, MPEG2-4 SP y MPEG-2. Códecs de audio: AAC Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.
AAC con encuadre ADTS y etiquetas ID3	ISO 13818-7	Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.
WebVTT	WebVTT

Formatos de segmentos

Referencias

Compatibilidad con códecs obligatoria

MPEG-2 Transport Stream

ISO 13818

Códecs de video:

H264 AVC
MPEG-4 SP
MPEG-2

Consulta la sección 5.1.3 para obtener detalles sobre H264 AVC, MPEG2-4 SP y
MPEG-2.

Códecs de audio:

Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.

AAC con encuadre ADTS y etiquetas ID3

ISO 13818-7

Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.

WebVTT

RTSP (RTP, SDP)

Nombre del perfil	Referencias	Compatibilidad con códecs obligatoria
H264 AVC	RFC 6184	Consulta la sección 5.1.3 para obtener detalles sobre H264 AVC.
MP4A-LATM	RFC 6416	Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Consulta la sección 5.1.3 para obtener detalles sobre H263.
H263-2000	RFC 4629	Consulta la sección 5.1.3 para obtener detalles sobre H263.
AMR	RFC 4867	Consulta la sección 5.1.1 para obtener detalles sobre AMR-NB.
AMR-WB	RFC 4867	Consulta la sección 5.1.1 para obtener detalles sobre AMR-WB.
MP4V-ES	RFC 6416	Consulta la sección 5.1.3 para obtener detalles sobre MPEG-4 SP.
mpeg4-generic	RFC 3640	Consulta la sección 5.1.1 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 detalles.

5.8. Medios seguros

Si las implementaciones de dispositivos admiten la salida de video segura y son capaces de admitir superficies seguras, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la compatibilidad con Display.FLAG_SECURE.

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y admiten el protocolo de pantalla inalámbrica, deben cumplir con lo siguiente:

[C-2-1] DEBE proteger la vinculación 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, deben cumplir con 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 accesible para el usuario.

5.9. Interfaz digital de instrumentos musicales (MIDI)

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

[C-1-1] DEBE 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 de host USB, sección 7.7
- MIDI a través de Bluetooth LE que actúa como 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 el modo periférico MIDI a través de USB, sección 7.7

5.10. Audio profesional

Si las implementaciones de dispositivos informan que admiten la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager, deben hacer 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, DEBE ser de 20 milisegundos o menos, y DEBE ser de 10 milisegundos o menos en al menos una ruta compatible.
[C-1-3] DEBE incluir uno o más puertos USB que admitan el modo de host USB y el modo de periférico USB.
[C-1-4] DEBE informar la compatibilidad con la función android.software.midi.
[C-1-5] DEBE cumplir con los requisitos de latencia y audio USB usando la API de cola de búfer PCM de OpenSL ES y, al menos, una ruta de la API de audio nativo de AAudio.
[SR] Se RECOMIENDA ENCARECIDAMENTE que cumplan con los requisitos de latencia y audio USB usando la API de audio nativo de AAudio en lugar de la ruta de MMAP.
[C-1-6] DEBE tener una latencia de salida en frío de 200 milisegundos o menos.
[C-1-7] DEBE tener una latencia de entrada en frío de 200 milisegundos o menos.
[SR] SE RECOMIENDA ENCARECIDAMENTE que proporcionen un nivel constante de rendimiento de la CPU mientras el audio está activo y la carga de la CPU varía. Esto se debe probar con el ID de confirmación 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 de la versión para Android de SynthMark. SynthMark usa un sintetizador de software que se ejecuta en un framework de audio simulado que mide el rendimiento del sistema. La app de SynthMark debe ejecutarse con la opción “Prueba automatizada” y lograr los siguientes resultados:
- voicemark.90 >= 32 voces
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms

Consulta la documentación de SynthMark para obtener una explicación de las comparativas.

DEBE minimizar la imprecisión y la desviación del reloj de audio en relación con la hora estándar.
DEBE minimizar la desviación del reloj de audio en relación con la CPU CLOCK_MONOTONIC 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 la fluctuación 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 durante el uso normal con la latencia informada.
DEBE proporcionar una diferencia de latencia entre canales igual a cero.
DEBE minimizar la latencia media 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 posterior al inicio en frío.
DEBE proporcionar una diferencia de reloj de audio nula entre los lados de entrada y salida de los extremos correspondientes, cuando ambos estén activos. Algunos ejemplos de extremos correspondientes incluyen 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 extremos correspondientes de entrada y salida en el mismo subproceso cuando ambos estén activos, y debe ingresar a la devolución de llamada de salida inmediatamente después de regresar de la devolución de llamada de entrada. O bien, si no es factible 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 una sincronización coherente de los lados de entrada y salida.
DEBE minimizar la diferencia de fase entre el almacenamiento en búfer de audio del 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 (fluctuación).
DEBE tener una latencia desde la entrada táctil hasta la salida de audio menor o igual a 40 ms.

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

[SR] SE RECOMIENDA ENCARECIDAMENTE informar la compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager.

Si las implementaciones de dispositivos incluyen un conector de audio de 3.5 mm con 4 conductores, deben cumplir con lo siguiente:

[C-2-1] DEBE tener una latencia de audio continua de ida y vuelta de 20 milisegundos o menos a través de la ruta de acceso del conector de audio.
[SR] SE RECOMIENDA ENCARECIDAMENTE cumplir con la sección Especificaciones del dispositivo móvil (conector) de la Especificación de auriculares con cable (v1.1).
La latencia de audio de ida y vuelta continua DEBE ser de 10 milisegundos o menos a través de la ruta del conector de audio.

Si las implementaciones de dispositivos omiten un conector de audio de 3.5 mm de 4 conductores y, en cambio, incluyen puertos USB que admiten el modo de host USB, deben cumplir con lo siguiente:

[C-3-1] DEBE implementar la clase de audio USB.
[C-3-2] DEBE tener una latencia de audio continua de ida y vuelta de 20 milisegundos o menos en el puerto de modo host USB con la clase de audio USB.
La latencia de audio continua de entrada y salida DEBE ser de 10 milisegundos o menos a través del puerto en modo host USB con la clase de audio USB.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que admitan E/S simultáneas de hasta 8 canales en cada dirección, una frecuencia de muestreo de 96 kHz y una profundidad de 24 o 32 bits cuando se usen con periféricos de audio USB que también admitan estos requisitos.

Si las implementaciones de dispositivos incluyen un puerto HDMI, deben cumplir con lo siguiente:

DEBE admitir la salida en estéreo y ocho canales a una profundidad de 20 o 24 bits y 192 kHz sin pérdida de profundidad de bits ni nuevo muestreo, 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 predeterminado de grabación SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si las implementaciones de dispositivos pretenden admitir la fuente de audio sin procesar y ponerla a disposición de apps de terceros, deben hacer lo siguiente:

[C-1-1] DEBE informar la compatibilidad a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] DEBE exhibir características de amplitud versus frecuencia aproximadamente planas en el rango de frecuencias medias: 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] DEBE mostrar niveles de amplitud en el rango de baja frecuencia: específicamente, de ±20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos que se usen para grabar la fuente de audio sin procesar.
[C-1-4] DEBE mostrar niveles de amplitud en el rango de alta frecuencia: específicamente, de ±30 dB desde 7,000 Hz hasta 22 kHz en comparación con el rango de frecuencia media para todos y cada uno de los micrófonos que se usen para grabar la fuente de audio sin procesar.
[C-1-5] SE DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz reproducida a un nivel de presión acústica (SPL) de 94 dB produzca una respuesta con un valor RMS de 520 para muestras de 16 bits (o -36 dB a escala completa para muestras de punto flotante o de doble precisión) 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 SNR se mide como la diferencia entre 94 dB SPL y el SPL equivalente del ruido propio, ponderado según 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 todos y cada uno de los micrófonos que se usen para grabar la fuente de audio sin procesar.
NO debe tener ningún otro procesamiento de señales (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-8] Si hay procesamiento de señales en la arquitectura por algún motivo, DEBE inhabilitarse y no introducir retraso ni latencia adicionales en la ruta de la señal.
[C-1-9] Si bien se permite que el multiplicador de nivel esté en la ruta, NO DEBE introducir demora o latencia en la ruta de la señal.

Todas las mediciones de SPL se realizan directamente junto al micrófono que se está probando. En el caso de las configuraciones con varios micrófonos, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone, pero no admiten la fuente de audio sin procesar, deben hacer lo siguiente:

[C-2-1] DEBE devolver null para el método de la API de AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), para indicar correctamente la falta de compatibilidad.
[SR] siguen siendo ALTAMENTE RECOMENDADOS para satisfacer la mayor cantidad posible de requisitos de la ruta de señal de la fuente de grabación sin procesar.

6. Compatibilidad de las herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Implementaciones de dispositivos:

[C-0-1] DEBE admitir las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.
Android Debug Bridge (adb)
- [C-0-2] DEBE admitir adb según se documenta en el SDK de Android y los comandos de shell que se proporcionan en el AOSP, que pueden usar los desarrolladores de apps, incluido dumpsys cmd stats
- [C-0-11] DEBE admitir el comando de shell cmd testharness. Las implementaciones de dispositivos que se actualicen desde una versión anterior de Android sin un bloque de datos persistente PUEDEN estar exentas del 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 omisiones, y hacer que los siguientes eventos sean accesibles y estén disponibles para el comando de shell cmd stats y la clase de la API del sistema StatsManager.
  - 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] El daemon de adb del dispositivo DEBE estar inactivo de forma predeterminada, y DEBE haber un mecanismo accesible para el usuario para activar Android Debug Bridge.
- [C-0-5] DEBE admitir adb seguro. Android incluye compatibilidad con adb seguro. Secure adb habilita adb en hosts autenticados conocidos.
- [C-0-6] DEBE proporcionar un mecanismo que permita conectar adb desde una máquina host. Más precisamente:
Si las implementaciones de dispositivos sin puerto USB admiten el modo periférico, deben cumplir con lo siguiente:
- [C-3-1] DEBE implementar adb a través de una red de área local (como Ethernet o Wi-Fi).
- [C-3-2] DEBE proporcionar controladores para Windows 7, 8 y 10, lo que permite a los desarrolladores conectarse al dispositivo con el protocolo adb.
Si las implementaciones de dispositivos admiten conexiones de adb a una máquina host a través de Wi-Fi, deben cumplir con lo siguiente:
- [C-4-1] DEBE hacer que el método AdbManager#isAdbWifiSupported() muestre true.
Si las implementaciones de dispositivos admiten conexiones adb a una máquina host a través de Wi-Fi y tienen al menos una cámara, deben cumplir con lo siguiente:
- [C-5-1] DEBE hacer que el método AdbManager#isAdbWifiQrSupported() devuelva true.
Servicio de supervisión de depuración de Dalvik (ddms)
- [C-0-7] DEBE admitir todas las funciones de ddms según se documentan en el SDK de Android. Como ddms usa adb, la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible siempre que el usuario haya activado Android Debug Bridge, como se indicó anteriormente.
Monkey
- [C-0-8] DEBE incluir el framework de Monkey y ponerlo a disposición de las aplicaciones para que lo usen.
SysTrace
- [C-0-9] DEBE admitir la herramienta systrace como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada, y DEBE haber un mecanismo accesible para el usuario para activar Systrace.
Perfetto
- [C-SR] Se RECOMIENDA ENCARECIDAMENTE exponer un archivo binario /system/bin/perfetto al usuario de la shell cuya línea de comandos cumpla con la documentación de Perfetto.
- [C-SR] Se RECOMIENDA ENCARECIDAMENTE que el binario de Perfetto acepte como entrada un archivo de configuración de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que el archivo binario de Perfetto escriba como resultado un registro de protobuf que cumpla con el esquema definido en la documentación de Perfetto.
- [C-SR] Se RECOMIENDA ENCARECIDAMENTE que proporcionen, a través del binario de Perfetto, al menos las fuentes de datos que se describen en la documentación de Perfetto.
Low Memory Killer
- [C-0-10] DEBE escribir un átomo LMK_KILL_OCCURRED_FIELD_NUMBER en el registro de statsd cuando el Low Memory Killer finaliza una app.
Modo de agente de prueba Si las implementaciones del dispositivo admiten el comando de shell cmd testharness y ejecutan cmd testharness enable, hacen lo siguiente:
- [C-2-1] DEBE devolver true para ActivityManager.isRunningInUserTestHarness()
- [C-2-2] DEBE implementar el modo de agente de prueba como se describe en la documentación del modo de agente de prueba.

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o una versión posterior a través de los parámetros de configuración android.hardware.vulkan.version, deben cumplir con lo siguiente:

[C-1-1] DEBE proporcionar una opción para que el desarrollador de la app habilite o inhabilite las capas de depuración de GPU.
[C-1-2] DEBE, cuando las capas de depuración de la GPU están habilitadas, enumerar las capas en las bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte del paquete de la plataforma o 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 relacionados con el desarrollo de aplicaciones.

Las implementaciones de dispositivos DEBEN proporcionar una experiencia coherente para las opciones para desarrolladores:

[C-0-1] DEBE respetar el intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar la configuración relacionada con el desarrollo de aplicaciones. La implementación de Android upstream oculta el menú Opciones para desarrolladores de forma predeterminada y permite que los usuarios lo inicien después de presionar siete (7) veces el elemento de menú Configuración > Acerca del dispositivo > Número de compilación.
[C-0-2] MUST hide Developer Options by default.
[C-0-3] DEBE proporcionar un mecanismo claro que no dé un trato preferencial a una app de terceros en comparación con otra para habilitar las Opciones para desarrolladores. DEBE proporcionar un documento o sitio web visible públicamente que describa cómo habilitar las Opciones para desarrolladores. Se DEBE poder vincular este documento o sitio web desde los documentos del SDK de Android.
DEBE mostrar una notificación visual continua al usuario cuando las Opciones para desarrolladores estén habilitadas y la seguridad del usuario sea motivo de preocupación.
Es POSIBLE que se limite temporalmente el acceso al menú Opciones para desarrolladores, ya sea ocultándolo visualmente o inhabilitándolo, para evitar distracciones en situaciones en las que la seguridad del usuario sea una preocupación.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware en particular que tiene una API correspondiente para desarrolladores externos, se aplican las siguientes condiciones:

[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 posee ese componente, se debe hacer lo siguiente:

[C-0-2] Aún se DEBEN presentar las definiciones de clase completas (como se documentan en el SDK) para las APIs de 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 devolver valores nulos cuando lo permita la documentación del SDK.
[C-0-5] Los métodos de la API DEBEN devolver implementaciones no operativas 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 arrojar 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 precisa sobre la configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella digital de compilación.

Un ejemplo típico de 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 se deben implementar como no-ops 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, lo que garantiza que las aplicaciones de terceros se ejecuten correctamente en una variedad de configuraciones de hardware. En las pantallas compatibles con Android en las que se pueden ejecutar todas las aplicaciones de terceros compatibles con Android, las implementaciones del dispositivo DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

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

Tamaño diagonal físico. Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
puntos por pulgada (DPI). Es la cantidad de píxeles que abarca un tramo lineal horizontal o vertical de 1". Cuando se indican valores de DPI, tanto el DPI horizontal como el vertical deben estar dentro del rango.
relación de aspecto. Es la proporción de píxeles de la dimensión más larga con respecto a la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480 × 854 píxeles tendría una relación de aspecto de 854/480 = 1.779, o aproximadamente “16:9”.
píxel independiente de la densidad (dp). Unidad de píxel virtual normalizada para una pantalla de 160 dpi, calculada de la siguiente manera: píxeles = dps * (densidad/160).

7.1.1. Configuración de 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 de 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, según se define en la documentación del SDK de Android. Específicamente, las implementaciones de dispositivos DEBEN informar las dimensiones de pantalla correctas en píxeles lógicos independientes de la densidad (dp) como se indica a continuación:
- Los dispositivos con Configuration.uiMode establecido en cualquier valor que no sea UI_MODE_TYPE_WATCH y que informen un tamaño de small para el Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
- Los dispositivos que informan un tamaño de normal para el Configuration.screenLayout DEBEN tener al menos 480 dp x 320 dp.
- Los dispositivos que informan un tamaño de large para el Configuration.screenLayout DEBEN tener al menos 640 dp x 480 dp.
- Los dispositivos que informan un tamaño de xlarge para el Configuration.screenLayout DEBEN tener al menos 960 dp x 720 dp.
[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 el archivo AndroidManifest.xml, como se describe en la documentación del SDK de Android.
PUEDE tener pantallas compatibles con Android con esquinas redondeadas.

Si las implementaciones de dispositivos admiten UI_MODE_TYPE_NORMAL y tienen pantallas compatibles con Android con esquinas redondeadas, deben cumplir con lo siguiente:

[C-1-1] DEBE garantizar que se cumpla al menos uno de los siguientes requisitos:
El radio de las esquinas redondeadas es menor o igual a 38 dp.
Cuando se ancla un cuadro de 15 dp por 15 dp en cada esquina de la pantalla lógica, se puede ver al menos un píxel de cada cuadro en la pantalla.
DEBE incluir la capacidad del usuario para cambiar al modo de visualización con las esquinas rectangulares.

Si las implementaciones de dispositivos incluyen pantallas compatibles con Android que son plegables o incluyen una bisagra plegable entre varios paneles de pantalla y hacen que esas pantallas estén disponibles para renderizar apps de terceros, deben cumplir con lo siguiente:

[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 para que la use la biblioteca de Window Manager de Jetpack.

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 atraviesan una ventana de aplicación en pantalla completa, deben cumplir con lo siguiente:

[C-3-1] DEBE informar la posición, los límites y el estado de la bisagra o el pliegue 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 Window Manager Jetpack.

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 en el caso 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 derivar de los valores de altura y ancho que se informan a través de las APIs de view.Display y las APIs de Configuration, DEBE cumplir con los siguientes requisitos:

[C-0-1] Las implementaciones de dispositivos con Configuration.uiMode establecido en UI_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 su tamaño a través del atributo android:resizeableActivity.
- La app se orienta al nivel de API 24 o uno superior, y no declara un android:maxAspectRatio que restrinja la relación de aspecto permitida.
[C-0-2] Las implementaciones de dispositivos con Configuration.uiMode establecido en UI_MODE_TYPE_NORMAL DEBEN tener un valor de relación de aspecto igual o superior a 1.3333 (4:3), a menos que la app se pueda extender para que sea más ancha cumpliendo una de las siguientes condiciones:
- La app declara que se puede cambiar su tamaño a través del atributo android:resizeableActivity.
- La app declara un android:minAspectRatio que restringiría la relación de aspecto permitida.
[C-0-3] Las implementaciones de dispositivos con el parámetro Configuration.uiMode establecido como UI_MODE_TYPE_WATCH DEBEN tener un valor de relación de aspecto establecido como 1.0 (1:1).

7.1.1.3. Densidad de la pantalla

El framework de IU de Android define un conjunto de densidades lógicas estándar para ayudar a los desarrolladores de aplicaciones a orientar los recursos de la aplicación.

[C-0-1] De forma predeterminada, las implementaciones de dispositivos DEBEN informar solo una de las densidades del framework de Android que se enumeran en DisplayMetrics a través de la API de DENSITY_DEVICE_STABLE, y este valor NO DEBE cambiar en ningún momento. Sin embargo, el dispositivo PUEDE informar una densidad arbitraria diferente según los cambios en la 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 sea numéricamente más cercana a la densidad física de la pantalla, a menos que esa densidad lógica reduzca el tamaño de pantalla informado por debajo del mínimo admitido. Si la densidad del framework de Android estándar que es numéricamente más cercana a la densidad física genera un tamaño de pantalla más pequeño que el tamaño de pantalla compatible más pequeño admitido (320 dp de ancho), las implementaciones del dispositivo DEBEN informar la siguiente densidad del framework de Android estándar más baja.

Si hay una opción para cambiar el tamaño de la pantalla del dispositivo, haz lo siguiente:

[C-1-1] El tamaño de la pantalla NO DEBE escalarse más de 1.5 veces la densidad nativa ni producir una dimensión mínima efectiva de la pantalla inferior a 320 dp (equivalente al calificador de recursos sw320dp), lo que ocurra primero.
[C-1-2] El tamaño de la pantalla NO DEBE reducirse a menos de 0.85 veces la densidad nativa.
Para garantizar una buena usabilidad y tamaños de fuente coherentes, se RECOMIENDA proporcionar el siguiente ajuste de escala de las opciones de pantalla nativa (sin incumplir los límites especificados anteriormente).
Pequeño: 0.85x
Valor predeterminado: 1x (escala de pantalla nativa)
Grande: 1.15x
Más grande: 1.3 veces
La más grande, 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 lo siguiente:

[C-1-1] DEBE informar los valores correctos para todas las métricas de pantalla compatibles con Android definidas en la API de android.util.DisplayMetrics.

Si las implementaciones de dispositivos no incluyen una pantalla integrada o salida de video, deben cumplir con lo siguiente:

[C-2-1] DEBE informar los valores correctos de la pantalla compatible con Android, según se define en la API de android.util.DisplayMetrics para el view.Display predeterminado emulado.

7.1.3. Orientación de pantalla

Implementaciones de dispositivos:

[C-0-1] DEBE informar qué orientaciones de pantalla admite (android.hardware.screen.portrait o android.hardware.screen.landscape) y DEBE informar al menos una orientación admitida. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como una televisión o una laptop, SOLO DEBE informar android.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 cualquier otra API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir la orientación dinámica de las aplicaciones a la orientación de 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 o la densidad de la pantalla informados cuando se cambia la orientación.
La MAY puede seleccionar la orientación vertical u horizontal como predeterminada.

7.1.4. Aceleración de gráficos 2D y 3D

7.1.4.1 OpenGL ES

Implementaciones de dispositivos:

[C-0-1] DEBE identificar correctamente las versiones compatibles de OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) a través de las APIs administradas (por ejemplo, con el método GLES10.getString()) y las APIs nativas.
[C-0-2] DEBE incluir la compatibilidad con todas las APIs administradas y nativas correspondientes para cada versión de OpenGL ES que se haya identificado como compatible.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, tal como se describe y detalla en la documentación del SDK de Android.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que admitan OpenGL ES 3.1.
DEBE admitir OpenGL ES 3.2.

Si las implementaciones de dispositivos admiten alguna de las versiones de OpenGL ES, deben cumplir con lo siguiente:

[C-2-1] DEBE informar a través de las APIs administradas de OpenGL ES y las APIs nativas cualquier otra extensión de OpenGL ES que haya implementado y, a la inversa, NO DEBE informar cadenas de extensión que no admita.
[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 y EGL_ANDROID_GLES_layers.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE que admitan las extensiones EGL_KHR_partial_update y OES_EGL_image_external.
DEBE informar con precisión, a través del método getString(), cualquier formato de compresión de texturas que admita, que suele ser específico del proveedor.

Si las implementaciones de dispositivos declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2, deben cumplir con 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.
[SR] Se RECOMIENDAN ENCARECIDAMENTE para admitir la extensión OES_EGL_image_external_essl3.

Si las implementaciones de dispositivos admiten OpenGL ES 3.2, deben cumplir con 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 en su totalidad, cumplen con los siguientes requisitos:

[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, deben cumplir con lo siguiente:

[C-6-1] TAMBIÉN DEBE admitir la extensión EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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, deben cumplir con lo siguiente:

[SR] SE RECOMIENDA ENCARECIDAMENTE incluir compatibilidad con Vulkan 1.1.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, deben cumplir con lo siguiente:

DEBE incluir compatibilidad con Vulkan 1.1.

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-master-YYYY-MM-DD.txt. Un dispositivo que admite Vulkan en un nivel autoinformado indica que puede aprobar las pruebas de dEQP en todas las listas de pruebas de este nivel y los anteriores.

Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.0 o versiones posteriores, deben cumplir con lo siguiente:

[C-1-1] DEBE informar el valor entero correcto con los parámetros de configuración android.hardware.vulkan.level y android.hardware.vulkan.version.
[C-1-2] DEBE enumerar, al menos, un VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .
[C-1-3] DEBE implementar por completo las APIs de Vulkan 1.0 para cada VkPhysicalDevice enumerado.
[C-1-4] DEBE enumerar las capas, incluidas en las bibliotecas nativas denominadas como libVkLayer*.so en el directorio de bibliotecas nativas del paquete de la aplicación, a través de las APIs nativas de Vulkan vkEnumerateInstanceLayerProperties() y vkEnumerateDeviceLayerProperties() .
[C-1-5] NO DEBE enumerar las capas proporcionadas por bibliotecas fuera del paquete de la aplicación ni proporcionar otras formas de rastrear o interceptar la API de Vulkan, a menos que la aplicación tenga el atributo android:debuggable establecido como true.
[C-1-6] DEBE informar todas las cadenas de extensión que admite a través de las APIs nativas de Vulkan y, a la inversa, NO DEBE informar las cadenas de extensión que no admite 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 indica en el parámetro de configuración android.software.vulkan.deqp.level.
[C-1-10] DEBE aprobar todas las pruebas de dEQP de Vulkan en las listas de pruebas entre la versión 132317953 y la versión especificada en el parámetro de configuración android.software.vulkan.deqp.level.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE admitir las extensiones VK_KHR_driver_properties y VK_GOOGLE_display_timing.

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 funciones 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 Vulkan vkEnumeratePhysicalDevices().

Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.1 y declaran cualquiera de las marcas de funciones de Vulkan, deben cumplir con lo siguiente:

[C-3-1] DEBE exponer la compatibilidad con los tipos de identificadores y semáforos externos SYNC_FD, y la extensión VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

[C-0-1] Las implementaciones de dispositivos DEBEN admitir Android RenderScript, como se detalla en la documentación del SDK de Android.

7.1.4.4 Aceleración de gráficos 2D

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D a nivel de Application, Activity, Window o View a través del 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 Android View.
[C-0-2] DEBE exhibir 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 procesamiento en una jerarquía de IU.

Implementaciones de dispositivos:

[C-0-3] DEBE admitir la API de TextureView y DEBE exhibir un comportamiento coherente con la implementación de Android upstream.

7.1.4.5 Pantallas con amplia gama de colores

Si las implementaciones de dispositivos indican que admiten pantallas de amplia gama a través de Configuration.isScreenWideColorGamut() , deben cumplir con lo siguiente:

[C-1-1] DEBE tener una pantalla calibrada en color.
[C-1-2] DEBE tener una pantalla cuya gama cubra por completo la gama de colores sRGB en el espacio CIE 1931 xyY.
[C-1-3] DEBE tener una pantalla cuyo gamut tenga un área de, al menos, el 90% de DCI-P3 en el espacio CIE 1931 xyY.
[C-1-4] DEBE admitir OpenGL ES 3.1 o 3.2 y registrarlo 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 y EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR] Se RECOMIENDAN ENCARECIDAMENTE para admitir GL_EXT_sRGB.

Por el contrario, si las implementaciones de dispositivos no admiten pantallas de amplia gama, deben hacer lo siguiente:

[C-2-1] DEBE cubrir el 100% o más de sRGB en el espacio CIE 1931 xyY, aunque la gama de colores de la pantalla no esté definida.

7.1.5. Modo de compatibilidad con aplicaciones heredadas

Android especifica un “modo de compatibilidad” en el que el framework opera 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 preceden a la independencia del tamaño de pantalla.

7.1.6. Tecnología de 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 según lo define el SDK de Android, a menos que se permita específicamente en este documento.

Todas las pantallas compatibles con Android de la implementación de un dispositivo:

[C-0-1] DEBE poder renderizar gráficos en color de 16 bits.
DEBE admitir pantallas capaces de mostrar gráficos de color de 24 bits.
[C-0-2] DEBE poder renderizar animaciones.
[C-0-3] DEBE tener una relación de aspecto de píxeles (PAR) entre 0.9 y 1.15. Es decir, la relación de aspecto del píxel DEBE ser casi cuadrada (1.0) con una tolerancia del 10 al 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 con cable, inalámbrica o una conexión de pantalla adicional integrada, deben cumplir con lo siguiente:

[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 contacto, 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] DEBE implementar por completo Input Management Framework
[C-1-3] DEBE tener un teclado de software preinstalado.

Implementaciones de dispositivos: * [C-0-1] NO DEBEN incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.keyboard (QWERTY o de 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 contacto.

Implementaciones de dispositivos:

[C-0-1] DEBE informar el valor correcto para android.content.res.Configuration.navigation.

Si las implementaciones de dispositivos no tienen navegaciones sin contacto, 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 entrada. 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 táctil.

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 exclusivo 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 opción para el usuario que permita iniciar aplicaciones instaladas que tengan una actividad con el parámetro <intent-filter> establecido con ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para las implementaciones de dispositivos de televisión. La función de inicio DEBE ser el mecanismo para esta capacidad de uso del usuario.
DEBE proporcionar botones para las funciones Recientes y Atrás.

Si se proporcionan las funciones de Inicio, Recientes o Atrás, se cumplen las siguientes condiciones:

[C-1-1] DEBE ser accesible con una sola acción (p.ej., presión, doble clic o gesto) cuando cualquiera de ellas sea accesible.
[C-1-2] DEBE proporcionar una indicación clara de qué acción única activaría cada función. Algunos ejemplos de este tipo de indicación son 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 paso a paso durante la experiencia de configuración inicial.

Implementaciones de dispositivos:

[SR] SE RECOMIENDA ENCARECIDAMENTE que no proporcione el mecanismo de entrada para la función de menú, ya que se dejó de usar en favor de la barra de acciones desde Android 4.0.

Si las implementaciones de dispositivos proporcionan la función Menú, deben cumplir con lo siguiente:

[C-2-1] DEBE mostrar el botón de menú ampliado de acciones siempre que la ventana emergente del menú ampliado de acciones no esté vacía y la barra de acciones esté visible.
[C-2-2] NO DEBE modificar la posición de la ventana emergente de desbordamiento de acciones que se muestra cuando se selecciona el botón de desbordamiento en la barra de acciones, pero PUEDE renderizar la ventana emergente de desbordamiento de acciones en una posición modificada en la pantalla cuando se muestra al seleccionar la función Menú.

Si las implementaciones de dispositivos no proporcionan la función de menú, para garantizar 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 del menú, a menos que se oculte junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función de Asistencia, deben cumplir con lo siguiente:

[C-4-1] DEBE hacer que la función de Asistencia sea accesible con una sola acción (p.ej., un toque, un doble clic o un gesto) cuando se pueda acceder a otras teclas de navegación.
[SR] SE RECOMIENDA ENCARECIDAMENTE usar la función de mantener presionado en INICIO como esta interacción designada.

Si las implementaciones de dispositivos usan una parte distinta de la pantalla para mostrar las teclas de navegación, deben cumplir con los siguientes requisitos:

[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 obstruir ni interferir de ninguna otra manera con la parte de la pantalla disponible para las aplicaciones.
[C-5-2] DEBE poner a disposición de las aplicaciones una parte de la pantalla que cumpla con los requisitos definidos en la sección 7.1.1.
[C-5-3] DEBE respetar los parámetros de configuración establecidos por la app a través del método de la API de View.setSystemUiVisibility(), de modo 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 la pantalla principal.
[C-6-2] Los gestos que comienzan dentro de un rectángulo de exclusión proporcionado por la aplicación en primer plano a través de View#setSystemGestureExclusionRects(), pero fuera de WindowInsets#getMandatorySystemGestureInsets(), NO DEBEN interceptarse para la función de navegación siempre que el rectángulo de exclusión se permita dentro del límite máximo de exclusión especificado en la documentación de View#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 anteriormente se envió a la app en primer plano un evento MotionEvent.ACTION_DOWN.
[C-6-4] DEBE proporcionar una opción para que el usuario cambie 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 soltar, 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 de View#setSystemGestureExclusionRects().

Si se proporciona una función de navegación desde cualquier lugar de los bordes izquierdo y derecho de la orientación actual de la pantalla, sucede lo siguiente:

[C-7-1] La función de navegación DEBE ser Atrás y 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 personalizados que se pueden deslizar 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 hacia atrás. El usuario PUEDE configurar un panel del sistema de modo que se ubique por debajo del 1/3 superior de los bordes de la pantalla, pero el panel del sistema NO DEBE usar más de 1/3 de los bordes.
[C-7-3] Cuando la app en primer plano tiene establecidos los parámetros View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, deslizar el dedo desde los bordes DEBE comportarse como se implementó en AOSP, lo que se documenta en el SDK.
[C-7-4] Cuando la app en primer plano tiene establecidos los parámetros View.SYSTEM_UI_FLAG_IMMERSIVE o View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, los paneles del sistema personalizados que se pueden deslizar DEBEN ocultarse hasta que el usuario muestre las barras del sistema (también conocidas como barra de navegación y barra de estado), como se implementa en AOSP.

7.2.4. Entrada táctil

Android incluye compatibilidad con una variedad de sistemas de entrada de puntero, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil simulada. 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 la pantalla directamente, el sistema no requiere ninguna ayuda adicional para indicar los objetos que se manipulan.

Implementaciones de dispositivos:

DEBE tener un sistema de entrada de puntero de algún tipo (similar al mouse o táctil).
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 lo siguiente:

[C-1-1] DEBE informar TOUCHSCREEN_FINGER para el campo de la API Configuration.touchscreen.
[C-1-2] DEBE informar las marcas de funciones android.hardware.touchscreen y android.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 lo siguiente:

[C-2-1] DEBE informar los parámetros de configuración de funciones android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct y android.hardware.touchscreen.multitouch.jazzhand correspondientes 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 trackball (es decir, no tocan directamente la pantalla) para ingresar datos en una pantalla principal compatible con Android y cumplen con los requisitos de toque simulado que se indican en la sección 7.2.5, deben cumplir con lo siguiente:

[C-3-1] NO DEBE informar ninguna marca de función que comience con android.hardware.touchscreen.
[C-3-2] SOLO se debe informar android.hardware.faketouch.
[C-3-3] Se DEBE informar TOUCHSCREEN_NOTOUCH para el campo de la API de Configuration.touchscreen.

7.2.5. Entrada táctil falsa

La interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un subconjunto de las capacidades de la pantalla táctil. Por ejemplo, un mouse o un control remoto que hace funcionar un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o enfoque y, luego, haga clic. Numerosos 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 de alta fidelidad que no es táctil (basado en puntero), como un mouse o un panel táctil, que puede emular de forma adecuada la entrada basada en el tacto (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 sí otro sistema de entrada de puntero que desean poner a disposición, deben hacer lo siguiente:

DEBE declarar la compatibilidad con la marca de función android.hardware.faketouch.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch, deben cumplir con lo siguiente:

[C-1-1] DEBE informar las posiciones absolutas X e Y de la pantalla 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 arriba o hacia abajo en la pantalla.
[C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto de la pantalla, lo que permite a los usuarios emular un toque en un objeto de 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 la acción de puntero hacia abajo en un punto arbitrario de la pantalla, el movimiento del puntero a cualquier otro punto arbitrario de la pantalla y, luego, la acción de puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
[C-1-6] DEBE admitir la acción de presionar el puntero y, luego, permitir que los usuarios muevan rápidamente el objeto a una posición diferente en la pantalla y, luego, levantar el puntero 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, deben cumplir con 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, deben cumplir con lo siguiente:

[C-3-1] DEBE declarar la 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 siguientes tablas. 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 lo siguiente:

[C-2-1] DEBE declarar la marca de función android.hardware.gamepad

Botón	Uso de HID²	Botón de Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pad direccional hacia arriba¹ Pad direccional hacia abajo¹	0x01 0x0039³	AXIS_HAT_Y⁴
Pad direccional izquierdo1 Pad direccional derecho¹	0x01 0x0039³	AXIS_HAT_X⁴
Botón izquierdo del hombro¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botón derecho del hombro¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic en el joystick izquierdo¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic en el joystick derecho¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Página principal¹	0x0c 0x0223	KEYCODE_HOME (3)
Atrás¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores se deben declarar dentro de una CA de Gamepad (0x01 0x0005).

3 Este uso debe tener un mínimo lógico de 0, un máximo lógico de 7, un mínimo físico de 0, un máximo físico de 315, unidades en grados y un tamaño de informe de 4. El valor lógico se define como la rotación en el sentido de las agujas del reloj desde el eje vertical. Por ejemplo, un valor lógico de 0 representa que no hay rotación y que se presionó el botón hacia arriba, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionaron las teclas hacia arriba y hacia la izquierda.

4 MotionEvent

Controles analógicos¹	Uso de HID	Botón de Android
Gatillo izquierdo	0x02 0x00C5	AXIS_LTRIGGER
Gatillo 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

1 MotionEvent

7.2.7. Control remoto

Consulta la Sección 2.3.1 para conocer los requisitos específicos de cada dispositivo.

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 la documentación de Android Open Source sobre sensores.

Implementaciones de dispositivos:

[C-0-1] DEBE informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager.
[C-0-2] DEBE devolver una lista precisa de los sensores admitidos 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 o false según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamando a los 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, deben cumplir con lo siguiente:

[C-1-1] DEBE informar todas las mediciones de los sensores con los valores pertinentes del Sistema Internacional de Unidades (métrico) para cada tipo de sensor, según 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 ms + 2 * sample_time en el caso de un flujo de sensores con una latencia máxima solicitada de 0 ms cuando el procesador de aplicaciones 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 después de que se active el sensor. Se acepta que esta muestra tenga una precisión de 0.
[C-1-4] Para cualquier API que la documentación del SDK de Android indique que es un sensor continuo, las implementaciones del dispositivo DEBEN proporcionar de forma continua muestras de datos periódicas que DEBEN tener una fluctuación inferior al 3%, donde la fluctuación se define como la desviación estándar de la diferencia de los valores de marca de tiempo informados entre eventos consecutivos.
[C-1-5] DEBE garantizar que el flujo de eventos del sensor NO impida que la CPU del dispositivo entre en un estado de suspensión o se reactive desde un estado de suspensión.
[C-1-6] DEBE registrar la hora del evento en nanosegundos, según se define en la documentación del SDK de Android, que representa la hora en que ocurrió el evento y se sincronizó con el reloj SystemClock.elapsedRealtimeNano().
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que tengan un error de sincronización de la marca de tiempo inferior a 100 milisegundos y DEBEN tener un error de sincronización de la marca de tiempo inferior a 1 milisegundo.
Cuando se activan varios sensores, el consumo de energía NO DEBE exceder la suma del consumo de energía informado de cada sensor.

La lista anterior no es exhaustiva. Se debe considerar como fuente oficial 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, deben cumplir con lo siguiente:

[C-1-6] DEBE establecer una resolución distinta de cero para todos los sensores y registrar el valor a través del método de la API de Sensor.getResolution().

Algunos tipos de sensores son compuestos, lo que significa que se pueden derivar de los 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:

DEBE implementar estos tipos de sensores cuando incluyan los sensores físicos necesarios, como se describe en tipos de sensores.

Si las implementaciones de dispositivos incluyen un sensor compuesto, deben cumplir con lo siguiente:

[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 deben cumplir con lo siguiente:

[C-3-1] Se DEBE establecer la resolución en 1 para el sensor y se debe informar el valor a través del método de la API de Sensor.getResolution().

Si las implementaciones de dispositivos incluyen un tipo de sensor en particular que admite SensorAdditionalInfo#TYPE_VEC3_CALIBRATION y el sensor se expone a desarrolladores externos, 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:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE 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 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] Se RECOMIENDA ENCARECIDAMENTE que incluyan un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE poder informar eventos con una frecuencia de al menos 50 Hz.
[C-1-2] DEBE implementar y registrar el sensor TYPE_ACCELEROMETER.
[C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android.
[C-1-4] DEBE poder medir desde la caída libre hasta cuatro veces la gravedad(4 g) o más en cualquier eje.
[C-1-5] DEBE tener una resolución de al menos 12 bits.
[C-1-6] DEBE tener una desviación estándar no superior a 0.05 m/s², donde la desviación estándar se debe calcular por eje en las muestras recopiladas durante un período de al menos 3 segundos con la frecuencia de muestreo más rápida.
Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION para [SR].
Se RECOMIENDA ENCARECIDAMENTE implementar y registrar el sensor TYPE_ACCELEROMETER_UNCALIBRATED. Se RECOMIENDA ENCARECIDAMENTE que los dispositivos Android cumplan con este requisito para que puedan actualizarse a la versión futura de la plataforma en la que este requisito podría ser OBLIGATORIO.
DEBE implementar los sensores compuestos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR y TYPE_STEP_COUNTER como se describe en el documento del SDK de Android.
DEBE informar eventos con una frecuencia de hasta 200 Hz como mínimo.
DEBE tener una resolución de al menos 16 bits.
Se DEBE calibrar mientras se usa si las características cambian durante el ciclo de vida y se compensan, y se 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 y se implementa cualquiera de los sensores compuestos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR o TYPE_STEP_COUNTER, se deben cumplir los siguientes requisitos:

[C-2-1] La suma de su consumo de energía SIEMPRE debe ser inferior a 4 mW.
Cada uno DEBE ser inferior a 2 mW y 0.5 mW cuando el dispositivo se encuentre 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, deben cumplir con lo siguiente:

[C-3-1] DEBE implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE 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, deben cumplir con lo siguiente:

[C-4-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

7.3.2. Magnetómetro

Implementaciones de dispositivos:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE incluir un magnetómetro de 3 ejes (brújula).

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar el sensor TYPE_MAGNETIC_FIELD.
[C-1-2] DEBE poder informar eventos con una frecuencia de al menos 10 Hz y DEBERÍA informar eventos con una frecuencia de al menos 50 Hz.
[C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android.
[C-1-4] DEBE poder 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 DEBERÍA tener un valor inferior a 200 µT, colocando el magnetómetro lejos de los 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 la compensación en línea de la desviación por hierro duro, y conservar los parámetros de compensación entre los reinicios del dispositivo.
[C-1-8] DEBE tener aplicada la compensación de hierro blando. La calibración se puede realizar durante el uso o durante la producción del dispositivo.
[C-1-9] DEBE tener una desviación estándar, calculada por eje en muestras recopiladas durante un período de al menos 3 segundos a la velocidad 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-SR] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un sensor acelerómetro y un sensor giroscopio de 3 ejes, deben cumplir con 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, deben cumplir con 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, deben cumplir con los siguientes requisitos:

[C-3-1] DEBE consumir menos de 10 mW.
DEBE consumir menos de 3 mW cuando el sensor se registra para el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones de dispositivos:

[C-SR] Se RECOMIENDA ENCARECIDAMENTE que incluyan un receptor de GPS/GNSS.

Si las implementaciones de dispositivos incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir resultados de ubicación a una velocidad de al menos 1 Hz cuando se solicitan a través de LocationManager#requestLocationUpdate.
[C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, interferencia por trayectos múltiples insignificante, HDOP < 2) en un plazo de 10 segundos (tiempo rápido para la primera corrección), cuando se conecta a una conexión a Internet con una velocidad de datos de 0.5 Mbps o más rápida. Por lo general, este requisito se cumple con el uso de alguna forma de técnica de GPS/GNSS asistido o predictivo para minimizar el tiempo de fijación del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y la efemérides/reloj del satélite).
- [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 realice sin una conexión de datos o después de un ciclo de energía.
En condiciones de cielo abierto, después de determinar la ubicación, ya sea que estés quieto o te muevas con una aceleración de menos de 1 metro por segundo al cuadrado:
- [C-1-3] DEBE poder determinar la ubicación con una precisión de 20 metros y la velocidad con una precisión de 0.5 metros por segundo, al menos el 95% del tiempo.
- [C-1-4] DEBE hacer 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 y al menos una de Glonass, Beidou o Galileo).
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que sigan proporcionando resultados normales de ubicación por GPS/GNSS a través de las APIs de GNSS Location Provider durante una llamada telefónica de emergencia.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE informar las mediciones del GNSS de todas las constelaciones rastreadas (como se informa en los mensajes de GnssStatus), con la excepción de SBAS.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que se informe el AGC y la frecuencia de medición del GNSS.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que se informen todas las estimaciones de precisión (incluidos el rumbo, la velocidad y la precisión vertical) como parte de cada ubicación del GPS o GNSS.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que informen las mediciones de GNSS tan pronto como se encuentren, incluso si aún no se informó una ubicación calculada a partir del GPS o GNSS.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que informen las seudoranges y las tasas de seudoranges del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras el dispositivo está estacionario o se mueve con una aceleración inferior a 0.2 m/s², son suficientes para calcular la posición con una precisión de 20 metros y la velocidad con una precisión de 0.2 m/s, al menos el 95% del tiempo.

7.3.4. Giroscopio

Implementaciones de dispositivos:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE que incluyan un sensor de giroscopio.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, deben cumplir con lo siguiente:

[C-1-1] DEBE poder informar eventos con una frecuencia de al menos 50 Hz.
[C-1-2] DEBE implementar el sensor TYPE_GYROSCOPE y se RECOMIENDA ENCARECIDAMENTE que también implemente el sensor TYPE_GYROSCOPE_UNCALIBRATED.
[C-1-4] DEBE tener una resolución de 12 bits o más y DEBERÍA tener una resolución de 16 bits o más.
[C-1-5] DEBE tener compensación de temperatura.
[C-1-6] DEBE calibrarse y compensarse mientras se usa, y conservar los parámetros de compensación entre los reinicios del dispositivo.
[C-1-7] DEBE tener una varianza no mayor que 1e-7 rad² / s² por Hz (varianza por Hz o rad² / 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 frecuencia de muestreo de 1 Hz, NO DEBERÍA ser mayor que 1e-7 rad²/s².
[SR] Se RECOMIENDA ENCARECIDAMENTE que el error de calibración sea inferior a 0.01 rad/s cuando el dispositivo está estacionario a temperatura ambiente.
DEBE informar eventos con una frecuencia de hasta 200 Hz como mínimo.

Si las implementaciones de dispositivos incluyen un giroscopio de 3 ejes, un sensor de acelerómetro y un sensor de magnetómetro, deben cumplir con lo siguiente:

[C-2-1] DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y un sensor de giroscopio de 3 ejes, deben cumplir con lo siguiente:

[C-3-1] DEBE implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barómetro

Implementaciones de dispositivos:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE que incluyan un barómetro (sensor de presión atmosférica).

Si las implementaciones de dispositivos incluyen un barómetro, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar y registrar el sensor TYPE_PRESSURE.
[C-1-2] DEBE poder entregar eventos a 5 Hz o más.
[C-1-3] DEBE tener compensación de temperatura.
[SR] SE RECOMIENDA ENCARECIDAMENTE que se puedan registrar mediciones de presión en el rango de 300 hPa a 1,100 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 ~1 m en un cambio de ~200 m a nivel del mar).

7.3.6. Termómetro

Si las implementaciones de dispositivos incluyen un termómetro ambiental (sensor de temperatura), deben cumplir con 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 (de la habitación o la cabina del vehículo) desde donde el usuario interactúa con el dispositivo en grados Celsius.

Si las implementaciones de dispositivos incluyen un sensor de termómetro que mide una temperatura diferente de la temperatura ambiente, como la temperatura de la CPU, deben cumplir con los siguientes requisitos:

[C-2-1] NO DEBE definir SENSOR_TYPE_AMBIENT_TEMPERATURE para el sensor de temperatura.

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, deben cumplir con 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 la intención principal de este tipo de sensor es detectar un teléfono que está usando el usuario. 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] DEBE tener 1 bit de precisión o más.

7.3.9. Sensores de alta fidelidad

Si las implementaciones de dispositivos incluyen un conjunto de sensores de mayor calidad, según se define en esta sección, y los ponen a disposición de las apps de terceros, deben cumplir con lo siguiente:

[C-1-1] DEBE identificar la capacidad 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, deben cumplir con 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 ENCARECIDAMENTE 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 2048 LSB/g.
- DEBE tener una frecuencia de medición mínima de 12.5 Hz o menos.
- DEBE tener una frecuencia de medición máxima de 400 Hz o más; DEBE admitir SensorDirectChannel RATE_VERY_FAST.
- DEBE tener un ruido de medición no superior a 400 μg/√Hz.
- DEBE implementar una forma de este sensor que no active el dispositivo y que tenga 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] SE RECOMIENDA ENCARECIDAMENTE que el ancho de banda de medición de 3 dB sea de, al menos, el 80% de la frecuencia de Nyquist y que el espectro de ruido blanco se encuentre 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 comparación con la temperatura de ≤ +/- 1 mg/°C.
- DEBE tener una no linealidad de la línea de mejor ajuste ≤ 0.5% y un cambio de sensibilidad en función de la temperatura ≤ 0.03%/C°.
- DEBE tener una sensibilidad entre ejes inferior al 2.5 % y una variación de la sensibilidad entre ejes 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 que TYPE_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 más; DEBE admitir SensorDirectChannel RATE_VERY_FAST.
- DEBE tener un ruido de medición no superior a 0.014°/s/√Hz.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que el ancho de banda de medición de 3 dB sea de, al menos, el 80% de la frecuencia de Nyquist y que el espectro de ruido blanco se encuentre dentro de este ancho de banda.
- DEBE tener una caminata aleatoria de la velocidad inferior a 0.001 °/s √Hz probada a temperatura ambiente.
- DEBE tener un cambio de sesgo en comparación con la temperatura de ≤ +/- 0.05 °/ s / °C.
- DEBE tener un cambio de sensibilidad en comparación con 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 ≤ 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 ℃ cuando el dispositivo está estacionario.
- DEBE tener una sensibilidad a la aceleración inferior a 0.1°/s/g.
- DEBE tener una sensibilidad entre ejes inferior al 4.0 % y una variación de sensibilidad entre ejes 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 que TYPE_GYROSCOPE.
[C-2-5] DEBE tener un sensor TYPE_GEOMAGNETIC_FIELD que cumpla con los siguientes requisitos:
- DEBE tener un rango de medición de al menos -900 y +900 μT.
- DEBE tener una resolución de medición de al menos 5 LSB/uT.
- DEBE tener una frecuencia de medición mínima de 5 Hz o menos.
- DEBE tener una frecuencia de medición máxima de 50 Hz o más.
- DEBE tener un ruido de medición no superior a 0.5 uT.
[C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GEOMAGNETIC_FIELD y, además, cumplir con lo siguiente:
- DEBE implementar una forma de este sensor que no active el dispositivo y que tenga una capacidad de almacenamiento en búfer de al menos 600 eventos del sensor.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE tener un espectro de ruido blanco de 1 Hz a, al menos, 10 Hz cuando la frecuencia de informes es de 50 Hz o más.
[C-2-7] DEBE tener un sensor TYPE_PRESSURE que cumpla con los siguientes requisitos:
- DEBE tener un rango de medición de entre 300 y 1,100 hPa, como mínimo.
- DEBE tener una resolución de medición de al menos 80 LSB/hPa.
- DEBE tener una frecuencia de medición mínima de 1 Hz o menos.
- DEBE tener una frecuencia de medición máxima de 10 Hz o más.
- DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
- DEBE implementar una forma de este sensor que no active el dispositivo y que tenga 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 de 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 de este sensor que no active el dispositivo y que tenga 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 físico que informan el acelerómetro, el giroscopio y el magnetómetro DEBE tener una diferencia de 2.5 milisegundos como máximo 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 los 0.25 milisegundos entre sí.
[C-2-14] DEBE tener marcas de tiempo de eventos del sensor de giroscopio en la misma base de tiempo que el subsistema de la cámara y con un error de 1 milisegundo.
[C-2-15] DEBE entregar muestras a las aplicaciones en un plazo de 5 milisegundos desde el momento en que los datos están disponibles en cualquiera de los sensores físicos mencionados anteriormente para la aplicación.
[C-2-16] NO DEBE tener un consumo de energía superior a 0.5 mW cuando el dispositivo está estático y 2.0 mW cuando el dispositivo está en movimiento cuando 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 de TYPE_PROXIMITY, pero, si lo tiene, DEBE tener una capacidad de búfer mínima 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, los circuitos de soporte, cualquier sistema de procesamiento de sensores dedicado, etcétera.

Si las implementaciones de dispositivos incluyen compatibilidad directa con sensores, deben cumplir con los siguientes requisitos:

[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 y getHighestDirectReportRateLevel.
[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.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
DEBE admitir el registro 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 información adicional sobre la medición de la seguridad del desbloqueo biométrico, consulta la documentación sobre la medición de la seguridad biométrica.

Si las implementaciones de dispositivos incluyen una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:

DEBE incluir un sensor biométrico

Los sensores biométricos se pueden clasificar como de clase 3 (antes sólidos), clase 2 (antes débiles) o clase 1 (antes de conveniencia) según sus tasas de aceptación de suplantación y de impostores, 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 las aplicaciones de terceros. Los sensores se clasifican como clase 1 de forma predeterminada y deben cumplir con requisitos adicionales, como se detalla a continuación, si desean clasificarse como clase 2 o clase 3. Los datos biométricos de clase 2 y clase 3 obtienen capacidades adicionales, como se detalla a continuación.

Si las implementaciones de dispositivos ponen a disposición de las aplicaciones de terceros un sensor biométrico a través de android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt y android.provider.Settings.ACTION_BIOMETRIC_ENROLL, deben cumplir con lo siguiente:

[C-4-1] DEBE cumplir con los requisitos de la biometría 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 ellos. Por el contrario, NO DEBE aceptar ni reconocer las constantes de números enteros que se pasan a los métodos canAuthenticate(int) y setAllowedAuthenticators(int) que no sean los que se documentan como constantes públicas en Authenticators y cualquier combinación de ellos.
[C-4-3] DEBE implementar la acción ACTION_BIOMETRIC_ENROLL en dispositivos que tengan datos biométricos de clase 3 o clase 2. Esta acción SOLO DEBE presentar los puntos de entrada de inscripción para los datos biométricos de clase 3 o clase 2.

Si las implementaciones de dispositivos admiten la biometría pasiva, deben cumplir con los siguientes requisitos:

[C-5-1] DEBE requerir, de forma predeterminada, un paso de confirmación adicional (p.ej., presionar un botón).
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que tengan un parámetro de configuración para permitir que los usuarios anulen la preferencia de la aplicación y siempre requieran un paso de confirmación complementario.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que la acción de confirmación esté protegida de modo que una vulneración del sistema operativo o del kernel no pueda suplantarla. 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 controlar 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ícita (sin paso de confirmación) correspondiente a setConfirmationRequired(boolean), que las aplicaciones pueden configurar para utilizar en los flujos de acceso.

Si las implementaciones de dispositivos tienen varios sensores biométricos, deben cumplir con los siguientes requisitos:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE que solo se requiera la confirmación de un dato biométrico por autenticación (p.ej., si los sensores de huella dactilar y de rostro están disponibles en el dispositivo, se debe enviar onAuthenticationSucceeded después de que se confirme cualquiera de ellos).

Para que las implementaciones de dispositivos permitan el acceso a las claves del almacén de claves a aplicaciones de terceros, deben cumplir con los siguientes requisitos:

[C-6-1] DEBE cumplir con los requisitos de la Clase 3, como se define en esta sección.
[C-6-2] DEBE presentar solo datos biométricos de clase 3 cuando la autenticación requiera BIOMETRIC_STRONG o cuando se invoque la autenticación con un CryptoObject.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como clase 1 (anteriormente conveniencia), deben hacer lo siguiente:

[C-1-1] DEBE tener una tasa de aceptación falsa inferior al 0.002%.
[C-1-2] DEBE divulgar que este modo puede ser menos seguro que una contraseña, un PIN o un patrón seguros, y enumerar claramente los riesgos de habilitarlo si las tasas de aceptación de suplantación y de impostores son superiores al 7% según lo medido por los Protocolos de prueba de biometría de Android.
[C-1-3] Se DEBEN limitar las tasas de intentos durante al menos 30 segundos después de cinco intentos fallidos de verificación biométrica, en los que un intento fallido es aquel con una calidad de captura adecuada (BIOMETRIC_ACQUIRED_GOOD) que no coincide con una biometría inscrita.
[C-1-4] DEBE impedir que se agreguen nuevos datos biométricos sin antes establecer una cadena de confianza, lo que se logra pidiéndole al usuario que confirme una credencial de dispositivo existente o que agregue una nueva (PIN, patrón o contraseña) 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] DEBE quitar por completo todos los datos biométricos identificables de un usuario cuando se quite su cuenta (incluso a través de un restablecimiento de la configuración de fábrica).
[C-1-6] DEBE respetar la marca individual para ese dato biométrico (es decir, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] DEBE solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 24 horas o menos en el caso de los dispositivos nuevos que se lancen con la versión 10 de Android, y una vez cada 72 horas o menos en el caso de los dispositivos que se actualicen desde una versión anterior de Android.
[C-1-8] DEBE solicitar al usuario la autenticación principal recomendada (p. ej., PIN, patrón o contraseña) después de una de las siguientes acciones:
- Un período de tiempo de espera de inactividad de 4 horas
- 3 intentos fallidos de autenticación biométrica
- El período de tiempo de espera por inactividad y el recuento de autenticaciones fallidas se restablecen después de cualquier confirmación exitosa de las credenciales del dispositivo.
La actualización de dispositivos desde una versión anterior de Android puede estar exenta del cumplimiento de C-1-8. * [C-SR] Se RECOMIENDA ENCARECIDAMENTE usar la lógica del framework proporcionado por el Proyecto de código abierto de Android para aplicar las restricciones especificadas en [C-1-7] y [C-1-8] para los dispositivos nuevos. * [C-SR] Se RECOMIENDA ENCARECIDAMENTE que tengan una tasa de rechazo falsa inferior al 10%, según se mide en el dispositivo. * [C-SR] Se RECOMIENDA ENCARECIDAMENTE que tengan una latencia inferior a 1 segundo, medida desde el momento en que se detecta el dato biométrico hasta que se desbloquea la pantalla, para cada dato biométrico registrado.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como Clase 2 (anteriormente Débil), deben hacer lo siguiente:

[C-2-1] DEBE cumplir con todos los requisitos de la Clase 1 mencionados anteriormente.
[C-2-2] DEBE tener una tasa de aceptación de suplantación y fraude no superior al 20%, según se mide con los Protocolos de prueba de biometría de Android.
[C-2-3] DEBE realizar la correlación 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), o en un chip con un canal seguro para el entorno de ejecución aislado.
[C-2-4] DEBE tener todos los datos identificables encriptados y autenticados de forma criptográfica para que no se puedan adquirir, leer ni alterar fuera del entorno de ejecución aislado o de un chip con un canal seguro para el entorno de ejecución aislado, como se documenta en los lineamientos de implementación del sitio del Proyecto de código abierto de Android.
[C-2-5] En el caso de la biometría basada en la cámara, mientras se realiza la autenticación o la inscripción biométrica, se deben cumplir los siguientes requisitos:
- DEBE operar la cámara en un modo que impida que los fotogramas de la cámara se lean o alteren fuera del entorno de ejecución aislado o de un chip con un canal seguro hacia el entorno de ejecución aislado.
- En el caso de las soluciones de cámara única RGB, los fotogramas de la cámara PUEDEN ser legibles fuera del entorno de ejecución aislado para admitir operaciones como la vista previa para la inscripción, pero NO DEBEN ser modificables.
[C-2-6] NO DEBE permitir que las aplicaciones de terceros distingan entre las inscripciones biométricas individuales.
[C-2-7] NO DEBE permitir el acceso sin encriptar a datos biométricos identificables ni a ningún dato derivado de ellos (como las incorporaciones) al procesador de aplicaciones fuera del contexto del TEE.
[C-2-8] DEBE tener una canalización de procesamiento segura de modo que la vulneración del sistema operativo o del kernel no permita que se inserten datos directamente para autenticarse falsamente como el usuario.

Si las implementaciones de dispositivos ya se lanzaron en una versión anterior de Android 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 las exima del requisito.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE incluir la detección de vida para todas las modalidades biométricas y la detección de atención para la biometría facial.

Si las implementaciones de dispositivos desean tratar un sensor biométrico como de clase 3 (anteriormente sólido), deben hacer lo siguiente:

[C-3-1] DEBE cumplir con todos los requisitos de la Clase 2 anterior, excepto [C-1-7] y [C-1-8]. Los dispositivos que se actualizan desde una versión anterior de Android no están exentos del requisito C-2-7.
[C-3-2] DEBE tener una implementación del almacén de claves con copia de seguridad en hardware.
[C-3-3] DEBE tener una tasa de aceptación de suplantación y fraude no superior al 7% según se mide con los Protocolos de prueba de biometría de Android.
[C-3-4] DEBE solicitar al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) una vez cada 72 horas o menos.

7.3.12. Sensor de posición

Implementaciones de dispositivos:

Es POSIBLE que admita el sensor de posición con 6 grados de libertad.

Si las implementaciones de dispositivos admiten el sensor de posición con 6 grados de libertad, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar y registrar el sensor TYPE_POSE_6DOF.
[C-1-2] DEBE ser más preciso que el vector de rotación por sí solo.

7.3.13. Sensor de ángulo de bisagra

Si las implementaciones de dispositivos admiten un sensor de ángulo de bisagra, deben cumplir con los siguientes requisitos:

[C-1-1] Se DEBE implementar y registrar TYPE_HINGLE_ANGLE.
[C-1-2] DEBE admitir al menos dos lecturas entre 0 y 360 grados (inclusive, es decir, incluidos 0 y 360 grados).
[C-1-3] DEBE devolver un sensor de activación para getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Conectividad de datos

7.4.1. Telefonía

El término "telefonía" que se usa en las APIs de Android y en este documento se refiere específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no conmutarse por paquetes, para Android se consideran independientes de cualquier conectividad de datos que se pueda implementar con la misma red. En otras palabras, la funcionalidad y las APIs de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS no se consideran dispositivos telefónicos, independientemente de si usan una red celular para la conectividad de datos.

Android SE PUEDE usar 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, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la marca de función android.hardware.telephony y otras marcas de subfunciones según la tecnología.
[C-1-2] DEBE implementar la compatibilidad total con la API para esa tecnología.

Si las implementaciones de dispositivos no incluyen hardware de telefonía, deben cumplir con lo siguiente:

[C-2-1] DEBE implementar las APIs completas como no-ops.

Si las implementaciones de dispositivos admiten eUICCs o eSIMs/SIMs integradas y tienen un mecanismo propietario para que la funcionalidad de eSIM esté disponible para los desarrolladores externos, deben cumplir con lo siguiente:

[C-3-1] DEBE proporcionar una implementación completa de EuiccManager API.

7.4.1.1. Compatibilidad con el bloqueo de números

Si las implementaciones de dispositivos informan el android.hardware.telephony feature, significa que:

[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] NO DEBE escribir en el proveedor de registros de llamadas de la plataforma para una llamada bloqueada.
[C-1-5] NO DEBE escribir en el 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 devuelve 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 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 bloqueo DEBE seguir respetándose.
DEBE migrar los números bloqueados al proveedor cuando un dispositivo se actualiza a Android 7.0.

7.4.1.2. API de Telecom

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

[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 al usuario la posibilidad de aceptar o rechazar la llamada entrante cuando el usuario esté en una llamada en curso realizada por una app de terceros que no admita la función de espera especificada a través de CAPABILITY_SUPPORT_HOLD.
[C-1-3] DEBE tener una aplicación que implemente InCallService.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE notificar al usuario que contestar una llamada entrante finalizará una llamada en curso.

La implementación del AOSP cumple con estos requisitos a través de una notificación de atención que le indica al usuario que contestar una llamada entrante provocará que se corte la otra llamada.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE precargar la app de marcador 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 de extras EXTRA_LOG_SELF_MANAGED_CALLS en su PhoneAccount como true.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE controlar los eventos KEYCODE_MEDIA_PLAY_PAUSE y KEYCODE_HEADSETHOOK de los auriculares de audio para las APIs de android.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 detecta una presión breve del evento de tecla durante una llamada entrante.
- Llama a Connection.onReject() cuando se detecte una presión prolongada del evento de tecla durante una llamada entrante.
- Activa o desactiva el estado de silencio de CallAudioState.

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, deben cumplir con lo siguiente:

[C-1-1] DEBE implementar la API de Android correspondiente.
[C-1-2] DEBE informar el parámetro de configuración de la 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) en ningún momento de la operación, incluidos los siguientes:
- Incluso cuando la pantalla no está en un estado activo.
- Para las implementaciones de dispositivos de televisión Android, incluso cuando se encuentran 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 el Network activo actualmente que se usa de forma predeterminada para el tráfico de la aplicación y que devuelven los métodos de la API de ConnectivityManager, como getActiveNetwork y registerDefaultNetworkCallback. 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 ENCARECIDAMENTE que, cuando se llame al método de la API de ConnectivityManager.reportNetworkConnectivity(), se vuelva a evaluar el acceso a Internet en el Network y, una vez que la evaluación determine que el Network 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-SR] Se RECOMIENDA ENCARECIDAMENTE 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 la STA está desconectada.
- Cada grupo de tramas de solicitud de sondeo que componen un análisis debe usar una dirección MAC coherente (NO se debe aleatorizar la dirección MAC a mitad de un análisis).
- El número de secuencia de la solicitud de sondeo debe iterar de forma normal (secuencial) entre las solicitudes de sondeo en un análisis.
- El número de secuencia de la solicitud de sondeo debe aleatorizarse entre la última solicitud de sondeo de un análisis y la primera solicitud de sondeo del siguiente análisis.
[C-SR] SE RECOMIENDAN ENORMEMENTE, mientras la STA está desconectada, para permitir solo los siguientes elementos en los tramas de solicitud de sondeo:
- Conjunto de parámetros del SSID (0)
- Conjunto de parámetros de DS (3)

Si las implementaciones de dispositivos incluyen compatibilidad con el modo de ahorro de energía de Wi-Fi, según se define en el estándar IEEE 802.11, deben cumplir con lo siguiente:

[C-3-1] DEBE desactivar el modo de ahorro de energía de Wi-Fi siempre que una app adquiera un bloqueo de WIFI_MODE_FULL_HIGH_PERF o WIFI_MODE_FULL_LOW_LATENCY a través de las APIs de WifiManager.createWifiLock() y WifiManager.WifiLock.acquire(), y el bloqueo esté activo.
[C-3-2] La latencia promedio de ida y vuelta entre el dispositivo y un punto de acceso mientras el dispositivo está en modo de bloqueo de baja latencia de Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) DEBE ser menor que la latencia durante un modo de bloqueo de alto rendimiento de Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] SE RECOMIENDAN ENCARECIDAMENTE para minimizar la latencia de ida y vuelta de Wi-Fi cada vez que se adquiere y entra en vigencia un bloqueo de baja latencia (WIFI_MODE_FULL_LOW_LATENCY).

Si las implementaciones de dispositivos admiten Wi-Fi y lo usan para la búsqueda de ubicación, deben cumplir con lo siguiente:

[C-2-1] DEBE proporcionar una opción para el usuario que permita habilitar o inhabilitar la lectura del valor 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, deben cumplir con lo siguiente:

[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 de Wi-Fi y Wi-Fi Direct de forma simultánea.

7.4.2.2. Configuración de Wi-Fi Tunneled Direct Link

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, se cumplen las siguientes condiciones:

[C-1-1] Se 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 podría ser peor que el de 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, deben cumplir con los siguientes requisitos:

[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 no superiores a 30 minutos y siempre que se habilite Wi-Fi Aware, a menos que haya una operación de rango de Aware en curso o una ruta de datos de Aware activa (no se espera aleatorización mientras la ruta de datos esté activa).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y Ubicación Wi-Fi, como se describe en la Sección 7.4.2.5, y exponen estas funcionalidades a apps de terceros, entonces:

[C-2-1] DEBE implementar las APIs de descubrimiento que tienen en cuenta 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), deben cumplir con lo siguiente:

DEBE incluir compatibilidad con Wi-Fi Passpoint.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Passpoint, deben cumplir con los siguientes requisitos:

[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 en relación con la detección y selección de redes, como el servicio de publicidad genérico (GAS) y el protocolo de consulta de redes de acceso (ANQP).

Por el contrario, si las implementaciones de dispositivos no incluyen compatibilidad con Wi-Fi Passpoint, ocurrirá lo siguiente:

[C-2-1] La implementación de las APIs de WifiManager relacionadas con Passpoint DEBE arrojar un UnsupportedOperationException.

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, deben cumplir con los siguientes requisitos:

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

7.4.2.6. Aligeramiento de Keepalive de Wi-Fi

Implementaciones de dispositivos:

DEBE incluir compatibilidad con la descarga de Wi-Fi keepalive.

Si las implementaciones de dispositivos incluyen compatibilidad con la descarga de Wi-Fi keepalive y exponen la funcionalidad a apps de terceros, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir la API de SocketKeepAlive.
[C-1-2] DEBE admitir al menos tres intervalos de conexión simultáneos a través de Wi-Fi y al menos un intervalo de conexión a través de la red celular.

Si las implementaciones de dispositivos no incluyen compatibilidad con la descarga de Wi-Fi Keep-Alive, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE devolver ERROR_UNSUPPORTED.

7.4.2.7. Easy Connect para Wi-Fi (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, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE hacer que el método WifiManager#isEasyConnectSupported() devuelva true.

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth, deben cumplir con 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, deben cumplir con 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, deben hacer 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, deben cumplir con lo siguiente:

[C-2-1] DEBE declarar las funciones de la plataforma pertinentes (android.hardware.bluetooth y android.hardware.bluetooth_le, respectivamente) y, luego, implementar las APIs de la plataforma.
DEBE implementar 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), deben cumplir con lo siguiente:

[C-3-1] DEBE declarar la función de hardware android.hardware.bluetooth_le.
[C-3-2] DEBE habilitar las APIs de Bluetooth basadas en GATT (perfil de atributo genérico) como se describe en la documentación del SDK y 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 dirección privada resoluble (RPA) que no supere los 15 minutos y rotar la dirección en el tiempo de espera para proteger la privacidad del usuario cuando el dispositivo usa BLE de forma activa para la búsqueda o la publicidad. Para evitar ataques de sincronización, los intervalos de tiempo de espera TAMBIÉN DEBEN aleatorizarse entre 5 y 15 minutos.
DEBE admitir la descarga de la lógica de filtrado en el chipset de Bluetooth cuando se implementa la API de ScanFilter.
DEBE admitir la descarga del análisis por lotes en el chipset Bluetooth.
DEBE admitir varios anuncios con al menos 4 espacios.

Si las implementaciones de dispositivos admiten Bluetooth LE y lo usan para la búsqueda de ubicación, deben cumplir con lo siguiente:

[C-4-1] DEBE proporcionar una ayuda para el usuario que permita habilitar o inhabilitar la lectura de valores a través de la API del sistema 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, deben cumplir con lo siguiente:

[C-5-1] DEBE devolver true para BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Comunicaciones de campo cercano

Implementaciones de dispositivos:

DEBE incluir un transceptor y hardware relacionado para la comunicación de campo cercano (NFC).
[C-0-1] DEBE implementar las APIs de android.nfc.NdefMessage y android.nfc.NdefRecord, incluso si no incluyen compatibilidad con NFC o no declaran la función android.hardware.nfc, ya que las clases representan un formato de representación de datos independiente del protocolo.

Si las implementaciones de dispositivos incluyen hardware NFC y planean ponerlo a disposición de apps de terceros, deben hacer lo siguiente:

[C-1-1] DEBE informar la función android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature().
DEBE poder leer y escribir mensajes NDEF a través de los siguientes estándares de NFC:
[C-1-2] DEBE poder actuar como lector o 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 1, 2, 3, 4 y 5 del NFC Forum (definidos por el NFC Forum)
[SR] SE RECOMIENDA ENCARECIDAMENTE que 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, si bien los estándares de NFC se indican como ALTAMENTE RECOMENDADOS, se prevé que la Definición de compatibilidad para una versión futura los cambie 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 ejecuten esta versión de Android cumplan con estos requisitos ahora para que puedan actualizarse a las versiones futuras de la plataforma.
[C-1-13] DEBE sondear todas las tecnologías admitidas mientras está en el modo de detección de NFC.
DEBE estar en modo de detección de NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.
DEBE poder leer el código de barras y la URL (si están codificados) de los productos Thinfilm NFC Barcode.

Ten en cuenta que los vínculos disponibles públicamente no están disponibles para las especificaciones de JIS, ISO y NFC Forum citadas 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 del ID de aplicación (AID), deben cumplir con lo siguiente:

[C-2-1] DEBE informar la constante de función android.hardware.nfc.hce.
[C-2-2] DEBE admitir las APIs de HCE de NFC según se definen 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, deben cumplir con los siguientes requisitos:

[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 según se definen 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/grabador, deben cumplir con lo siguiente:

[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 desde el método android.content.pm.PackageManager.hasSystemFeature(). Ten en cuenta que esta no es una función estándar de Android y, como tal, no aparece como una constante en la clase android.content.pm.PackageManager.

7.4.5. APIs y protocolos 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 los 200 Kbit/s o más. Entre los ejemplos de tecnologías que satisfacen este requisito, se incluyen 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 redes físicas (como Ethernet) sea 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 y java.net.URLConnection, así como las APIs nativas, como los sockets AF_INET6.
[C-0-3] DEBE habilitar IPv6 de forma predeterminada.
DEBE garantizar que la comunicación IPv6 sea tan confiable como la IPv4, por ejemplo:
- [C-0-4] DEBE mantener la conectividad IPv6 en el modo de suspensión.
- [C-0-5] La limitación de velocidad NO DEBE provocar que el dispositivo pierda la conectividad IPv6 en ninguna red compatible con IPv6 que use tiempos de vida de RA de al menos 180 segundos.
[C-0-6] DEBE proporcionar a las aplicaciones de terceros conectividad IPv6 directa a la red cuando se conectan a una red IPv6, sin que se produzca ninguna forma de traducción de direcciones o puertos de forma local en el dispositivo. Tanto las APIs administradas, como Socket#getLocalAddress o Socket#getLocalPort, como las APIs del NDK, como getsockname() o IPV6_PKTINFO, DEBEN devolver la dirección IP y el puerto que se usan realmente para enviar y recibir paquetes en la red, y que son visibles como la IP y el puerto de origen para los servidores de Internet (web).

El nivel requerido de compatibilidad con IPv6 depende del tipo de red, como se muestra en los siguientes requisitos.

Si las implementaciones de dispositivos admiten Wi-Fi, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE admitir el funcionamiento de pila doble y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos admiten Ethernet, deben cumplir con los siguientes requisitos:

[C-2-1] DEBE admitir el funcionamiento de pila doble y solo IPv6 en Ethernet.

Si las implementaciones de dispositivos admiten datos celulares, deben cumplir con lo siguiente:

[C-3-1] DEBE admitir el funcionamiento de IPv6 (solo IPv6 y, posiblemente, doble pila) en redes celulares.

Si las implementaciones de dispositivos admiten más de un tipo de red (p.ej., Wi-Fi y datos móviles), se realizan las siguientes acciones:

[C-4-1] DEBE cumplir simultáneamente con los requisitos anteriores en cada red cuando el dispositivo está conectado simultáneamente a más de un tipo de red.

7.4.5.3. Portales cautivos

Un portal cautivo 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, enviando ese intent, en la llamada a la API del sistema ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] DEBE realizar la detección de portales cautivos y admitir el acceso a través de la aplicación de portal cautivo cuando el dispositivo esté conectado a cualquier tipo de red, incluidas las redes celulares o móviles, Wi-Fi, Ethernet o Bluetooth.
[C-1-3] DEBE admitir el acceso a portales cautivos con DNS de texto no cifrado cuando el dispositivo esté configurado para usar el modo estricto de DNS privado.
[C-1-4] DEBE usar DNS encriptado según la documentación del SDK para android.net.LinkProperties.getPrivateDnsServerName y android.net.LinkProperties.isPrivateDnsActive para todo el tráfico de red que no se comunique 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 devuelven ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback y la 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 principal 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 medida, se aplican las siguientes condiciones:

[SR] SE RECOMIENDA ENCARECIDAMENTE proporcionar el modo de ahorro de datos.

Si las implementaciones de dispositivos proporcionan el modo de ahorro de datos, deben cumplir con 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, deben hacer lo siguiente:

[C-2-1] DEBE devolver el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] NO DEBE emitir 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, deben cumplir con lo siguiente:

[C-1-1] Se DEBEN enumerar los lectores de elementos seguros disponibles a través de la API de android.se.omapi.SEService.getReaders().
[C-1-2] DEBE declarar los parámetros de configuración correctos a través de android.hardware.se.omapi.uicc para el dispositivo con elementos seguros basados en UICC, android.hardware.se.omapi.ese para el dispositivo con elementos seguros basados en eSE y android.hardware.se.omapi.sd para el dispositivo con elementos seguros basados en SD.

7.5. Cámaras

Si las implementaciones de dispositivos incluyen al menos una cámara, deben cumplir con 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 de forma simultánea 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 del dispositivo, mientras la cámara está abierta para la vista previa básica y la captura de fotos.
[C-1-3] DEBE garantizar que la aplicación de cámara predeterminada preinstalada que controla los intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE o MediaStore.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 tenga ACCESS_FINE_LOCATION.

7.5.1. Cámara posterior

Una cámara trasera es una cámara ubicada en el lado del dispositivo opuesto a la pantalla, es decir, capta imágenes de escenas en el lado lejano del dispositivo, como una cámara tradicional.

Implementaciones de dispositivos:

DEBE incluir una cámara posterior.

Si las implementaciones de dispositivos incluyen al menos una cámara trasera, deben cumplir con lo siguiente:

[C-1-1] DEBE informar los parámetros de configuración android.hardware.camera y android.hardware.camera.any.
[C-1-2] DEBE tener una resolución de al menos 2 megapíxeles.
DEBE tener enfoque automático por hardware o por software implementado en el controlador de la cámara (transparente para el software de la aplicación).
PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida).
PUEDE incluir un flash.

Si la cámara incluye un flash, haz lo siguiente:

[C-2-1] La lámpara del flash NO DEBE encenderse mientras se haya registrado 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 explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de un objeto Camera.Parameters. Ten en cuenta que esta restricción no se aplica a la aplicación de cámara integrada en el sistema del dispositivo, sino solo a las aplicaciones de terceros que usan Camera.PreviewCallback.

7.5.2. Cámara frontal

Una cámara frontal es una cámara ubicada en el mismo lado del dispositivo que la pantalla, es decir, una cámara que se usa normalmente para tomar imágenes del usuario, como para videoconferencias y aplicaciones similares.

Implementaciones de dispositivos:

PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, deben cumplir con lo siguiente:

[C-1-1] DEBE informar los parámetros de configuración android.hardware.camera.any y android.hardware.camera.front.
[C-1-2] DEBE tener una resolución de, al menos, VGA (640 x 480 píxeles).
[C-1-3] NO DEBE usar una cámara frontal como la predeterminada para 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 especificada por la aplicación cuando la aplicación actual haya solicitado explícitamente que se rote la pantalla de la cámara a través de 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 solicita de forma explícita que se rote la pantalla de la cámara a través de una llamada al método android.hardware.Camera.setDisplayOrientation().
[C-1-5] NO DEBE reflejar la imagen estática final capturada ni los flujos de video que se devuelven a las devoluciones de llamada de la aplicación o que se confirman en el almacenamiento de medios.
[C-1-6] DEBE reflejar la imagen que muestra la vista previa de la publicación de la misma manera que el flujo de imágenes de la vista previa de la cámara.
PUEDE incluir funciones (como enfoque automático, flash, etcétera) disponibles para las cámaras posteriores, según se describe en el artículo 7.5.1.

Si las implementaciones de dispositivos pueden rotarse por el usuario (por ejemplo, automáticamente a través de un acelerómetro o manualmente 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

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 y android.hardware camera.any.
[C-1-2] DEBE admitir la clase de video USB (UVC 1.0 o posterior) 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ísica 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).
MAY admite varias cámaras.
Es POSIBLE que admita la 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 (resolución QVGA o superior).

7.5.4. Comportamiento de la API de Camera

Android incluye dos paquetes de APIs para acceder a la cámara. La API de android.hardware.camera2 más reciente expone el control de la cámara de nivel inferior a la app, incluidos los flujos eficientes de ráfaga o transmisión sin copia y los controles por fotograma de exposición, ganancia, ganancias de balance de blancos, conversión de color, reducción de ruido, nitidez y mucho más.

El paquete de API anterior,android.hardware.Camera, se marcó como en desuso en Android 5.0, pero debería seguir disponible para que las apps lo usen. Las implementaciones de dispositivos Android DEBEN garantizar la compatibilidad continua con 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 que dejó de estar disponible y el paquete android.hardware.camera2 más reciente DEBEN tener un rendimiento y una calidad equivalentes en ambas APIs. Por ejemplo, con la misma configuración, 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. No es necesario que las funciones que dependen de las diferentes semánticas de las dos APIs tengan la misma velocidad o calidad, pero DEBEN coincidir lo más posible.

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara, en 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ó a android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] DEBE estar en formato de codificación NV21 cuando una aplicación registra una instancia de android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame(), y el formato de vista previa es YCbCr_420_SP, los datos en el byte[] que se pasa a onPreviewFrame(). Es decir, NV21 DEBE ser el valor predeterminado.
[C-0-3] DEBE admitir el formato YV12 (como lo indica la constante android.graphics.ImageFormat.YV12) para las vistas previas de la cámara frontal y posterior para android.hardware.Camera. (El codificador de video y la cámara de hardware pueden usar cualquier formato de píxel nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
[C-0-4] DEBE admitir los formatos android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como salidas a través de la API de android.media.ImageReader para los dispositivos android.hardware.camera2 que anuncian la capacidad de REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities.
[C-0-5] DEBE implementar la API de Camera completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático por hardware o cualquier otra capacidad. Por ejemplo, las cámaras que no tienen enfoque automático DEBEN llamar a las instancias de android.hardware.Camera.AutoFocusCallback registradas (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 deben “simularse” como se describe.
[C-0-6] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters y la clase android.hardware.camera2.CaptureRequest. Por el contrario, las implementaciones de dispositivos NO DEBEN reconocer ni respetar las constantes de cadena que se pasan al método android.hardware.Camera.setParameters(), excepto las que se documentan como constantes en android.hardware.Camera.Parameters. Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de Camera estándar si el hardware lo permite y NO DEBEN admitir tipos de parámetros de Camera 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ámetro de cámara Camera.SCENE_MODE_HDR.
[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 los marcas de funciones del framework correspondientes.
[C-0-8] TAMBIÉN DEBE declarar las capacidades individuales de la cámara de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar los parámetros de configuración de funciones adecuados. DEBE definir el parámetro de configuración de funciones si alguno de los dispositivos de cámara adjuntos admite la función.
[C-0-9] DEBE transmitir la intención Camera.ACTION_NEW_PICTURE cada vez que la cámara tome una foto nueva y se agregue la entrada de la foto al almacén de medios.
[C-0-10] DEBE transmitir la intención Camera.ACTION_NEW_VIDEO cada vez que la cámara grabe un video nuevo y se agregue la entrada de la imagen al almacén de medios.
[C-0-11] DEBE tener todas las cámaras accesibles a través de la API android.hardware.Camera obsoleta también accesibles a través de la API android.hardware.camera2.
[C-0-12] DEBE garantizar que la apariencia facial NO se altere, 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 o android.hardware.Camera.
[C-SR] En el caso de los dispositivos con varias cámaras RGB que apuntan en la misma dirección, se RECOMIENDA ENCARECIDAMENTE que admitan un dispositivo de cámara lógico que incluya la capacidad CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, que consta de todas las cámaras RGB que apuntan en esa dirección como subdispositivos físicos.

Si las implementaciones de dispositivos proporcionan una API de cámara propietaria a apps de terceros, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE implementar esa API de cámara 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 cámaras deben cumplir con los siguientes requisitos:

[C-1-1] DEBE orientarse de modo que la dimensión larga de la cámara se alinee con la dimensión larga de la pantalla. Es decir, cuando el dispositivo se sostiene en orientación horizontal, las cámaras DEBEN capturar imágenes en orientación horizontal. Esto se aplica independientemente de la orientación natural del dispositivo, es decir, se aplica tanto a los dispositivos con orientación horizontal principal como a los dispositivos con orientación vertical principal.

7.6. Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Implementaciones de dispositivos:

[C-0-1] DEBE incluir un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos y DEBEN poder 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, también conocido como “almacenamiento externo compartido”, “almacenamiento compartido de aplicaciones” o por la ruta de Linux “/sdcard” en la que se monta.
[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., ranura para tarjeta Secure Digital).
[C-0-3] DEBE montar el almacenamiento compartido de la aplicación directamente en la ruta de Linux sdcard o incluir un vínculo simbólico de Linux desde sdcard hasta el punto de montaje real.
[C-0-4] Se DEBE habilitar el almacenamiento específico de forma predeterminada para todas las apps que se segmenten para el nivel de API 29 o versiones posteriores, excepto en la siguiente situación:
- Cuando la app solicitó android:requestLegacyExternalStorage="true" en su manifiesto
[C-0-5] Se 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 permiso ACCESS_MEDIA_LOCATION.

Las implementaciones de dispositivos PUEDEN cumplir con los requisitos anteriores de cualquiera de las siguientes maneras:

Almacenamiento extraíble al que puede acceder el usuario, como una ranura para tarjetas Secure Digital (SD).
Una parte del almacenamiento interno (no extraíble) tal como se implementa en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones 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 que advierta al usuario cuando no haya ningún 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 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, deben hacer lo siguiente:

DEBE usar la implementación del AOSP del almacenamiento compartido interno de la aplicación.
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, deben cumplir con 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 análisis de medios de Android y android.provider.MediaStore.
PUEDE usar el almacenamiento masivo USB, pero DEBE usar el protocolo de transferencia de medios para satisfacer este requisito.

Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y admiten el Protocolo de transferencia de medios, deben cumplir con lo siguiente:

DEBE ser compatible con el host de referencia de MTP de Android, 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 del dispositivo son las siguientes:

[SR] SE RECOMIENDA ENCARECIDAMENTE implementar el almacenamiento adaptable en una ubicación estable a largo plazo, ya que desconectarlo accidentalmente puede causar 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 de otra cubierta protectora, las implementaciones del dispositivo son las siguientes:

[SR] SE RECOMIENDA ENCARECIDAMENTE implementar el almacenamiento adoptable.

7.7. USB

Si las implementaciones de dispositivos tienen un puerto USB, deben cumplir con lo siguiente:

DEBE admitir el modo periférico USB y DEBE admitir el modo host USB.

7.7.1. Modo de 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 estándar de tipo A o tipo C.
[C-1-2] DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo estándar de USB a través de android.os.Build.SERIAL.
[C-1-3] DEBE detectar cargadores de 1.5 A y 3.0 A según el estándar de resistencia de Type-C y DEBE detectar cambios en el anuncio si admiten USB Type-C.
[SR] El puerto DEBE usar un factor de forma USB micro-B, micro-AB o tipo C. SE RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
[SR] El puerto DEBE ubicarse en la parte inferior del dispositivo (según la orientación natural) o habilitar la rotación de pantalla por software para todas las apps (incluida la pantalla principal), de modo que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. SE RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
[SR] DEBE implementar la compatibilidad para extraer una corriente de 1.5 A durante el chirp de alta velocidad y el tráfico, como se especifica en la especificación de carga de batería por USB, revisión 1.2. SE RECOMIENDA ENCARECIDAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
[SR] SE RECOMIENDA ENCARECIDAMENTE no admitir métodos de carga propietarios que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o que alteren los roles de fuente o receptor, ya que esto puede generar problemas de interoperabilidad con los cargadores o dispositivos que admiten los métodos estándar de USB Power Delivery. Si bien se indica como "ALTAMENTE RECOMENDADO", en futuras versiones de Android, es posible que EXIJAMOS que todos los dispositivos tipo C admitan la interoperabilidad completa con los cargadores estándar tipo C.
[SR] SE RECOMIENDA ENCARECIDAMENTE admitir Power Delivery para el intercambio de roles de datos y alimentación cuando admitan USB Type-C y el modo de host USB.
DEBE admitir Power Delivery para la carga de alto voltaje y los 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 cumplen con la especificación de AOA, deben hacer 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 USB DEBE incluir la cadena "android" al final de la cadena iInterface de descripción de la interfaz del almacenamiento masivo USB.

7.7.2. Modo de host USB

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de host, deben cumplir con lo siguiente:

[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] DEBE implementar compatibilidad para conectar periféricos USB estándar, es decir, DEBE hacer una de las siguientes acciones:
- Tener un puerto tipo C en el dispositivo o incluir cables que adapten un puerto propietario del dispositivo a un puerto USB estándar tipo C (dispositivo USB Type-C)
- Tener un puerto tipo A en el dispositivo o incluir cables que adapten un puerto propietario del dispositivo a un puerto USB estándar tipo A
- Tener un puerto micro-AB en el dispositivo, que DEBE incluir un cable adaptador a un puerto estándar de tipo A
[C-1-3] NO DEBE incluir un adaptador que convierta puertos USB tipo A o micro-AB en un puerto tipo C (receptáculo).
[C-SR] SE RECOMIENDA ENCARECIDAMENTE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
DEBE admitir la carga del dispositivo periférico USB conectado mientras está en modo de host, anunciando una corriente de fuente de al menos 1.5 A, como se especifica en la sección Termination Parameters de la USB Type-C Cable and Connector Specification Revision 1.2 para los conectores USB Type-C, o bien usando el rango de corriente de salida del puerto de carga descendente(CDP) como se especifica en las especificaciones de carga de batería USB, revisión 1.2 para los conectores Micro-AB.
DEBE implementar y admitir los estándares de USB Type-C.

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de host y la clase de audio USB, deben cumplir con lo siguiente:

[C-2-1] DEBE admitir la clase HID de USB.
[C-2-2] DEBE admitir la detección y la asignación de los siguientes campos de datos de HID especificados en las Tablas de uso de HID de USB y la Solicitud de uso de comandos por voz a las constantes de KeyEvent como se indica a continuación:
- Página de uso (0xC), ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Página de uso (0xC), ID de uso (0x0E9): KEYCODE_VOLUME_UP
- Página de uso (0xC), ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
- Página de uso (0xC), ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de host y el framework de acceso al almacenamiento (SAF), deben cumplir con lo siguiente:

[C-3-1] DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia multimedia) conectado de forma remota y hacer que su contenido sea accesible a través de los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT. .

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo de host y USB Type-C, deben cumplir con lo siguiente:

[C-4-1] DEBE implementar la funcionalidad de puerto de doble función según se define en la especificación de USB Type-C (sección 4.5.1.3.3).
[SR] SE RECOMIENDA ENCARECIDAMENTE que admitan DisplayPort, DEBEN admitir velocidades de datos USB SuperSpeed y SE RECOMIENDA ENCARECIDAMENTE que admitan Power Delivery para el intercambio de roles de datos y energía.
[SR] SE RECOMIENDA ENCARECIDAMENTE NO admitir el modo de accesorio del adaptador de audio, como se describe en el Apéndice A de la Especificación de cable y conector USB Type-C, revisión 1.2.
DEBE implementar el modelo Try.* que sea más adecuado 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 lo siguiente:

[C-1-1] DEBE informar la constante de función android.hardware.microphone.
[C-1-2] DEBE cumplir con los requisitos de grabación de audio que se indican en la sección 5.4.
[C-1-3] DEBE cumplir con los requisitos de latencia de audio que se indican en la sección 5.6.
[SR] Se RECOMIENDA ENCARECIDAMENTE que admitan la grabación de cerca del ultrasonido, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos omiten un micrófono, deben cumplir con 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 un altavoz o un puerto de salida de audio o multimedia para un periférico de salida de audio, como un conector de audio de 3.5 mm de 4 conductores o un puerto en modo de host USB que use la clase de audio USB, deben cumplir con lo siguiente:

[C-1-1] DEBE informar la constante de función android.hardware.audio.output.
[C-1-2] DEBE cumplir con los requisitos de reproducción de audio de la sección 5.5.
[C-1-3] DEBE cumplir con los requisitos de latencia de audio que se indican en la sección 5.6.
[SR] SE RECOMIENDA ENCARECIDAMENTE admitir la reproducción de sonido casi ultrasónico, 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, deben cumplir con lo siguiente:

[C-2-1] NO DEBE informar la función android.hardware.audio.output.
[C-2-2] DEBE implementar las APIs relacionadas con la salida de audio como no-ops, al menos.

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 en 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 redes celulares, no se considera como la inclusión de un "puerto de salida".

7.8.2.1. Puertos de audio analógicos

Para que sean compatibles con los auriculares y otros accesorios de audio que usan el conector de audio de 3.5 mm en todo el ecosistema de Android, si las implementaciones de dispositivos incluyen uno o más puertos de audio analógicos, deben cumplir con lo siguiente:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE que se incluya al menos uno de los puertos de audio como un conector de audio de 3.5 mm con 4 conductores.

Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm con 4 conductores, deben cumplir con lo siguiente:

[C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono.
[C-1-2] DEBE admitir conectores de audio TRRS con el orden de pines de CTIA.
[C-1-3] DEBE admitir la detección y la asignación a los códigos de teclas de los siguientes 3 rangos de impedancia equivalente entre los conductores del micrófono y de tierra en el conector de audio:
- 70 ohmios o menos: KEYCODE_HEADSETHOOK
- 210 a 290 ohm: KEYCODE_VOLUME_UP
- 360 a 680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] DEBE activar ACTION_HEADSET_PLUG cuando se inserta un conector, pero solo después de que todos los contactos del conector toquen sus segmentos correspondientes en el conector hembra.
[C-1-5] DEBE poder 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 el código de tecla para el siguiente rango de impedancia equivalente entre los conductores del micrófono y de tierra en el conector de audio:
- 110 a 180 ohm: KEYCODE_VOICE_ASSIST
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que admitan conectores de audio con el orden de pines OMTP.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE admitir la grabación de audio desde auriculares estéreo con micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm con 4 conductores y admiten un micrófono, y transmiten el android.intent.action.HEADSET_PLUG con el micrófono de valor adicional establecido en 1, cumplen con las siguientes condiciones:

[C-2-1] DEBE admitir la detección del micrófono en el accesorio de audio conectado.

7.8.2.2. Puertos de audio digital

Para ser compatible con los auriculares y otros accesorios de audio que usan conectores USB-C y que implementan (clase de audio USB) en todo el ecosistema de Android, según se define en la especificación de auriculares USB de Android

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

7.8.3. Cercano al ultrasonido

El audio casi ultrasónico se encuentra en la banda de 18.5 a 20 kHz.

Implementaciones de dispositivos:

DEBE informar correctamente la compatibilidad con la capacidad de audio casi ultrasónico a través de la API de AudioManager.getProperty de la siguiente manera:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es "true", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED DEBEN cumplir con los siguientes requisitos:

[C-1-1] La respuesta de potencia media del micrófono en la banda de 18.5 kHz a 20 kHz NO DEBE ser más de 15 dB inferior a la respuesta a 2 kHz.
[C-1-2] La relación señal-ruido no ponderada del micrófono en el rango 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 "true", haz lo siguiente:

[C-2-1] La respuesta media del altavoz en el rango de 18.5 kHz a 20 kHz NO DEBE ser inferior a 40 dB por debajo de la respuesta a 2 kHz.

7.8.4. Integridad de la señal

Implementaciones de dispositivos: * DEBEN proporcionar una ruta de señal de audio sin fallas para los flujos de entrada y salida en dispositivos portátiles, según se define con cero fallas medidas durante una prueba de un minuto por ruta. Realiza pruebas con la “Prueba de fallas automatizada” de [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

La prueba requiere un adaptador de bucle de audio, que se usa directamente en un conector de 3.5 mm o en combinación con un adaptador de USB-C a 3.5 mm. Se DEBEN probar todos los puertos de salida de audio.

Actualmente, OboeTester admite rutas de AAudio, por lo que 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 una onda sinusoidal de 2,000 Hz.

Transductor	THD	SNR
Altavoz integrado principal, medido con un micrófono de referencia externo	< 3.0%	>= 50 dB
Micrófono integrado principal, medido con un altavoz de referencia externo	< 3.0%	>= 50 dB
Conectores analógicos integrados de 3.5 mm, probados con un adaptador de bucle	< 1%	>= 60 dB
Adaptadores USB incluidos con el teléfono, probados con el adaptador de bucle	< 1.0%	>= 60 dB

7.9. Realidad virtual

Android incluye APIs y herramientas para crear 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 VR, una función que controla la renderización estereoscópica de las notificaciones y que inhabilita los componentes de la IU del sistema monoculares mientras una aplicación de VR tiene el enfoque del usuario.

7.9.2. Modo de realidad virtual: Alto rendimiento

Si las implementaciones de dispositivos admiten el modo de RV, deben cumplir con los siguientes requisitos:

[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] Se RECOMIENDA ENCARECIDAMENTE admitir 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] DEBE implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace y exponer las extensiones en la lista de extensiones de EGL disponibles.
[C-1-8] DEBE implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures y exponer las extensiones en la lista de extensiones de GL disponibles.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array y GL_OVR_multiview_multisampled_render_to_texture, y exponer las extensiones en la lista de extensiones de GL disponibles.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que admitan Vulkan 1.1.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing y VK_KHR_shared_presentable_image, y exponerlo en la lista de extensiones de Vulkan disponibles.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE exponer al menos una familia de filas de Vulkan en la que flags contenga VK_QUEUE_GRAPHICS_BIT y VK_QUEUE_COMPUTE_BIT, y queueCount sea al menos 2.
[C-1-7] La GPU y la pantalla DEBEN poder sincronizar el acceso al búfer frontal compartido de modo que la renderización de ojos alternados del contenido de RV a 60 FPS con dos contextos de renderización se muestre sin artefactos de desgarro visibles.
[C-1-9] DEBE implementar la compatibilidad con los parámetros AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, como se describe en el NDK.
[C-1-10] DEBE implementar la compatibilidad con AHardwareBuffers con cualquier combinación de las marcas de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para, al menos, los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM y AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR] SE RECOMIENDAN ENORMEMENTE para admitir la asignación de AHardwareBuffers con más de una capa y marcas y formatos especificados en C-1-10.
[C-1-11] DEBE admitir la decodificación H.264 de al menos 3840 x 2160 a 30 fps, comprimida a un promedio de 40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps y 10 Mbps o 2 instancias de 1920 x 1080 a 60 fps y 20 Mbps).
[C-1-12] DEBE admitir HEVC y VP9, DEBE poder decodificar al menos 1,920 x 1,080 a 30 FPS comprimido a un promedio de 10 Mbps y DEBE poder decodificar 3,840 x 2,160 a 30 FPS y 20 Mbps (equivalente a 4 instancias de 1,920 x 1,080 a 30 FPS y 5 Mbps).
[C-1-13] DEBE admitir la API de HardwarePropertiesManager.getDeviceTemperatures y devolver valores precisos para la temperatura cutánea.
[C-1-14] DEBE tener una pantalla integrada, y su resolución DEBE ser de al menos 1920 x 1080.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE que tengan una resolución de pantalla de, al menos, 2560 x 1440.
[C-1-15] La pantalla DEBE actualizarse a una frecuencia de al menos 60 Hz mientras está en el modo de VR.
[C-1-17] La pantalla DEBE admitir un modo de baja persistencia con una persistencia ≤ 5 milisegundos, donde la persistencia se define como la cantidad de tiempo durante la cual un píxel emite luz.
[C-1-18] DEBE admitir 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] SE RECOMIENDA ENCARECIDAMENTE que admitan 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] SE RECOMIENDA ENCARECIDAMENTE que admitan la función android.hardware.sensor.hifi_sensors.
[C-1-22] DEBE tener una latencia de movimiento a fotón de extremo a extremo no superior a 28 milisegundos.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que la latencia de movimiento a fotón de extremo a extremo 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] Se RECOMIENDA ENCARECIDAMENTE que tengan una proporció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 devolver la cantidad de núcleos de CPU que son exclusivos para la aplicación en primer plano superior.

Si se admite el uso exclusivo del núcleo, este debe cumplir con los siguientes requisitos:

[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

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

7.11. Clase de rendimiento de medios

La clase de rendimiento del contenido multimedia de la implementación del dispositivo se puede obtener de la API de android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Los requisitos de la clase de rendimiento del contenido multimedia se definen para cada versión de Android a partir de R (versión 30). El valor especial 0 designa que el dispositivo no pertenece a una clase de rendimiento de contenido multimedia.

Si las implementaciones del dispositivo devuelven un valor distinto de cero para android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, deben hacer lo siguiente:

[C-1-1] DEBE devolver al menos un valor de android.os.Build.VERSION_CODES.R.
[C-1-2] DEBE ser una implementación de dispositivo portátil.
[C-1-3] DEBE cumplir con todos los requisitos de la "Clase de rendimiento del contenido multimedia" que se describen en la sección 2.2.7.

Consulta la sección 2.2.7 para conocer los requisitos específicos de los dispositivos.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y potencia son fundamentales para la experiencia del usuario y afectan las suposiciones básicas que los desarrolladores tendrían al crear una app.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si se cumplen 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 del acceso a E/S de archivos

Proporcionar un valor de referencia común para un rendimiento coherente del acceso a archivos en el almacenamiento de datos privados de la aplicación (partición /data) permite a los desarrolladores de apps establecer una expectativa adecuada que ayude al diseño de su software. Las implementaciones de dispositivos, según el tipo de dispositivo, PUEDEN tener ciertos requisitos que se describen 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 escritura aleatoria Se midió 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., segmento de App Standby, Descanso) o extienden las funciones que no aplican restricciones más estrictas que el segmento de App Standby de uso poco frecuente, deben cumplir con lo siguiente:

[C-1-1] NO DEBE desviarse de la implementación del AOSP para los algoritmos de activación, mantenimiento y activación, ni para el uso de la configuración global del sistema 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 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 del AOSP para la cantidad de intervalos App Standby que se usan para App Standby.
[C-1-4] DEBE implementar App Standby Buckets y Descanso como se describe en Administración de energía.
[C-1-5] DEBE devolver true para PowerManager.isPowerSaveMode() cuando el dispositivo esté en modo de ahorro de energía.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que se proporcione al usuario la posibilidad de habilitar y, luego, inhabilitar la función de ahorro de batería.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE que se proporcione una opción para que el usuario muestre todas las apps que están exentas de los modos de ahorro de energía Descanso y App Standby.

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 segmento de App Standby poco frecuentes, 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 definidos por la Interfaz avanzada de configuración y energía (ACPI).

Si las implementaciones de dispositivos implementan estados de energía S4 según lo define ACPI, deben hacer 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., cerrar una tapa que forma parte física del dispositivo o apagar un vehículo o una televisión) y antes de que el usuario reactive el dispositivo (p.ej., abrir la tapa o volver a encender el vehículo o la televisión).

Si las implementaciones de dispositivos implementan estados de energía S3 según lo define ACPI, deben hacer 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, DEBE salir del estado S3 cuando las aplicaciones de terceros necesiten los recursos del sistema, como se describe en este SDK.

Por ejemplo, mientras las aplicaciones de terceros solicitan mantener la pantalla encendida a través de FLAG_KEEP_SCREEN_ON o mantener la CPU en funcionamiento a través de PARTIAL_WAKE_LOCK, el dispositivo NO DEBE ingresar al estado S3, a menos que, como se describe en C-1-1, el usuario haya realizado una acción explícita para poner el dispositivo en un estado inactivo. Por el contrario, en el momento en que se activa una tarea que las apps de terceros implementan a través de JobScheduler o se entrega Firebase Cloud Messaging a las 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 el AOSP implementa indicadores de activación extensos que activan la salida de este estado.

8.4. Contabilización del consumo de energía

Un registro y un informe más precisos del consumo de energía proporcionan al desarrollador de la app los incentivos y las herramientas para optimizar el patrón de uso de energía de la aplicación.

Implementaciones de dispositivos:

[SR] SE RECOMIENDA ENCARECIDAMENTE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y el agotamiento aproximado de la batería que causan los componentes con el tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
[SR] SE RECOMIENDA ENCARECIDAMENTE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
[SR] SE RECOMIENDA ENCARECIDAMENTE informar el consumo de energía de la CPU para el 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.
[SR] SE RECOMIENDA ENCARECIDAMENTE que este uso de energía esté disponible a través del comando de shell adb shell dumpsys batterystats para el desarrollador de la app.
Se DEBE atribuir al componente de hardware en sí si no se puede atribuir el uso de energía del componente de hardware a una aplicación.

8.5. Rendimiento coherente

El rendimiento puede fluctuar drásticamente en el caso de las apps de alto rendimiento que se ejecutan durante mucho tiempo, ya sea por las otras apps que se ejecutan en segundo plano o por la regulació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 con precisión la compatibilidad con el modo de rendimiento sostenido 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 que admiten el modo de rendimiento sostenido, deben hacer lo siguiente:

[C-1-1] DEBE proporcionar a la aplicación en primer plano superior un nivel de rendimiento constante durante al menos 30 minutos, cuando la app lo solicite.
[C-1-2] DEBE cumplir con la API de Window.setSustainedPerformanceMode() y otras APIs relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, deben cumplir con lo siguiente:

DEBE proporcionar al menos un núcleo exclusivo que pueda reservar la aplicación en primer plano superior.

Si las implementaciones de dispositivos admiten la reserva de un núcleo exclusivo para la aplicación en primer plano superior, deben cumplir con los siguientes requisitos:

[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 del usuario, excepto los controladores de dispositivos que usa la aplicación para ejecutarse en los núcleos exclusivos, pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.

Si las implementaciones de dispositivos no admiten un núcleo exclusivo, deben cumplir con lo siguiente:

[C-3-1] DEBE devolver una lista vacía a través del método de la API de Process.getExclusiveCores().

9. Compatibilidad del modelo 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, tal como se define en el documento de referencia de Seguridad y permisos en las APIs de la documentación para desarrolladores de Android.
[C-0-2] DEBE admitir la instalación de aplicaciones autofirmadas sin requerir permisos o certificados adicionales de terceros o autoridades. Específicamente, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad que se describen en las siguientes subsecciones.

9.1. Permisos

Implementaciones de dispositivos:

[C-0-1] DEBE admitir el modelo de permisos de Android según se define en la documentación para desarrolladores de Android. Específicamente, DEBEN aplicar cada permiso definido según se describe en la documentación del SDK. No se pueden omitir, alterar ni ignorar permisos.
PUEDE agregar permisos adicionales, siempre que las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.\*.
[C-0-2] Los permisos con un protectionLevel de PROTECTION_FLAG_PRIVILEGED SOLO se deben otorgar a las apps preinstaladas en las rutas privilegiadas de la imagen del sistema y dentro del subconjunto de permisos incluidos explícitamente en la lista de entidades permitidas para cada app. La implementación de AOSP cumple con este requisito leyendo y respetando los permisos incluidos en la lista de entidades permitidas para cada app de los archivos en la ruta de acceso etc/permissions/ y usando la ruta de acceso system/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 exclusiva para que el usuario decida si otorga los permisos de tiempo de ejecución solicitados y también proporcionar una interfaz para que el usuario administre los permisos de tiempo de ejecución.
[C-0-4] DEBE tener una sola implementación de ambas interfaces de usuario.
[C-0-5] NO SE DEBE otorgar ningún permiso de tiempo de ejecución a las apps preinstaladas, a menos que se cumpla una de las siguientes condiciones:
- El consentimiento del usuario se puede obtener antes de que la aplicación lo use.
- Los permisos de tiempo de ejecución se asocian con un patrón de intents para el que la aplicación preinstalada se establece como controlador predeterminado.
[C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo a las apps del sistema que registren un agente de recuperación correctamente protegido. Un agente de recuperación correctamente protegido 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 protección equivalente o superior a 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 solicita los 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:
- Ubicación del dispositivo (p. ej., latitud y longitud)
- Es la 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).
- Actividad física del usuario o clasificación de la actividad física.

Específicamente, las implementaciones de dispositivos:

[C-0-8] DEBE 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 el permiso suficiente, como se describe en el SDK. Por ejemplo, TelephonyManager#getServiceState requiere android.permission.ACCESS_FINE_LOCATION.

Los permisos se pueden marcar como restringidos, lo que altera su comportamiento.

[C-0-10] Los permisos marcados con la marca hardRestricted NO SE DEBEN otorgar a una app, a menos que se cumpla una de las siguientes condiciones:
- El archivo APK de la app está en la partición del sistema.
- El usuario asigna un rol asociado con los permisos de hardRestricted a una app.
- El instalador otorga el permiso hardRestricted a una app.
- Se otorga el permiso hardRestricted a una app en una versión anterior de Android.
[C-0-11] Las apps que tienen un permiso de softRestricted SOLO deben obtener acceso limitado y NO deben obtener acceso completo hasta que se incluyan en la lista de entidades permitidas, como se describe en el SDK, en el que se define el acceso completo y limitado para cada permiso de softRestricted (por ejemplo, READ_EXTERNAL_STORAGE).

Si las implementaciones de dispositivos proporcionan una opción para que el usuario elija qué apps pueden dibujar sobre otras apps con una actividad que controla el intent ACTION_MANAGE_OVERLAY_PERMISSION, deben cumplir con 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 la actividad o de la información que proporcione.

9.2. Aislamiento de procesos y UID

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 único de estilo Unix y en un proceso independiente.
[C-0-2] DEBE admitir la ejecución de varias aplicaciones con el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de seguridad y permisos.

9.3. Permisos del sistema de archivos

Implementaciones de dispositivos:

[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 sean 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 otra parte de la sección 9.
[C-0-2] Los tiempos de ejecución alternativos NO DEBEN tener acceso a los 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 usen un tiempo de ejecución alternativo NO DEBEN reutilizar 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 otorgar o recibir acceso a ellas.
[C-0-6] Los tiempos de ejecución alternativos NO DEBEN iniciarse con privilegios de superusuario (root) o de cualquier otro ID de usuario, ni otorgar o recibir privilegios de superusuario (root) o de cualquier otro ID de usuario de otras aplicaciones.
[C-0-7] Cuando los archivos .apk de los tiempos de ejecución alternativos se incluyen 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 en las implementaciones de dispositivos.
[C-0-8] Cuando se instalan aplicaciones, los tiempos 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 del dispositivo para el que hay un permiso de Android correspondiente (como la cámara, el GPS, etcétera), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.
[C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, DEBE enumerar todos los permisos que tiene el entorno de ejecución cuando se instala cualquier aplicación que use ese entorno de ejecución.
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.).
Los tiempos de ejecución alternativos PUEDEN proporcionar una sola zona de pruebas de Android compartida por todas las aplicaciones que usan el tiempo de ejecución alternativo.

9.5. Compatibilidad con múltiples usuarios

Android incluye compatibilidad con varios usuarios y proporciona compatibilidad con el aislamiento completo del usuario.

Las implementaciones de dispositivos PUEDEN, pero NO DEBEN habilitar la función multiusuario si usan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones de dispositivos incluyen varios usuarios, deben cumplir con lo siguiente:

[C-1-1] DEBE cumplir con los siguientes requisitos relacionados con la compatibilidad con varios usuarios.
[C-1-2] Para cada usuario, DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, tal como se define en el documento de referencia sobre seguridad y permisos en las APIs.
[C-1-3] DEBE tener directorios de almacenamiento de aplicaciones compartidos (también conocidos como /sdcard) separados y aislados para cada instancia de usuario.
[C-1-4] DEBE 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 cualquier 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 puede acceder el sistema si las implementaciones del dispositivo usan medios extraíbles para las APIs de almacenamiento externo. Como esto hará que la 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.

9.6. Advertencia de SMS premium

Android incluye compatibilidad para advertir a los usuarios sobre cualquier mensaje SMS premium saliente. Los mensajes SMS premium son mensajes de texto que se envían a un servicio registrado con un operador y que pueden generar un cargo para el usuario.

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

[C-1-1] DEBE advertir a los usuarios antes de enviar un mensaje SMS a los números identificados por las 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 SELinux o cualquier otra función de seguridad se implementen debajo del framework de Android.
[C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta y bloquea correctamente un incumplimiento de seguridad con la función de seguridad implementada debajo del framework de Android, pero PUEDE tener una interfaz de usuario visible cuando se produce un incumplimiento de seguridad no bloqueado que resulta en un aprovechamiento exitoso.
[C-0-3] NO DEBE permitir que el usuario o el desarrollador de apps configuren SELinux ni ninguna otra función de seguridad implementada por debajo del framework de Android.
[C-0-4] NO DEBE permitir que una aplicación que pueda afectar a otra aplicación a través de una API (como una API de administración de dispositivos) configure una política que interrumpa la compatibilidad.
[C-0-5] SE DEBE dividir el framework de medios en varios procesos para que sea posible otorgar acceso de forma más limitada 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 aislamiento de aplicaciones del kernel que permita filtrar las llamadas al sistema con una política configurable de programas multiproceso. 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 y autoprotección del kernel son fundamentales para la seguridad de Android. Implementaciones de dispositivos:

[C-0-7] SE DEBEN implementar mecanismos de protección contra desbordamiento de búfer de pila del kernel. CC_STACKPROTECTOR_REGULAR y CONFIG_CC_STACKPROTECTOR_STRONG son ejemplos de estos mecanismos.
[C-0-8] DEBE implementar protecciones estrictas de la memoria del kernel en las que el código ejecutable sea de solo lectura, los datos de solo lectura no sean ejecutables ni se puedan escribir, y los datos que se puedan escribir no sean ejecutables (p.ej., CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
[C-0-9] DEBE implementar la verificación de límites de tamaño de objetos estáticos y dinámicos de copias entre el espacio del usuario y el espacio del kernel (p.ej., CONFIG_HARDENED_USERCOPY) en dispositivos que se lanzaron originalmente con el nivel de API 28 o posterior.
[C-0-10] NO DEBE ejecutar memoria del espacio del usuario cuando se ejecuta en el modo kernel (p.ej., PXN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se lanzaron originalmente con el nivel de API 28 o superior.
[C-0-11] NO DEBE leer ni escribir en la memoria del espacio del usuario en el kernel fuera de las APIs de acceso normales de usercopy (p.ej., PAN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se lanzaron 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 lanzaron originalmente con el nivel de API 28 o superior (p.ej., CONFIG_PAGE_TABLE_ISOLATION o CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] DEBE implementar la protección contra la predicción de ramas si el hardware es vulnerable a CVE-2017-5715 en todos los dispositivos que se lanzaron originalmente con el nivel de API 28 o posterior (p.ej., CONFIG_HARDEN_BRANCH_PREDICTOR).
[SR] SE RECOMIENDA ENCARECIDAMENTE mantener los datos del kernel que se escriben solo durante la inicialización marcados como de solo lectura después de la inicialización (p.ej., __ro_after_init).
[C-SR] SE RECOMIENDA ENCARECIDAMENTE aleatorizar el diseño del código y la memoria del kernel, y evitar las exposiciones que comprometan la aleatorización (p.ej., CONFIG_RANDOMIZE_BASE con entropía del cargador de arranque a través de /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).
[C-SR] SE RECOMIENDA ENCARECIDAMENTE habilitar la integridad del flujo de control (CFI) en el kernel para proporcionar protección adicional contra ataques de reutilización de código (p.ej., CONFIG_CFI_CLANG y CONFIG_SHADOW_CALL_STACK).
[C-SR] Se RECOMIENDA ENCARECIDAMENTE no inhabilitar la integridad del flujo de control (CFI), la pila de llamadas de sombra (SCS) ni la limpieza de desbordamiento de números enteros (IntSan) en los componentes que tienen habilitadas estas funciones.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE habilitar CFI, SCS y IntSan para cualquier componente adicional del espacio del usuario sensible a la seguridad, como se explica en CFI y IntSan.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE habilitar la inicialización de la pila en el kernel para evitar el uso de variables locales no inicializadas (CONFIG_INIT_STACK_ALL o CONFIG_INIT_STACK_ALL_ZERO). Además, las implementaciones del dispositivo NO DEBEN suponer el valor que usa el compilador para inicializar las variables locales.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE habilitar la inicialización del montón en el kernel para evitar el uso de asignaciones del montón no inicializadas (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) y NO DEBEN suponer el valor que usa el kernel para inicializar esas asignaciones.

Si las implementaciones de dispositivos usan un kernel de Linux, deben cumplir con lo siguiente:

[C-1-1] SE DEBE implementar SELinux.
[C-1-2] DEBE establecer SELinux en modo de aplicación global.
[C-1-3] Se DEBEN configurar todos los dominios en modo de aplicación. No se permiten dominios en modo permisivo, incluidos los dominios específicos de un dispositivo o proveedor.
[C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas 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 neverallow presentes, tanto para los dominios SELinux del AOSP como para los dominios específicos del dispositivo o del proveedor.
[C-1-5] DEBE ejecutar aplicaciones de terceros orientadas al nivel de API 28 o superior en zonas de pruebas de SELinux por aplicación con restricciones de SELinux por app en el directorio de datos privados de cada aplicación.
DEBE conservar la política de SELinux predeterminada que se proporciona 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 ya se lanzaron en una versión anterior de Android y no pueden cumplir con los requisitos [C-1-1] y [C-1-5] a través de una actualización de software del sistema, se PUEDEN eximir de estos requisitos.

Si las implementaciones de dispositivos usan un kernel que no es de Linux, deben hacer lo siguiente:

[C-2-1] DEBE usar un sistema de control de acceso obligatorio que sea equivalente a SELinux.

Android contiene varias funciones de defensa en profundidad que son fundamentales para la seguridad del dispositivo.

9.8. Privacidad

9.8.1. Historial de uso

Android almacena el historial de las elecciones del usuario y lo administra con UsageStatsManager.

Implementaciones de dispositivos:

[C-0-1] DEBE mantener un período de retención razonable de dicho historial del usuario.
[SR] SE RECOMIENDA ENCARECIDAMENTE mantener el período de retención de 14 días tal como está configurado de forma predeterminada en la implementación del AOSP.

Android almacena los eventos del sistema con los identificadores StatsLog y administra ese historial a través de la API del sistema StatsManager y IncidentManager.

Implementaciones de dispositivos:

[C-0-2] SOLO DEBE incluir los campos marcados con DEST_AUTOMATIC en el informe de incidentes creado por la clase IncidentManager de la API del sistema.
[C-0-3] NO DEBE usar los identificadores de eventos del sistema para registrar ningún otro evento que no sea el que se describe en los documentos del SDK de StatsLog. Si se registran eventos adicionales del sistema, ES POSIBLE que usen un identificador de átomo diferente en el rango entre 100,000 y 200,000.

9.8.2. Grabando

Implementaciones de dispositivos:

[C-0-1] NO DEBE precargar ni distribuir componentes de software listos para usar que envíen la información privada del usuario (p.ej., pulsaciones de teclas, texto que se muestra en la pantalla, informe de errores) fuera del dispositivo sin el consentimiento del usuario ni notificaciones claras y continuas.
[C-0-2] DEBE mostrar y obtener el consentimiento explícito del usuario para permitir que se capture cualquier información sensible que se muestre en la pantalla del usuario cada vez que se habilite la transmisión o grabación de pantalla a través de MediaProjection o APIs propietarias. NO DEBE proporcionar a los usuarios la posibilidad de inhabilitar la visualización futura del consentimiento del usuario.
[C-0-3] DEBE mostrar una notificación continua al usuario mientras la transmisión o grabación de pantalla estén habilitadas. El AOSP cumple con este requisito mostrando un ícono de notificación continua en la barra de estado.

Si las implementaciones de dispositivos incluyen funcionalidad en el sistema que captura el contenido que se muestra en la pantalla o graba el flujo de audio que se reproduce en el dispositivo de otra manera que no sea a través de la API del sistema ContentCaptureService, o bien otros medios propietarios que se describen en la Sección 9.8.6 Captura de contenido, deben cumplir con lo siguiente:

[C-1-1] DEBE mostrar una notificación continua al usuario cada vez que esta función esté habilitada y capture o grabe de forma activa.

Si las implementaciones de dispositivos incluyen un componente habilitado de forma predeterminada que puede grabar audio ambiental o el audio que se reproduce en el dispositivo para inferir información útil sobre el contexto del usuario, deben cumplir con lo siguiente:

[C-2-1] NO DEBE almacenar en el almacenamiento persistente del dispositivo ni transmitir fuera del dispositivo el audio sin procesar grabado ni ningún formato que se pueda convertir en el audio original o en una copia casi exacta, excepto con el consentimiento explícito del usuario.

9.8.3. Conectividad

Si las implementaciones de dispositivos tienen un puerto USB con compatibilidad con el modo periférico USB, deben cumplir con 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] Se DEBEN preinstalar los mismos certificados raíz para el almacén de la autoridad certificadora (CA) de confianza del sistema que los proporcionados en el proyecto de código abierto de Android upstream.
[C-0-2] DEBE incluir un almacén de CA 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 CA raíz del usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones del dispositivo deben cumplir con lo siguiente:

[C-1-1] DEBE mostrar una advertencia al usuario que indique una de las siguientes opciones:
- 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, precargando un servicio de VPN con android.permission.CONTROL_VPN otorgado), deben cumplir con lo siguiente:

[C-2-1] DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el Device Policy Controller habilite esa VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage() , en cuyo caso el usuario no necesita proporcionar un consentimiento independiente, sino que SOLO DEBE recibir una notificación.

Si las implementaciones de dispositivos incluyen una opción para activar o desactivar la función "VPN siempre activada" de una app de VPN de terceros, deben cumplir con lo siguiente:

[C-3-1] DEBE inhabilitar esta opción para el usuario en las apps que no admiten el servicio de VPN siempre activada en el archivo AndroidManifest.xml configurando el atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON en false.

9.8.5. Identificadores de dispositivos

Implementaciones de dispositivos:

[C-0-1] DEBE impedir 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 de operador firmada y verificada por 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 propietario del dispositivo o del perfil y se le otorgó el permiso READ_PHONE_STATE.
- (Solo para el número de serie de la SIM o el ICCID) Cumple con el requisito de las reglamentaciones locales de que la app detecte cambios en la identidad del suscriptor.

9.8.6. Captura de contenido

Android, a través de la API del sistema ContentCaptureService o por otros medios propios, admite un mecanismo para que las implementaciones de dispositivos capturen las siguientes interacciones entre las aplicaciones y el usuario.

Texto y gráficos renderizados en la pantalla, incluidos, sin limitaciones, los datos de asistencia y las notificaciones a través de la API de AssistStructure
Datos multimedia, como audio o video, grabados o reproducidos por el dispositivo.
Eventos de entrada (p. ej., teclado, mouse, gestos, voz, video y accesibilidad)
Cualquier otro evento que una aplicación proporcione al sistema a través de la API de Content Capture o una API propietaria con capacidades similares
Cualquier texto o dato que se envíe a través de TextClassifier API al clasificador de texto del sistema, es decir, al servicio del sistema para comprender el significado del texto, así como generar las próximas acciones predichas basadas en el texto.

Si las implementaciones de dispositivos capturan los datos anteriores, deben hacer lo siguiente:

[C-1-1] DEBE encriptar todos esos datos cuando se almacenan en el dispositivo. Esta encriptación SE PUEDE llevar a cabo con la encriptación basada en archivos de Android o con cualquiera de los cifrados que se indican como versión de API 26 o posterior, como se describe en Cipher SDK.
[C-1-2] NO DEBE crear copias de seguridad de datos sin procesar ni 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 registro del dispositivo a través de un mecanismo que preserve la privacidad. El mecanismo que preserva la privacidad se define como “aquellos que solo permiten el análisis de forma agregada y evitan la correlación de eventos registrados o resultados derivados con usuarios individuales”, para evitar que se puedan inspeccionar los datos por usuario (p.ej., se implementa con una tecnología de privacidad diferencial como RAPPOR).
[C-1-4] NO DEBE 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 DEBE compartir esos datos con otras apps, excepto con el consentimiento explícito del usuario cada vez que se compartan.
[C-1-6] DEBE proporcionar al usuario la posibilidad de borrar los datos que recopile la ContentCaptureService o los medios propietarios si los datos se almacenan de alguna forma en el dispositivo.

Si las implementaciones de dispositivos incluyen un servicio que implementa la API del sistema ContentCaptureService o cualquier servicio propietario que capture los datos como se describió anteriormente, deben hacer lo siguiente:

[C-2-1] NO DEBE permitir que los usuarios reemplacen el servicio de captura de contenido por una aplicación o servicio instalable por el usuario, y SOLO DEBE permitir que el servicio preinstalado capture esos datos.
[C-2-2] NO DEBE permitir que ninguna app, excepto el mecanismo de servicio de captura de contenido preinstalado, pueda capturar esos datos.
[C-2-3] DEBE proporcionar al usuario la posibilidad de inhabilitar el servicio de captura de contenido.
[C-2-4] NO DEBE omitir la capacidad del usuario para administrar los permisos de Android que tiene el servicio de captura de contenido y seguir el modelo de permisos de Android como se describe en la Sección 9.1. Permiso.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE mantener separados los componentes del servicio de captura de contenido, por ejemplo, no vincular el servicio ni compartir IDs de proceso, de otros componentes del sistema, excepto los siguientes:
- Telefonía, Contactos, IU del sistema y Contenido multimedia

9.8.7. Acceso al portapapeles

Implementaciones de dispositivos:

[C-0-1] NO DEBE devolver datos recortados en el portapapeles (p.ej., a través de la API de ClipboardManager), a menos que la app sea el IME predeterminado o la app que tiene el enfoque actualmente.

9.8.8. Ubicación

Implementaciones de dispositivos:

[C-0-1] NO DEBE activar ni desactivar la configuración de ubicación del dispositivo ni la configuración de búsqueda de Wi-Fi o Bluetooth sin el consentimiento explícito del usuario o sin que este inicie la acción.
[C-0-2] DEBE proporcionar la opción para que el usuario acceda a la información relacionada con la ubicación, incluidas las solicitudes de ubicación recientes, los permisos a nivel de la app y el uso del análisis de Wi-Fi o Bluetooth para determinar la ubicación.
[C-0-3] DEBE garantizar que la aplicación que usa la API de Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] sea una sesión de emergencia iniciada por el usuario (p.ej., marcar el 911 o enviar un mensaje de texto al 911). Sin embargo, en el caso de Automotive, un vehículo PUEDE iniciar una sesión de emergencia sin interacción activa del usuario en caso de que se detecte un accidente (p.ej., para satisfacer los requisitos de eCall).
[C-0-4] DEBE conservar la capacidad de la API de Emergency Location Bypass para omitir la configuración de ubicación del dispositivo sin cambiarla.
[C-0-5] DEBE programar una notificación que le recuerde al usuario que una app en segundo plano accedió a su ubicación con el permiso [ACCESS_BACKGROUND_LOCATION].

9.8.9. Apps instaladas

De forma predeterminada, las apps para Android que se segmentan para el nivel de API 30 o superior no pueden ver detalles sobre otras apps instaladas (consulta Visibilidad de paquetes en la documentación del SDK de Android).

Implementaciones de dispositivos:

[C-0-1] NO DEBE exponer a ninguna app que se oriente al nivel de API 30 o superior detalles sobre ninguna otra app instalada, a menos que la app ya pueda ver detalles sobre la otra app instalada a través de las APIs administradas. Esto incluye, sin limitaciones, los detalles expuestos por las APIs personalizadas que agregó el implementador del dispositivo o a los que se puede acceder a través del sistema de archivos.

9.8.10. Informe de errores de conectividad

Si las implementaciones de dispositivos generan informes de errores con la API del sistema BUGREPORT_MODE_TELEPHONY y BugreportManager, deben hacer lo siguiente:

[C-1-1] DEBE obtener el consentimiento del usuario cada vez que se llame a la API del sistema BUGREPORT_MODE_TELEPHONY para generar un informe y NO DEBE solicitarle al usuario que dé su consentimiento para todas las solicitudes futuras de la aplicación.
[C-1-2] DEBE mostrar y obtener el consentimiento explícito del usuario cuando se comiencen a generar los informes, y NO DEBE devolver el informe generado a la app solicitante sin el consentimiento explícito del usuario.
[C-1-3] DEBE generar los informes solicitados que contengan, al menos, la siguiente información:
- Volcado de TelephonyDebugService
- Volcado de TelephonyRegistry
- Volcado de WifiService
- Volcado de ConnectivityService
- Es un volcado de la instancia de CarrierService del paquete de llamadas (si está vinculada).
- Búfer de registro de radio
[C-1-4] NO DEBE incluir lo siguiente en los informes generados:
- Cualquier tipo de información que no esté relacionada con la depuración de la conectividad
- Registros de tráfico de aplicaciones instaladas por el usuario de cualquier tipo o perfiles detallados de aplicaciones o paquetes instalados por el usuario (los UID están bien, los nombres de los paquetes no).
PUEDE incluir información adicional que no esté asociada con ninguna identidad del usuario. (p.ej., registros de proveedores).

Si las implementaciones de dispositivos incluyen información adicional (p. ej., registros de proveedores) en el informe de errores y esa información tiene un impacto en la privacidad, la seguridad, la batería, el almacenamiento o la memoria, deben hacer lo siguiente:

[C-SR] SE RECOMIENDA ENCARECIDAMENTE que tengan un parámetro de configuración para desarrolladores inhabilitado de forma predeterminada. El AOSP cumple con este requisito proporcionando la opción Enable verbose vendor logging en la configuración para desarrolladores para incluir registros adicionales de proveedores específicos del dispositivo en los informes de errores.

9.8.11. Uso compartido de BLOB de datos

Android, a través de BlobStoreManager, permite que las apps aporten BLOB de datos al sistema para compartirlos con un conjunto seleccionado de apps.

Si las implementaciones de dispositivos admiten blobs de datos compartidos, como se describe en la documentación del SDK, deben cumplir con los siguientes requisitos:

[C-1-1] NO DEBE compartir blobs de datos que pertenezcan a apps más allá de lo que se pretendía permitir (es decir, no se debe modificar el alcance del acceso predeterminado ni los otros modos de acceso que se pueden especificar con BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() o BlobStoreManager.session#allowPublicAccess()). La implementación de referencia de AOSP cumple con estos requisitos.
[C-1-2] NO DEBE enviar fuera del dispositivo ni compartir con otras apps los hashes seguros de los BLOB de datos (que se usan para controlar el acceso).

9.9. Encriptación del almacenamiento de datos

Todos los dispositivos DEBEN cumplir con los requisitos de la sección 9.9.1. Los dispositivos que se lanzaron con un nivel de API anterior al de este documento están exentos de los requisitos de las secciones 9.9.2 y 9.9.3. En cambio, DEBEN cumplir con los requisitos de la sección 9.9 del documento de Definición de compatibilidad de Android correspondiente al nivel de API con el que se lanzó el dispositivo.

9.9.1. Inicio directo

Implementaciones de dispositivos:

[C-0-1] DEBE implementar las APIs del modo de inicio directo, incluso si no admiten el cifrado de almacenamiento.
[C-0-2] Los intents ACTION_LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED DEBEN seguir transmitiéndose para indicar a las aplicaciones compatibles con el inicio directo que las ubicaciones de almacenamiento encriptado por dispositivo (DE) y encriptado por credenciales (CE) están disponibles para el usuario.

9.9.2. Requisitos de encriptación

Implementaciones de dispositivos:

[C-0-1] DEBE encriptar los datos privados de la aplicación (partición /data), así como la partición de almacenamiento compartido de la aplicación (partición /sdcard) si es una parte permanente y no extraíble del dispositivo.
[C-0-2] DEBE habilitar la encriptación del almacenamiento de datos de forma predeterminada cuando el usuario haya completado la experiencia de configuración inicial.
[C-0-3] DEBE cumplir con el requisito de encriptación de almacenamiento de datos anterior implementando uno de los siguientes dos métodos de encriptación:
- Encriptación basada en archivos (FBE) y Encriptación de metadatos, como se describe en la sección 9.9.3.1
- Encriptación a nivel de bloque por usuario, como se describe en la sección 9.9.3.2

9.9.3. Métodos de encriptación

Si las implementaciones de dispositivos están encriptadas, deben cumplir con los siguientes requisitos:

[C-1-1] DEBE iniciarse sin solicitarle credenciales al usuario y permitir que las apps compatibles con el inicio directo accedan al almacenamiento encriptado por dispositivo (DE) después de que se transmita el mensaje ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] SOLO DEBE permitir el acceso al almacenamiento encriptado por credenciales (CE) después de que el usuario desbloquee el dispositivo proporcionando sus credenciales (p. ej., código, PIN, patrón o huella dactilar) y se transmita el mensaje ACTION_USER_UNLOCKED.
[C-1-13] NO DEBE ofrecer ningún método para desbloquear el almacenamiento protegido por CE sin las credenciales proporcionadas por el usuario, una clave de depósito registrada o una implementación de reanudación en el reinicio que cumpla con los requisitos de la sección 9.9.4.
[C-1-4] DEBE usar el inicio verificado.

9.9.3.1. Encriptación basada en archivos con encriptación de metadatos

Si las implementaciones de dispositivos usan la encriptación basada en archivos con encriptación de metadatos, deben cumplir con lo siguiente:

[C-1-5] DEBE encriptar el contenido de los archivos y los metadatos del sistema de archivos con AES-256-XTS o Adiantum. AES-256-XTS hace referencia al Estándar de encriptación avanzada con una longitud de clave de cifrado de 256 bits, que se opera en modo XTS. La longitud completa de la clave es de 512 bits. Adiantum hace referencia a Adiantum-XChaCha12-AES, como se especifica en https://github.com/google/adiantum. Los metadatos del sistema de archivos son datos como los tamaños de los archivos, la propiedad, los modos y los atributos extendidos (xattrs).
[C-1-6] DEBE encriptar los nombres de archivos con AES-256-CBC-CTS o Adiantum.
[C-1-12] Si el dispositivo tiene instrucciones del Estándar de Encriptación Avanzada (AES) (como las extensiones de criptografía ARMv8 en dispositivos basados en ARM o AES-NI en dispositivos basados en x86), se DEBEN usar las opciones basadas en AES mencionadas anteriormente para la encriptación del nombre del archivo, el contenido del archivo y los metadatos del sistema de archivos, y no Adiantum.
[C-1-13] DEBE usar una función de derivación de claves criptográficamente sólida y no reversible (p.ej., HKDF-SHA512) para derivar las subclaves necesarias (p.ej., claves por archivo) de las claves CE y DE. "Criptográficamente sólida y no reversible" significa que la función de derivación de claves tiene una solidez de seguridad de al menos 256 bits y se comporta como una familia de funciones seudoaleatorias en sus entradas.
[C-1-14] NO DEBE usar las mismas claves o subclaves de File Based Encryption (FBE) para diferentes propósitos criptográficos (p.ej., para la encriptación y la derivación de claves, o para dos algoritmos de encriptación diferentes).
Las claves que protegen las áreas de almacenamiento de CE y DE, y los metadatos del sistema de archivos:
[C-1-7] DEBE estar vinculado de forma criptográfica a un almacén de claves respaldado por hardware. Este almacén de claves DEBE estar vinculado al inicio verificado y a la raíz de confianza del hardware del dispositivo.
[C-1-8] Las claves de CE DEBEN estar vinculadas a las credenciales de la pantalla de bloqueo del usuario.
[C-1-9] Las claves de CE DEBEN estar vinculadas a un código predeterminado cuando el usuario no haya especificado credenciales de pantalla de bloqueo.
[C-1-10] DEBE ser único y distinto, es decir, la clave de CE o DE de ningún usuario debe coincidir con la clave de CE o DE de ningún otro usuario.
[C-1-11] DEBE usar los algoritmos de encriptación, las longitudes de clave y los modos obligatorios admitidos.
DEBE hacer que las apps esenciales preinstaladas (p.ej., Alarma, Teléfono y Mensajes) sean compatibles con el inicio directo.

El proyecto de código abierto de Android upstream proporciona una implementación preferida de la encriptación basada en archivos basada en la función de encriptación "fscrypt" del kernel de Linux y de la encriptación de metadatos basada en la función "dm-default-key" del kernel de Linux.

9.9.3.2. Encriptación a nivel de bloque por usuario

Si las implementaciones de dispositivos usan la encriptación a nivel de bloque por usuario, deben cumplir con lo siguiente:

[C-1-1] DEBE habilitar la compatibilidad con varios usuarios, como se describe en la sección 9.5.
[C-1-2] DEBE proporcionar particiones por usuario, ya sea con particiones sin procesar o volúmenes lógicos.
[C-1-3] DEBE usar claves de encriptación únicas y distintas por usuario para encriptar los dispositivos de bloques subyacentes.
[C-1-4] DEBE usar AES-256-XTS para la encriptación a nivel de bloque de las particiones del usuario.
Las claves que protegen los dispositivos encriptados a nivel de bloque por usuario:
[C-1-5] DEBE estar vinculado de forma criptográfica a un almacén de claves respaldado por hardware. Este almacén de claves DEBE estar vinculado al inicio verificado y a la raíz de confianza del hardware del dispositivo.
[C-1-6] DEBE estar vinculado a las credenciales de la pantalla de bloqueo del usuario correspondiente.

La encriptación a nivel de bloque por usuario se puede implementar con la función "dm-crypt" del kernel de Linux en particiones por usuario.

9.9.4. Reanudar después de reiniciar

La función Reanudar después del reinicio permite desbloquear el almacenamiento CE de todas las apps, incluidas las que aún no admiten el inicio directo, después de un reinicio iniciado por una actualización inalámbrica. Esta función permite que los usuarios reciban notificaciones de las apps instaladas después del reinicio.

Una implementación de Reanudar tras reinicio debe seguir garantizando que, cuando un dispositivo cae en manos de un atacante, sea extremadamente difícil para este recuperar los datos encriptados con CE del usuario, incluso si el dispositivo está encendido, el almacenamiento con CE está desbloqueado y el usuario desbloqueó el dispositivo después de recibir una OTA. Para la resistencia a ataques internos, también suponemos que el atacante obtiene acceso a las claves de firma criptográfica de transmisión.

Más precisamente:

[C-0-1] El almacenamiento de CE NO DEBE ser legible, ni siquiera para el atacante que tiene el dispositivo físicamente y, luego, tiene estas capacidades y limitaciones:
- Puede usar la clave de firma de cualquier proveedor o empresa para firmar mensajes arbitrarios.
- Puede hacer que el dispositivo reciba una OTA.
- Puede modificar el funcionamiento de cualquier hardware (AP, flash, etc.), excepto como se detalla a continuación, pero dicha modificación implica una demora de al menos una hora y un ciclo de energía que destruye el contenido de la RAM.
- No se puede modificar el funcionamiento del hardware resistente a manipulaciones (p. ej., Titan M).
- No se puede leer la RAM del dispositivo activo.
- No puede obtener la credencial del usuario (PIN, patrón, contraseña) ni hacer que se ingrese de ninguna otra manera.

A modo de ejemplo, una implementación del dispositivo que implemente y cumpla con todas las descripciones que se encuentran aquí cumplirá con [C-0-1].

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan la transparencia del estado de la integridad del dispositivo. Implementaciones de dispositivos:

[C-0-1] DEBE informar correctamente a través del método de la API del sistema PersistentDataBlockManager.getFlashLockState() si el estado del bootloader permite la escritura de la imagen del sistema. El estado FLASH_LOCK_UNKNOWN se reserva para las implementaciones de dispositivos que se actualizan desde una versión anterior de Android en la que no existía este nuevo método de la API del sistema.
[C-0-2] DEBE admitir el inicio verificado para la integridad del dispositivo.

Si las implementaciones de dispositivos ya se lanzaron sin admitir el inicio verificado en una versión anterior de Android y no pueden agregar compatibilidad con esta función con una actualización de software del sistema, ES POSIBLE que se eximan del requisito.

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si las implementaciones de dispositivos admiten la función, deben cumplir con lo siguiente:

[C-1-1] DEBE declarar la marca de función de la plataforma android.software.verified_boot.
[C-1-2] DEBE realizar la verificación en cada secuencia de inicio.
[C-1-3] DEBE iniciar la verificación desde una clave de hardware inmutable que sea la raíz de confianza y llegar hasta la partición del sistema.
[C-1-4] DEBE implementar cada etapa de verificación para comprobar la integridad y autenticidad de todos los bytes en la siguiente etapa antes de ejecutar el código en la siguiente etapa.
[C-1-5] DEBE usar algoritmos de verificación tan sólidos como las recomendaciones actuales del NIST para los algoritmos de hash (SHA-256) y los tamaños de clave pública (RSA-2048).
[C-1-6] NO DEBE permitir que se complete el inicio cuando falla la verificación del sistema, a menos que el usuario acepte intentar el inicio de todos modos, en cuyo caso NO SE DEBEN usar los datos de los bloques de almacenamiento no verificados.
[C-1-7] NO DEBE permitir que se modifiquen las particiones verificadas en el dispositivo, a menos que el usuario haya desbloqueado explícitamente el cargador de arranque.
[C-SR] Si hay varios chips discretos en el dispositivo (p.ej., radio, procesador de imágenes especializado), se RECOMIENDA ENCARECIDAMENTE que el proceso de arranque de cada uno de esos chips verifique cada etapa al arrancar.
[C-1-8] DEBE usar almacenamiento a prueba de manipulaciones: para almacenar si el bootloader está desbloqueado. El almacenamiento a prueba de manipulaciones significa que el bootloader puede detectar si se manipuló el almacenamiento desde Android.
[C-1-9] DEBE solicitarle al usuario, mientras usa el dispositivo, y requerir confirmación física antes de permitir una transición del modo de bootloader bloqueado al modo de bootloader desbloqueado.
[C-1-10] DEBE implementar protección contra reversiones para las particiones que usa Android (p.ej., particiones de arranque y del sistema) y usar almacenamiento a prueba de manipulaciones para almacenar los metadatos que se usan para determinar la versión mínima permitida del SO.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE verificar todos los archivos APK de apps con privilegios con una cadena de confianza basada en particiones protegidas por el inicio verificado.
[C-SR] SE RECOMIENDA ENCARECIDAMENTE verificar cualquier artefacto ejecutable que cargue una app con privilegios desde fuera de su archivo APK (como código cargado de forma dinámica o código compilado) antes de ejecutarlo o SE RECOMIENDA ENCARECIDAMENTE no ejecutarlo en absoluto.
DEBE implementar protección contra reversiones para cualquier componente con firmware persistente (p.ej., módem, cámara) y DEBE usar almacenamiento a prueba de manipulaciones para almacenar los metadatos que se usan para determinar la versión mínima permitida.

Si las implementaciones de dispositivos ya se lanzaron sin admitir los requisitos de C-1-8 a C-1-10 en una versión anterior de Android y no pueden agregar compatibilidad con estos requisitos con una actualización de software del sistema, PUEDEN quedar exentas de los requisitos.

El Proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función en el repositorio external/avb/, que se puede integrar en el bootloader que se usa para cargar Android.

Implementaciones de dispositivos:

[C-0-3] DEBE admitir la verificación criptográfica del contenido del archivo con una clave de confianza sin leer todo el archivo.
[C-0-4] NO DEBE permitir que las solicitudes de lectura en un archivo protegido se realicen correctamente cuando el contenido de lectura no se verifica con una clave de confianza.

Si las implementaciones de dispositivos ya se lanzaron sin la capacidad de verificar el contenido del archivo con una clave de confianza en una versión anterior de Android y no se puede agregar compatibilidad con esta función con una actualización de software del sistema, ES POSIBLE que se eximan del requisito. El proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función basada en la función fs-verity del kernel de Linux.

Implementaciones de dispositivos:

[C-R] Se RECOMIENDA que admitan la API de Android Protected Confirmation.

Si las implementaciones de dispositivos admiten la API de Android Protected Confirmation, deben cumplir con lo siguiente:

[C-3-1] Se DEBE informar true para la API de ConfirmationPrompt.isSupported().
[C-3-2] DEBE garantizar que el código que se ejecuta en el SO Android, incluido su kernel, ya sea malicioso o no, no pueda generar una respuesta positiva sin la interacción del usuario.
[C-3-3] DEBE garantizar que el usuario haya podido revisar y aprobar el mensaje solicitado, incluso en el caso de que se vea comprometido el SO Android, incluido su kernel.

9.11. Claves y credenciales

El sistema Android Keystore permite que los desarrolladores de apps almacenen claves criptográficas en un contenedor y las usen en operaciones criptográficas a través de la API de KeyChain o la API de Keystore. Implementaciones de dispositivos:

[C-0-1] DEBE permitir la importación o generación de al menos 8,192 claves.
[C-0-2] La autenticación de la pantalla de bloqueo DEBE limitar la frecuencia de los intentos y DEBE tener un algoritmo de retirada exponencial. Después de 150 intentos fallidos, la demora DEBE ser de al menos 24 horas por intento.
NO DEBE limitar la cantidad de claves que se pueden generar

Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, sucede lo siguiente:

[C-1-1] DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
[C-1-2] DEBE tener implementaciones de los algoritmos criptográficos RSA, AES, ECDSA y HMAC, y las funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos admitidos del sistema Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y en niveles superiores. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito a través de 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.
[C-1-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislado y, solo si se realiza correctamente, permitir que se usen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de manera que solo el entorno de ejecución aislado pueda realizar la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android upstream proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
[C-1-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 realice en hardware seguro. Las claves de firma de la 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.

[C-1-5] DEBE permitir que el usuario elija el tiempo de espera de suspensión para la transición del estado desbloqueado al bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos. Los dispositivos para automóviles, que bloquean la pantalla cada vez que se apaga la unidad principal o se cambia de usuario, NO DEBEN tener la configuración de tiempo de espera de suspensión.

9.11.1. Pantalla de bloqueo y autenticación seguras

La implementación del AOSP sigue un modelo de autenticación por niveles en el que una autenticación principal basada en un factor de conocimiento puede respaldarse con una autenticación biométrica secundaria sólida o con modalidades terciarias más débiles.

Implementaciones de dispositivos:

[C-SR] Se RECOMIENDA ENCARECIDAMENTE establecer solo uno de los siguientes métodos como el método de autenticación principal:
- Un PIN numérico
- Una contraseña alfanumérica
- Un patrón de deslizamiento en una cuadrícula de exactamente 3 x 3 puntos

Ten en cuenta que los métodos de autenticación anteriores se consideran los métodos de autenticación principales recomendados en este documento.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación principales recomendados y usan un nuevo método de autenticación como una forma segura de bloquear la pantalla, el nuevo método de autenticación debe cumplir con los siguientes requisitos:

[C-2-1] DEBE ser el método de autenticación del usuario como se describe en Solicita la autenticación del usuario para el uso de la clave.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla bloqueada si se basan en un secreto conocido y usan un nuevo método de autenticación para que se considere una forma segura de bloquear la pantalla, se deben cumplir los siguientes requisitos:

[C-3-1] La entropía de la longitud más corta permitida de las entradas DEBE ser mayor que 10 bits.
[C-3-2] La entropía máxima de todas las entradas posibles DEBE ser superior a 18 bits.
[C-3-3] El nuevo método de autenticación NO DEBE reemplazar ninguno de los métodos de autenticación principales recomendados (es decir, PIN, patrón, contraseña) implementados y proporcionados en AOSP.
[C-3-4] El nuevo método de autenticación DEBE inhabilitarse cuando la aplicación de Device Policy Controller (DPC) haya establecido la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_SOMETHING.
[C-3-5] Los métodos de autenticación nuevos DEBEN recurrir a los métodos de autenticación principales recomendados (es decir, PIN, patrón, contraseña) cada 72 horas o menos, O bien divulgar claramente al usuario que no se realizará una copia de seguridad de algunos datos para preservar la privacidad de sus datos.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación principales recomendados para desbloquear la pantalla de bloqueo y usan un nuevo método de autenticación basado en datos biométricos para que se considere una forma segura de bloquear la pantalla, el nuevo método debe cumplir con los siguientes requisitos:

[C-4-1] DEBE cumplir con todos los requisitos descritos en la sección 7.3.10 para la clase 1 (anteriormente Convenience).
[C-4-2] DEBE tener un mecanismo de respaldo para usar uno de los métodos de autenticación principales recomendados que se basa en un secreto conocido.
[C-4-3] DEBE inhabilitarse y solo permitir la autenticación principal recomendada para desbloquear la pantalla cuando la aplicación del controlador de políticas de dispositivo (DPC) haya establecido la política de funciones de keyguard llamando al método DevicePolicyManager.setKeyguardDisabledFeatures() con cualquiera de los parámetros biométricos asociados (es decir, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).

Si los métodos de autenticación biométrica no cumplen con los requisitos de clase 3 (anteriormente segura) como se describe en la sección 7.3.10, haz lo siguiente:

[C-5-1] Los métodos DEBEN inhabilitarse si la aplicación de Device Policy Controller (DPC) estableció la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] Se DEBE solicitar al usuario que realice la autenticación principal recomendada (p. ej., PIN, patrón o contraseña) como se describe en [C-1-7] y [C-1-8] en la sección 7.3.10.
[C-5-3] Los métodos NO DEBEN tratarse como una pantalla de bloqueo segura y DEBEN cumplir con los requisitos que comienzan con C-8 en esta sección.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo, y un nuevo método de autenticación se basa en un token físico o la ubicación, se deben cumplir los siguientes requisitos:

[C-6-1] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados que se basa en un secreto conocido y cumple con los requisitos para considerarse un bloqueo de pantalla seguro.
[C-6-2] El nuevo método DEBE inhabilitarse y solo debe permitir uno de los métodos de autenticación principales recomendados para desbloquear la pantalla cuando la aplicación del controlador de políticas de dispositivos (DPC) haya establecido la política con el método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o el método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_UNSPECIFIED.
[C-6-3] Se DEBE solicitar al usuario que utilice uno de los métodos de autenticación principales recomendados (p.ej., PIN, patrón o contraseña) al menos una vez cada 4 horas o menos.
[C-6-4] El nuevo método NO DEBE tratarse como una pantalla de bloqueo segura y DEBE cumplir con las restricciones que se indican en C-8 a continuación.

Si las implementaciones de dispositivos tienen una pantalla de bloqueo segura y uno o más agentes de confianza que implementan la API del sistema TrustAgentService, cumplen con los siguientes requisitos:

[C-7-1] DEBE haber una indicación clara en el menú de configuración y en la pantalla de bloqueo cuando se pospone el bloqueo del dispositivo o cuando se puede desbloquear con agentes de confianza. Por ejemplo, el AOSP cumple con este requisito mostrando una descripción de texto para el parámetro de configuración de bloqueo automático y el bloqueo instantáneo con el botón de encendido en el menú de configuración, y un ícono distinguible en la pantalla de bloqueo.
[C-7-2] DEBE respetar y, por completo, implementar todas las APIs de agentes de confianza en la clase DevicePolicyManager, como la constante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NO DEBE implementar por completo la función TrustAgentService.addEscrowToken() en un dispositivo que se use como dispositivo personal principal (p.ej., de mano), pero PUEDE implementar por completo la función en implementaciones de dispositivos que suelen ser compartidos (p.ej., Android TV o dispositivos para automóviles).
[C-7-4] DEBE encriptar todos los tokens almacenados que agregó TrustAgentService.addEscrowToken().
[C-7-5] NO DEBE almacenar la clave de encriptación ni el token de depósito en garantía en el mismo dispositivo en el que se usa la clave. Por ejemplo, se permite que una llave almacenada en un teléfono desbloquee una cuenta de usuario en una TV. En el caso de los dispositivos para automóviles, no se permite que el token de depósito en garantía se almacene en ninguna parte del vehículo.
[C-7-6] DEBE informar al usuario sobre las implicaciones de seguridad antes de habilitar el token de garantía para desencriptar el almacenamiento de datos.
[C-7-7] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados.
[C-7-8] Se DEBE solicitar al usuario que use uno de los métodos de autenticación principal recomendados (p. ej., PIN, patrón o contraseña) al menos una vez cada 72 horas o menos, a menos que la seguridad del usuario (p. ej., distracción del conductor) sea un problema.
[C-7-9] Se DEBE solicitar al usuario uno de los métodos de autenticación principal recomendados (p. ej., PIN, patrón, contraseña) como se describe en [C-1-7] y [C-1-8] en la sección 7.3.10, a menos que la seguridad del usuario (p. ej., distracción del conductor) sea un problema.
[C-7-10] NO DEBE tratarse como una pantalla de bloqueo segura y DEBE cumplir con las restricciones que se enumeran en C-8 a continuación.
[C-7-11] NO DEBE permitir que los agentes de confianza en dispositivos personales principales (p. ej., portátiles) desbloqueen el dispositivo y solo puede usarlos para mantener un dispositivo ya desbloqueado en el estado de desbloqueo durante un máximo de 4 horas. La implementación predeterminada de TrustManagerService en AOSP cumple con este requisito.
[C-7-12] DEBE usar un canal de comunicación seguro a nivel criptográfico (p. ej., UKEY2) para pasar el token de depósito del dispositivo de almacenamiento al dispositivo de destino.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo que no es una pantalla de bloqueo segura como se describió anteriormente, y usan un nuevo método de autenticación para desbloquear el keyguard, deben cumplir con los siguientes requisitos:

[C-8-1] El nuevo método DEBE inhabilitarse cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_UNSPECIFIED.
[C-8-2] NO DEBEN restablecer los temporizadores de caducidad de contraseña establecidos por DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] NO DEBEN exponer una API para que las apps de terceros la usen y cambien el estado de bloqueo.

9.11.2. StrongBox

El sistema Android Keystore permite a los desarrolladores de apps almacenar claves criptográficas en un procesador seguro dedicado, así como en el entorno de ejecución aislado que se describió anteriormente. Este procesador seguro exclusivo se denomina "StrongBox". Los requisitos C-1-3 a C-1-11 que se indican a continuación definen los requisitos que debe cumplir un dispositivo para calificar como StrongBox.

Implementaciones de dispositivos que tienen un procesador seguro dedicado:

[C-SR] Se RECOMIENDA ENCARECIDAMENTE que admitan StrongBox. Es probable que StrongBox se convierta en un requisito en una versión futura.

Si las implementaciones de dispositivos admiten StrongBox, deben cumplir con los siguientes requisitos:

[C-1-1] Se DEBE declarar FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] DEBE proporcionar hardware seguro dedicado que se use para respaldar el almacén de claves y la autenticación segura del usuario. El hardware seguro dedicado también se puede usar para otros fines.
[C-1-3] DEBE tener una CPU discreta que no comparta caché, DRAM, coprocesadores ni otros recursos principales con el procesador de aplicaciones (AP).
[C-1-4] DEBE garantizar que los periféricos compartidos con el AP no puedan alterar el procesamiento de StrongBox de ninguna manera ni obtener información de StrongBox. El AP PUEDE inhabilitar o bloquear el acceso a StrongBox.
[C-1-5] DEBE tener un reloj interno con una precisión razonable (±10%) que sea inmune a la manipulación por parte del AP.
[C-1-6] DEBE tener un generador de números aleatorios reales que produzca resultados impredecibles y distribuidos de manera uniforme.
[C-1-7] DEBE tener resistencia a la manipulación, incluida la resistencia a la penetración física y a las fallas.
[C-1-8] DEBE tener resistencia a los canales laterales, incluida la resistencia a la filtración de información a través de canales laterales de energía, tiempo, radiación electromagnética y radiación térmica.
[C-1-9] DEBE tener un almacenamiento seguro que garantice la confidencialidad, la integridad, la autenticidad, la coherencia y la actualización del contenido. El almacenamiento NO DEBE poder leerse ni alterarse, excepto según lo permitan las APIs de StrongBox.
Para validar el cumplimiento de [C-1-3] a [C-1-9], las implementaciones de dispositivos deben hacer lo siguiente:
- [C-1-10] DEBE incluir el hardware certificado según el perfil de protección de CI seguro BSI-CC-PP-0084-2014 o evaluado por un laboratorio de pruebas acreditado a nivel nacional que incorpore la evaluación de vulnerabilidades con alto potencial de ataque según los Criterios Comunes para la aplicación del potencial de ataque a tarjetas inteligentes.
- [C-1-11] DEBE incluir el firmware que evalúa un laboratorio de pruebas acreditado a nivel nacional que incorpora la evaluación de vulnerabilidad con alto potencial de ataque según los Criterios Comunes para la Aplicación del Potencial de Ataque a Tarjetas Inteligentes.
- [C-SR] SE RECOMIENDA ENCARECIDAMENTE que se incluya el hardware que se evalúa con un objetivo de seguridad, un nivel de garantía de evaluación (EAL) 5, aumentado por AVA_VAN.5. Es probable que la certificación EAL 5 se convierta en un requisito en una versión futura.
Se RECOMIENDA ENCARECIDAMENTE que los [C-SR] proporcionen resistencia a ataques internos (IAR), lo que significa que un empleado interno con acceso a las claves de firma del firmware no puede producir firmware que haga que StrongBox filtre secretos, eluda los requisitos de seguridad funcionales o permita el acceso a datos sensibles del usuario. La forma recomendada de implementar IAR es permitir las actualizaciones de firmware solo cuando se proporciona la contraseña del usuario principal a través del HAL de IAuthSecret.

9.11.3. Credencial de identidad

El sistema de credenciales de identidad se define y se logra implementando todas las APIs en el paquete android.security.identity.*. Estas APIs permiten que los desarrolladores de apps almacenen y recuperen documentos de identidad del usuario. Implementaciones de dispositivos:

[C-SR] se RECOMIENDA ENCARECIDAMENTE implementar el Sistema de credenciales de identidad.

Si las implementaciones de dispositivos implementan el sistema de credenciales de identidad, deben hacer lo siguiente:

[C-0-1] DEBE devolver un valor no nulo para el método IdentityCredentialStore#getInstance().
[C-0-2] DEBE implementar el sistema de credenciales de identidad (p.ej., las APIs de android.security.identity.*) con código que se comunique con una aplicación de confianza en un área aislada de forma segura del código que se ejecuta en el kernel y por encima de él. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales por los que el código del kernel o del espacio de usuario podría acceder al estado interno del entorno aislado, incluido el DMA.
[C-0-3] Las operaciones criptográficas necesarias para implementar el sistema de credenciales de identidad (p.ej., las APIs de android.security.identity.*) DEBEN realizarse por completo en la aplicación de confianza, y el material de la clave privada NUNCA debe salir del entorno de ejecución aislado, a menos que las APIs de nivel superior lo requieran específicamente (p.ej., el método createEphemeralKeyPair()).
[C-0-4] La aplicación de confianza DEBE implementarse de manera tal que sus propiedades de seguridad no se vean afectadas (p.ej., los datos de credenciales no se liberan a menos que se cumplan las condiciones de control de acceso, no se pueden producir MAC para datos arbitrarios) incluso si Android se comporta de forma incorrecta o está comprometido.

9.12. Eliminación de Datos

Todas las implementaciones de dispositivos:

[C-0-1] DEBE proporcionar a los usuarios un mecanismo para realizar un "restablecimiento de la configuración de fábrica".
[C-0-2] DEBE borrar todos los datos del sistema de archivos userdata.
[C-0-3] DEBE borrar los datos de manera que satisfaga los estándares de la industria pertinentes, como NIST SP800-88.
[C-0-4] DEBE activar el proceso de "Restablecimiento de la configuración de fábrica" anterior cuando la app de controlador de política de dispositivo del usuario principal llame a la API de DevicePolicyManager.wipeData().
PUEDE proporcionar una opción de borrado rápido de datos que solo realice un borrado lógico de los datos.

9.13. Modo de inicio seguro

Android proporciona el modo seguro, que permite a los usuarios iniciar el dispositivo en un modo en el que solo se pueden ejecutar las apps del sistema preinstaladas y se inhabilitan todas las apps de terceros. Este modo, conocido como "Modo de arranque seguro", le permite al usuario desinstalar apps de terceros potencialmente dañinas.

Las implementaciones de dispositivos son las siguientes:

[SR] SE RECOMIENDA ENCARECIDAMENTE implementar el modo de inicio seguro.

Si las implementaciones de dispositivos implementan el modo de inicio seguro, deben hacer lo siguiente:

[C-1-1] DEBE proporcionar al usuario una opción para ingresar al modo seguro de forma tal que no se interrumpa desde las apps de terceros instaladas en el dispositivo, excepto cuando la app de terceros sea un controlador de políticas del dispositivo y haya establecido el parámetro UserManager.DISALLOW_SAFE_BOOT como verdadero.
[C-1-2] DEBE proporcionar al usuario la capacidad de desinstalar cualquier app de terceros en el modo seguro.
DEBE proporcionar al usuario una opción para ingresar al Modo de arranque seguro desde el menú de arranque con un flujo de trabajo diferente al de un arranque normal.

9.14. Aislamiento del sistema del vehículo automotriz

Se espera que los dispositivos Android Automotive intercambien datos con subsistemas críticos del vehículo a través de la HAL del vehículo para enviar y recibir mensajes a través de redes del vehículo, como el bus CAN.

El intercambio de datos se puede proteger implementando funciones de seguridad debajo de las capas del framework de Android para evitar la interacción maliciosa o no intencional con estos subsistemas.

9.15. Planes de suscripción

Los "planes de suscripción" hacen referencia a los detalles del plan de relación de facturación que proporciona un operador de telefonía celular a través de SubscriptionManager.setSubscriptionPlans().

Todas las implementaciones de dispositivos:

[C-0-1] DEBE devolver los planes de suscripción solo a la app del operador de telefonía celular que los proporcionó originalmente.
[C-0-2] NO DEBE crear copias de seguridad de forma remota ni subir planes de suscripción.
[C-0-3] SOLO DEBE permitir anulaciones, como SubscriptionManager.setSubscriptionOverrideCongested(), desde la app del operador de telefonía celular que actualmente proporciona planes de suscripción válidos.

9.16. Migración de datos de la aplicación

Si las implementaciones de dispositivos incluyen la capacidad de migrar datos de un dispositivo a otro y no limitan los datos de la aplicación que copian a lo que configuró el desarrollador de la aplicación en el manifiesto a través del atributo android:fullBackupContent, deben hacer lo siguiente:

[C-1-1] NO DEBE iniciar transferencias de datos de la aplicación desde dispositivos en los que el usuario no haya establecido una autenticación principal, como se describe en 9.11.1 Pantalla de bloqueo y autenticación seguras.
[C-1-2] DEBE confirmar de forma segura la autenticación principal en el dispositivo fuente y confirmar con el usuario la intención de copiar los datos en el dispositivo fuente antes de que se transfieran los datos.
[C-1-3] DEBE usar la certificación de llave de seguridad para garantizar que tanto el dispositivo de origen como el de destino en la migración de dispositivo a dispositivo sean dispositivos Android legítimos y tengan un bootloader bloqueado.
[C-1-4] SOLO SE DEBEN migrar los datos de la aplicación a la misma aplicación en el dispositivo de destino, con el mismo nombre de paquete Y certificado de firma.
[C-1-5] DEBE mostrar una indicación de que el dispositivo fuente migró datos a través de una migración de datos de un dispositivo a otro en el menú de configuración. El usuario NO DEBE poder quitar esta indicación.

10. Pruebas de compatibilidad de software

Las implementaciones de dispositivos DEBEN aprobar todas las pruebas que se describen en esta sección. Sin embargo, ten en cuenta que ningún paquete de pruebas de software es completamente integral. Por este motivo, se RECOMIENDA ENCARECIDAMENTE a los implementadores de dispositivos que realicen la menor cantidad posible de cambios en la implementación de referencia y preferida de Android disponible en Android Open Source Project. Esto minimizará el riesgo de introducir errores que creen incompatibilidades que requieran volver a trabajar y posibles actualizaciones del dispositivo.

10.1. Conjunto de pruebas de compatibilidad (CTS)

Implementaciones de dispositivos:

[C-0-1] DEBE aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el Proyecto de código abierto de Android, con el software final de envío en el dispositivo.
[C-0-2] DEBE garantizar la compatibilidad en casos de ambigüedad en el CTS y para cualquier reimplementación de partes del código fuente de referencia.

El CTS está diseñado para ejecutarse en un dispositivo real. Al igual que cualquier software, el CTS puede contener errores. El CTS tendrá versiones independientes de esta Definición de compatibilidad, y es posible que se lancen varias revisiones del CTS para Android 11.

Implementaciones de dispositivos:

[C-0-3] DEBE aprobar la versión más reciente del CTS disponible en el momento en que se complete el software del dispositivo.
DEBE usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible.

10.2. Verificador del CTS

El CTS Verifier se incluye en el Conjunto de pruebas de compatibilidad y está diseñado para que lo ejecute un operador humano para probar la funcionalidad que no puede probar un sistema automatizado, como el funcionamiento correcto de una cámara y los sensores.

Implementaciones de dispositivos:

[C-0-1] DEBE ejecutar correctamente todos los casos aplicables en el verificador de CTS.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluido hardware opcional.

Implementaciones de dispositivos:

[C-0-2] DEBE aprobar todas las pruebas del hardware que posee. Por ejemplo, si un dispositivo tiene un acelerómetro, DEBE ejecutar correctamente el caso de prueba del acelerómetro en el CTS Verifier.

Los casos de prueba para las funciones que se indican como opcionales en este documento de Definición de compatibilidad SE PUEDEN omitir.

[C-0-2] Cada dispositivo y cada compilación DEBEN ejecutar correctamente el CTS Verifier, como se indicó anteriormente. Sin embargo, dado que muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten explícitamente el CTS Verifier en compilaciones que solo difieran de manera trivial. Específicamente, las implementaciones de dispositivos que difieren de una implementación que aprobó el verificador del CTS solo por el conjunto de configuraciones regionales incluidas, la marca, etcétera, PUEDEN omitir la prueba del verificador del CTS.

11. Software actualizable

[C-0-1] Las implementaciones de dispositivos DEBEN incluir un mecanismo para reemplazar la totalidad del software del sistema. El mecanismo no necesita realizar actualizaciones “en vivo”, es decir, ES POSIBLE que se requiera un reinicio del dispositivo. Se puede usar cualquier método, siempre y cuando pueda reemplazar la totalidad del software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques satisfará este requisito:
- Descargas “inalámbricas (OTA)” con actualización sin conexión a través del reinicio.
- Actualizaciones “vinculadas” por USB desde una PC host
- Actualizaciones “sin conexión” a través de un reinicio y una actualización desde un archivo en un almacenamiento extraíble
[C-0-2] El mecanismo de actualización que se use DEBE admitir actualizaciones sin borrar los datos del usuario. Es decir, el mecanismo de actualización DEBE conservar los datos privados y los datos compartidos de la aplicación. Ten en cuenta que el software de Android upstream incluye un mecanismo de actualización que satisface este requisito.
[C-0-3] Toda la actualización DEBE estar firmada, y el mecanismo de actualización en el dispositivo DEBE verificar la actualización y la firma con una clave pública almacenada en el dispositivo.
[C-SR] Se RECOMIENDA ENCARECIDAMENTE que el mecanismo de firma genere un hash de la actualización con SHA-256 y valide el hash con la clave pública usando ECDSA NIST P-256.

Si las implementaciones del dispositivo incluyen compatibilidad con una conexión de datos sin medición, como el perfil 802.11 o PAN (red de área personal) de Bluetooth, entonces:

[C-1-1] DEBE admitir descargas OTA con actualización sin conexión a través del reinicio.

En el caso de las implementaciones de dispositivos que se lanzan con Android 6.0 y versiones posteriores, el mecanismo de actualización DEBE admitir la verificación de que la imagen del sistema es idéntica en términos binarios al resultado esperado después de una actualización OTA. La implementación de OTA basada en bloques en el Proyecto de código abierto de Android upstream, que se agregó desde Android 5.1, satisface este requisito.

Además, las implementaciones de dispositivos DEBEN admitir actualizaciones del sistema A/B. El AOSP implementa esta función con el HAL de control de arranque.

Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro de su vida útil razonable, que se determina en consulta con el equipo de compatibilidad de Android y que afecta la compatibilidad de las aplicaciones de terceros, se hará lo siguiente:

[C-2-1] El implementador del dispositivo DEBE corregir el error a través de una actualización de software disponible que se pueda aplicar según el mecanismo que se acaba de describir.

Android incluye funciones que permiten que la app de propietario del dispositivo (si está presente) controle la instalación de actualizaciones del sistema. Si el subsistema de actualización del sistema para dispositivos informa android.software.device_admin, entonces:

[C-3-1] DEBE implementar el comportamiento que se describe en la clase SystemUpdatePolicy.

12. Registro de cambios del documento

Para obtener un resumen de los cambios en la Definición de compatibilidad en esta versión, haz lo siguiente:

Registro de cambios del documento

A continuación, se incluye un resumen de los cambios en las secciones para individuos:

12.1. Sugerencias para ver el registro de cambios

Los cambios se marcan de la siguiente manera:

CDD
Cambios sustanciales en los requisitos de compatibilidad.
Documentos
Cambios cosméticos o relacionados con la compilación.

Para una mejor visualización, agrega los parámetros de URL pretty=full y no-merges a las URLs de tu registro de cambios.

13. Comunícate con nosotros

Puedes unirte al foro de compatibilidad con Android y solicitar aclaraciones o plantear cualquier problema que creas que el documento no aborda.

Definición de compatibilidad de Android 11 Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

1. Introducción

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

1.1.2. ID del requisito

1.1.3. ID de requisito en la sección 2

2. Tipos de dispositivos

2.1 Configuraciones del dispositivo

2.2. Requisitos para dispositivos portátiles

2.2.1. Hardware

2.2.2. Multimedia

2.2.3. Software

2.2.4. Rendimiento y potencia

2.2.5. Modelo de seguridad

2.2.6. Compatibilidad de las herramientas y opciones para desarrolladores

2.2.7 Clase de rendimiento del contenido multimedia manual

2.2.7.1. Contenido multimedia

2.2.7.2. Cámara

2.2.7.3. Hardware

2.2.7.4. Rendimiento

2.3. Requisitos de la televisión

2.3.1. Hardware

2.3.2. Multimedia

2.3.3. Software

2.3.4. Rendimiento y potencia

2.3.5. Modelo de seguridad

2.3.6. Compatibilidad de las herramientas y opciones para desarrolladores

2.4. Requisitos del reloj

2.4.1. Hardware

2.4.2. Multimedia

2.4.3. Software

2.4.4. Rendimiento y potencia

2.4.5. Modelo de seguridad

2.5. Requisitos para la industria automotriz

2.5.1. Hardware

2.5.2. Multimedia

2.5.3. Software

2.5.4. Rendimiento y potencia

2.5.5. Modelo de seguridad

2.5.6. Compatibilidad de las herramientas y opciones para desarrolladores

2.6. Requisitos de la tablet

2.6.1. Hardware

2.6.2. Modelo de seguridad

2.6.2. Software

3. Software

3.1. Compatibilidad de la API administrada

3.1.1. Extensiones de Android

3.1.2. Biblioteca de Android

3.2. Compatibilidad de API flexible

3.2.1. Permisos

3.2.2. Parámetros de compilación

3.2.3. Compatibilidad de intents

3.2.3.1. Intents de aplicaciones comunes

3.2.3.2. Resolución de intents

3.2.3.3. Espacios de nombres de intents

3.2.3.4. Intents de transmisión

3.2.3.5. Intents de la aplicación condicionales

3.2.4. Actividades en pantallas secundarias o múltiples

3.3. Compatibilidad con la API nativa

3.3.1. Interfaces binarias de aplicaciones

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

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

3.4.2. Compatibilidad del navegador

3.5. Compatibilidad de comportamiento de la API

3.5.1. Restricción de la aplicación

3.6. Espacios de nombres de la API

3.7. Compatibilidad con el entorno de ejecución

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Selector (pantalla principal)

3.8.2. Widgets

3.8.3. Notificaciones

3.8.3.1. Presentación de notificaciones

3.8.3.2. Servicio de detección de notificaciones

3.8.3.3. DND (No interrumpir)

3.8.4. Buscar

3.8.5. Alertas y mensajes Toast

3.8.6. Temas

3.8.7. Fondos de pantalla animados

3.8.8. Cambio de actividad

Definición de compatibilidad de Android 11