Definición de compatibilidad de Android 8.1

1. Introducción

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

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

Como se usa en este documento, un “implementador de dispositivos” o “implementador” es una persona u organización que desarrolla una solución de hardware o software con Android 8.1. Una “implementación de dispositivo” o “implementación de dispositivo” es la solución de hardware/software tan desarrollada.

Para que se consideren compatibles con Android 8.1, las implementaciones en dispositivos 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 son silenciosas, ambiguas o incompletas, es responsabilidad del implementador de dispositivos garantizar la compatibilidad con las implementaciones existentes.

Por este motivo, el Proyecto de código abierto de Android es la referencia y la implementación preferida de Android. Se recomienda que los implementadores de dispositivos basen sus implementaciones en la mayor medida posible en el código fuente “ascendente” disponible en el Proyecto de código abierto de Android. Si bien algunos componentes pueden reemplazarse hipotéticamente con implementaciones alternativas, es SEGURO RECOMENDADO no seguir esta práctica, ya que pasar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluida y más allá del Conjunto de pruebas de compatibilidad. Por último, ten en cuenta que en este documento se prohíben explícitamente algunas sustituciones y modificaciones de componentes.

Muchos de los recursos vinculados en este documento derivan directa o indirectamente del SDK de Android y serán funcionalmente idénticos a la información de la documentación de dicho SDK. En los casos en los que esta definición de compatibilidad o el Conjunto de pruebas de compatibilidad no estén de acuerdo con la documentación del SDK, la documentación del SDK se considera confiable. Cualquier detalle técnico que se proporcione en los recursos vinculados en este documento se considerará 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 DEBEN y ESPECIAMENTE RECOMENDADOS que se aplican a un tipo de dispositivo específico. Cada subsección de la Sección 2 está dedicada a un tipo de dispositivo específico.

Todos los demás requisitos, que se aplican universalmente a cualquier implementación de dispositivos Android, se enumeran en las secciones posteriores a la Sección 2. Estos requisitos se mencionan como “Requisitos principales” en este documento.

1.1.2. ID de requisito

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

  • El ID se asigna solo para los requisitos MUST.
  • Los requisitos ESPECIAMENTE RECOMENDADOS se marcan como [SR], pero no se asigna el ID.
  • El ID se compone de lo siguiente : Device Type ID - Condition ID - Requirement ID (p.ej., C-0-1).

Cada ID se define de la siguiente manera:

  • ID del tipo de dispositivo (obtén más información en 2. Tipos de dispositivo
    • C: Core (requisitos que se aplican a cualquier implementación de dispositivos Android)
    • H: Dispositivo de mano Android
    • T: dispositivo de televisión Android
    • A: Implementación de Android Automotive
  • 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 1a condición, y el número se incrementa en 1 dentro de la misma sección y el mismo tipo de dispositivo.
  • ID de requisito
    • Este ID comienza desde 1 y aumenta de a 1 dentro de la misma sección y la misma condición.

2. Tipos de dispositivo

Si bien el Proyecto de código abierto de Android proporciona una pila de software que puede usarse para una variedad de tipos de dispositivos y factores de forma, hay algunos tipos de dispositivos que tienen un ecosistema de distribución de aplicaciones establecido relativamente mejor.

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 ajustan 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 por tipo de dispositivo, consulta los requisitos específicos de cada dispositivo que se incluyen a continuación en esta sección.

2.2. Requisitos para dispositivos portátiles

Un dispositivo de mano Android hace referencia a una implementación en un dispositivo Android que, por lo general, se usa al sostenerlo en la mano, como un reproductor de mp3, un teléfono o una tablet.

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

  • Tener una fuente de alimentación que brinde movilidad, como una batería
  • Tener un tamaño de pantalla diagonal físico de entre 2.5 y 8 pulgadas

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

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

2.2.1. Hardware

Tamaño de pantalla (sección 7.1.1.1)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE tener una pantalla de al menos 2.5 pulgadas de tamaño diagonal físico.*

Densidad de la pantalla (sección 7.1.1.3)

Implementaciones en dispositivos de mano:

  • [H-SR] SE RECOMIENDA ENcarecidamente que les ofrezcan a los usuarios una indicación para cambiar el tamaño de visualización.

Modo de compatibilidad de aplicaciones heredado (sección 7.1.5)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE incluir compatibilidad con el modo de compatibilidad de aplicaciones heredadas, tal como lo implementa el código fuente abierto de Android ascendente. Es decir, las implementaciones en dispositivos NO DEBEN alterar los activadores o umbrales en los que se activa el modo de compatibilidad, ni el comportamiento del modo de compatibilidad en sí.

Teclado (sección 7.2.1)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE incluir compatibilidad con aplicaciones de terceros del Editor de método de entrada (IME).

Teclas de navegación (sección 7.2.3)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE proporcionar las funciones Inicio, Recientes y Atrás.

  • [H-0-2] SE DEBE enviar el evento de presión normal y de mantener presionado de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.

Entrada de la pantalla táctil (sección 7.2.4)

Implementaciones en dispositivos de mano:

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

Acelerómetro (sección 7.3.1)

Implementaciones en dispositivos de mano:

  • [H-SR] SE RECOMIENDA COMPLETAMENTE incluir un acelerómetro de 3 ejes.

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

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

Giroscopio (Sección 7.3.4)

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

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

Sensor de proximidad (sección 7.3.8)

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

  • SE DEBE incluir un sensor de proximidad.

Sensor de postura (sección 7.3.12)

Implementaciones en dispositivos de mano:

  • SE RECOMIENDA que admitan un sensor de poses con 6 grados de libertad.

Bluetooth (Artículo 7.4.3)

Implementaciones en dispositivos de mano:

  • SE DEBE incluir compatibilidad con Bluetooth y Bluetooth LE.

Ahorro de datos (sección 7.4.7)

Si las implementaciones de dispositivos de mano incluyen una conexión de uso medido, sucederá lo siguiente:

  • [H-1-1] SE DEBE proporcionar el modo de Ahorro de datos.

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

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

  • [H-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 416 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta qHD (p.ej., FWVGA).

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

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

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

Si las implementaciones de dispositivos de mano declaran compatibilidad con ABI de 32 y 64 bits:

  • [H-5-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 816 MB si la pantalla predeterminada usa resoluciones de búfer de fotogramas de hasta qHD (p.ej., FWVGA).

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

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

  • [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" mencionada anteriormente hace referencia al espacio de memoria proporcionado además de cualquier memoria que ya esté dedicada a componentes de hardware, como radio, video, etc., que no estén bajo el control del kernel en las implementaciones en dispositivos.

Si las implementaciones para dispositivos de mano incluyen 1 GB de memoria disponible para el kernel y el espacio del usuario igual o inferior, deben hacer lo siguiente:

  • [H-9-1] SE DEBE declarar la marca de función android.hardware.ram.low.
  • [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 de mano incluyen más de 1 GB de memoria disponible para el kernel y el espacio del usuario, deben hacer lo siguiente:

  • [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”).
  • SE DEBE declarar la marca de función android.hardware.ram.normal.

Almacenamiento compartido de la aplicación (Sección 7.6.2)

Implementaciones en dispositivos de mano:

  • [H-0-1] NO DEBE proporcionar un almacenamiento compartido de la aplicación de menos de 1 GiB.

Modo periférico USB (sección 7.7.1)

Implementaciones en dispositivos de mano:

  • SE RECOMIENDA incluir un puerto USB que admita el modo periférico.

Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con el modo periférico, sucederá lo siguiente:

  • [H-1-1] SE DEBE implementar la API de Android Open Accessory (AOA).*

Micrófono (Sección 7.8.1)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE incluir un micrófono.

Salida de audio (sección 7.8.2)

Implementaciones en dispositivos de mano:

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

Modo de realidad virtual (sección 7.9.1)

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

  • [H-1-1] SE DEBE declarar la función android.software.vr.mode.*

Si las implementaciones de dispositivos declaran la función android.software.vr.mode, hará lo siguiente:

  • [H-2-1] DEBE incluir una aplicación que implemente android.service.vr.VrListenerService que las aplicaciones de RV puedan habilitar a través de android.app.Activity#setVrModeEnabled.*

Realidad virtual con alto rendimiento (Artículo 7.9.2)

Si las implementaciones de dispositivos de mano pueden cumplir con todos los requisitos para declarar la marca de función android.hardware.vr.high_performance, deben cumplir con lo siguiente:

  • [H-1-1] SE DEBE declarar la marca de función android.hardware.vr.high_performance.*

2.2.2. Multimedia

Codificación de audio (Sección 5.1.1)

Las implementaciones en dispositivos portátiles DEBEN admitir la siguiente codificación de audio:

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

Decodificación de audio (Sección 5.1.2)

Las implementaciones en dispositivos portátiles DEBEN admitir la siguiente decodificación de audio:

  • [H-0-1] AMR-NB
  • [H-0-2] AMR-WB

Codificación de video (Sección 5.2)

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

  • [H-0-1] H.264 AVC
  • [H-0-2] Vp8

Decodificación de video (Sección 5.3)

Las implementaciones en dispositivos portátiles DEBEN admitir la siguiente decodificación de video:

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

2.2.3. Software

Compatibilidad con WebView (sección 3.4.1)

Implementaciones en dispositivos de mano:

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

Compatibilidad con navegadores (Sección 3.4.2)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE incluir una aplicación de Navegador independiente para la navegación web de los usuarios en general.

Selector (Sección 3.8.1)

Implementaciones en dispositivos de mano:

  • [H-SR] SE RECOMIENDA COMPLETAMENTE implementar un selector predeterminado que admita la fijación de combinaciones de teclas y widgets en la app.

  • [H-SR] SE RECOMIENDA ENERCMENTE implementar un selector predeterminado que proporcione acceso rápido a las combinaciones de teclas adicionales que proporcionan las apps de terceros a través de la API de shortManager.

  • [H-SR] SE RECOMIENDA ENERCMENTE incluir una app de selector predeterminada que muestre insignias para los íconos de las apps.

Widgets (Sección 3.8.2)

Implementaciones en dispositivos de mano:

  • [H-SR] SE RECOMIENDA ENERGENTE para admitir widgets de apps de terceros.

Notificaciones (Sección 3.8.3)

Implementaciones en dispositivos de mano:

  • [H-0-1] DEBE permitir que las apps de terceros notifiquen a los usuarios sobre eventos notables a través de las clases de API Notification y NotificationManager.
  • [H-0-2] DEBE admitir notificaciones enriquecidas.
  • [H-0-3] DEBE admitir notificaciones de atención.
  • [H-0-4] DEBE incluir un panel de notificaciones que le permita al usuario controlar directamente (por ejemplo, responder, posponer, descartar o bloquear) las notificaciones a través de la indicación visual del usuario, como los botones de acción o el panel de control, como se implementa en el AOSP.

Búsqueda (sección 3.8.4)

Implementaciones en dispositivos de mano:

  • [H-SR] SE RECOMIENDA ENERCMENTE implementar un asistente en el dispositivo para realizar la acción de asistencia.

Control de contenido multimedia en la pantalla de bloqueo (sección 3.8.10)

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

  • [H-1-1] SE DEBE mostrar las notificaciones de la pantalla bloqueada, incluida la plantilla de notificaciones multimedia.

Administración de dispositivos (sección 3.9)

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

Accesibilidad (sección 3.10)

Implementaciones en dispositivos de mano:

  • [H-SR] DEBE admitir servicios de accesibilidad de terceros.

  • [H-SR] SE RECOMIENDA EJECUTARMENTE que precarguen los servicios de accesibilidad en el dispositivo con funciones similares o superiores a las de la Accesibilidad con interruptores y los servicios de accesibilidad de TalkBack (para los idiomas compatibles con el motor de texto a voz precargado) como se proporciona en el proyecto de código abierto de TalkBack.

Text‐to‐Speech (Artículo 3.11)

Implementaciones en dispositivos de mano:

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

  • [H-SR] SE RECOMIENDA INTENSIFICAMENTE que incluyan un motor de TTS compatible con los idiomas disponibles en el dispositivo.

Configuración rápida (Sección 3.13)

Implementaciones en dispositivos de mano:

  • [H-SR] SE RECOMIENDA IMPORTANTE incluir un componente de IU de Configuración rápida.

Vinculación de dispositivos complementarios (sección 3.15)

Si las implementaciones de dispositivos de mano Android declaran compatibilidad con FEATURE_BLUETOOTH o FEATURE_WIFI, harán lo siguiente:

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

2.2.4. Rendimiento y potencia

Coherencia de la experiencia del usuario (sección 8.1)

Para implementaciones en dispositivos de mano:

  • [H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas no es uniforme o un retraso en la renderización de fotogramas NO DEBE tener una frecuencia superior a 5 fotogramas por segundo, y SE DEBE ser inferior a 1 fotograma en un segundo.
  • [H-0-2] Latencia de la interfaz de usuario. Las implementaciones del dispositivo DEBEN garantizar una experiencia del usuario de baja latencia desplazando 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 segundos.
  • [H-0-3] Cambio de tareas. Cuando se han iniciado varias aplicaciones, volver a iniciar una aplicación que ya está en ejecución DEBE tardar menos de 1 segundo.

Rendimiento del acceso a E/S de archivos (Sección 8.2)

Implementaciones en dispositivos de mano:

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

Modos de ahorro de energía (sección 8.3)

Para implementaciones en dispositivos de mano:

  • [H-0-1] Todas las apps exentas de los modos de ahorro de energía App Standby y Descanso DEBEN ser visibles para el usuario final.
  • [H-0-2] Los algoritmos de activación, mantenimiento y activación, y el uso de la configuración global del sistema de los modos de ahorro de energía App Standby y Descanso no DEBEN desviarse del Proyecto de código abierto de Android.

Contabilidad del consumo de energía (artículos 8.4)

Implementaciones en dispositivos de mano:

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

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

2.2.5. Modelo de seguridad

Permisos (secciones 9.1)

Implementaciones en dispositivos de mano:

  • [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 otorgue o revoque el acceso a esas apps en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

2.3. Requisitos de televisión

Un dispositivo de televisión Android hace referencia a una implementación de dispositivo Android que es una interfaz de entretenimiento que permite consumir contenido multimedia digital, películas, juegos, apps y TV en vivo para usuarios que están sentados a unos tres metros de distancia (una “interfaz de usuario inclinada” o “interfaz de usuario de 10 pies”).

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

  • Proporcionaron un mecanismo para controlar de forma remota la interfaz de usuario renderizada en la pantalla, que podría ubicarse a 3 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 incluyen en el resto de esta sección son específicos para las implementaciones en dispositivos de Android Television.

2.3.1. Hardware

Navegación no táctil (Sección 7.2.2)

Implementaciones de dispositivos de televisión:

Teclas de navegación (sección 7.2.3)

Implementaciones de dispositivos de televisión:

  • [T-0-1] DEBE proporcionar las funciones Home y Back.
  • [T-0-2] SE DEBE enviar el evento de presión normal y de mantener presionado de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.

Asignaciones de botones (sección 7.2.6.1)

Implementaciones de dispositivos de televisión:

  • [T-0-1] DEBE incluir compatibilidad con controles de juegos y declarar la marca de función android.hardware.gamepad.

Control remoto (sección 7.2.7)

Implementaciones de dispositivos de televisión:

Giroscopio (Sección 7.3.4)

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

  • [T-1-1] SE DEBE poder informar eventos con una frecuencia de al menos 100 Hz.

Bluetooth (Artículo 7.4.3)

Implementaciones de dispositivos de televisión:

  • [T-0-1] DEBE ser compatible con Bluetooth y Bluetooth LE.

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

Implementaciones de dispositivos de televisión:

  • [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”)
  • [T-0-2] SE DEBE mostrar “true” para ActivityManager.isLowRamDevice() cuando hay menos de 1 GB de memoria disponible para el kernel y el espacio de usuario.

Micrófono (Sección 7.8.1)

Implementaciones de dispositivos de televisión:

  • SE DEBE incluir un micrófono.

Salida de audio (sección 7.8.2)

Implementaciones de dispositivos de televisión:

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

2.3.2. Multimedia

Codificación de audio (Sección 5.1)

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

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

Codificación de video (Sección 5.2)

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

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

H-264 (Sección 5.2.2)

Las implementaciones de dispositivos de televisión son las siguientes:

  • [T-SR] SE RECOMIENDA ENRENDER que sea compatible con la codificación H.264 de videos con resoluciones de 720p y 1080p.
  • [T-SR] SE RECOMIENDA ENRENDER que sea compatible con la codificación H.264 de videos con resolución de 1080p a 30 fotogramas por segundo (FPS).

Decodificación de video (Sección 5.3)

Las implementaciones en dispositivos de televisión DEBEN admitir la siguiente decodificación de video:

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

Se RECOMIENDA ELEGIR implementaciones en dispositivos de televisión para admitir la siguiente decodificación de video:

  • [T-SR] MPEG-2

H.264 (Sección 5.3.4)

Si las implementaciones de dispositivos de televisión admiten decodificadores H.264, sucederá lo siguiente:

  • [T-1-1] DEBE ser compatible con el nivel de perfil alto 4.2 y el perfil de decodificación HD de 1080p (a 60 fps).
  • [T-1-2] SE DEBE poder decodificar videos con ambos perfiles HD, como se indica en la siguiente tabla, y codificados con el perfil de Baseline, el perfil principal o el nivel de perfil alto 4.2.

H.265 (HEVC) (Artículo 5.3.5)

Si las implementaciones de dispositivos de televisión admiten el códec H.265 y el perfil de decodificación HD 1080p, sucederá lo siguiente:

  • [T-1-1] DEBE admitir el perfil principal nivel 4.1.
  • [T-SR] SE RECOMIENDA ENERGENTE para admitir una velocidad de fotogramas de video de 60 FPS en HD de 1080p.

Si las implementaciones de dispositivos de televisión admiten el códec H.265 y el perfil de decodificación UHD, entonces:

  • [T-2-1] El códec DEBE admitir el perfil de nivel principal de Main10 de nivel 5.

VP8 (sección 5.3.6)

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

  • [T-1-1] DEBE admitir el perfil de decodificación HD 1080p60.

Si las implementaciones de dispositivos de televisión admiten el códec VP8 y la resolución 720p, deben hacer lo siguiente:

  • [T-2-1] DEBE admitir el perfil de decodificación HD 720p60.

VP9 (sección 5.3.7)

Si las implementaciones de dispositivos de televisión admiten el códec VP9 y la decodificación de video UHD, sucederá lo siguiente:

  • [T-1-1] DEBE admitir profundidad de color de 8 bits y SE DEBE admitir el perfil 2 de VP9 (10 bits).

Si las implementaciones de dispositivos de televisión admiten el códec VP9, el perfil de 1080p y la decodificación por hardware de VP9, harán lo siguiente:

  • [T-2-1] DEBE admitir 60 fps para 1080p.

Secure Media (Sección 5.8)

Si las implementaciones de dispositivos son dispositivos Android Television y admiten la resolución 4K, deberán hacer lo siguiente:

  • [T-1-1] DEBE ser compatible con HDCP 2.2 para todas las pantallas externas con cable.

Si las implementaciones de dispositivos de televisión no admiten la resolución 4K, sucederá lo siguiente:

  • [T-2-1] DEBE ser compatible con HDCP 1.4 para todas las pantallas externas con cable.

Implementaciones de dispositivos de televisión:

  • [T-SR] SE RECOMIENDA ENERCMENTE para admitir la decodificación simultánea de transmisiones seguras. Como mínimo, SE RECOMIENDA COMPLEMENTE la decodificación simultánea de dos flujos.

Volumen de salida de audio (Sección 5.5.3)

Implementaciones de dispositivos de televisión:

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

2.3.3. Software

Implementaciones de dispositivos de televisión:

Compatibilidad con WebView (sección 3.4.1)

Implementaciones de dispositivos de televisión:

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

Control de contenido multimedia en la pantalla de bloqueo (sección 3.8.10)

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

  • [T-1-1] SE DEBE mostrar las notificaciones de la pantalla bloqueada, incluida la plantilla de notificaciones multimedia.

Multiventana (Sección 3.8.14)

Implementaciones de dispositivos de televisión:

  • [T-SR] SE RECOMIENDA ENERGENTE para admitir el modo de pantalla en pantalla (PIP) multiventana.

Accesibilidad (sección 3.10)

Implementaciones de dispositivos de televisión:

  • [T-SR] DEBE admitir servicios de accesibilidad de terceros.

  • [T-SR] Se RECOMIENDA que las implementaciones de dispositivos de Android Television precarguen los servicios de accesibilidad en el dispositivo de manera similar a la funcionalidad de la Accesibilidad con interruptores y de TalkBack (para idiomas compatibles con el motor de texto a voz precargado) o que las superen, tal como se proporciona en el proyecto de código abierto de TalkBack.

Text‐to‐Speech (Artículo 3.11)

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

  • [T-SR] SE RECOMIENDA INCREÍBLEMENTE incluir un motor de TTS compatible con los idiomas disponibles en el dispositivo.

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

Marco de trabajo de entrada de TV (sección 3.12)

Implementaciones de dispositivos de televisión:

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

2.2.4. Rendimiento y potencia

Coherencia de la experiencia del usuario (sección 8.1)

Para implementaciones en dispositivos de televisión:

  • [T-0-1] Latencia de fotogramas coherente. La latencia de fotogramas no es uniforme o un retraso en la renderización de fotogramas NO DEBE tener una frecuencia superior a 5 fotogramas por segundo, y SE DEBE ser inferior a 1 fotograma en un segundo.

Rendimiento del acceso a E/S de archivos (Sección 8.2)

Implementaciones de dispositivos de televisión:

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

Modos de ahorro de energía (sección 8.3)

Para implementaciones en dispositivos de televisión:

  • [T-0-1] Todas las apps exentas de los modos de ahorro de energía App Standby y Descanso DEBEN ser visibles para el usuario final.
  • [T-0-2] Los algoritmos de activación, mantenimiento y activación, y el uso de la configuración global del sistema de los modos de ahorro de energía App Standby y Descanso no DEBEN desviarse del Proyecto de código abierto de Android.

Contabilidad del consumo de energía (artículos 8.4)

Implementaciones de dispositivos de televisión:

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

2.4. Requisitos para el reloj

El término dispositivo Android Watch hace referencia a la implementación de dispositivos Android para llevar en el cuerpo, por ejemplo, en la muñeca.

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

  • Asegúrate de tener una pantalla con una longitud diagonal física de entre 1.1 y 2.5 pulgadas.
  • Tienen un mecanismo proporcionado para su uso en el cuerpo.

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

2.4.1. Hardware

Tamaño de pantalla (sección 7.1.1.1)

Implementaciones de dispositivos de reloj:

  • [W-0-1] DEBE tener una pantalla con un tamaño diagonal físico de entre 1.1 y 2.5 pulgadas.

Teclas de navegación (sección 7.2.3)

Implementaciones de dispositivos de reloj:

  • [W-0-1] DEBE tener la función de inicio disponible para el usuario y la función de retroceso, excepto cuando se encuentra en UI_MODE_TYPE_WATCH.

Entrada de la pantalla táctil (sección 7.2.4)

Implementaciones de dispositivos de reloj:

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

Acelerómetro (sección 7.3.1)

Implementaciones de dispositivos de reloj:

  • [W-SR] SE RECOMIENDA COMPLETAMENTE incluir un acelerómetro de 3 ejes.

Bluetooth (Artículo 7.4.3)

Implementaciones de dispositivos de reloj:

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

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

Implementaciones de dispositivos de reloj:

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

Micrófono (Sección 7.8.1)

Implementaciones de dispositivos de reloj:

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

Salida de audio (sección 7.8.1)

Implementaciones de dispositivos de reloj:

  • PUEDE, pero NO DEBE tener salida de audio.

2.4.2. Multimedia

Sin requisitos adicionales.

2.4.3. Software

Implementaciones de dispositivos de reloj:

  • [W-0-1] SE DEBE declarar la función android.hardware.type.watch.
  • [W-0-2] DEBE admitir uiMode = UI_MODE_TYPE_WATCH.

Búsqueda (sección 3.8.4)

Implementaciones de dispositivos de reloj:

  • [W-SR] SE RECOMIENDA ENcarecidamente implementar un asistente en el dispositivo para realizar la acción de asistencia.

Accesibilidad (sección 3.10)

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

  • [W-1-1] DEBE admitir servicios de accesibilidad de terceros.

  • [W-SR] SE RECOMIENDA EJECUTARMENTE que precarguen los servicios de accesibilidad en el dispositivo con funciones similares o superiores a las de la Accesibilidad con interruptores y los servicios de accesibilidad de TalkBack (para idiomas compatibles con el motor de texto a voz precargado) como se proporciona en el proyecto de código abierto de TalkBack.

Text‐to‐Speech (Artículo 3.11)

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

  • [W-SR] SE RECOMIENDA INTENSIFICAMENTE que incluyan un motor de TTS compatible con los idiomas disponibles en el dispositivo.

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

2.5 Requisitos de la industria automotriz

La implementación de Android Automotive hace referencia a la consola central de un vehículo que ejecuta Android como sistema operativo para una parte o la totalidad del sistema o la funcionalidad de infoentretenimiento.

Las implementaciones en dispositivos Android se clasifican como Automotive si declaran la función android.hardware.type.automotive o cumplen con todos los siguientes criterios.

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

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

2.5.1. Hardware

Tamaño de pantalla (sección 7.1.1.1)

Implementaciones en dispositivos de Automotive:

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

Teclas de navegación (sección 7.2.3)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE proporcionar la función Inicio y PUEDE proporcionar las funciones Atrás y Recientes.
  • [A-0-2] SE DEBE enviar el evento de presión normal y de mantener presionado de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.

Acelerómetro (sección 7.3.1)

Implementaciones en dispositivos de Automotive:

  • [A-SR] SE RECOMIENDA ENERCMENTE incluir un acelerómetro de 3 ejes.

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

GPS (Artículo 7.3.3)

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

  • [A-1-1] La generación de tecnología de GNSS DEBE ser del año "2017" o posterior.

Giroscopio (Sección 7.3.4)

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

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

Sensores solo de Android Automotive (sección 7.3.11) Current Gear (sección 7.3.11.1)

Implementaciones en dispositivos de Automotive:

  • SE DEBE proporcionar el equipo actual como SENSOR_TYPE_GEAR.

Modo nocturno diurno (sección 7.3.11.2)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE admitir el modo diurno/nocturno definido como SENSOR_TYPE_NIGHT.
  • [A-0-2] El valor de la marca SENSOR_TYPE_NIGHT DEBE ser coherente con el modo diurno/nocturno del panel y SE DEBE basarse en la entrada del sensor de luz ambiente.
  • Es posible que el sensor de luz ambiente subyacente sea el mismo que el Fotómetro.

Estado de conducción (sección 7.3.11.3)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE admitir el estado de conducción definido como SENSOR_TYPE_DRIVING_STATUS, con un valor predeterminado de DRIVE_STATUS_UNRESTRICTED cuando el vehículo está completamente detenido y estacionado. Es responsabilidad de los fabricantes de dispositivos configurar SENSOR_TYPE_DRIVING_STATUS de acuerdo con todas las leyes y reglamentaciones que se aplican a los mercados a los que se envía el producto.

Velocidad de las ruedas (sección 7.3.11.4)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE proporcionar la velocidad del vehículo definida como SENSOR_TYPE_CAR_SPEED.

Bluetooth (Artículo 7.4.3)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE ser compatible con Bluetooth y DEBE admitir Bluetooth LE.

  • [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).
    • Uso compartido de contactos mediante el perfil de acceso a la agenda telefónica (PBAP)
  • SE DEBE admitir el perfil de acceso a mensajes (MAP).

Capacidad mínima de red (Artículo 7.4.5)

Implementaciones en dispositivos de Automotive:

  • Se DEBE incluir compatibilidad con la conectividad de datos basada en la red móvil.

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

Implementaciones en dispositivos de Automotive:

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

Modo periférico USB (sección 7.7.1)

Implementaciones en dispositivos de Automotive:

  • SE RECOMIENDA incluir un puerto USB que admita el modo periférico.

Micrófono (Sección 7.8.1)

Implementaciones en dispositivos de Automotive:

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

Salida de audio (sección 7.8.2)

Implementaciones en dispositivos de Automotive:

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

2.5.2. Multimedia

Codificación de audio (Sección 5.1)

Las implementaciones en dispositivos de Automotive DEBEN admitir la siguiente codificación de audio:

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

Codificación de video (Sección 5.2)

Las implementaciones en dispositivos de Automotive DEBEN admitir la siguiente codificación de video:

  • [A-0-1] H.264 AVC
  • [A-0-2] VCP8

Decodificación de video (Sección 5.3)

Las implementaciones en dispositivos de Automotive DEBEN admitir la siguiente decodificación de video:

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

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

  • [A-SR] H.265 HEVC

2.5.3. Software

Implementaciones en dispositivos de Automotive:

  • [A-0-1] SE DEBE declarar la función android.hardware.type.automotive.
  • [A-0-2] DEBE admitir uiMode = UI_MODE_TYPE_CAR.
  • [A-0-3] Las implementaciones de Android Automotive DEBEN admitir todas las APIs públicas en el espacio de nombres android.car.*.

Compatibilidad con WebView (sección 3.4.1)

Implementaciones en dispositivos de Automotive:

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

Notificaciones (Sección 3.8.3)

Implementaciones en dispositivos Android Automotive:

  • [A-0-1] DEBE mostrar notificaciones que usen la API de Notification.CarExtender cuando lo soliciten aplicaciones de terceros.

Búsqueda (sección 3.8.4)

Implementaciones en dispositivos de Automotive:

IU de contenido multimedia (sección 3.14)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE incluir un framework de IU para admitir apps de terceros usando las APIs de contenido multimedia, como se describe en la sección 3.14.

2.2.4. Rendimiento y potencia

Modos de ahorro de energía (sección 8.3)

Para implementaciones en dispositivos de Automotive:

  • [A-0-1] Todas las apps exentas de los modos de ahorro de energía App Standby y Descanso DEBEN ser visibles para el usuario final.
  • [A-0-2] Los algoritmos de activación, mantenimiento y activación, y el uso de la configuración global del sistema de los modos de ahorro de energía App Standby y Descanso no DEBEN desviarse del Proyecto de código abierto de Android.

Contabilidad del consumo de energía (artículos 8.4)

Implementaciones en dispositivos de Automotive:

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

2.2.5. Modelo de seguridad

Asistencia para varios usuarios (Artículo 9.5)

Si las implementaciones en dispositivos de Automotive incluyen varios usuarios, deben hacer lo siguiente:

  • [A-1-1] DEBE incluir una cuenta de invitado que permita todas las funciones proporcionadas por el sistema del vehículo sin que el usuario tenga que acceder.

Aislamiento del sistema de vehículos autónomos (Artículo 9.14)

Implementaciones en dispositivos de Automotive:

  • [A-0-1] DEBE mantener los mensajes de los subsistemas del vehículo del framework de Android, p.ej., incluir en la lista de entidades permitidas los tipos de mensajes permitidos y las fuentes de mensajes.
  • [A-0-2] DEBE Supervisar los ataques de denegación del servicio del framework de Android o las apps de terceros. Esto brinda protección contra software malicioso que inunda de tráfico la red del vehículo, lo que puede provocar el mal funcionamiento de los subsistemas del vehículo.

2.6. Requisitos de las tabletas

Un dispositivo Android Tablet hace referencia a una implementación de dispositivo Android que generalmente se usa con ambas manos y no en un factor de forma convencional.

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

  • Tener una fuente de alimentación que brinde movilidad, como una batería
  • Tener un tamaño de pantalla diagonal físico de entre 7 y 18 pulgadas

Las implementaciones en dispositivos de tablets tienen requisitos similares a las implementaciones en dispositivos de mano. Las excepciones se indican con un * en esa sección y se indican a modo de referencia en esta sección.

2.4.1. Hardware

Tamaño de pantalla (sección 7.1.1.1)

Implementaciones en tablets:

  • [Ta-0-1] DEBE tener una pantalla en un rango de entre 7 y 18 pulgadas.

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

Las densidades de pantalla que se indican para las pantallas pequeñas/normales en los requisitos para dispositivos portátiles no se aplican a las tablets.

Modo periférico USB (sección 7.7.1)

Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con el modo periférico, sucederá lo siguiente:

  • PUEDES implementar la API de Android Open Accessory (AOA).

Modo de realidad virtual (sección 7.9.1)

Realidad virtual con alto rendimiento (Artículo 7.9.2)

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

3. Software

3.1. Compatibilidad con APIs administradas

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

  • [C-0-1] Las implementaciones en dispositivos DEBEN 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 ascendente de Android.

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

  • [C-0-3] Las implementaciones del dispositivo NO DEBEN omitir ninguna API administrada, alterar las interfaces o firmas de las APIs, desviarse del comportamiento documentado ni incluir no-ops, salvo que esta definición de compatibilidad lo permita específicamente.

  • [C-0-4] Las implementaciones en dispositivos DEBEN mantener las APIs presentes y comportarse de manera razonable, incluso cuando se omitan algunas funciones de hardware para las cuales Android incluye APIs. Consulta la sección 7 para conocer los requisitos específicos para esta situación.

3.1.1. Extensiones de Android

Android incluye la posibilidad de extender las APIs administradas y de mantener la misma versión de nivel de API.

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

3.2. Compatibilidad con la API de Soft

Además de las APIs administradas de la sección 3.1, Android también incluye una API “secundaria” significativa de solo tiempo de ejecución, en forma de intents, permisos y aspectos similares de 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 según lo documentado en la página de referencia de permisos. Ten en cuenta que en la sección 9 se mencionan requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de compilación

Las APIs de Android incluyen una serie de constantes en la clase android.os.Build que están pensadas para 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 que DEBEN cumplir las implementaciones de dispositivos.
Parámetro Detalles
VERSION.LANZAMIENTO Es la versión del sistema Android en ejecución actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en el archivo 8.1.
VERSION.SDK Es la versión del sistema Android en ejecución actualmente, en un formato accesible para el código de la aplicación de terceros. Para Android 8.1, este campo DEBE tener el valor entero 8.1_INT.
VERSION.SDK_INT Es la versión del sistema Android en ejecución actualmente, en un formato accesible para el código de la aplicación de terceros. Para Android 8.1, este campo DEBE tener el valor entero 8.1_INT.
VERSION.INCREMENTAL Es un valor elegido por el implementador de dispositivos que designa la compilación específica del sistema Android en ejecución actualmente, en un formato legible por humanos. Este valor NO SE DEBE volver a usar en diferentes compilaciones que se ponen a disposición de los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de origen se usó para generar la compilación. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
JUEGOS DE MESA Es un valor que elige el implementador del dispositivo para identificar el hardware interno específico que utiliza el dispositivo, en un formato legible por humanos. Este campo puede usarse para indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SEGURIDAD Un valor que refleja el nombre de la marca asociada con el dispositivo, como lo conocen los usuarios finales. DEBE tener un formato legible por humanos y DEBERÍA representar al fabricante del dispositivo o a la marca de la empresa con la que se comercializa el dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ABIS_COMPATIBLES Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABIS_COMPATIBLES_32_BIT Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABIS_COMPATIBLES_64_BIT Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABI_de_CPU Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
ABI2 de CPU Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad de API nativa.
DISPOSITIVO Es un valor elegido por el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno que identifica la configuración de las características del hardware y el diseño industrial del dispositivo. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre de este dispositivo NO DEBE cambiar durante la vida útil del producto.
IMPRESIÓN DE DEDOS Es una cadena que identifica esta compilación de forma exclusiva. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla:

$(BRAND)/$(PRODUCT)/
$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Por ejemplo:

acme/myproduct/
mydevice:8.1/LMYXX/3359:userdebug/test-keys

La huella digital NO DEBE incluir caracteres de espacio en blanco. Si otros campos incluidos en la plantilla anterior tienen caracteres de espacio en blanco, DEBEN reemplazarse en la huella digital de compilación por otro carácter, como el carácter de guion bajo (“_”). El valor de este campo SE DEBE codificar como ASCII de 7 bits.

HARDWARE Es el nombre del hardware (de la línea de comandos del kernel o /proc). DEBE ser razonablemente legible por humanos. El valor de este campo SE DEBE codificar 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 existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
ID Es un identificador que elige el implementador de dispositivos para hacer referencia a una versión específica, en formato legible por humanos. Este campo puede ser igual a android.os.Build.VERSION.INCREMENTAL, pero DEBERÍA ser un valor lo suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE Es el nombre comercial del fabricante del equipo original (OEM) del producto. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
MODELO. Es un valor elegido por el implementador de dispositivos que contiene el nombre del dispositivo como lo conoce el usuario final. Debe ser el mismo nombre con el que el dispositivo se comercializa y vende a usuarios finales. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
PRODUCTO Es un valor elegido por el implementador de dispositivos que contiene el nombre de desarrollo o el nombre interno del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBE ser legible por humanos, pero no necesariamente para que lo vean los usuarios finales. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. El nombre del producto NO DEBE cambiar durante su vida útil.
SERIE 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 SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^([a-zA-Z0-9]{6,20})$”.
ETIQUETAS Una lista de etiquetas separadas por comas que elige el implementador de dispositivos que distingue aún más la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones de firma típicas de la plataforma de Android: release-keys, dev-keys y test-keys.
TIEMPO Un valor que representa la marca de tiempo del momento en que se produjo la compilación.
MÁQUINA DE ESCRIBIR Es un valor que elige el implementador de dispositivos que especifica la configuración del tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: user, userdebug o eng.
USUARIO Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No existen requisitos para el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
PANTALLA_SEGURIDAD Es un valor que indica el nivel de parche de seguridad de una compilación. DEBE indicar que la compilación no es vulnerable de ninguna manera a ninguno de los problemas descritos en el Boletín de seguridad pública de Android designado. DEBE tener el formato [YYYY-MM-DD], que coincida con una cadena definida documentada en el Boletín de seguridad pública de Android o en el Aviso de seguridad de Android, por ejemplo, "2015-11-01".
BASE_SO Un valor que representa el parámetro FINGERPRINT de la compilación que es idéntico a esta compilación, excepto por los parches proporcionados en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si tal compilación no existe, informar una cadena vacía ("").
CARGADOR DE ARRANQUE Es un valor que elige el implementador del dispositivo para identificar la versión específica del bootloader interno que se usa en el dispositivo, en un formato legible por humanos. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion(), DEBE (ser o mostrar) un valor elegido por el implementador del dispositivo que identifique la versión interna de radio/módem específica utilizada en el dispositivo, en un formato legible por humanos. Si un dispositivo no tiene radio/módem interno, DEBE mostrar NULL. El valor de este campo SE DEBE codificar como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.

3.2.3. Compatibilidad con intents

3.2.3.1. Intents de aplicaciones principales

Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidades a otros componentes de Android. El proyecto upstream de Android incluye una lista de aplicaciones que se consideran aplicaciones principales de Android, la cual implementa varios patrones de intents para realizar acciones comunes.

  • [C-0-1] Las implementaciones en dispositivos DEBEN precargar una o más aplicaciones o componentes de servicio con un controlador de intents para todos los patrones de filtro de intents públicos definidos por las siguientes aplicaciones principales para Android en el AOSP:

    • Reloj de escritorio
    • Navegador
    • Calendario
    • Contactos
    • Galería
    • Búsqueda global
    • Lanzadores
    • Música
    • Configuración
3.2.3.2. Resolución de intents
  • [C-0-1] Como Android es una plataforma extensible, las implementaciones en dispositivos DEBEN permitir que las aplicaciones de terceros anulen cada patrón de intent al que se hace referencia en la sección 3.2.3.1. La implementación ascendente de código abierto de Android lo permite de forma predeterminada.

  • [C-0-2] Los implementadores de Dvice 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 con estos patrones y asuman el control sobre ellos. Esta prohibición incluye, entre otros aspectos, la inhabilitación de la interfaz de usuario del "Selector", que permite al usuario elegir entre varias aplicaciones que manejan el mismo patrón de intents.

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

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

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

  • [C-0-4] SE DEBE intentar validar cualquier filtro de intents. Para ello, se deben realizar los pasos de validación definidos en la especificación de Vínculos de recursos digitales, tal como la implementó el Administrador de paquetes en el Proyecto de código abierto de Android ascendente.
  • [C-0-5] DEBE intentar la validación de los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de UIR validados correctamente como controladores de app predeterminados para sus UIR.
  • PUEDE establecer filtros de intents de URI específicos como controladores de app predeterminados para sus URI si se verifican correctamente, pero los demás filtros de URI candidatos no aprueban la verificación. Si la implementación de un dispositivo hace esto, DEBE proporcionar al usuario anulaciones de patrones por URI apropiadas en el menú de configuración.
  • DEBE proporcionar al usuario controles de App Links por app en Configuración de la siguiente manera:
    • [C-0-6] El usuario DEBE ser capaz de anular de forma integral el comportamiento predeterminado de los vínculos de aplicaciones para que una aplicación sea siempre abierta, siempre preguntar o nunca abierta, lo que debe aplicarse 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 brindar al usuario la capacidad de anular filtros de intents de URI candidatos específicos que se verificaron correctamente, en función del filtro de intents.
    • [C-0-8] La implementación del dispositivo DEBE permitir que los usuarios vean y anulen filtros de intents de URI candidatos específicos si la implementación del dispositivo permite que algunos filtros candidatos de intents de URI tengan éxito en la verificación, mientras que otros pueden fallar.
3.2.3.3 Espacios de nombres de intents
  • [C-0-1] Las implementaciones en dispositivos NO DEBEN incluir ningún componente de Android que respete un intent nuevo o patrón de intent de transmisión mediante ACTION, CATEGORY, o bien otra cadena de claves en el espacio de nombres android. o com.android..
  • [C-0-2] Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete un intent nuevo o patrón de intent de transmisión mediante ACTION, CATEGORY, o bien otra cadena de claves en un espacio de paquete que pertenezca a otra organización.
  • [C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni extender ninguno de los patrones de intents usados por las apps principales 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 especificada 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 con el fin de notificarles cambios en el entorno de hardware o software.

Implementaciones en dispositivos:

  • [C-0-1] DEBE transmitir los intents de transmisión pública en respuesta a los eventos del sistema correspondientes, como se describe en la documentación del SDK. Ten en cuenta que este requisito no entra en conflicto con la sección 3.5, ya que las limitaciones para las aplicaciones en segundo plano también se describen en la documentación del SDK.
3.2.3.5 Configuración predeterminada de la app

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

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

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

  • [C-1-1] DEBE respetar el intent 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, sucederá lo siguiente:

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

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

3.2.4. Actividades en pantallas secundarias

Si las implementaciones en dispositivos permiten iniciar actividades de Android normales en pantallas secundarias, sucederá lo siguiente:

  • [C-1-1] SE DEBE establecer la marca de función android.software.activities_on_secondary_displays.
  • [C-1-2] DEBE garantizar la compatibilidad de la API de manera similar a una actividad que se ejecuta en la pantalla principal.
  • [C-1-3] DEBE colocar la actividad nueva en la misma pantalla que la actividad que la inició, cuando la actividad nueva se lanza sin especificar una pantalla de destino a través de la API de ActivityOptions.setLaunchDisplayId().
  • [C-1-4] SE DEBE destruir todas las actividades cuando se quita una pantalla con la marca Display.FLAG_PRIVATE.
  • [C-1-5] SE DEBE cambiar el tamaño de todas las actividades en consecuencia en un VirtualDisplay si se cambia el tamaño de la pantalla.
  • PUEDE mostrar un IME (editor de método de entrada, un control para el usuario que permite que los usuarios ingresen texto) en la pantalla principal cuando un campo de entrada de texto se enfoca en una pantalla secundaria.
  • SE DEBE implementar el foco de entrada en la pantalla secundaria independientemente de la pantalla principal, cuando se admitan las entradas táctiles o de teclas.
  • SE RECOMIENDA tener android.content.res.Configuration, que corresponda a esa pantalla, para que se muestre, funcione correctamente y mantenga la compatibilidad si se inicia una actividad en una pantalla secundaria.

Si las implementaciones en dispositivos permiten iniciar actividades de Android normales en pantallas secundarias y las pantallas principales y secundarias tienen android.util.DisplayMetrics diferentes:

  • [C-2-1] Las actividades que no pueden cambiar de tamaño (que tienen resizeableActivity=false en AndroidManifest.xml) y las aplicaciones orientadas al nivel de API 23 o versiones anteriores NO DEBEN permitirse en las pantallas secundarias.

Si las implementaciones de dispositivos permiten iniciar actividades de Android normales en pantallas secundarias y una pantalla secundaria tiene la marca android.view.Display.FLAG_PRIVATE:

  • [C-3-1] Solo el propietario de esa pantalla, sistema y actividades que ya están en esa pantalla DEBE poder iniciarlos. Todos pueden abrir una pantalla que tenga la marca android.view.Display.FLAG_PUBLIC.

3.3. Compatibilidad con APIs nativas

Implementadores de dispositivos:

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

  • [SR] SE RECOMIENDA ENERGMENTE usar las implementaciones de las bibliotecas que se indican a continuación del proyecto ascendente de código abierto de Android.

3.3.1. Interfaces binarias de la aplicación

El código de bytes 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 correspondiente. Como el código nativo depende en gran medida de la tecnología de procesador subyacente, Android define varias interfaces binarias de la aplicación (ABI) en el NDK de Android.

Implementaciones en dispositivos:

  • [C-0-1] DEBE ser compatible con una o más ABI definidas, además de implementar la compatibilidad con el NDK de Android.
  • [C-0-2] DEBE incluir compatibilidad con código que se ejecuta en el entorno administrado para llamar al código nativo, a través de la semántica estándar de la interfaz nativa de Java (JNI).
  • [C-0-3] DEBE ser compatible con la fuente (es decir, con el encabezado) y con el formato binario (para la ABI) con cada biblioteca obligatoria de la siguiente lista.
  • [C-0-4] DEBE admitir la ABI equivalente de 32 bits si se admite cualquier ABI de 64 bits.
  • [C-0-5] DEBE informar con precisión la interfaz binaria de la aplicación (ABI) nativa compatible con 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 los cuales es una lista separada por comas de ABI ordenadas de la más a la menos preferida.
  • [C-0-6] DEBE informar, a través de los parámetros anteriores, solo las ABI documentadas y descritas en la versión más reciente de la documentación de Administración de ABI de NDK de Android, y DEBEN incluir compatibilidad con la extensión Advanced SIMD (también conocida como NEON).

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

    • libaaudio.so (compatibilidad con audio nativo de AAudio)
    • libandroid.so (compatibilidad con actividades nativas de Android)
    • libc (biblioteca C)
    • libcamera2ndk.so
    • libdl (vinculador dinámico)
    • libEGL.so (administración de superficie nativa de OpenGL)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (registro de Android)
    • libmediandk.so (compatibilidad con APIs de medios nativos)
    • libm (biblioteca de matemáticas)
    • libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
    • libOpenSLES.so (compatibilidad con audio de OpenSL ES 1.0.1)
    • libRS.so
    • libstdc++ (compatibilidad mínima con C++)
    • libvulkan.so (Vulkan)
    • libz (compresión Zlib)
    • Interfaz JNI

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

  • [C-0-9] DEBE enumerar otras bibliotecas que no sean del AOSP expuestas directamente a apps de terceros en /vendor/etc/public.libraries.txt.
  • [C-0-10] NO DEBE exponer ninguna otra biblioteca nativa, implementada y proporcionada en AOSP como bibliotecas del sistema, a apps de terceros que se orienten al nivel de API 24 o versiones posteriores, ya que están reservadas.
  • [C-0-11] SE DEBE exportar todos los símbolos de función OpenGL ES 3.1 y Android Extension Pack, como se define en el NDK, a través de la biblioteca libGLESv3.so. Ten en cuenta que, si bien todos los símbolos DEBEN estar presentes, en la sección 7.1.4.1 se describen en más detalle los requisitos para cuando se espere la implementación completa de las funciones correspondientes.
  • [C-0-12] SE DEBE exportar símbolos de funciones para los simbolos de función 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, en la sección 7.1.4.2 se describen en más detalle los requisitos para cuando se espere la implementación completa de las funciones correspondientes.
  • SE DEBE compilar con el código fuente y los archivos de encabezado disponibles en el Proyecto de código abierto de Android ascendente.

Ten en cuenta que en las versiones futuras del NDK de Android se podría incorporar compatibilidad con ABI adicionales.

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

Si las implementaciones de dispositivos son dispositivos ARM de 64 bits, entonces:

  • [C-1-1] Aunque la arquitectura ARMv8 deja de estar disponible varias operaciones de CPU, incluidas algunas operaciones usadas en el código nativo existente, las siguientes operaciones obsoletas DEBEN permanecer disponibles para el código ARM nativo de 32 bits, ya sea a través de la compatibilidad de CPU nativa o de emulación de software:

    • Instrucciones de SWP y SWPB
    • Instrucción SETEND
    • Operaciones de barrera CP15ISB, CP15DSB y CP15DMB

Si las implementaciones de dispositivos incluyen una ABI ARM de 32 bits, sucederá lo siguiente:

  • [C-2-1] DEBE incluir las siguientes líneas en /proc/cpuinfo cuando lo leen aplicaciones ARM de 32 bits para garantizar la compatibilidad con aplicaciones compiladas con versiones heredadas del NDK de Android.

    • Features:, seguido de una lista de las funciones opcionales de CPU ARMv7 compatibles con el dispositivo.
    • CPU architecture:, seguido de un valor entero que describe la arquitectura ARM compatible más alta del dispositivo (p.ej., "8" para dispositivos ARMv8).

  • No se DEBE alterar /proc/cpuinfo cuando lo leen aplicaciones ARM de 64 bits o que no son ARM.

3.4. Compatibilidad con la Web

3.4.1. Compatibilidad con WebView

Si las implementaciones en dispositivos proporcionan una implementación completa de la API de android.webkit.Webview, harán lo siguiente:

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

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

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, como Gecko) versión/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • El valor de la cadena $(VERSION) DEBE ser el mismo que el de android.os.Build.VERSION.release.
    • El valor de la cadena $(MODEL) DEBE ser el mismo que el de android.os.Build.MODEL.
    • El valor de la cadena $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID.
    • El valor de la cadena $(CHROMIUM_VER) DEBE ser la versión de Chromium en el proyecto de código abierto de Android ascendente.
    • Las implementaciones de dispositivos PUEDEN omitir a dispositivos móviles en la string del usuario-agente.

  • El componente de WebView DEBE incluir compatibilidad con la mayor cantidad posible de funciones HTML5. Si es compatible, DEBE cumplir con la especificación de HTML5.

3.4.2. Compatibilidad del navegador

Si las implementaciones en dispositivos incluyen una aplicación de navegador independiente para la navegación web general, sucederá lo siguiente:

  • [C-1-1] DEBE admitir cada una de estas APIs asociadas con HTML5:
  • [C-1-2] DEBE admitir la API de Webstorage 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 hacen la transición para favorecer a IndexedDB sobre el almacenamiento web, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.
  • PUEDE enviar una cadena de usuario-agente personalizada a la aplicación independiente del navegador.
  • SE DEBE implementar la compatibilidad con la mayor cantidad de archivos HTML5 posible en la aplicación de navegador independiente (ya sea basada en la aplicación ascendente del navegador WebKit o en un reemplazo de terceros).

Sin embargo, si las implementaciones en dispositivos no incluyen una aplicación de navegador independiente, sucederá lo siguiente:

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

3.5 Compatibilidad de comportamiento de las APIs

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

  • [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent estándar.
  • [C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etcétera).
  • [C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
  • Los dispositivos NO DEBEN alterar las limitaciones que se aplican a las aplicaciones en segundo plano. Más específicamente, en el caso de las apps en segundo plano:
    • [C-0-4] DEBEN dejar de ejecutar devoluciones de llamada registradas por 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 API LocationManager o el método WifiManager.startScan().
    • [C-0-6] Si la app tiene como objetivo un nivel de API 25 o superior, NO DEBEN permitir el registro de receptores de emisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la app, a menos que el intent de transmisión requiera un permiso "signature" o "signatureOrSystem" protectionLevel o estén incluidos en la lista de exenciones.
    • [C-0-7] Si la app se orienta al nivel de API 25 o superior, DEBEN detener sus servicios en segundo plano, como si esta hubiera llamado al método stopSelf() de los servicios, a menos que se encuentre en una lista de entidades permitidas temporal para controlar una tarea que el usuario pueda ver.
    • [C-0-8] si la app tiene como objetivo un nivel de API 25 o superior, se DEBEN liberar los bloqueos de activación que contiene.

La lista anterior no es exhaustiva. El Conjunto de pruebas de compatibilidad (CTS) prueba la compatibilidad de comportamiento en partes significativas de la plataforma, pero no en todas. El implementador es responsable de garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android. Por esta razón, 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.6 Espacios de nombres de 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) a estos espacios de nombres de paquetes:

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

Es decir, ellos hacen lo siguiente:

  • [C-0-1] NO DEBE modificar las APIs expuestas públicamente en la plataforma de Android cambiando ningún método o firma de clases, o 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 utiliza en el código fuente ascendente de Android.

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

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

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

  • [C-0-5] NO DEBE estar en un espacio de nombres que pertenezca a otra organización o haga referencia a otra. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* o 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] SE DEBE empaquetar en una biblioteca compartida de Android para que solo las apps que los usan explícitamente (a través del mecanismo <uses-library>) se vean afectadas por el aumento en el 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 funciones nuevas útiles a una API existente o agregando una API nueva), el implementador DEBE visitar source.android.com y comenzar el proceso para contribuir con cambios y código, según la información de ese sitio.

Ten en cuenta que las restricciones anteriores corresponden a las convenciones estándar para asignar nombres a las APIs en el lenguaje de programación Java. Esta sección simplemente apunta a reforzar esas convenciones y hacerlas vinculantes a través de la inclusión en esta definición de compatibilidad.

3.7 Compatibilidad del entorno de ejecución

Implementaciones en dispositivos:

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

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

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

  • SE RECOMIENDA realizar pruebas de Fuzz 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 en dispositivos PUEDEN asignar más memoria por aplicación.

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

3.8. Compatibilidad con la interfaz de usuario

3.8.1. Selector (pantalla principal)

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

Si las implementaciones de dispositivos permiten que aplicaciones de terceros reemplacen su pantalla principal:

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

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

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

Si las implementaciones de dispositivos implementan un selector predeterminado que proporciona acceso rápido a las combinaciones de teclas adicionales que proporcionan las apps de terceros a través de la API de shortManager, sucede lo siguiente:

  • [C-4-1] DEBE admitir todas las funciones de atajos documentadas (p.ej., atajos estáticos y dinámicos, fijación de atajos) y de implementar completamente 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 las apps, sucederá lo siguiente:

  • [C-5-1] DEBE respetar el método de la API NotificationChannel.setShowBadge(). En otras palabras, muestra una indicación visual asociada con el ícono de la app si el valor se estableció como true y no muestres ningún esquema de insignias del ícono de la app cuando todos los canales de notificaciones de la app tengan configurado el valor como false.
  • PUEDE anular las insignias del ícono de la app con su esquema de insignias propio cuando las aplicaciones de terceros indiquen compatibilidad con este esquema mediante el uso de APIs propias, pero DEBERÍA usar los recursos y valores proporcionados a través de las APIs de insignias de notificación descritas en el SDK, como Notification.Builder.setNumber() y la API de Notification.Builder.setBadgeIconType().

3.8.2. Widgets

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

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

  • [C-1-1] DEBE declarar compatibilidad con la función android.software.app_widgets de la plataforma.
  • [C-1-2] DEBE incluir compatibilidad integrada con AppWidgets y exponer las posibilidades de la interfaz de usuario para agregar, configurar, ver y quitar AppWidgets directamente en el Selector.
  • [C-1-3] DEBE ser capaz de renderizar widgets de 4 x 4 en el tamaño de cuadrícula estándar. Para obtener más información, consulta los Lineamientos de diseño de widgets de apps en la documentación del SDK de Android.
  • PUEDE admitir widgets de apps 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, sucederá lo siguiente:

3.8.3. Notificaciones

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

3.8.3.1. Presentación de notificaciones

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

  • [C-1-1] DEBE admitir notificaciones que usan funciones de hardware, como se describe en la documentación del SDK, y en la medida de lo posible con 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 la implementación de un dispositivo no tiene hardware, las APIs correspondientes DEBEN implementarse como modalidad no-ops. Este comportamiento se detalla con más detalle en la sección 7.
  • [C-1-2] DEBE renderizar correctamente todos los recursos (íconos, archivos de animación, etc.) proporcionados en las APIs o en la guía de estilo de íconos de la barra de estado/sistema, aunque PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de código abierto de Android de referencia.
  • [C-1-3] DEBE respetar e implementar correctamente los comportamientos descritos para las APIs para actualizar, quitar y agrupar las notificaciones.
  • [C-1-4] DEBE proporcionar el comportamiento completo de la API de NotificationChannel documentado en el SDK.
  • [C-1-5] DEBE proporcionar una indicación visual del usuario para bloquear y modificar la notificación de una app de terceros en cada canal y nivel de paquete de app.
  • [C-1-6] también DEBE proporcionar una indicación visual del usuario para mostrar los canales de notificaciones borrados.
  • DEBE admitir notificaciones enriquecidas.
  • Se DEBEN presentar algunas notificaciones de prioridad más alta como notificaciones de atención.
  • SE RECOMIENDA tener una indicación visual del usuario para posponer las notificaciones.
  • ES POSIBLE que solo administre la visibilidad y los horarios de las apps de terceros que notifiquen a los usuarios sobre eventos notables para mitigar problemas de seguridad, como la distracción del conductor.

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

  • [C-2-1] SE DEBE usar los recursos exactos tal como se proporcionan a través de la clase de API Notification.Style y sus subclases para los elementos de recursos presentados.
  • SE DEBE presentar todos los elementos de recursos (p.ej., íconos, títulos y textos de resumen) definidos en la clase de API Notification.Style y sus subclases.

Si las implementaciones de dispositivos admiten notificaciones de atención:

  • [C-3-1] DEBE usar la vista de notificaciones de atención y los recursos descritos en la clase de API de Notification.Builder cuando se presentan notificaciones de atención.
3.8.3.2. Servicio de escucha de notificaciones

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

Si las implementaciones de dispositivos informan la marca de función android.hardware.ram.normal, sucede lo siguiente:

  • [C-1-1] DEBE actualizar de manera correcta y oportuna las notificaciones en su totalidad para todos los servicios de escucha instalados y habilitados por el usuario, incluidos todos y cada uno de los metadatos adjuntos al objeto de notificación.
  • [C-1-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 posposición establecida en la llamada a la API.

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

  • [C-2-1] DEBE reflejar correctamente el estado de las notificaciones pospuestas mediante las APIs estándar, como NotificationListenerService.getSnoozedNotifications().
  • [C-2-2] DEBE hacer que esta indicación visual del usuario esté disponible para posponer notificaciones de cada app de terceros instalada, a menos que sean de servicios persistentes o en primer plano.
3.8.3.3 No interrumpir (No interrumpir)

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

  • [C-1-1] DEBE implementar una actividad que responda al intent ACTION_NOTIFICATION_POLICY_ACCESS_CONFIGURACIÓN, que, en el caso de las implementaciones con UI_MODE_TYPE_NORMAL, DEBE ser una actividad en la que el usuario pueda otorgar o denegar a la app el acceso a las configuraciones de la política de DND.
  • [C-1-2] DEBE, cuando la implementación del dispositivo haya proporcionado un medio para que el usuario otorgue o rechace que apps de terceros accedan a la configuración de la política de No interrumpir, se deben mostrar Reglas automáticas de No interrumpir creadas por las aplicaciones junto con las reglas creadas por el usuario y predefinidas.
  • [C-1-3] DEBE respetar los valores de suppressedVisualEffects pasados en NotificationManager.Policy y, si una app estableció alguna de las marcas SUPPRESSED_Effect_SCREEN_OFF o SUPPRESSED_Effect_SCREEN_ON, DEBE indicar al usuario que los efectos visuales se suprimen en el menú de configuración de No interrumpir.

Android incluye API que permiten a los desarrolladores incorporar la búsqueda en sus aplicaciones y exponer los datos de estas en la búsqueda global del sistema. En términos generales, esta funcionalidad consiste en una única interfaz de usuario para todo el sistema que permite que los usuarios ingresen consultas, muestre sugerencias a medida que los usuarios escriban y muestre los resultados. Las API de Android permiten a los desarrolladores reutilizar esta interfaz para proporcionar búsquedas dentro de sus propias apps y proporcionar resultados a la interfaz de usuario de búsqueda global común.

  • Las implementaciones en dispositivos Android DEBEN incluir búsqueda global, una interfaz de usuario de búsqueda única y compartida en todo el sistema que pueda realizar sugerencias en tiempo real en respuesta a las entradas del usuario.

Si las implementaciones en dispositivos implementan la interfaz de búsqueda global, sucederá lo siguiente:

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

Si no hay aplicaciones de terceros instaladas que usen la búsqueda global:

  • El comportamiento predeterminado DEBE mostrar resultados y 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, harán lo siguiente:

  • [C-2-1] DEBE indicar claramente al usuario final cuando se comparte el contexto de alguna de las siguientes maneras:
    • Cada vez que la aplicación de asistencia accede al contexto, muestra una luz blanca alrededor de los bordes de la pantalla que alcanza o supera la duración y el brillo de la implementación del Proyecto de código abierto de Android.
    • En el caso de la app de asistencia preinstalada, proporcionar una indicación visual del usuario a menos de dos navegaciones del menú de configuración de la app de Asistente y entrada de voz predeterminada, y compartir el contexto solo cuando el usuario invoca explícitamente la app de asistencia a través de una entrada de palabra clave o tecla de navegación de asistencia.
  • [C-2-2] La interacción designada para iniciar la aplicación de asistencia, tal como se describe en la sección 7.2.3, DEBE iniciar la aplicación de asistencia seleccionada por el usuario; en otras palabras, la aplicación que implementa VoiceInteractionService o una actividad que controla el intent ACTION_ASSIST.
  • [SR] SE RECOMIENDA ENRENDER usar mantener presionada la tecla HOME como esta interacción designada.

3.8.5. Alertas y avisos

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

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

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

  • [C-1-2] DEBE respetar la API de avisos y mostrar avisos de las aplicaciones a los usuarios finales 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 quieren que coincidan con el diseño del tema Holo según lo definido por el SDK de Android.

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

Android también incluye una familia de temas "Device Default" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen si quieren que coincidan con el aspecto del tema del dispositivo según lo definido por el implementador de dispositivos.

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

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

  • [C-2-1] DEBE usar blanco para los íconos de estado del sistema (como la intensidad de la señal y el nivel de batería) y las notificaciones que emite el sistema, a menos que el ícono indique un estado problemático o una app solicite una barra de estado luminosa con el indicador SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
  • [C-2-2] Las implementaciones en dispositivos Android DEBEN cambiar el color de los íconos de estado del sistema a negro (para obtener más información, consulta R.style) cuando una app solicita una barra de estado de luz.

3.8.7. Fondos de pantalla animados

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

Se considera que un hardware es capaz de ejecutar fondos de pantalla animados de manera confiable si puede ejecutar todos los fondos de pantalla animados, sin limitaciones de funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware hacen que los fondos de pantalla o las aplicaciones fallen, fallen, consuman demasiada energía de la CPU o la batería, o se ejecuten a velocidades de fotogramas inaceptables, se considera que el hardware no puede ejecutar fondos de pantalla animados. Por ejemplo, algunos fondos de pantalla animados pueden usar un contexto OpenGL 2.0 o 3.x para renderizar su contenido. El fondo animado no se ejecutará de manera confiable en hardware que no admite varios contextos OpenGL, ya que el uso del fondo animado de un contexto de OpenGL puede entrar en conflicto con otras aplicaciones que también usan un contexto OpenGL.

  • Las implementaciones en dispositivos capaces de ejecutar fondos de pantalla animados de manera confiable, como se describió anteriormente, DEBEN implementar fondos de pantalla animados.

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

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

3.8.8. Cambio de actividad

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

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

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

  • [C-1-1] DEBE admitir al menos un máximo de 7 actividades mostradas.
  • SE RECOMIENDA mostrar, al menos, el título de 4 actividades a la vez.
  • [C-1-2] DEBE implementar el comportamiento de fijación de pantalla y proporcionarle al usuario un menú de configuración para activar o desactivar la función.
  • SE DEBE mostrar el color de resaltado, el ícono, el título de la pantalla en recientes.
  • SE DEBE mostrar una indicación visual de cierre ("x"), pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas.
  • SE RECOMIENDA implementar una combinación de teclas para cambiar fácilmente a la actividad anterior
  • SE DEBE activar la acción de cambio rápido entre las dos apps usadas más recientemente cuando se presione dos veces la tecla de función Recientes.
  • SE DEBE activar el modo multiventana de pantalla dividida, si es compatible, cuando se mantiene presionada la tecla de funciones recientes.

  • PUEDE mostrar los recientes afiliados como un grupo que se mueve de forma conjunta.

  • [SR] SE RECOMIENDA EXITOSAMENTE usar la interfaz de usuario upstream de Android (o una interfaz similar basada en miniaturas) para la pantalla de información general.

3.8.9. Administración de entradas

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

Si las implementaciones en dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, sucederá lo siguiente:

  • [C-1-1] SE DEBE declarar la función de la plataforma android.software.input_methods y admitir API de IME, como se define en la documentación del SDK de Android.
  • [C-1-2] DEBE proporcionar un mecanismo al que el usuario pueda acceder para agregar y configurar métodos de entrada de terceros en respuesta al intent android.settings.INPUT_METHOD_d.

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

3.8.10. Control multimedia de la pantalla de bloqueo

La API de cliente de control remoto dejó de estar disponible en Android 5.0 y se reemplazó por la Plantilla de notificación multimedia, que permite a las aplicaciones multimedia integrarse con los controles de reproducción que se muestran en la pantalla de bloqueo.

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

Android incluye compatibilidad con interactscreensavers, conocidos anteriormente como Dreams. Los protectores de pantalla permiten a los usuarios interactuar con aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o en un conector para escritorio. PUEDEN implementar los protectores de pantalla en los dispositivos Android Watch, pero otros tipos de implementaciones DE dispositivos DEBEN incluir compatibilidad con protectores de pantalla y proporcionar una opción de configuración para que los usuarios los configuren en respuesta al intent android.settings.DREAM_SETTINGS.

3.8.12. Ubicación

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

  • [C-1-1] Los modos de ubicación DEBEN mostrarse en el menú Ubicación dentro de Configuración.

3.8.13. Unicode y fuentes

Android admite los caracteres de emojis que se definen en Unicode 10.0.

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

  • [C-1-1] DEBE ser capaz de renderizar estos caracteres de emojis con glifos de color.
  • [C-1-2] DEBE incluir compatibilidad con lo siguiente:
  • Fuente Roboto 2 con diferentes grosores: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light para los idiomas disponibles en el dispositivo.
  • Cobertura completa de Unicode 7.0 en latín, griego y cirílico, incluidos los rangos latinos A, B, C y D extendidos, y todos los glifos en el bloque de símbolos monetarios de Unicode 7.0.
  • SE DEBE admitir el tono de piel y los diversos emojis familiares, como se especifica en el Informe técnico de Unicode n.o 51.

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

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

3.8.14. Multiventana

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

  • [C-1-1] DEBE implementar dichos modos multiventana de acuerdo con los comportamientos de la aplicación y las APIs que se describen en la documentación de compatibilidad del modo multiventana del SDK de Android y cumplir con los siguientes requisitos:
  • [C-1-2] Las aplicaciones pueden indicar si son capaces de operar en el modo multiventana en el archivo AndroidManifest.xml, ya sea explícitamente mediante la configuración del atributo android:resizeableActivity en true o implícitamente mediante la targetSdkVersion > 24. Las apps que establecen explícitamente este atributo como false en su manifiesto NO DEBEN iniciarse en el modo multiventana. Las apps más antiguas con targetSdkVersion < 24 que no establecieron este atributo android:resizeableActivity PUEDEN iniciarse en el modo multiventana, pero el sistema DEBE advertir que es posible que la app no funcione como se espera en este modo.
  • [C-1-3] NO DEBE ofrecer el modo de pantalla dividida ni forma libre si la altura de la pantalla es inferior a 440 dp y el ancho de la pantalla es inferior a 440 dp.
  • Las implementaciones en dispositivos con tamaño de pantalla xlarge DEBEN admitir el modo de forma libre.

Si las implementaciones de dispositivos admiten modos multiventana y el modo de pantalla dividida, harán lo siguiente:

  • [C-2-1] DEBE precargar un selector redimensionable como predeterminado.
  • [C-2-2] SE DEBE recortar la actividad anclada de un multiventana de pantalla dividida, pero SE DEBE mostrar algo de contenido si la app Launcher es la ventana enfocada.
  • [C-2-3] DEBE respetar los valores declarados de AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight de la aplicación de selector de terceros y no de anular estos valores mientras se muestra parte del contenido de la actividad acoplada.

Si las implementaciones de dispositivos admiten los modos multiventana y el modo multiventana:

  • [C-3-1] DEBE iniciar actividades en el modo multiventana de pantalla en pantalla cuando la aplicación: * Se orienta al nivel de API 26 o superior y declara android:supportsPictureInPicture. * Se orienta al nivel de API 25 o anterior, y declara android:resizeableActivity y android:supportsPictureInPicture.
  • [C-3-2] DEBE exponer las acciones en su SystemUI como se especifica en la actividad de PIP actual a través de la API de setActions().
  • [C-3-3] DEBE admitir relaciones de aspecto superiores o iguales a 1:2.39, e inferiores o iguales a 2.39:1, según se especifica en la actividad de PIP a través de la API de setAspectRatio().
  • [C-3-4] DEBE usar KeyEvent.KEYCODE_WINDOW para controlar la ventana de PIP. Si no se implementa este modo, la clave DEBE estar disponible para la actividad en primer plano.
  • [C-3-5] DEBE proporcionar una indicación visual del usuario para bloquear una app para que no se muestre en modo PIP. La implementación de AOSP cumple con este requisito por tener controles en el panel de notificaciones.
  • [C-3-6] DEBE asignar un ancho y una altura mínimos de 108 dp a la ventana de PIP, un ancho mínimo de 240 dp y una altura de 135 dp para la ventana de PIP cuando Configuration.uiMode se configura como UI_MODE_TYPE_TELEVISION

3.9 Administración del dispositivo

Android incluye funciones que permiten a las aplicaciones conscientes de la seguridad realizar funciones de administración de dispositivos a nivel del sistema, como la aplicación de políticas de contraseñas o la limpieza remota, a través de la API de administración de dispositivos Android].

Si las implementaciones de dispositivos implementan la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android, harán lo siguiente:

  • [C-1-1] DEBE declarar android.software.device_admin.
  • El [C-1-2] DEBE admitir el aprovisionamiento del propietario del dispositivo, como se describe en las secciones 3.9.1 y 3.9.1.1.
  • [C-1-3] DEBE declarar la compatibilidad de perfiles administrados a través de la marca de función android.software.managed_users, excepto cuando el dispositivo está configurado para informarse como un dispositivo con poca memoria RAM o para asignar almacenamiento interno (no extraíble) como almacenamiento compartido.

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

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

  • [C-1-1] DEBE admitir la inscripción de un Cliente de política de dispositivo (DPC) como una aplicación del propietario del dispositivo, tal como se describe a continuación:
  • [C-1-2] NO DEBE establecer una aplicación (incluida la preinstalada) como aplicación del propietario del dispositivo sin el consentimiento o la acción explícitos del usuario o del administrador del dispositivo.

Si las implementaciones de dispositivos declaran android.software.device_admin, pero también incluyen una solución propia de administración del propietario del dispositivo y proporcionan un mecanismo para promover una aplicación configurada en su solución como "equivalente al propietario del dispositivo" a la API estándar "Propietario del dispositivo" como reconocen las APIs estándar de DevicePolicyManager de Android, sucederá lo siguiente:

  • [C-2-1] DEBE tener un proceso para verificar que la aplicación específica que se promociona pertenezca a una solución legítima de administración de dispositivos empresariales y que ya se configuró en la solución de propiedad para tener los derechos equivalentes a "Propietario del dispositivo".
  • [C-2-2] DEBE mostrar la misma divulgación de consentimiento del propietario del dispositivo del AOSP que el flujo que inició 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 de DPC como "Propietario del dispositivo".
3.9.1.2 Aprovisionamiento de perfiles administrados

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

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

  • [C-1-2] La experiencia de los usuarios del proceso de aprovisionamiento de perfiles administrados (el flujo que inicia android.app.action.PROVISION_MANAGED_PROFILE) DEBE alinearse con la implementación de AOSP.

  • [C-1-3] DEBE proporcionar las siguientes posibilidades de usuario dentro de la Configuración para indicarle al usuario que el controlador de política de dispositivo (DPC) inhabilitó una función del sistema en particular:

    • Un ícono coherente u otra indicación visual del usuario (por ejemplo, el ícono de información ascendente de AOSP) para representar cuando un administrador de dispositivos restringe una configuración específica
    • Un mensaje de explicación breve, proporcionado por el administrador de dispositivos a través de setShortSupportMessage.
    • Ícono de la aplicación de DPC

3.9.2 Asistencia para perfiles administrados

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

  • [C-1-1] DEBE admitir perfiles administrados a través de las APIs de android.app.admin.DevicePolicyManager.
  • [C-1-2] DEBE permitir que se cree un solo perfil administrado.
  • [C-1-3] DEBE usar una insignia de ícono (similar a la insignia de trabajo ascendente de AOSP) para representar las aplicaciones y los widgets administrados, y otros elementos de la IU con insignia, como Recientes y Notificaciones.
  • [C-1-4] DEBE mostrar un ícono de notificación (similar a la insignia de trabajo upstream de AOSP) para indicar cuando el usuario se encuentra dentro de una aplicación de perfil administrado.
  • [C-1-5] DEBE mostrar un aviso que indique que el usuario está en el perfil administrado si se activa el dispositivo (ACTION_USER_PRESENT) y la aplicación en primer plano está dentro del perfil administrado.
  • [C-1-6] Cuando existe un perfil administrado, DEBE mostrar una indicación visual en el "Selector de intents" para permitir que el usuario reenvíe el intent del perfil administrado al usuario principal o viceversa, si el controlador de Device Policy lo habilita.
  • [C-1-7] Cuando existe un perfil administrado, DEBE exponer las siguientes condiciones del usuario tanto para el usuario principal como para el perfil administrado:
    • Contabilización independiente de la batería, la ubicación, los datos móviles y el uso del almacenamiento del usuario principal y el perfil administrado
    • Administración independiente de aplicaciones de VPN instaladas dentro del usuario principal o perfil administrado
    • Administración independiente de aplicaciones instaladas dentro del usuario principal o perfil administrado
    • Administración independiente de cuentas dentro del usuario principal o el perfil administrado
  • [C-1-8] DEBE asegurarse de que el marcador preinstalado, los contactos y las aplicaciones de mensajería puedan buscar y obtener la información del emisor desde el perfil administrado (si existe uno) junto con los del perfil principal, si el controlador de política de dispositivo lo permite.
  • [C-1-9] SE DEBE asegurarse de que cumpla con todos los requisitos de seguridad aplicables a un dispositivo que tenga habilitados varios usuarios (consulta la sección 9.5), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.
  • [C-1-10] DEBE admitir la posibilidad de especificar una pantalla de bloqueo independiente que cumpla con los siguientes requisitos para otorgar acceso a las apps que se ejecutan en un perfil administrado.
  • Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la IU durante la llamada, las notificaciones de llamadas perdidas y en curso, los contactos y las aplicaciones de mensajería, SE DEBE usar la misma insignia que se utiliza para indicar las aplicaciones del perfil administrado.

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 plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamada para eventos del usuario y del sistema, y generen mecanismos alternativos de respuesta, como texto a voz, respuesta táctil y navegación con bola de seguimiento o pad direccional.

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

  • [C-1-1] DEBE implementar 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, tal como se documenta en el SDK.
  • [C-1-3] DEBE respetar el intent android.settings.ACCESSIBILITY_SETTINGS para proporcionar un mecanismo accesible para el usuario que permita habilitar o inhabilitar los servicios de accesibilidad de terceros junto con los servicios de accesibilidad precargados.
  • [C-1-4] DEBE agregar un botón en la barra de navegación del sistema que le permita al usuario controlar el servicio de accesibilidad cuando los servicios de accesibilidad habilitados declaren la AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Ten en cuenta que este requisito no es aplicable para las implementaciones en dispositivos sin barra de navegación del sistema, pero DEBEN proporcionar al usuario la indicación visual de controlar estos servicios de accesibilidad.

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

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

3.11. Text-to-Speech

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

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

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

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

3.12. Marco de trabajo de entrada de TV

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

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

  • [C-1-1] SE DEBE declarar la función android.software.live_tv de la plataforma.
  • [C-1-2] SE DEBE precargar una aplicación de TV (aplicación de TV) y debe cumplir con todos los requisitos descritos en la sección 3.12.1.

3.12.1. App para TV

Si las implementaciones en dispositivos admiten el TIF:

  • [C-1-1] La app de TV DEBE proporcionar instalaciones para instalar y usar canales de TV. Además, debe cumplir con los siguientes requisitos:

La app para TV que se requiere para las implementaciones en dispositivos Android que declaran la marca de función android.software.live_tv DEBE cumplir con los siguientes requisitos:

  • Las implementaciones en dispositivos DEBEN permitir que se instalen y administren entradas de terceros basadas en el TIF (entradas de terceros).
  • Las implementaciones en dispositivos PUEDEN proporcionar una separación visual entre las entradas basadas en TIF (instaladas) preinstaladas y las de terceros.
  • Las implementaciones en dispositivos NO DEBEN mostrar las entradas de terceros más de una sola acción de navegación fuera de la app para TV (es decir, expandir una lista de entradas de terceros desde la app para TV).

El Proyecto de código abierto de Android proporciona una implementación de la app para TV que cumple con los requisitos anteriores.

3.12.1.1. Guía electrónica de programas

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

  • [C-1-1] DEBE mostrar una superposición informativa e interactiva, que DEBE incluir una guía electrónica de programas (EPG) generada a partir de los valores en los campos TvContract.Programs.
  • [C-1-2] En un cambio de canal, las implementaciones del dispositivo DEBEN mostrar los datos de la EPG del programa que se está reproduciendo.
  • [SR] Se recomienda encarecidamente que la EPG muestre las entradas instaladas y de terceros con la misma importancia. La EPG NO DEBE mostrar las entradas de terceros más de una sola acción de navegación fuera de las entradas instaladas en la EPG.
  • La EPG DEBE mostrar información de todas las entradas instaladas y de terceros.
  • Es posible que la EPG proporcione una separación visual entre las entradas instaladas y las de terceros.
3.12.1.2. Navegación

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

  • [C-1-1] DEBE permitir la navegación para las siguientes funciones a través de las teclas de inicio, Atrás y Pad direccional en los dispositivos de entrada del dispositivo de televisión Android (es decir, control remoto, aplicación de control remoto o controlador de juegos):

    • Cambio de canales de TV
    • Abriendo EPG
    • Configuración y ajuste a entradas de terceros basadas en TIF (si esas entradas son compatibles)
    • Abriendo el menú Configuración

  • SE DEBE pasar los eventos de teclas a entradas HDMI a través de CEC.

3.12.1.3. Vinculación de apps de entrada de TV

Las implementaciones de dispositivos de televisión para Android DEBEN admitir la vinculación de apps de entrada de TV, que permite que todas las entradas proporcionen vínculos de actividad de la actividad actual a otra actividad (es decir, un vínculo de la programación en vivo a contenido relacionado). La app de TV DEBE mostrar la vinculación de la app de entrada de TV cuando está disponible.

3.12.1.4. Pausa en vivo

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

  • [SR] SE RECOMIENDA ENRENDERMENTE la compatibilidad con la pausa en directo, lo que permite al usuario pausar y reanudar el contenido en vivo.
  • SE DEBE ofrecerles al usuario una forma de pausar y reanudar el programa en reproducción si está disponible la pausa en directo de ese programa.
3.12.1.5. Grabación de TV

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

  • [SR] SE RECOMIENDA COMPLETAMENTE admitir la grabación de TV.
  • Si la entrada de TV admite la grabación y la grabación de un programa no está prohibida, la EPG PUEDE proporcionar una forma de grabar un programa.

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

  • [C-1-1] DEBE permitir que el usuario agregue o quite los mosaicos proporcionados 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 multimedia

Si las implementaciones en dispositivos incluyen el framework de IU que admite apps de terceros que dependen de MediaBrowser y MediaSession , sucederá lo siguiente:

3.15. Apps instantáneas

Las implementaciones en dispositivos DEBEN cumplir con los siguientes requisitos:

  • [C-0-1] A las Apps instantáneas solo DEBEN tener permisos con android:protectionLevel establecido en "ephemeral".
  • [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 patrón de intents del componente está expuesto y tiene CATEGORY_BROWSABLE
    • La acción es una de las siguientes: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
    • El destino se expone de forma explícita con android:visibleToInstantApps.
  • [C-0-3] Las Apps instantáneas NO DEBEN interactuar explícitamente 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 los detalles de las Apps instantáneas en el dispositivo, a menos que estas se conecten explícitamente a la aplicación instalada.

3.16. Sincronización de dispositivos complementarios

Android admite la vinculación de dispositivos complementarios para administrar de manera más eficaz la asociación con estos dispositivos 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, sucederá lo siguiente:

  • [C-1-1] SE DEBE declarar la marca de función FEATURE_COMPANION_DEVICE_SETUP .
  • [C-1-2] DEBE asegurarse de que las APIs del paquete android.companion estén completamente implementadas.
  • [C-1-3] DEBE proporcionar las condiciones del usuario para que este seleccione o confirme que un dispositivo complementario está presente y en funcionamiento.

4. Compatibilidad con paquetes de aplicaciones

Implementaciones en dispositivos:

  • [C-0-1] DEBE ser capaz de instalar y ejecutar archivos ".apk" de Android generados por la herramienta "aapt" incluida en el SDK oficial de Android.
  • Como el requisito anterior puede ser desafiante, se RECOMIENDA las implementaciones en dispositivos que usen las implementaciones de systemDevice de administración de paquetes de la implementación de referencia de AOSP.
  • [C-0-2] DEBE admitir la verificación de archivos ".apk" con el esquema de firma de APK v2 y la firma JAR.
  • [C-0-3] NO DEBE extender los formatos de código de byte .apk, Android Manifest, Dalvik bytecode ni RenderScript de manera que eviten 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 manera silenciosa y sin ningún mensaje, como se documenta en el SDK para el permiso DELETE_PACKAGE. Las únicas excepciones son la app del verificador de paquetes del sistema que maneja el intent PACKAGE_NEEDS_VERIFICATION y la app del administrador de almacenamiento que controla el intent ACTION_MANAGE_STORAGE.

Las implementaciones de dispositivos NO DEBEN instalar paquetes de aplicaciones de fuentes desconocidas, a menos que la aplicación que solicita la instalación cumpla con todos los requisitos que se indican a continuación:

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

Las implementaciones en dispositivos DEBEN tener una actividad que controle el intent android.settings.MANAGE_UNKNOWN_APP_SOURCES. DEBEN proporcionar una indicación al usuario para otorgar o revocar el permiso para instalar apps de fuentes desconocidas por cada aplicación, pero PUEDE optar por implementar esto como una no-op y mostrar RESULT_CANCELED para startActivityForResult() si la implementación del dispositivo no quiere permitir que los usuarios tengan esta opción. Sin embargo, incluso en tales casos, DEBEN indicar al usuario por qué no se presenta esa opción.

5. Compatibilidad multimedia

Implementaciones en dispositivos:

  • [C-0-1] DEBE admitir los formatos multimedia, los codificadores, los decodificadores, los tipos de archivo y los formatos de contenedor definidos en la sección 5.1 para cada códec declarado por MediaCodecList.
  • [C-0-2] DEBE declarar e informar la compatibilidad de los codificadores y decodificadores disponibles para aplicaciones de terceros a través de MediaCodecList.
  • [C-0-3] DEBE poder decodificar y poner a disposición de apps de terceros todos los formatos que pueda codificar. Esto incluye todos los flujos de bits que generan sus codificadores y los perfiles informados en su CamcorderProfile.

Implementaciones en dispositivos:

  • DEBERÍAN lograr una latencia de códec mínima; en otras palabras, deben tener las siguientes características:
    • NO DEBEN consumir ni almacenar búferes de entrada ni devolver búferes de entrada solo una vez procesados.
    • NO SE DEBEN retener los búferes decodificados durante más tiempo del que se especifica en el estándar (p.ej., SPS).
    • NO DEBERÍAS retener los búferes codificados más tiempo que el requerido por la estructura del GOP.

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

Ten en cuenta que ni Google ni Open Handset Alliance declaran que estos códecs no tienen patentes de terceros. Quienes deseen utilizar este código fuente en productos de hardware o software deben considerar que las implementaciones de este código, incluso en software de código abierto o shareware, pueden requerir licencias de patentes de los titulares de patentes pertinentes.

5.1. Códecs de contenido multimedia

5.1.1 Codificación de audio

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

Si las implementaciones de dispositivos declaran android.hardware.microphone, DEBEN admitir la siguiente codificación de audio:

  • [C-1-1] PCM/WAVE

5.1.2. Decodificación de audio

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

Si las implementaciones de dispositivos declaran la compatibilidad con la función android.hardware.audio.output, sucederá lo siguiente:

  • [C-1-1] Perfil MPEG-4 AAC (AAC LC)
  • [C-1-2] Perfil MPEG-4 HE AAC (AAC+)
  • [C-1-3] Perfil MPEG-4 HE AACv2 (AAC+ mejorado)
  • [C-1-4] AAC ELD (AAC mejorado de bajo retraso)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [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 mezclar (p.ej., una transmisión 5.0 AAC se debe decodificar en cinco canales de PCM, y una transmisión 5.1 AAC se debe decodificar en seis canales de PCM).
  • [C-2-2] Los metadatos de rango dinámico DEBEN ser los que se definen en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3 y las claves del DRC android.media.MediaFormat para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves DRC de AAC se introdujeron en la API 21 y son: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL y KEY_AAC_ENCODED_TARGET_LEVEL

5.1.3 Detalles de los códecs de audio

Formato/códec Detalles Tipos de archivos/formatos de contenedor admitidos
Perfil MPEG-4 AAC
(AAC LC) 		Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 8 kHz a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC sin formato ADTS (.aac, ADIF no es compatible)
  • MPEG-TS (.ts, no permite búsquedas)
Perfil MPEG-4 HE AAC (AAC+) Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 kHz a 48 kHz.
MPEG-4 HE AACv2
Perfil (AAC+ mejorado) 		Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 kHz a 48 kHz.
AAC ELD (AAC mejorado de bajo retraso) Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 kHz a 48 kHz.
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
FLAC Mono/estéreo (sin multicanal). Tasas de muestreo de hasta 48 kHz (pero hasta 44.1 kHz se RECOMIENDA en dispositivos con salida de 44.1 kHz, ya que el reducción de muestreo de 48 a 44.1 kHz no incluye un filtro de paso bajo). Se RECOMIENDA 16 bits; no se aplicó ninguna interpolación para 24 bits. Solo FLAC (.flac)
MP3 Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps MP3 (.mp3)
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.
  • Tipos 0 y 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • Inalámbrico (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 y versiones posteriores)
PCM/WAVE PCM lineal de 16 bits (las tasas llegan hasta el límite del hardware). Los dispositivos DEBEN admitir tasas de muestreo para la grabación PCM sin procesar a frecuencias de 8000, 11025, 16000 y 44100 Hz. WAVE (.wav)
Opus Matroska (.mkv) y Ogg(.ogg)

5.1.4. Codificación de imágenes

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

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

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

5.1.5 Decodificación de imágenes

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

Las implementaciones del dispositivo DEBEN admitir la codificación de la siguiente decodificació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

5.1.6. Detalles de los códecs de imagen

Formato/códec Detalles Tipos de archivos/formatos de contenedor admitidos
JPEG Básica + progresiva JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Voraz ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.7 Códecs de video

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

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

  • [C-1-1] Los códecs de video DEBEN admitir tamaños de búfer de bytes de entrada y salida que se adapten al mayor fotograma comprimido y sin comprimir posible según lo determine el estándar y la configuración, pero tampoco de manera general.

  • [C-1-2] Los codificadores y decodificadores de video DEBEN ser compatibles con el formato de color flexible YUV420 (COLOR_FormatYUV420Flexible).

Si las implementaciones de dispositivos anuncian la compatibilidad con perfiles HDR a través de Display.HdrCapabilities, sucederá lo siguiente:

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

Si las implementaciones de dispositivos anuncian la compatibilidad con actualizaciones internas a través de FEATURE_IntraRefresh en la clase MediaCodecInfo.CodecCapabilities, harán lo siguiente:

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

5.1.8. Lista de códecs de video

Formato/códec Detalles Tipos de archivo/formatos de contenedor
admitidos
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC Consulta los artículos 5.2 y 5.3 para obtener más información.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, AAC solo de audio, no permite búsquedas, Android 3.0 o versiones posteriores)
H.265 HEVC Consulta la sección 5.3 para obtener más información. MPEG-4 (.mp4)
MPEG-2 Perfil principal MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 Consulta los artículos 5.2 y 5.3 para obtener más información.
VP9 Consulta la sección 5.3 para obtener más información.

5.2 Codificación de videos

Si las implementaciones de dispositivos admiten cualquier codificador de video y permiten que estén disponibles para apps de terceros, sucederá lo siguiente:

  • En dos ventanas variables, NO DEBERÍA ser, más de ~15% por encima de la tasa de bits entre los intervalos intramarco (I-frame).
  • NO DEBE superar, aproximadamente, el 100% por encima de la tasa de bits en una ventana variable de 1 segundo.

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

  • [C-1-1] DEBE incluir compatibilidad con al menos uno de los codificadores de video VP8 o H.264 y ponerlo a disposición de aplicaciones de terceros.
  • SE RECOMIENDA ser compatible con los codificadores de video VP8 y H.264, y debe estar disponible para aplicaciones de terceros.

Si las implementaciones de dispositivos admiten cualquiera de los codificadores de video H.264, VP8, VP9 o HEVC y hacen que estén disponibles para aplicaciones de terceros, deben hacer lo siguiente:

  • [C-2-1] DEBE admitir tasas de bits configurables dinámicamente.
  • DEBE admitir velocidades de fotogramas variables, en las que el codificador de video DEBE determinar la duración instantánea de los fotogramas según las marcas de tiempo de los búferes de entrada y asignar su intervalo de bits en función de esa duración de fotogramas.

Si las implementaciones de dispositivos admiten el codificador de video MPEG-4 SP y lo ponen a disposición de apps de terceros, deben hacer lo siguiente:

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

5.2.1 H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y permiten que estén disponibles para apps de terceros, deben hacer lo siguiente:

  • [C-1-1] DEBE admitir el perfil de Baseline nivel 45.
  • DEBE admitir tasas de bits configurables de forma dinámica para el codificador compatible.

5.2.2. H‐264

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

  • [C-1-1] DEBE admitir el perfil de Baseline de nivel 3. Sin embargo, la compatibilidad con ASO (ordenamiento arbitrario de porciones), FMO (pedido de macrobloqueo flexible) y RS (porciones redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no usen ASO, FMO ni RS para el perfil de Baseline.
  • [C-1-2] SE DEBE admitir los perfiles de codificación de video SD (definición estándar) que se indican en la siguiente tabla.
  • SE DEBE admitir el perfil principal de nivel 4.
  • SE RECOMIENDA admitir los perfiles de codificación de video HD (alta definición) como se indica en la siguiente tabla.

Si las implementaciones de dispositivos informan la compatibilidad con la codificación H.264 para videos de resolución 720p o 1080p a través de las APIs multimedia, sucede lo siguiente:

  • [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p
Resolución de video 320 × 240 px 720 × 480 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 20 fps 30 fps 30 fps 30 fps
Tasa de bits del video 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3 VP8

Si las implementaciones de dispositivos admiten el códec VP8, harán lo siguiente:

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

Si las implementaciones de dispositivos informan compatibilidad con la codificación VP8 para videos de resolución 720p o 1080p a través de las APIs multimedia, sucederá lo siguiente:

  • [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps
Tasa de bits del video 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

Si las implementaciones de dispositivos admiten el códec VP9, harán lo siguiente:

  • SE RECOMIENDA admitir la escritura de archivos Matroska WebM.

5.3 Decodificación de video

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

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

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

  • [C-2-1] DEBE proporcionar un extractor compatible con Dolby Vision.
  • [C-2-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-2-3] SE DEBE configurar el índice de seguimiento de las capas base retrocompatibles (si están presentes) para que sea el mismo que el índice de seguimiento de la capa combinada de Dolby Vision.

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2, sucederá lo siguiente:

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

5.3.2. H.263

Si las implementaciones de dispositivos admiten decodificadores H.263, sucederá lo siguiente:

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

5.3.3. MPEG-4

Si se implementan en dispositivos con decodificadores MPEG-4, sucederá lo siguiente:

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

5.3.4. H.264

Si las implementaciones de dispositivos admiten decodificadores H.264, sucederá lo siguiente:

  • [C-1-1] DEBE admitir el perfil principal nivel 3.1 y el perfil de Baseline. La compatibilidad con ASO (ordenamiento de Slices arbitrario), FMO (orden de macrobloqueo flexible) y RS (Slices redundantes) es OPCIONAL.
  • [C-1-2] SE DEBE poder decodificar videos con los perfiles SD (definición estándar) que se indican en la siguiente tabla y codificados con el perfil de Baseline y el perfil principal nivel 3.1 (incluida la resolución 720p30).
  • SE DEBE poder decodificar videos con los perfiles HD (alta definición) como se indica en la siguiente tabla.

Si la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución de video, las implementaciones en dispositivos hacen lo siguiente:

  • [C-2-1] DEBE admitir los perfiles de codificación de video HD 720p que se indican en la siguiente tabla.
  • [C-2-2] DEBE admitir los perfiles de codificación de video HD 1080p que se indican en la siguiente tabla.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p
Resolución de video 320 × 240 px 720 × 480 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 30 fps 30 fps 60 fps 30 FPS (60 FPS Televisión)
Tasa de bits del video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5 H.265 (HEVC)

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

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

  • [C-2-1] Las implementaciones en dispositivos DEBEN admitir al menos una decodificación H.265 o VP9 de perfiles 720, 1080 y UHD.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p UHD
Resolución de video 352 × 288 px 720 × 480 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30/60 FPS (60 FPS Televisión con decodificación por hardware H.265) 60 fps
Tasa de bits del video 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3.6. VP8

Si las implementaciones de dispositivos admiten el códec VP8, harán lo siguiente:

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

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

  • [C-2-1] Las implementaciones en dispositivos DEBEN admitir perfiles de 720p en la siguiente tabla.
  • [C-2-2] Las implementaciones en dispositivos DEBEN admitir perfiles de 1080p en la siguiente tabla.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
Velocidad de fotogramas del video 30 fps 30 fps 30 FPS (60 FPS Televisión) 30 (60 FPS Televisión)
Tasa de bits del video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

Si las implementaciones de dispositivos admiten el códec VP9, harán lo siguiente:

  • [C-1-1] DEBE admitir los perfiles de decodificación de video SD como se indica en la siguiente tabla.
  • SE RECOMIENDA admitir los perfiles de decodificación HD como se indica en la siguiente tabla.

Si las implementaciones de dispositivos admiten el códec VP9 y un decodificador de hardware:

  • [C-2-2] DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.

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

  • [C-3-1] Las implementaciones en dispositivos DEBEN admitir al menos una decodificación VP9 o H.265 de los perfiles 720, 1080 y UHD.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p UHD
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 FPS (60 FPS 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

5.4. Grabación de audio

Si bien algunos de los requisitos descritos en esta sección se enumeran como DEBEN a partir de Android 4.3, se planea cambiar la definición de compatibilidad para versiones futuras a DEBE. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con los requisitos que se indican como DEBEN. De lo contrario, no serán compatibles con Android cuando se actualicen a la versión futura.

5.4.1 Captura de audio sin procesar

Si las implementaciones de dispositivos declaran android.hardware.microphone, hará lo siguiente:

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

  • Formato: PCM lineal, 16 bits

  • Tasas de muestreo: 8,000, 11,025, 16,000, 44,100 Hz

  • Canales: Mono

  • [C-1-2] DEBE capturar con tasas de muestreo superiores sin sobremuestreo.

  • [C-1-3] DEBE incluir un filtro de suavizado de contorno adecuado cuando las tasas de muestreo proporcionadas anteriormente se capturan con submuestreo.

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

  • Formato: PCM lineal, 16 bits

  • Tasas de muestreo: 22,050, 48,000 Hz
  • Canales: estéreo

Si las implementaciones de dispositivos permiten la captura con calidad de radio AM y DVD de contenido de audio sin procesar, sucederá lo siguiente:

  • [C-2-1] SE DEBE capturar sin sobremuestreo en cualquier proporción superior a 16000:22050 o 44100:48000.
  • [C-2-2] DEBE incluir un filtro de suavizado de contorno adecuado para cualquier aumento o reducción de muestreo.

5.4.2. Capturar para el reconocimiento de voz

Si las implementaciones de dispositivos declaran android.hardware.microphone, hará lo siguiente:

  • [C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION con una de las tasas de muestreo, 44,100 y 48,000.
  • [C-1-2] DEBE inhabilitar de forma predeterminada el procesamiento de audio con reducción de ruido cuando se graba una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
  • [C-1-3] DEBE inhabilitar de forma predeterminada cualquier control de ganancia automático cuando se graba una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
  • SE DEBE grabar la transmisión de audio mediante reconocimiento de voz con una amplitud aproximadamente plana en comparación con las características de la frecuencia: específicamente, ±3 dB, de 100 Hz a 4000 Hz.
  • SE DEBE grabar la transmisión de audio mediante reconocimiento de voz con la sensibilidad de entrada configurada de modo que una fuente de nivel de potencia de sonido (SPL) de 90 dB a 1000 Hz produzca un RMS de 2500 para muestras de 16 bits.
  • SE DEBE grabar la transmisión de audio de reconocimiento de voz para que los niveles de amplitud de PCM monitoreen linealmente los cambios de SPL de entrada en un rango de al menos 30 dB, entre -18 dB y +12 dB y 90 dB de SPL en el micrófono.
  • SE DEBE grabar la transmisión de audio mediante 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 con el micrófono.

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

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

5.4.3. Captura para el redireccionamiento de la reproducción

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

Si las implementaciones de dispositivos declaran tanto android.hardware.audio.output como android.hardware.microphone, harán lo siguiente:

  • [C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX de modo que cuando una aplicación use la API de android.media.AudioRecord para grabar desde esta fuente de audio, capture una mezcla de todas las transmisiones de audio, excepto las siguientes:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5 Reproducción de audio

Android incluye 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, hará lo siguiente:

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

    • Formato: PCM lineal, 16 bits
    • Tasas de muestreo: 8000, 11025, 16000, 22050, 32000, 44100
    • Canales: Mono, estéreo

  • SE DEBE permitir la reproducción de contenido de audio sin procesar con las siguientes características:

    • Tasas de muestreo: 24,000, 48,000

5.5.2. Efectos de audio

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

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

  • [C-1-1] DEBE admitir las implementaciones 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.
  • SE DEBE admitir las implementaciones EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB y EFFECT_TYPE_VIRTUALIZER controlables a través de las subclases de AudioEffect BassBoost, EnvironmentalReverb, PresetReverb y Virtualizer.

5.5.3. Volumen de audio saliente

Implementaciones en dispositivos de Automotive:

  • SE DEBE permitir ajustar el volumen del audio de forma independiente en cada transmisión de audio con el tipo de contenido o uso, como se define en AudioAttributes, y el uso del audio del vehículo, como se define públicamente en android.car.CarAudioManager.

5.6. Latencia de audio

La latencia de audio es el retraso de tiempo cuando una señal de audio pasa a través de un sistema. Muchas clases de aplicaciones dependen de latencias cortas para lograr efectos de sonido en tiempo real.

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

  • latencia de salida. El intervalo entre el momento en que una aplicación escribe una trama de datos codificados en PCM y el momento en que el sonido correspondiente se presenta al entorno en un transductor o una señal integrados en el dispositivo sale del dispositivo a través de un puerto y se puede observar externamente.
  • latencia de salida en frío. 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. La latencia de salida para los fotogramas posteriores, después de que el dispositivo reproduce audio.
  • latencia de entrada. El intervalo entre el momento en que el entorno presenta un sonido al dispositivo cuando un transductor o la señal del dispositivo ingresa al dispositivo a través de un puerto y cuando una aplicación lee la trama correspondiente de datos codificados en PCM.
  • entrada perdida. La parte inicial de una señal de entrada que no se puede usar o no está disponible.
  • latencia de entrada en frío. La suma del tiempo de entrada perdido y la latencia de entrada de la primera trama cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
  • latencia de entrada continua. La latencia de entrada para los fotogramas posteriores, mientras el dispositivo está capturando audio.
  • Jitter de salida en frío. La variabilidad entre mediciones independientes de valores de latencia de salida en frío.
  • Jitter de entrada en frío. La variabilidad entre mediciones independientes de 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 la señal y que mitigue la diferencia de fase entre las transmisiones 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 nativo de AAudio. Conjunto de APIs de AAudio dentro del NDK de Android.

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

  • [SR] Latencia de salida en frío de 100 milisegundos o menos
  • [SR] Latencia de salida continua de 45 milisegundos o menos
  • [SR] Minimiza el jitter de salida en frío

Si las implementaciones del dispositivo cumplen con los requisitos anteriores después de cualquier calibración inicial cuando se usa la API de 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:

  • [SR] SE RECOMIENDA COMPLETARMENTE informar de audio de baja latencia declarando la marca de función android.hardware.audio.low_latency.
  • [SR] SE RECOMIENDA ENRENDER también cumplir con los requisitos de audio de baja latencia a través de la API de AAudio.

Si las implementaciones de dispositivos no cumplen con los requisitos para audio de baja latencia a través de la API de cola de búfer PCM de OpenSL ES, sucederá lo siguiente:

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

Si las implementaciones de dispositivos incluyen android.hardware.microphone, SE RECOMIENDA ENcarecidamente que cumplan con estos requisitos de audio de entrada:

  • [SR] Latencia de entrada en frío de 100 milisegundos o menos.
  • [SR] Latencia de entrada continua de 30 milisegundos o menos
  • [SR] Latencia de ida y vuelta continua de 50 milisegundos o menos
  • [SR] Minimiza el jitter de entrada en frío

5.7. Protocolos de red

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

Si las implementaciones de dispositivos incluyen un decodificador de audio o video, sucederá 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 tabla de formatos de segmentación de medios a continuación en el protocolo de borrador de transmisión en vivo HTTP, versión 7.

  • [C-1-3] DEBE admitir el siguiente perfil de audio de video de RTP y los códecs relacionados en la tabla RTSP que aparece a continuación. Para conocer las excepciones, consulte las notas al pie de la tabla de la sección 5.1.

Formatos de segmentos de medios

Formatos de segmentos Referencias Compatibilidad con códecs requeridos
MPEG-2 Transport Stream ISO 13818 Códecs de video:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Consulta la sección 5.1.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 AAC y sus variantes.
AAC con enmarcado ADTS y etiquetas ID3 ISO 13818‐7 Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
WebVTT WebVTT

RTSP (RTP, SDP)

Nombre del perfil Referencias Compatibilidad con códecs requeridos
H264 AVC RFC 6184 Consulta la sección 5.1.3 para obtener información detallada acerca de H264 AVC.
MP4A-LATM RFC 6416 Consulta la sección 5.1.1 para obtener detalles sobre 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 información detallada acerca de MPEG-4 SP
MPEG-4-genérico RFC 3640 Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes
MP2T RFC 2250 Consulta MPEG-2 Transport Stream debajo de HTTP Live Streaming para obtener más detalles.

5.8. Contenido multimedia seguro

Si las implementaciones de dispositivos admiten salida de video segura y pueden admitir plataformas seguras, sucederá lo siguiente:

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

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

  • [C-2-1] DEBE asegurar el vínculo con un mecanismo criptográfico seguro, 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 admiten pantallas externas con cable, harán lo siguiente:

  • [C-3-1] DEBE ser compatible con HDCP 1.2 o superior para todas las pantallas externas con cable.

5.9 Interfaz digital para instrumentos musicales (MIDI)

Si las implementaciones de dispositivos informan compatibilidad con la función android.software.midi a través de la clase android.content.pm.PackageManager, harán lo siguiente:

  • [C-1-1] DEBE admitir MIDI en todos los transportes de hardware compatibles con MIDI para los que proporcionan conectividad genérica que no es MIDI, en los casos en que dichos transportes son:

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

5.10. Audio profesional

Si las implementaciones de dispositivos informan compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager, sucede 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, tal 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 admitida.
  • [C-1-3] DEBE incluir uno o más puertos USB que admitan el modo de host USB y el modo periférico USB.
  • [C-1-4] DEBE informar la compatibilidad con la función android.software.midi.
  • [C-1-5] DEBE cumplir con los requisitos de latencia y audio USB con la API de cola de búfer PCM de OpenSL ES.
  • [SR] SE RECOMIENDEN EXITOSAMENTE para proporcionar un nivel coherente de rendimiento de CPU mientras el audio está activo y la carga de la CPU varía. Esto se debe probar con la confirmación 1bd6391 de SimpleSynth. La app de SimpleSynth debe ejecutarse con los siguientes parámetros y no alcanzar ningún subdesbordamiento después de 10 minutos:
    • Ciclos de trabajo: 200,000
    • Carga variable: ACTIVADA (esto cambiará entre el 100% y el 10% de los valores de los ciclos de trabajo cada 2 segundos y está diseñado para probar el comportamiento del regulador de CPU)
    • Carga estabilizada: Desactivada
  • SE DEBE minimizar la imprecisión y la desviación del reloj de audio en relación con la hora estándar.
  • SE DEBE minimizar el desvío del reloj de audio en relación con el CLOCK_MONOTONIC de la CPU cuando ambos están activos.
  • SE DEBE minimizar la latencia de audio en los transductores integrados en el dispositivo.
  • SE DEBE minimizar la latencia de audio mediante audio digital USB.
  • SE RECOMIENDA documentar las mediciones de latencia de audio en todas las rutas de acceso.
  • SE DEBE minimizar el jitter en los tiempos de entrada de devolución de llamada de finalización del búfer de audio, ya que esto afecta el porcentaje utilizable del ancho de banda total de la CPU por parte de la devolución de llamada.
  • SE DEBE proporcionar cero subdesbordamientos (salida) o excesos (entrada) de audio en el uso normal con la latencia informada.
  • SE DEBE proporcionar una diferencia de latencia entre canales de cero.
  • DEBES minimizar la latencia media de MIDI en todos los transportes.
  • SE RECOMIENDA minimizar la variabilidad de la latencia MIDI bajo carga (jitter) en todos los transportes.
  • DEBERÍAS proporcionar marcas de tiempo MIDI precisas en todos los transportes.
  • SE DEBE minimizar el ruido de la señal de audio en los transductores del dispositivo, incluido el período inmediatamente posterior al inicio en frío.
  • SE DEBE proporcionar una diferencia de reloj de audio cero entre los lados de entrada y salida de los puntos finales correspondientes, cuando ambos están activos. Algunos ejemplos de los extremos correspondientes incluyen el micrófono y la bocina integrados en el dispositivo o la entrada y salida del conector de audio.
  • DEBES administrar las devoluciones de llamada de finalización del búfer de audio para los extremos de entrada y salida de los extremos correspondientes en el mismo subproceso cuando ambos estén activos. Luego, se debe ingresar la devolución de llamada de salida inmediatamente después del retorno de la devolución de llamada de entrada. O, si no es posible manejar 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.
  • Se recomienda minimizar la diferencia de fase entre el almacenamiento en búfer de audio HAL para los lados de entrada y salida de los puntos finales correspondientes.
  • SE DEBE minimizar la latencia táctil.
  • SE DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).

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

Si las implementaciones de dispositivos cumplen con los requisitos a través de la API de cola de búfer PCM de OpenSL ES, sucederá lo siguiente:

  • [SR] SE RECOMIENDA ENRENDER también cumplir con los mismos requisitos a través de la API de AAudio.

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

Si las implementaciones de dispositivos omiten un conector de audio de 3.5 mm de 4 conductores e incluyen un puerto USB que admite el modo de host USB, sucederá lo siguiente:

  • [C-3-1] SE DEBE implementar la clase de audio USB.
  • [C-3-2] DEBE tener una latencia de audio de ida y vuelta continua de 20 milisegundos o menos en el puerto del modo de host USB mediante la clase de audio USB.
  • La latencia de audio de ida y vuelta continua DEBE ser de 10 milisegundos o menos en el puerto del modo de host USB mediante la clase de audio USB.

Si las implementaciones de dispositivos incluyen un puerto HDMI, sucederá lo siguiente:

  • [C-4-1] DEBE admitir salidas en estéreo y ocho canales a una profundidad de 20 bits o 24 bits y 192 kHz sin pérdida de profundidad de bits ni remuestreo.

5.11. Captura para contenido sin procesar

Android admite 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 ajuste predeterminado de grabación SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si las implementaciones de dispositivos intentan admitir fuentes de audio sin procesar y hacer que estén disponibles para 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 mostrar características aproximadamente planas de amplitud frente a frecuencia en el rango de frecuencia media: específicamente ±10 dB de 100 Hz a 7,000 Hz para cada micrófono utilizado para grabar la fuente de audio no procesada.

  • [C-1-3] DEBE mostrar niveles de amplitud en el rango de frecuencia baja: específicamente de ±20 dB, de 5 Hz a 100 Hz, en comparación con el rango de frecuencia media de cada uno de los micrófonos utilizados para grabar la fuente de audio no procesada.

  • [C-1-4] DEBE mostrar niveles de amplitud en el rango de frecuencia alta: específicamente de ±30 dB, de 7,000 Hz a 22 KHz, en comparación con el rango de frecuencia media de cada uno de los micrófonos utilizados para grabar la fuente de audio no procesada.

  • [C-1-5] SE DEBE establecer la sensibilidad de entrada de audio de modo que una fuente de tono sinusoidal de 1,000 Hz que se reproduzca a un nivel de presión sonora (SPL) de 94 dB produzca una respuesta con un RMS de 520 para muestras de 16 bits (o -36 dB de escala completa para muestras de punto flotante o de precisión doble) para cada fuente de audio usada para grabar el micrófono sin procesar.

  • El [C-1-6] DEBE tener una relación señal/ruido (SNR) de 60 dB o más para todos y cada uno de los micrófonos utilizados para grabar la fuente de audio no procesada. (mientras que la SNR se mide como la diferencia entre 94 dB del SPL y el SPL equivalente del propio ruido, ponderado A).

  • El [C-1-7] DEBE tener una distorsión armónica total inferior al 1% para 1 kHZ a un nivel de entrada de SPL de 90 dB en cada micrófono utilizado para grabar la fuente de audio no procesada.

  • NO DEBE tener ningún otro procesamiento de señal (p.ej., control automático de ganancia, filtro de paso alto o cancelación de eco) en la ruta que no sea un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:

  • [C-1-8] Si hay procesamiento de señal presente en la arquitectura por algún motivo, se DEBE inhabilitar y, de manera efectiva, introducir cero retraso o latencia adicional en la ruta de acceso de la señal.
  • [C-1-9] Si bien el multiplicador de nivel puede estar en la ruta, NO DEBE generar demora ni latencia en la ruta de acceso de la señal.

Todas las mediciones del SPL se realizan directamente junto al micrófono que se está probando. Para varias configuraciones de micrófono, estos requisitos se aplican a cada micrófono.

Si las implementaciones de dispositivos declaran android.hardware.microphone, pero no admiten fuentes de audio sin procesar, sucederá lo siguiente:

  • [C-2-1] DEBE mostrar null para el método de la API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), a fin de indicar correctamente la falta de compatibilidad.
  • Aún se RECOMIENDA [SR] a fin de cumplir con la mayor cantidad de requisitos de la ruta de acceso de la señal para la fuente de registro no procesada.

6. Compatibilidad de las Herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Implementaciones en dispositivos:

  • [C-0-1] DEBE ser compatible con las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.

  • Android Debug Bridge (adb)

    • [C-0-2] DEBE admitir todas las funciones de adb según se documenta en el SDK de Android, incluida dumpsys.
    • [C-0-3] NO DEBE alterar el formato ni el contenido de los eventos del sistema del dispositivo (batterystats , disquete, huella digital, graphicsstats, netstats, notification, procstats) registrados a través de dumpsys.
    • [C-0-4] DEBE tener el daemon adb del dispositivo 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 admite adb seguro. adb seguro habilita adb en hosts autenticados conocidos.

    • [C-0-6] DEBE proporcionar un mecanismo que permita conectar adb desde una máquina anfitrión. Por ejemplo:

      • Las implementaciones de dispositivos sin puerto USB compatibles con el modo periférico DEBEN implementar adb a través de una red de área local (como Ethernet o Wi-Fi).
      • DEBEN proporcionar controladores para Windows 7, 9 y 10, que permitan a los desarrolladores conectarse al dispositivo mediante el protocolo adb.

  • Servicio Dalvik Debug Monitor (ddms)

    • [C-0-7] DEBE admitir todas las funciones de DDMS, tal como se documenta en el SDK de Android. Dado que ddms usa adb, su compatibilidad DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario activa Android Debug Bridge, como se indicó anteriormente.
  • Mono
    • [C-0-8] DEBE incluir el framework Monkey y ponerlo a disposición de las aplicaciones.
  • SysTrace
    • [C-0-9] DEBE admitir la herramienta systrace tal como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activarlo.

6.2. Opciones para desarrolladores

Android incluye asistencia para que los desarrolladores configuren la configuración relacionada con el desarrollo de aplicaciones.

Las implementaciones en dispositivos DEBEN proporcionar una experiencia coherente para las Opciones para desarrolladores, deben cumplir con lo siguiente:

  • [C-0-1] DEBE respetar el intent android.settings.APPLICATION_DEVELOPMENT_CONFIGURACIÓN para mostrar la configuración relacionada con el desarrollo de la aplicación. La implementación ascendente de Android oculta el menú Opciones para desarrolladores de forma predeterminada y permite que los usuarios inicien estas opciones después de presionar siete (7) veces en el elemento de menú Configuración > Acerca del dispositivo > Número de compilación.
  • [C-0-2] SE DEBE ocultar las Opciones para desarrolladores de forma predeterminada y DEBE proporcionar un mecanismo para habilitarlas sin la necesidad de incluir una lista especial de entidades permitidas.
  • PUEDE limitar temporalmente el acceso al menú Opciones para desarrolladores, con la opción de ocultar o inhabilitar visualmente el menú, para evitar distracciones en situaciones en las que la seguridad del usuario sea de preocupación.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware en particular que tiene una API correspondiente para desarrolladores externos:

  • [C-0-1] La implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android.

Si una API del SDK interactúa con un componente de hardware que se indica como opcional y la implementación del dispositivo no posee ese componente:

  • [C-0-2] Se DEBEN presentar las definiciones completas de la clase (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 una manera razonable.
  • [C-0-4] Los métodos de API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
  • Los métodos de API [C-0-5] DEBEN mostrar implementaciones no-op de clases donde la documentación del SDK no permite valores nulos.
  • [C-0-6] Los métodos de la API NO DEBEN generar excepciones no documentadas en la documentación del SDK.
  • [C-0-7] Las implementaciones de dispositivos DEBEN informar de manera coherente información precisa sobre la configuración del 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 sean teléfonos, estas APIs deben implementarse como no-ops razonables.

7.1. Pantalla y gráficos

Android incluye funciones que ajustan automáticamente los recursos de aplicaciones y los diseños de la IU de manera adecuada para el dispositivo a fin de garantizar que las aplicaciones de terceros se ejecuten bien en una variedad de configuraciones de hardware. Los dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

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

  • tamaño diagonal físico. 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 incluidos en un intervalo lineal, horizontal o vertical de 1". En los casos en que se indican los valores de DPI, los DPI horizontal y vertical deben estar dentro del rango.
  • relación de aspecto. Es la proporción entre los píxeles de la dimensión más larga y la más corta de la pantalla. Por ejemplo, una pantalla de 480 x 854 píxeles sería 854/480 = 1.779 o aproximadamente “16:9”.
  • píxel independiente de la densidad (dp). La unidad de píxeles virtuales normalizada en 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 de la pantalla

El framework de la IU de Android admite varios tamaños lógicos de diseño de pantalla 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.

  • [C-0-1] Las implementaciones en dispositivos DEBEN 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 en dispositivos DEBEN informar las dimensiones de pantalla correctas de píxeles independientes de la densidad (dp) lógica como se muestra a continuación:

    • Los dispositivos con Configuration.uiMode configurado como cualquier valor distinto de UI_MODE_TYPE_WATCH y que informan un tamaño de small para Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
    • Los dispositivos que informan un tamaño de normal para 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 Configuration.screenLayout DEBEN tener, al menos, 960 dp x 720 dp.

  • [C-0-2] Las implementaciones de dispositivos DEBEN respetar correctamente la compatibilidad con tamaños de pantalla indicada por las aplicaciones a través del atributo <supports-screens> en el archivo AndroidManifest.xml, como se describe en la documentación del SDK de Android.

7.1.1.2. Relación de aspecto de la pantalla

Si bien no hay restricciones para el valor de relación de aspecto de la pantalla física, la relación de aspecto de la pantalla lógica de la pantalla lógica en la que se renderizan las apps de terceros, como se puede derivar de los valores de altura y ancho informados a través de las APIs de view.Display y la API de Configuration, DEBE cumplir con los siguientes requisitos:

  • [C-0-1] Las implementaciones en dispositivos con Configuration.uiMode establecido como UI_MODE_TYPE_NORMAL DEBEN tener un valor de relación de aspecto de entre 1.3333 (4:3) y 1.86 (aproximadamente 16:9), a menos que se pueda considerar que la app está lista para extenderse por más tiempo mediante una de las siguientes condiciones:

    • La app declaró que admite una relación de aspecto de pantalla más grande mediante el 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 26 o superior y no declara un android:MaxAspectRatio que restrinja la relación de aspecto permitida.

  • [C-0-2] Las implementaciones en dispositivos con Configuration.uiMode configurado como UI_MODE_TYPE_WATCH DEBEN tener un valor de relación de aspecto establecido en 1.0 (1:1).

7.1.1.3. Densidad de la pantalla

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

  • [C-0-1] De forma predeterminada, las implementaciones de dispositivos DEBEN informar solo una de las siguientes densidades del framework lógico de Android a través de la API de DENSITY_DEVICE_STABLE y este valor NO DEBE cambiar en ningún momento. Sin embargo, ES POSIBLE que el dispositivo informe una densidad arbitraria diferente según los cambios en la configuración de pantalla que realice el usuario (por ejemplo, el tamaño de la pantalla) que se estableció después del inicio.

    • 120 DPI (ldpi)
    • 160 dpi (mdpi)
    • 213 dpi (tvdpi)
    • 240 dpi (hdpi)
    • 260 dpi (260dpi)
    • 280 DPI (280 DPI)
    • 300 dpi (300dpi)
    • 320 dpi (xhdpi)
    • 340 dpi (340dpi)
    • 360 dpi (360dpi)
    • 400 dpi (400dpi)
    • 420 DPI (420 DPI)
    • 480 dpi (xxhdpi)
    • 560 dpi (560dpi)
    • 640 dpi (xxxhdpi)

  • Las implementaciones en dispositivos DEBEN definir la densidad estándar del framework de Android que es numéricamente más cercana a la densidad física de la pantalla, a menos que esa densidad lógica desplace el tamaño de pantalla informado por debajo del mínimo admitido. Si la densidad del framework estándar de Android que es numéricamente más cercana a la densidad física da como resultado un tamaño de pantalla menor que el tamaño de pantalla más pequeño compatible y compatible (320 dp de ancho), las implementaciones de dispositivos DEBEN informar la siguiente densidad del framework estándar de Android más baja.

Si hay una indicación para cambiar el tamaño de visualización del dispositivo, haz lo siguiente:

  • [C-1-1] El tamaño de pantalla NO DEBE ajustarse a más de 1.5 veces la densidad nativa ni producir una dimensión de pantalla mínima efectiva inferior a 320 dp (equivalente al sw320 dp del calificador de recursos), lo que ocurra primero.
  • [C-1-2] El tamaño de la pantalla NO se DEBE ajustar a una escala inferior a 0.85 veces la densidad nativa.
  • Para garantizar una buena usabilidad y tamaños de fuente coherentes, se RECOMIENDA proporcionar la siguiente escala de opciones de anuncios gráficos nativos (siempre y cuando se cumplan los límites especificados anteriormente):
  • Pequeño: 0.85x
  • Predeterminado: 1x (escala de visualización nativa)
  • Grande: 1.15x
  • Más grande: 1.3 veces
  • Mayor 1.45 veces

7.1.2. Métricas de Display

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

  • [C-1-1] DEBE informar los valores correctos para todas las métricas de visualización definidas en la API de android.util.DisplayMetrics.

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

  • [C-2-1] DEBE informar valores razonables para todas las métricas de pantalla definidas en la API de android.util.DisplayMetrics para el view.Display predeterminado emulado.

7.1.3 Orientación de pantalla

Implementaciones en dispositivos:

  • [C-0-1] DEBE informar qué orientaciones de pantalla admiten (android.hardware.screen.portrait o android.hardware.screen.landscape) y DEBE informar, al menos, una orientación compatible. Por ejemplo, un dispositivo con una pantalla horizontal con orientación fija, como una televisión o una laptop, solo DEBE informar android.hardware.screen.landscape.
  • [C-0-2] SE DEBE informar el valor correcto para la orientación actual del dispositivo, siempre que se realice una consulta a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() o alguna otra API.

Si las implementaciones de dispositivos admiten ambas orientaciones de pantalla, sucederá lo siguiente:

  • [C-1-1] DEBE admitir la orientación dinámica de las aplicaciones a la orientación de pantalla vertical u horizontal. Es decir, el dispositivo debe respetar la solicitud de la aplicación respecto de una orientación de pantalla específica.
  • [C-1-2] NO DEBE cambiar la densidad o el tamaño de pantalla informados cuando se cambia la orientación.
  • PUEDES seleccionar la orientación vertical u horizontal como opción predeterminada.

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

7.1.4.1 OpenGL ES

Implementaciones en dispositivos:

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

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

  • [C-1-1] DEBE admitir OpenGL ES 1.0 y 2.0, tal como se detalla en la documentación del SDK de Android.
  • [SR] SE RECOMIENDA COMPLETAMENTE ser compatible con OpenGL ES 3.0.
  • SE DEBE admitir OpenGL ES 3.1 o 3.2.

Si las implementaciones de dispositivos admiten alguna de las versiones de OpenGL ES, sucederá lo siguiente:

  • [C-2-1] SE DEBE informar a través de las APIs nativas y las APIs administradas de OpenGL ES sobre cualquier otra extensión de OpenGL ES que hayan implementado. Por el contrario, NO DEBE informar las cadenas de extensión que no admiten.
  • [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 y EGL_ANDROID_recordable.
  • Se RECOMIENDA [SR] que admitan EGL_KHR_partial_update.
  • SE DEBEN informar con precisión a través del método getString(), cualquier formato de compresión de texturas que admitan, que suele ser específico del proveedor.

Si las implementaciones de dispositivos declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2, suceden lo siguiente:

  • [C-3-1] DEBE exportar los símbolos de función correspondientes a estas versiones, además de los símbolos de función OpenGL ES 2.0 en la biblioteca libGLESv2.so.

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

  • [C-4-1] DEBE admitir el paquete de extensiones de Android para OpenGL ES en su totalidad.

Si las implementaciones de dispositivos admiten el Android Extension Pack de OpenGL ES en su totalidad, sucederá lo siguiente:

  • [C-5-1] SE DEBE identificar la compatibilidad a través de la marca de función android.hardware.opengles.aep.

Si las implementaciones de dispositivos exponen la compatibilidad con la extensión EGL_KHR_mutable_render_buffer, harán lo siguiente:

  • [C-6-1] también DEBE admitir la extensión EGL_ANDROID_front_buffer_auto_refresh.
7.1.4.2 Vulkan

Android admite Vulkan, una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento.

Si las implementaciones de dispositivos admiten OpenGL ES 3.0 o 3.1, significan lo siguiente:

  • [SR] SE RECOMIENDA COMPLETAMENTE incluir compatibilidad con Vulkan 1.0 .

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

  • SE RECOMIENDA incluir compatibilidad con Vulkan 1.0.

Implementaciones en dispositivos, si se incluye compatibilidad con Vulkan 1.0:

  • [C-1-1] DEBE informar el valor de número entero correcto con las marcas de función android.hardware.vulkan.level y android.hardware.vulkan.version.
  • [C-1-2] SE DEBE enumerar, al menos, un VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .
  • [C-1-3] SE DEBE implementar por completo las APIs de Vulkan 1.0 para cada VkPhysicalDevice enumerado.
  • [C-1-4] SE DEBE enumerar las capas, contenidas en bibliotecas nativas denominadas 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 aplicación ni proporcionar otras formas de hacer un seguimiento 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 sí admiten a través de las APIs nativas de Vulkan. Por el contrario , NO DEBE informar cadenas de extensión que no admiten correctamente.

Implementaciones en dispositivos, si no se incluye compatibilidad con Vulkan 1.0:

  • [C-2-1] NO DEBE declarar ninguna de las marcas de función de Vulkan (p.ej., android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NO DEBE enumerar ningún VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices().
7.1.4.3 RenderScript
  • [C-0-1] Las implementaciones en dispositivos DEBEN ser compatibles con Android RenderScript, como se detalla en la documentación del SDK de Android.
7.1.4.4 Aceleración de gráficos 2D

Android incluye un mecanismo para que las aplicaciones declaren que desean habilitar la aceleración de hardware para gráficos 2D a nivel de aplicación, actividad, ventana o vista mediante el uso de una etiqueta de manifiesto android:hardwareAccelerated o llamadas directas a la API.

Implementaciones en dispositivos:

  • [C-0-1] DEBE habilitar la aceleración de hardware de forma predeterminada y DEBE inhabilitarla si el desarrollador lo solicita configurando android:hardwareAccelerated="false” o inhabilitando la aceleración de hardware directamente a través de las API de Android View.
  • [C-0-2] DEBE mostrar un comportamiento coherente con la documentación del SDK de Android sobre aceleración de hardware.

Android incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas de OpenGL ES con aceleración de hardware como objetivos de renderización en una jerarquía de IU.

  • [C-0-3] DEBE ser compatible con la API de TextureView y DEBE mostrar un comportamiento coherente con la implementación ascendente de Android.
7.1.4.5 Pantallas de amplia gama

Si las implementaciones de dispositivos afirman ser compatibles con pantallas de amplia gama a través de Display.isWideColorGamut() , sucede lo siguiente:

  • [C-1-1] DEBE tener una pantalla con calibración de color.
  • [C-1-2] DEBE tener una pantalla cuyo gamut cubra el gamut de colores sRGB por completo en el espacio CIE 1931 xyY.
  • [C-1-3] DEBE tener una pantalla cuyo gamut tenga un área de al menos el 90% de NTSC 1953 en el espacio xyY de CIE 1931.
  • [C-1-4] DEBE ser compatible con OpenGL ES 3.0, 3.1 o 3.2, y se debe informar correctamente.
  • [C-1-5] DEBE promocionar la compatibilidad con las extensiones EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear y EGL_GL_colorspace_display_p3.
  • [SR] SE RECOMIENDA MUY BIEN apoyar a GL_EXT_sRGB.

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

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

7.1.5 Modo de compatibilidad de aplicaciones heredadas

Android especifica un "modo de compatibilidad" en el que el framework opera en un modo de tamaño de pantalla "normal" equivalente (320 dp de ancho) para el beneficio de aplicaciones heredadas no desarrolladas para versiones anteriores de Android que son anteriores a la independencia del tamaño de la pantalla.

7.1.6. Tecnología de pantalla

La plataforma de Android incluye API que permiten a las aplicaciones renderizar gráficos enriquecidos en la pantalla. 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.

Implementaciones en dispositivos:

  • [C-0-1] DEBE ser compatible con pantallas capaces de renderizar gráficos de colores de 16 bits.
  • SE RECOMIENDA admitir pantallas que admitan gráficos de color de 24 bits.
  • [C-0-2] DEBE admitir pantallas capaces de renderizar animaciones.
  • [C-0-3] SE DEBE usar la tecnología de pantalla que tenga una relación de aspecto de píxeles (PAR) entre 0.9 y 1.15. Es decir, la relación de aspecto de los píxeles DEBE ser cercana al cuadrado (1.0) con una tolerancia del 10% al 15%.

7.1.7 Pantallas secundarias

Android incluye compatibilidad con la pantalla secundaria para habilitar las capacidades de uso compartido de contenido multimedia y APIs para desarrolladores para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa, ya sea a través de una conexión con cable, inalámbrica o una conexión de pantalla adicional incorporada, hacen lo siguiente:

  • [C-1-1] SE DEBE implementar el servicio del sistema y la API de DisplayManager como se describe en la documentación del SDK de Android.

7.2. Dispositivos de entrada

Implementaciones en dispositivos:

7.2.1. Teclado

Si las implementaciones de dispositivos incluyen compatibilidad con aplicaciones de terceros del Editor de método de entrada (IME), sucederá lo siguiente:

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.tecla (QWERTY o teclas de 12 teclas). SE RECOMIENDA incluir implementaciones adicionales de teclado en pantalla. * PUEDE incluir un teclado de hardware.

7.2.2. Navegación no táctil

Android incluye compatibilidad con pad direccional, bola de seguimiento y rueda como mecanismos de navegación no táctil.

Implementaciones en dispositivos:

Si las implementaciones de dispositivos no tienen navegaciones no táctiles, sucede lo siguiente:

  • [C-1-1] DEBE proporcionar un mecanismo de interfaz de usuario alternativo razonable para la selección y edición de texto que sea compatible con los motores de administración de entradas. La implementación ascendente de código abierto de Android incluye un mecanismo de selección adecuado para su uso con dispositivos que carecen de entradas de navegación no táctiles.

7.2.3. Teclas de navegación

Las funciones Inicio, Recientes y Atrás que, por lo general, se proporcionan mediante la interacción con un botón físico dedicado o una parte distinta de la pantalla táctil, son esenciales para el paradigma de navegación de Android y, por lo tanto, son implementaciones en dispositivos:

  • [C-0-1] DEBE proporcionar una indicación visual de usuario para iniciar aplicaciones instaladas que tienen una actividad con el <intent-filter> establecido con ACTION=MAIN y CATEGORY=LAUNCHER o CATEGORY=LEANBACK_LAUNCHER para implementaciones de dispositivos de televisión. La función Inicio DEBE ser el mecanismo de esta indicación del usuario.
  • SE DEBE proporcionar botones para las funciones Recientes y Atrás.

Si se proporcionan las funciones Inicio, Recientes o Atrás, significan lo siguiente:

  • Se DEBE poder acceder al [C-1-1] con una sola acción (p.ej., tocar, hacer doble clic o gesto) cuando se puede acceder a cualquiera de ellas.
  • [C-1-2] DEBE proporcionar una indicación clara de qué acción activaría cada función. Tener un ícono visible impreso en el botón, mostrar un ícono de software en la parte de la barra de navegación de la pantalla o guiar al usuario a través de un flujo de demostración guiado paso a paso durante la experiencia de configuración lista para usar son ejemplos de esta indicación.

Implementaciones en dispositivos:

  • Se RECOMIENDA [SR] no proporcionar el mecanismo de entrada para la función Menú, ya que dejó de estar disponible y se reemplazó por la barra de acciones a partir de Android 4.0.

Si las implementaciones de dispositivos proporcionan la función Menú, sucederá lo siguiente:

  • [C-2-1] SE DEBE mostrar el botón de ampliación de acciones 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 ampliación de acciones que se muestra seleccionando el botón de menú ampliado en la barra de acciones, pero PUEDE representarla en una posición modificada en la pantalla cuando se muestra seleccionando la función Menú.

Si las implementaciones de dispositivos no proporcionan la función de menú, para la retrocompatibilidad, harán lo siguiente:

  • [C-3-1] DEBE hacer que la función Menú esté disponible para las aplicaciones cuando targetSdkVersion es inferior a 10, ya sea por un botón físico, una tecla de software o gestos. Se debe poder acceder a esta función de menú, a menos que esté oculta junto con otras funciones de navegación.

Si las implementaciones de dispositivos proporcionan la función Assist, hacen lo siguiente:

  • [C-4-1] DEBE permitir el acceso a la función de asistencia con una sola acción (por ejemplo, tocar, hacer doble clic o gesto) cuando otras teclas de navegación están disponibles.
  • [SR] SE RECOMIENDA ENRENDER que se mantenga presionada la función 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, harán lo siguiente:

  • [C-5-1] Las teclas de navegación DEBEN usar una parte distinta de la pantalla, no están disponibles para las aplicaciones, y NO DEBEN oscurecer ni interferir de ninguna otra manera la parte de la pantalla disponible para las aplicaciones.
  • [C-5-2] DEBE poner una parte de la pantalla a disposición de las aplicaciones que cumplan con los requisitos definidos en la sección 7.1.1.
  • [C-5-3] DEBE respetar las marcas establecidas por la app a través del método de la API View.setSystemUiVisibility() para que esta parte distinta de la pantalla (también conocida como barra de navegación) esté oculta correctamente, como se documenta en el SDK.

7.2.4. Entrada de pantalla 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 falsos. Las implementaciones de dispositivos basados en pantallas táctiles se asocian con una pantalla de modo que el usuario tenga la impresión de manipular directamente elementos en pantalla. Dado que el usuario está tocando directamente la pantalla, el sistema no requiere indicaciones adicionales para indicar los objetos que se están manipulando.

Implementaciones en dispositivos:

  • SE RECOMIENDA tener algún tipo de sistema de entrada de puntero (ya sea similar al de un mouse o táctil).
  • SE RECOMIENDA admitir punteros con seguimiento independiente en su totalidad.

Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor), sucederá lo siguiente:

  • [C-1-1] SE DEBE informar TOUCHSCREEN_FINGER para el campo de API Configuration.touchscreen.
  • [C-1-2] SE DEBE informar las marcas de función android.hardware.touchscreen y android.hardware.faketouch.

Si las implementaciones del dispositivo incluyen una pantalla táctil que puede rastrear más de un toque, sucederá lo siguiente:

  • [C-2-1] DEBE informar las marcas de función correspondientes android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand correspondientes al tipo de pantalla táctil específica del dispositivo.

Si las implementaciones de dispositivos no incluyen una pantalla táctil (y dependen solo de un dispositivo apuntador) y cumplen con los requisitos de acciones táctiles falsas de la sección 7.2.5, sucederá lo siguiente:

  • [C-3-1] NO DEBE informar ninguna marca de función que comience con android.hardware.touchscreen, y DEBE informar solo de android.hardware.faketouch.

7.2.5. Entrada táctil falsa

La interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un subconjunto de capacidades de pantalla táctil. Por ejemplo, un mouse o un control remoto que impulsa un cursor en pantalla se aproxima al tacto, pero requiere que el usuario primero apunte o enfoque y, luego, haga clic. Varios 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 función constante android.hardware.faketouch, que corresponde a un dispositivo de entrada de alta fidelidad no táctil (basado en puntero), como un mouse o un panel táctil que puede emular de forma adecuada una entrada táctil (incluida la compatibilidad básica con gestos), e indica que el dispositivo admite un subconjunto emulado de funcionalidad de pantalla táctil.

Si las implementaciones de dispositivos no incluyen una pantalla táctil, pero sí otro sistema de entrada de puntero que desean que esté disponible, sucede lo siguiente:

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

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

  • [C-1-1] DEBE informar las posiciones X e Y absolutas de la pantalla de la ubicación del puntero y mostrar un puntero visual en la pantalla.
  • [C-1-2] DEBE informar un evento táctil con el código de acción que especifica el cambio de estado que se produce cuando el puntero hacia abajo o hacia arriba en la pantalla.
  • [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en pantalla, lo que permite a los usuarios emular el toque en un objeto en pantalla.
  • [C-1-4] DEBE admitir puntero hacia abajo, puntero hacia arriba, puntero hacia abajo y, luego, 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 presionar dos veces en un objeto en pantalla.
  • [C-1-5] DEBE admitir el puntero hacia abajo en un punto arbitrario de la pantalla, el puntero se mueve a cualquier otro punto arbitrario de la pantalla y el puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
  • [C-1-6] DEBE admitir el puntero hacia abajo y, luego, permitir a los usuarios mover rápidamente el objeto a una posición diferente en la pantalla y, luego, apuntar hacia arriba en la pantalla, lo que permite a los usuarios desplazar un objeto en la pantalla.
  • [C-1-7] DEBE informar TOUCHSCREEN_NOTOUCH para el campo de API Configuration.touchscreen.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.distinct, sucederá lo siguiente:

  • [C-2-1] DEBE declarar compatibilidad con android.hardware.faketouch.
  • [C-2-2] DEBE admitir un seguimiento distinto de dos o más entradas de puntero independientes.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.faketouch.multitouch.jazzhand, sucederá lo siguiente:

  • [C-3-1] DEBE declarar compatibilidad con android.hardware.faketouch.
  • [C-3-2] DEBE admitir un seguimiento distinto de 5 (seguimiento de una mano de dedos) o más entradas del puntero de forma completamente independiente.

7.2.6. Compatibilidad con controles de juegos

7.2.6.1. Asignaciones de botones

Si las implementaciones de dispositivos declaran la marca de función android.hardware.gamepad, sucederá lo siguiente:

  • [C-1-1] DEBE tener incorporado un controlador o enviarlo con un controlador separado en la caja, ya que eso proporcionaría medios para ingresar todos los eventos que se indican en las siguientes tablas.
  • [C-1-2] DEBE ser capaz de asignar eventos HID a sus constantes view.InputEvent de Android asociadas, como se indica en las siguientes tablas. La implementación ascendente de Android incluye una implementación para controles de juegos que cumple con este requisito.
Botón Uso de HID2 Botón de Android
R1 0x09 0x0001. KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x090x0004. KEYCODE_BUTTON_X (99)
A1 0x090x0005. KEYCODE_BUTTON_Y (100)
Pad direccional arriba1
Pad direccional abajo1 		0x01 0x00393 AXIS_HAT_Y4
Pad direccional izquierdo1
Pad direccional derecha1 		0x01 0x00393 AXIS_HAT_X4
Botón del hombro izquierdo1 0x090x0007. KEYCODE_BUTTON_L1 (102)
Botón del hombro derecho1 0x09 0x0008. KEYCODE_BUTTON_R1 (103)
Clic con la palanca izquierda1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Clic derecho1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Página principal1 0x0c 0x0223 KEYCODE_HOME (3)
Atrás1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores se deben declarar en una CA de pad para juegos (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 del informe de 4. El valor lógico se define como la rotación en el sentido de las manecillas del reloj fuera del eje vertical; por ejemplo, un valor lógico de 0 representa la ausencia de rotación y el botón Arriba se presiona, mientras que un valor lógico de 1 representa una rotación de 45 grados y que se presionan las teclas Arriba y la izquierda.

4 MotionEvent

Controles analógicos1 Uso de HID Botón de Android
Activador izquierdo 0x02 0x00C5 AXIS_LTRIGGER
Activador derecho 0x02 0x00C4 AXIS_RTRIGGER
Joystick izquierdo 0 × 01 0 × 0030
0 × 01 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 los dispositivos.

7.3 Sensores

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, la implementación de dispositivos DEBE implementar esa API como se describe en la documentación del SDK de Android y en la documentación de código abierto de Android sobre sensors.

Implementaciones en dispositivos:

  • [C-0-1] DEBE informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager.
  • [C-0-2] DEBE mostrar una lista precisa de los sensores admitidos por medio 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, mostrar true o false según corresponda cuando las aplicaciones intenten registrar objetos de escucha y no llamar a objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etc.).

Si las implementaciones de dispositivos incluyen un tipo de sensor particular que tiene una API correspondiente para desarrolladores externos, hacen lo siguiente:

  • [C-1-1] DEBE informar todas las mediciones de los sensores con los valores correspondientes del sistema internacional de unidades (métrica) para cada tipo de sensor, como se define en la documentación del SDK de Android.
  • [C-1-2] DEBE informar los datos del sensor con una latencia máxima de 100 milisegundos.
  • 2 × sample_time para el caso de que se transmita un sensor con una latencia mínima requerida de 5 ms + 2 × sample_time cuando el procesador de la aplicación esté activo. Esta demora no incluye ninguna demora en el filtrado.
  • [C-1-3] DEBE informar la primera muestra del sensor dentro de los 400 milisegundos + 2 * sample_time del sensor que se está activando. La exactitud aceptable de esta muestra es 0.

  • [SR] SE DEBE informar la hora del evento en nanosegundos, como se define en la documentación del SDK de Android, que represente la hora en que ocurrió el evento y se sincronizó con el reloj SystemClock.elapsedRealtimeNano(). Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma, en las que se podría convertir en un componente OBLIGATORIO. El error de sincronización DEBE ser inferior a 100 milisegundos.

  • [C-1-7] Para que cualquier API indicada en la documentación del SDK de Android sea un sensor continuo, las implementaciones de dispositivos DEBEN proporcionar continuamente muestras de datos periódicas que DEBEN tener un Jitter inferior al 3%, en el que el Jitter se define como la desviación estándar de la diferencia de los valores de marca de tiempo informados entre eventos consecutivos.

  • [C-1-8] DEBE asegurarse de que la transmisión de eventos del sensor NO DEBE evitar que la CPU del dispositivo entre en un estado de suspensión ni se active después de un estado de suspensión.

  • Cuando se activan varios sensores, el consumo de energía NO DEBE superar la suma del consumo de energía informado del sensor individual.

La lista anterior no es exhaustiva; el comportamiento documentado del SDK de Android y las Documentación de código abierto de Android sobre sensors se debe considerar autorizado.

Algunos tipos de sensores son compuestos, lo que significa que pueden derivarse de los datos proporcionados por uno o más sensores. (algunos ejemplos incluyen el sensor de orientación y el sensor de aceleración lineal).

Implementaciones en dispositivos:

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

Si las implementaciones de dispositivos incluyen un sensor compuesto, sucederá lo siguiente:

  • [C-2-1] SE DEBE implementar el sensor como se describe en la documentación de código abierto de Android sobre sensores compuestos.

7.3.1. Acelerómetro

  • Las implementaciones en dispositivos DEBEN incluir un acelerómetro de 3 ejes.

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

  • [C-1-1] DEBE ser capaz de informar eventos con una frecuencia de al menos 50 Hz.
  • [C-1-2] SE DEBE implementar e informar el sensor TYPE_ACCELEROMETER.
  • [C-1-3] DEBE cumplir con el sistema de coordenadas del sensor de Android como se detalla en las APIs de Android.
  • [C-1-4] DEBE ser capaz de medir desde una caída libre hasta cuatro veces la gravedad(4g) o más en cualquier eje.
  • [C-1-5] DEBE tener una resolución de al menos 12 bits.
  • [C-1-6] DEBE tener una desviación estándar no superior a 0.05 m/s^, en la que la desviación estándar se debe calcular por eje en las muestras obtenidas durante un período de al menos 3 segundos a la tasa de muestreo más rápida.
  • [SR] SE RECOMIENDA ENRENDER implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION.
  • Se recomienda encarecidamente que [SR] implemente el sensor TYPE_ACCELEROMETER_UNCALIBRATED si la calibración del acelerómetro en línea está disponible.
  • SE RECOMIENDA implementar los sensores compuestos de TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR y TYPE_STEP_COUNTER como se describe en el documento del SDK de Android.
  • SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.
  • DEBE tener una resolución de al menos 16 bits.
  • SE DEBE calibrar mientras está en uso si las características cambian durante el ciclo de vida y se compensan, y se conservan los parámetros de compensación entre los reinicios del dispositivo.
  • SE DEBE compensar la temperatura.
  • También se DEBE implementar el sensor TYPE_ACCELEROMETER_UNCALIBRATED.

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes y se implementan cualquiera de los sensores compuestos de TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR y TYPE_STEP_COUNTER, haz lo siguiente:

  • [C-2-1] La suma de su consumo de energía DEBE ser siempre inferior a 4 mW.
  • Cuando el dispositivo esté en condiciones dinámicas o estáticas, SE DEBE ser inferior a 2 mW y 0.5 mW cada uno.

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

  • [C-3-1] DEBE implementar los sensores compuestos de TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
  • SE DEBE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR.
  • [SR] SE RECOMIENDA ENcarecidamente que se usen dispositivos Android nuevos y existentes para implementar el sensor TYPE_GAME_ROTATION_VECTOR.

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

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

7.3.2. Magnetómetro

  • Las implementaciones en dispositivos DEBEN incluir un magnetómetro de 3 ejes (brújula).

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

  • [C-1-1] SE DEBE implementar el sensor TYPE_MAGNETIC_FIELD.
  • [C-1-2] SE DEBE poder informar eventos con una frecuencia de al menos 10 Hz. A su vez, SE DEBE informar eventos de hasta 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 ser capaz de medir entre -900 μT y +900 μT en cada eje antes de saturar.
  • [C-1-5] DEBE tener un valor de desplazamiento de hierro resistente inferior a 700 μT y DEBERÍA tener un valor inferior a 200 μT. Para ello, coloca el magnetómetro lejos de los campos magnéticos dinámicos (inducidos por la corriente) y estáticos (inducidos por imanes).
  • [C-1-6] DEBE tener una resolución igual o mayor que 0.6 μT.
  • [C-1-7] DEBE admitir la calibración en línea y la compensación del sesgo de hierro resistente, y conservar los parámetros de compensación entre los reinicios del dispositivo.
  • [C-1-8] SE DEBE aplicar la compensación de hierro blando: la calibración se puede realizar mientras se usa o durante la producción del dispositivo.
  • [C-1-9] DEBE tener una desviación estándar, calculada por eje en las muestras recopiladas durante un período de al menos 3 segundos a la tasa de muestreo más rápida, no superior a 1.5 μT; SE DEBE tener una desviación estándar no superior a 0.5 μT.
  • Se DEBE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] SE RECOMIENDA ENcarecidamente que se usen dispositivos Android nuevos y existentes para 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 de giroscopio, sucederá lo siguiente:

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

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes o un acelerómetro, harán lo siguiente:

  • PUEDES implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, un acelerómetro y un sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR, sucederá lo siguiente:

  • [C-3-1] DEBE consumir menos de 10 mW.
  • SE DEBE consumir menos de 3 mW cuando el sensor está registrado en el modo por lotes a 10 Hz.

7.3.3. GPS

Implementaciones en dispositivos:

  • SE DEBE incluir un receptor GPS/GNSS.

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

  • [C-1-1] DEBE admitir salidas de ubicación a una tasa de al menos 1 Hz cuando se solicita a través de LocationManager#requestLocationUpdate.
  • [C-1-2] SE DEBE poder determinar la ubicación en un cielo abierto (señales fuertes, insignificantes de ruta múltiple, HDOP < 2) en un plazo de 10 segundos (tiempo rápido hasta la primera corrección), cuando se conecta a una conexión a Internet de 0.5 Mbps o más velocidad de datos. Por lo general, este requisito se cumple con algún tipo de técnica de GPS/GNSS asistido o previsto para minimizar el tiempo de bloqueo del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y la efeméris/reloj del satélite).
    • [SR] Después de realizar el cálculo de la ubicación, se RECOMIENDA ENRENDER que el dispositivo pueda determinar su ubicación a cielo abierto en un plazo de 10 segundos, cuando se reinicien las solicitudes de ubicación, hasta una hora después del cálculo inicial de la ubicación, incluso cuando la solicitud posterior se realice sin una conexión de datos o después de un reinicio.

  • En condiciones a cielo abierto después de determinar la ubicación, mientras estás detenido o en movimiento a menos de 1 metro por segundo al cuadrado de aceleración:

    • [C-1-3] DEBE poder determinar la ubicación dentro de los 20 metros y la velocidad dentro de los 0.5 metros por segundo, al menos el 95% de las veces.
    • [C-1-4] DEBE realizar un seguimiento y, también, informar simultáneamente mediante GnssStatus.Callback al menos 8 satélites de una constelación.
    • DEBERÍAS poder realizar un seguimiento simultáneo de al menos 24 satélites de múltiples constelaciones (por ejemplo, GPS +, al menos, uno de los objetos Glonass, Beidou, Galileo).
    • [C-1-5] DEBE informar la generación de tecnología GNSS a través de la API de prueba “getGnssYearOfHardware”.
    • [SR] Continúa enviando salidas normales de ubicación por GPS/GNSS durante una llamada telefónica de emergencia.
    • [SR] Informa las mediciones del GNSS de todas las constelaciones rastreadas (como se informa en los mensajes GnssStatus), excepto en el caso de SBAS.
    • [SR] Informe de AGC y frecuencia de medición del GNSS.
    • [SR] Informa todas las estimaciones de precisión (incluidas el rumbo, la velocidad y la vertical) como parte de cada ubicación GPS.
    • Se RECOMIENDA ENCENDER A [SR] que cumpla con la mayor cantidad posible de los requisitos adicionales obligatorios para los dispositivos que informan el año “2016” o “2017” a través de la API de prueba LocationManager.getGnssYearOfHardware().

Si las implementaciones de dispositivos incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps y la API de prueba de LocationManager.getGnssYearOfHardware() informan el año "2016" o más reciente, sucederá lo siguiente:

  • [C-2-1] DEBE informar las mediciones de GPS, tan pronto como se encuentran, incluso si una ubicación calculada a partir del GPS/GNSS todavía no se informó.
  • [C-2-2] DEBE informar pseudorrangos y velocidades de pseudorrango de GPS que, en condiciones a cielo abierto después de determinar la ubicación, mientras se encuentra en movimiento o con menos de 0.2 metros por segundo de aceleración, son suficientes para calcular la posición dentro de 20 metros y la velocidad dentro de 0.2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos incluyen un receptor GPS/GNSS e informan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps y la API de prueba de LocationManager.getGnssYearOfHardware() informan el año "2017" o más reciente, sucederá lo siguiente:

  • [C-3-1] DEBE continuar enviando salidas normales de ubicación GPS/GNSS durante una llamada telefónica de emergencia.
  • [C-3-2] DEBE informar las mediciones GNSS de todas las constelaciones rastreadas (como se informa en los mensajes GnssStatus), a excepción de SBAS.
  • [C-3-3] SE DEBE informar el AGC y la frecuencia de la medición del GNSS.
  • [C-3-4] DEBE informar todas las estimaciones de precisión (incluidas las orientaciones, la velocidad y la vertical) como parte de cada ubicación GPS.

7.3.4. Giroscopio

Implementaciones en dispositivos:

  • SE RECOMIENDA incluir un giroscopio (sensor de cambio angular).
  • NO SE DEBE incluir un sensor de giroscopio, a menos que también se incluya un acelerómetro de 3 ejes.

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

  • [C-1-1] DEBE ser capaz de informar eventos con una frecuencia de al menos 50 Hz.
  • [C-1-2] SE DEBE implementar el sensor de TYPE_GYROSCOPE y también DEBE implementar el sensor de TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] DEBE ser capaz de medir los cambios de orientación de hasta 1,000 grados por segundo.
  • [C-1-4] DEBE tener una resolución de 12 bits o más y DE 16 bits o más.
  • [C-1-5] SE DEBE compensar la temperatura.
  • [C-1-6] SE DEBE calibrar y compensar mientras se usa, además de conservar los parámetros de compensación entre reinicios del dispositivo.
  • [C-1-7] DEBE tener una varianza no superior a 1e-7 rad^2 / s^2 por Hz (varianza por Hz o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero DEBE estar limitada por este valor. En otras palabras, si mides la varianza del giroscopio a una tasa de muestreo de 1 Hz, NO DEBE ser superior a 1e-7 rad^2/s^2.
  • [SR] SE RECOMIENDA ENcarecidamente que se usen dispositivos Android nuevos y existentes para implementar el sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • [SR] SE RECOMIENDA QUE el error de la calibración sea inferior a 0.01 rad/s cuando el dispositivo está quieto a temperatura ambiente.
  • SE RECOMIENDA informar eventos de hasta 200 Hz como mínimo.

Si las implementaciones de dispositivos incluyen un giroscopio, un sensor acelerómetro y un sensor magnetómetro, sucederá lo siguiente:

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

Si las implementaciones de dispositivos incluyen un giroscopio y un sensor acelerómetro, harán lo siguiente:

  • [C-3-1] DEBE implementar los sensores compuestos de TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
  • [SR] SE RECOMIENDA ENcarecidamente que se usen dispositivos Android nuevos y existentes para implementar el sensor TYPE_GAME_ROTATION_VECTOR.
  • SE DEBE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barómetro

  • Las implementaciones en dispositivos DEBEN incluir un barómetro (sensor de presión de aire ambiental).

Si las implementaciones en dispositivos incluyen un barómetro, hacen lo siguiente:

  • [C-1-1] SE DEBE implementar e informar el sensor de TYPE_PRESSURE.
  • [C-1-2] DEBE ser capaz de transmitir eventos a 5 Hz o más.
  • [C-1-3] SE DEBE compensar la temperatura.
  • [SR] SE RECOMIENDA ENRENDADAMENTE poder informar las mediciones de presión en el rango de 300 hPa a 1,100 hPa.
  • SE DEBE tener una precisión absoluta de 1 hPa.
  • SE DEBE tener una precisión relativa de 0.12 hPa sobre el rango de 20 hPa (equivalente a una exactitud de ~1 m por sobre el cambio de ~200 m a nivel del mar).

7.3.6. Termómetro

Implementaciones en dispositivos: PUEDEN incluir un termómetro de ambiente (sensor de temperatura). PUEDE, pero NO DEBERÍA incluir un sensor de temperatura de la CPU.

Si las implementaciones de dispositivos incluyen un termómetro de ambiente (sensor de temperatura), sucederá lo siguiente:

  • [C-1-1] DEBE definirse como SENSOR_TYPE_AMBIENT_TEMPERATURE y DEBE medir en grados Celsius la temperatura ambiente (de la habitación o la cabina del vehículo) desde donde el usuario interactúa con el dispositivo.
  • [C-1-2] DEBE definirse como SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] SE DEBE medir la temperatura de la CPU del dispositivo.
  • [C-1-4] NO DEBES medir ninguna otra temperatura.

Ten en cuenta que el tipo de sensor SENSOR_TYPE_TEMPERATURE dejó de estar disponible en Android 4.0.

7.3.7. Fotómetro

  • Las implementaciones del dispositivo PUEDEN incluir un fotómetro (sensor de luz ambiente).

7.3.8. sensor de proximidad

  • Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad.

Si las implementaciones de dispositivos incluyen un sensor de proximidad, sucederá 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 cercanos a la pantalla, ya que la intención principal de este tipo de sensor es detectar un teléfono en uso por el usuario. Si las implementaciones 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, como se define en esta sección, y los ponen a disposición de apps de terceros, deben hacer lo siguiente:

  • [C-1-1] DEBE identificar la función 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, hará lo siguiente:

  • [C-2-1] DEBE tener un sensor TYPE_ACCELEROMETER con las siguientes características:

    • DEBE tener un rango de medición entre -8 g y +8 g.
    • DEBE tener una resolución de medición de al menos 1024 LSB/G.
    • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 400 uG/√ Hz.
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 3,000 eventos de sensores.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 3 mW.
    • SE DEBE tener una estabilidad de sesgo de ruido estacionario de \<15 μg √Hz a partir de un conjunto de datos estático de 24 h.
    • SE RECOMIENDA tener un cambio de sesgo respecto a la temperatura de ≤ +/- 1 mg / °C.
    • SE RECOMIENDA tener una no linealidad de la línea que mejor se ajuste a ≤ 0.5% y un cambio de sensibilidad en comparación con la temperatura de ≤ 0.03%/C°.
    • SE DEBE tener un espectro de ruido blanco para garantizar una calificación adecuada de la integridad del ruido del sensor.

  • [C-2-2] DEBE tener una TYPE_ACCELEROMETER_UNCALIBRATED con los mismos requisitos de calidad que TYPE_ACCELEROMETER.

  • [C-2-3] DEBE tener un sensor TYPE_GYROSCOPE con las siguientes características:

    • DEBE tener un rango de medición de al menos -1,000 y +1,000 dps.
    • DEBE tener una resolución de medición de al menos 16 LSB/dps.
    • DEBE tener una frecuencia de medición mínima de 12.5 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 400 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 0.014 °/s/√ Hz.
    • SE DEBE tener una estabilidad de sesgo estacionaria de < 0.0002 °/s √Hz a partir de un conjunto de datos estático de 24 horas.
    • SE RECOMIENDA tener un cambio de sesgo respecto a la temperatura de ≤ +/- 0.05 °/ s / °C.
    • SE RECOMIENDA cambiar la sensibilidad frente a la temperatura de ≤ 0.02% / °C.
    • SE DEBE tener una no linealidad de la línea más adecuada de ≤ 0.2%.
    • SE DEBE tener una densidad de ruido igual o superior a ≤ 0.007 °/s/√ Hz.
    • SE DEBE tener un espectro de ruido blanco para garantizar una calificación adecuada de la integridad del ruido del sensor.
    • Cuando el dispositivo está quieto, SE DEBE tener un error de calibración inferior a 0.002 rad/s en un rango de temperatura de 10 a 40 °C.

  • [C-2-4] DEBE tener una 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 las siguientes características:
    • DEBE tener un rango de medición de al menos -900 y +900 uT.
    • DEBE tener una resolución de medición de al menos 5 LSB/uT.
    • DEBE tener una frecuencia de medición mínima de 5 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 50 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 0.5 uT.
  • [C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GEOMAGNETIC_FIELD y, además:
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 600 eventos de sensores.
    • SE DEBE tener un espectro de ruido blanco para garantizar una calificación adecuada de la integridad del ruido del sensor.
  • [C-2-7] DEBE tener un sensor TYPE_PRESSURE con las siguientes características:
    • DEBE tener un rango de medición de al menos 300 y 1,100 hPa.
    • DEBE tener una resolución de medición de al menos 80 LSB/hPa.
    • DEBE tener una frecuencia de medición mínima de 1 Hz o inferior.
    • DEBE tener una frecuencia de medición máxima de 10 Hz o superior.
    • DEBE tener un ruido de medición que no supere los 2 Pa/√Hz.
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 300 eventos de sensores.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 2 mW.
  • [C-2-8] DEBE tener un sensor TYPE_GAME_ROTATION_VECTOR con las siguientes características:
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 300 eventos de sensores.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 4 mW.
  • [C-2-9] DEBE tener un sensor TYPE_SIGNIFICANT_MOTION con las siguientes características:
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
  • [C-2-10] DEBE tener un sensor TYPE_STEP_DETECTOR que cumpla con las siguientes características:
    • DEBE implementar una forma de este sensor que no sea activa con una capacidad de almacenamiento en búfer de al menos 100 eventos de sensores.
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
    • DEBE tener un consumo de energía por lotes que no sea inferior a 4 mW.
  • [C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER que cumpla con las siguientes características:
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
  • [C-2-12] DEBE tener un sensor TILT_DETECTOR que cumpla con las siguientes características:
    • DEBE tener un consumo de energía que no sea inferior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando el dispositivo está en movimiento.
  • [C-2-13] La marca de tiempo del mismo evento físico que informa el acelerómetro, el sensor del giroscopio y el magnetómetro DEBE tener una diferencia de 2.5 milisegundos.
  • [C-2-14] DEBE tener marcas de tiempo de eventos del sensor del giroscopio en la misma base de tiempo que el subsistema de la cámara y dentro de 1 milisegundos desde el error.
  • [C-2-15] DEBE entregar las 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 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 si se habilita cualquier combinación de los siguientes sensores:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] PUEDE tener un sensor TYPE_PROXIMITY, pero, si está presente, DEBE tener una capacidad 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 del sensor: el sensor, cualquier circuito de soporte, cualquier sistema de procesamiento de sensores dedicado, etcétera.

Si las implementaciones de dispositivos incluyen compatibilidad directa con el sensor, sucederá lo siguiente:

  • [C-3-1] DEBE declarar correctamente la compatibilidad con los tipos de canales directos y el nivel de tarifas 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 canal directo del sensor para todos los sensores que declaran la compatibilidad con el canal directo del sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • SE DEBE admitir la generación de informes de eventos a través del canal directo del sensor para el sensor principal (variante sin activación) de los siguientes tipos:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensor de huellas digitales

Si las implementaciones en dispositivos incluyen una pantalla de bloqueo segura, sucederá lo siguiente:

  • SE DEBE incluir un sensor de huellas dactilares.

Si las implementaciones de dispositivos incluyen un sensor de huellas dactilares y hacen que este esté disponible para apps de terceros, sucederá lo siguiente:

  • [C-1-1] DEBE declarar compatibilidad con la función android.hardware.fingerprint.
  • [C-1-2] DEBE implementar completamente la API correspondiente como se describe en la documentación del SDK de Android.
  • [C-1-3] DEBE tener una tasa de aceptación de falsos no superior al 0.002%.
  • [SR] SE RECOMIENDA ENcarecidamente tener una tasa de aceptación de falsificaciones e impostores que no supere el 7%.
  • [C-1-4] DEBE divulgar que este modo puede ser menos seguro que un PIN, un patrón o una contraseña seguros y enumerar claramente los riesgos de habilitarlo si las tasas de aceptación de falsificación de identidad y impostores son superiores al 7%.
  • [C-1-5] SE DEBE limitar la frecuencia de intentos durante al menos 30 segundos después de cinco pruebas falsas para la verificación de huella digital.
  • [C-1-6] DEBE tener una implementación de un almacén de claves guardadas en hardware y realizar la coincidencia de huellas digitales en un entorno de ejecución confiable (TEE) o en un chip con un canal seguro hacia el TEE.
  • [C-1-7] DEBE tener todos los datos identificables de la huella digital encriptados y autenticados de manera criptográfica de modo que no puedan adquirirse, leerse ni alterarse fuera del entorno de ejecución confiable (TEE), tal como se documenta en los lineamientos de implementación en el sitio del Proyecto de código abierto de Android.
  • [C-1-8] DEBE evitar agregar una huella digital sin primero establecer una cadena de confianza pidiéndole al usuario que confirme la credencial de dispositivo existente o 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-9] NO DEBE habilitar aplicaciones de terceros para distinguir huellas dactilares individuales.
  • [C-1-10] DEBE respetar la marca DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • Cuando se actualiza desde una versión anterior a Android 6.0, SE DEBE migrar o quitar de manera segura los datos de la huella digital para cumplir con los requisitos anteriores.
  • [SR] SE RECOMIENDA ENcarecidamente tener una tasa de rechazo falso inferior al 10%, según las mediciones del dispositivo.
  • [SR] SE RECOMIENDA ENcarecidamente tener una latencia inferior a 1 segundo, medida desde el momento en que se toca el sensor de huellas dactilares hasta que se desbloquea la pantalla, para un dedo registrado.
  • DEBES usar el ícono de huella dactilar de Android que se proporciona en el Proyecto de código abierto de Android.

7.3.11. Sensores exclusivos de Android Automotive

Los sensores específicos de Automotive se definen en el android.car.CarSensorManager API.

7.3.11.1. Engranaje actual

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

7.3.11.2. Modo noche día

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

7.3.11.3. Estado de la conducción

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

7.3.11.4. Velocidad de las ruedas

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

7.3.12. Sensor de postura

Implementaciones en dispositivos:

  • PUEDE admitir el sensor de poses con 6 grados de libertad.

Si las implementaciones de dispositivos admiten el sensor de poses con 6 grados de libertad, harán lo siguiente:

  • [C-1-1] SE DEBE implementar e informar el sensor TYPE_POSE_6DOF.
  • [C-1-2] DEBE ser más preciso que el vector de rotación solo.

7.4. Conectividad de datos

7.4.1 Telefonía

El término "Telefonía", tal como utilizan las API de Android, y este documento hace referencia específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS a través de una red GSM o CDMA. Si bien estas llamadas de voz pueden o no cambiarse de paquetes, se usan para que Android se considere independientemente de cualquier conectividad de datos que se pueda implementar usando la misma red. En otras palabras, la funcionalidad y las APIs de "telefonía" de Android se refieren específicamente a las llamadas de voz y los SMS. Por ejemplo, las implementaciones de dispositivos que no pueden realizar llamadas ni enviar o recibir mensajes SMS no se consideran dispositivos de telefonía, independientemente de si usan una red móvil para la conectividad de datos.

  • Android PUEDE usarse en dispositivos que no incluyen hardware de telefonía. Es decir, Android es compatible con dispositivos que no son teléfonos.

Si las implementaciones de dispositivos incluyen telefonía GSM o CDMA, sucederá lo siguiente:

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

Si las implementaciones de dispositivos no incluyen hardware de telefonía:

  • [C-2-1] DEBE implementar las APIs completas como no-ops.
7.4.1.1. Compatibilidad con bloqueo de números

Si las implementaciones de dispositivos informan el android.hardware.telephony feature, harán lo siguiente:

  • [C-1-1] DEBE incluir asistencia para 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 provenientes de un número de teléfono en "BlockedNumberProvider" sin ninguna interacción con las apps. La única excepción ocurre cuando se quita temporalmente el bloqueo de números, como se describe en la documentación del SDK.
  • [C-1-4] NO DEBE escribir al proveedor de registro de llamadas de la plataforma para una llamada bloqueada.
  • [C-1-5] NO DEBE escribirle al proveedor de telefonía para un mensaje bloqueado.
  • [C-1-6] DEBE implementar una IU de administración de números bloqueados, que se abre con el intent que muestra el método TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] NO DEBE permitir que los usuarios secundarios vean o editen los números bloqueados en el dispositivo, ya que la plataforma de Android asume que el usuario principal tiene el control total de los servicios de telefonía, una única instancia, en el dispositivo. Todas las IUs relacionadas con el bloqueo DEBEN estar ocultas para los usuarios secundarios, y la lista de entidades bloqueadas DEBE respetarse.
  • SE 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, sucederá lo siguiente:

  • [C-SR] SE RECOMIENDA EXITOSAMENTE para 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 pulsación breve de un evento de tecla durante una llamada en curso.
    • Llama a Connection.onAnswer() cuando se detecte una pulsación breve de un evento de tecla durante una llamada entrante.
    • Llama a Connection.onReject() cuando se detecte la acción de mantener presionado un evento de tecla durante una llamada entrante.
    • Activar o desactivar el estado de silencio de CallAudioState

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones en dispositivos:

  • SE DEBE incluir compatibilidad con uno o más formularios de 802.11.

Si las implementaciones de dispositivos incluyen compatibilidad con 802.11 y exponen la funcionalidad a una aplicación de terceros,

  • [C-1-1] DEBE implementar la API de Android correspondiente.
  • [C-1-2] SE DEBE informar la marca de función de hardware android.hardware.wifi.
  • [C-1-3] DEBE implementar la API de multicast como se describe en la documentación del SDK.
  • [C-1-4] DEBE admitir DNS multidifusión (mDNS) y NO filtrar paquetes mDNS (224.0.0.251) en ningún momento de la operación, lo que incluye:
    • incluso cuando la pantalla no esté activa.
    • Para implementaciones en dispositivos de Android Television, incluso en estados de energía en espera
  • SE DEBE aleatorizar la dirección MAC de origen y el número de secuencia de los marcos de solicitud de sondeo una vez al comienzo de cada análisis mientras el STA esté desconectado.
    • Cada grupo de tramas de solicitud de sondeo que conforma un análisis debe usar una dirección MAC coherente (NO SE DEBE aleatorizar la dirección MAC a mitad del análisis).
    • El número de secuencia de la solicitud de sondeo debe iterarse con normalidad (de forma secuencial) entre las solicitudes de sondeo de un análisis
    • El número de secuencia de la solicitud de sondeo debe ser aleatorio entre la última solicitud de sondeo de un análisis y la primera solicitud de sondeo del siguiente análisis.
  • Solo se DEBE permitir los siguientes elementos de información en los marcos de solicitud de sondeo, mientras el STA esté desconectado:
    • Conjunto de parámetros de SSID (0)
    • Conjunto de parámetros de DS (3)
7.4.2.1. Wi-Fi directo

Implementaciones en dispositivos:

  • Se recomienda incluir compatibilidad con Wi-Fi directo (Wi-Fi entre pares).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi directo, sucederá lo siguiente:

  • [C-1-1] DEBE implementar la API de Android correspondiente 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.
  • DEBE admitir operaciones de Wi-Fi y Wi-Fi directo en simultáneo.

Implementaciones en dispositivos:

Si las implementaciones de dispositivos incluyen compatibilidad con TDLS y TDLS está habilitado por la API de WifiManager, sucederá lo siguiente:

  • [C-1-1] DEBE declarar la compatibilidad con TDLS a través de WifiManager.isTdlsSupported.
  • DEBE usar TDLS solo cuando sea posible Y beneficioso.
  • SE DEBE tener una heurística y NO usar TDLS cuando su rendimiento podría ser peor que el de pasar por el punto de acceso Wi-Fi.
7.4.2.3 Reconocimiento de Wi-Fi

Implementaciones en dispositivos:

  • Se recomienda incluir compatibilidad con Wi-Fi Aware.

Si las implementaciones de dispositivos incluyen compatibilidad con el reconocimiento de Wi-Fi y exponen la funcionalidad a apps de terceros, sucederá lo siguiente:

  • [C-1-1] SE 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 reconocimiento de Wi-Fi al mismo tiempo.
  • [C-1-4] DEBE aleatorizar la dirección de la interfaz de administración de reconocimiento de Wi-Fi a intervalos que no superen los 30 minutos, siempre que se habilite esa función.
7.4.2.4. Passpoint para Wi-Fi

Implementaciones en dispositivos:

Si las implementaciones en dispositivos incluyen compatibilidad con Wi-Fi Passpoint, ocurrirá lo siguiente:

  • [C-1-1] DEBE implementar las APIs de WifiManager relacionadas con Passpoint, como se describe en la documentación del SDK.
  • [C-1-2] DEBE ser compatible con el estándar IEEE 802.11u, relacionado específicamente con el descubrimiento y la selección de redes, como el servicio de publicidad genérica (GAS) y el protocolo de consulta de red de acceso (ANQP).

En cambio, si las implementaciones de dispositivos no incluyen compatibilidad con Wi-Fi Passpoint, haz lo siguiente:

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

7.4.3. Bluetooth

Si las implementaciones de dispositivos admiten el perfil de audio Bluetooth, sucederá lo siguiente:

  • DEBE admitir Códecs de audio avanzados y códecs de audio Bluetooth (p.ej., LDAC).

Si las implementaciones de dispositivos declaran la función android.hardware.vr.high_performance, hará lo siguiente:

  • [C-1-1] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE.

Android admite Bluetooth y Bluetooth de bajo consumo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo, sucederá lo siguiente:

  • [C-2-1] DEBE declarar las funciones relevantes de la plataforma (android.hardware.bluetooth y android.hardware.bluetooth_le respectivamente) e implementar las APIs de la plataforma.
  • SE DEBE implementar perfiles de Bluetooth relevantes, como A2DP, AVCP, OBEX, etc., según corresponda para el dispositivo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo, sucederá lo siguiente:

  • [C-3-1] SE 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 en android.bluetooth.
  • [C-3-3] SE DEBE informar el valor correcto de BluetoothAdapter.isOffloadedFilteringSupported() para indicar si se implementó la lógica de filtrado para las clases de API ScanFilter.
  • [C-3-4] SE DEBE informar el valor correcto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo.
  • SE DEBE admitir la transferencia de la lógica de filtrado al chipset de Bluetooth cuando se implementa la API de ScanFilter.
  • SE DEBE admitir la transferencia del escaneo por lotes al chipset Bluetooth.

  • SE DEBE admitir anuncios múltiples con al menos 4 espacios.

  • [SR] RECOMIENDA implementar un tiempo de espera de dirección privada resolvable (RPA) de no más de 15 minutos y rotar la dirección en el tiempo de espera para proteger la privacidad del usuario.

7.4.4. Comunicaciones de campo cercano

Implementaciones en dispositivos:

  • SE DEBE incluir un transceptor y el hardware relacionado para las comunicaciones 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 si 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 que esté disponible para apps de terceros, deben hacer lo siguiente:

  • [C-1-1] SE DEBE informar el atributo android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature().
  • DEBE ser capaz de leer y escribir mensajes NDEF a través de los siguientes estándares NFC como se indica a continuación:
  • [C-1-2] DEBE ser capaz de actuar como lector/escritor de NFC Forum (según se define en la especificación técnica NFCForum-TS-DigitalProtocol-1.0 del foro de NFC) mediante los siguientes estándares de NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Tipos de etiquetas del foro de NFC 1, 2, 3, 4, 5 (definidas por NFC Forum)

  • [SR] SE RECOMIENDA SER capaz de leer y escribir mensajes NDEF, así como datos sin procesar a través de los siguientes estándares NFC. Ten en cuenta que, si bien los estándares de NFC se indican como MUY RECOMENDADOS, se planea que la definición de compatibilidad para una versión futura cambie a DEBE. Estos estándares son opcionales en esta versión, pero serán obligatorios en versiones futuras. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan esta versión de Android cumplan con estos requisitos ahora para que puedan actualizarse a versiones futuras de la plataforma.

  • [C-1-3] DEBE ser capaz de transmitir y recibir datos a través de los siguientes estándares y protocolos entre pares:

  • ISO 18092
  • LLCP 1.2 (definida por el Foro de NFC)
  • SDP 1.0 (definido por NFC Forum)
  • Protocolo de envío NDEF
  • SNEP 1.0 (definido por NFC Forum)
  • [C-1-4] DEBE incluir compatibilidad con Android Beam y SE DEBE habilitar Android Beam de forma predeterminada.
  • [C-1-5] DEBE poder enviar y recibir contenido con Android Beam cuando esté habilitado Android Beam o cuando se active otro modo P2p NFC de propiedad.
  • [C-1-6] DEBE implementar el servidor predeterminado de SNEP. Los mensajes NDEF válidos que recibe el servidor SNEP predeterminado DEBEN enviarse a las aplicaciones mediante el intent android.nfc.ACTION_NDEF_DISCOVERED. Inhabilitar Android Beam en la configuración NO DEBE inhabilitar el envío de mensajes NDEF entrantes.
  • [C-1-7] DEBE respetar el intent android.settings.NFCSHARING_SETTINGS para mostrar la configuración de uso compartido de NFC.
  • [C-1-8] DEBE implementar el servidor NPP. Los mensajes recibidos por el servidor NPP DEBEN procesarse del mismo modo que el servidor predeterminado SNEP
  • [C-1-9] DEBE implementar un cliente SNEP e intentar enviar P2P NDEF saliente al servidor SNEP predeterminado cuando Android Beam está habilitado. Si no se encuentra ningún servidor SNEP predeterminado, el cliente DEBE intentar enviar a un servidor NPP.
  • [C-1-10] DEBE permitir que las actividades en primer plano establezcan el mensaje P2P NDEF saliente usando android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback y android.nfc.NfcAdapter.enableForegroundNdefPush.
  • SE DEBE usar un gesto o una confirmación en pantalla, como “Tocar para transmitir”, antes de enviar mensajes P2P NDEF salientes.
  • [C-1-11] DEBE admitir el traspaso de la conexión NFC a Bluetooth cuando el dispositivo es compatible con el perfil de envío de objetos Bluetooth.
  • [C-1-12] DEBE admitir el traspaso de la conexión a Bluetooth cuando se usa android.nfc.NfcAdapter.setBeamPushUris. Para ello, se deben implementar las especificaciones “Connection Handover versión 1.2” y “Vinculación simple y segura por Bluetooth con NFC versión 1.0” del foro de NFC. Dicha implementación DEBE implementar el servicio LLCP de traspaso con el nombre de servicio “urn:nfc:sn:handover” para intercambiar la solicitud de transferencia/seleccionar registros a través de NFC, y DEBE usar el perfil push de objetos Bluetooth para la transferencia de datos Bluetooth. Por motivos heredados (para seguir siendo compatible con dispositivos Android 4.1), la implementación DEBE aceptar solicitudes de SNEP GET para intercambiar la solicitud de transferencia o seleccionar registros a través de NFC. Sin embargo, una implementación por sí misma NO DEBE enviar solicitudes SNEP GET para realizar el traspaso de la conexión.
  • [C-1-13] SE DEBE sondear todas las tecnologías compatibles en el modo de descubrimiento de NFC.
  • DEBES estar en el modo de descubrimiento de NFC mientras el dispositivo está activo con la pantalla activa y la pantalla bloqueada desbloqueada.
  • SE 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 JIS, ISO y NFC Forum citadas anteriormente).

Android admite el modo de emulación de tarjeta de host NFC (HCE).

Si las implementaciones de dispositivos incluyen un chipset del controlador NFC capaz de HCE (para NfcA o NfcB) y que admiten el enrutamiento de Application ID (AID), deben hacer lo siguiente:

  • [C-2-1] DEBE informar la constante de función android.hardware.nfc.hce.
  • [C-2-2] DEBE ser compatible con las APIs de NFC HCE según se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen un chipset del controlador NFC capaz de HCE para NfcF e implementan la función para aplicaciones de terceros, deben hacer lo siguiente:

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 la función de lector/escritor:

  • [C-4-1] SE DEBE implementar las API de Android correspondientes según se documenta en el SDK de Android.
  • [C-4-2] SE DEBE informar el atributo 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, por lo tanto, no aparece como una constante en la clase android.content.pm.PackageManager.

7.4.5. Capacidad de red mínima

Implementaciones en dispositivos:

  • [C-0-1] DEBE incluir compatibilidad con una o más formas de red de datos. Específicamente, las implementaciones en dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos con capacidad de 200 Kbit/s o superior. Algunos ejemplos de tecnologías que cumplen este requisito incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet, número PAN Bluetooth, etcétera.
  • [C-0-2] DEBE incluir una pila de red IPv6 y admitir la comunicación IPv6 usando las APIs administradas, como java.net.Socket y java.net.URLConnection, además de las APIs nativas, como los sockets AF_INET6.
  • [C-0-3] SE DEBE habilitar IPv6 de forma predeterminada.
  • DEBE asegurarse de que la comunicación IPv6 sea tan confiable como IPv4, por ejemplo.
  • [C-0-4] DEBE mantener la conectividad IPv6 en modo Descanso.
  • [C-0-5] El límite de frecuencia NO DEBE provocar que el dispositivo pierda conectividad IPv6 en ninguna red compatible con IPv6 que use ciclos de vida con RA de al menos 180 segundos.
  • También se DEBE admitir, al menos, un estándar común de datos inalámbricos, como 802.11 (Wi-Fi), cuando un estándar de red físico (como Ethernet) es la conexión de datos principal.
  • PUEDE implementar más de una forma de conectividad de datos.

El nivel requerido de compatibilidad con IPv6 depende del tipo de red, de la siguiente manera:

Si las implementaciones de dispositivos admiten redes Wi-Fi, sucederá lo siguiente:

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

Si las implementaciones de dispositivos son compatibles con redes Ethernet, sucederá lo siguiente:

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

Si las implementaciones de dispositivos admiten datos móviles:

  • [C-3-1] DEBE cumplir con estos requisitos simultáneamente en cada red a la que está conectado cuando un dispositivo está conectado simultáneamente a más de una red (p.ej., Wi-Fi y datos móviles), .
  • SE RECOMIENDA admitir la operación IPv6 (solo IPv6 y posiblemente de pila doble) en datos móviles.

7.4.6. Configuración de sincronización

Implementaciones en dispositivos:

  • [C-0-1] DEBE tener activada la sincronización automática de la instancia principal de forma predeterminada para que el método getMasterSyncAutomatically() muestre el valor “true”.

7.4.7. Ahorro de datos

Si las implementaciones en dispositivos incluyen una conexión de uso medido, son las siguientes:

  • [SR] SE RECOMIENDA COMPLETAMENTE proporcionar el modo de Ahorro de datos.

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

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

  • [C-2-1] SE DEBE mostrar el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().
  • [C-2-2] NO DEBE transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] DEBE tener una actividad que controle el intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, pero PUEDE implementarla como una no-op.

7.5 Cámaras

Si las implementaciones en dispositivos incluyen al menos una cámara, sucederá lo siguiente:

  • [C-1-1] DEBE declarar la marca de función android.hardware.camera.any.
  • [C-1-2] DEBE ser posible para que una aplicación asigne simultáneamente 3 mapas de bits RGBA_8888 igual al tamaño de las imágenes producidas por el sensor de la cámara de mayor resolución en el dispositivo, mientras la cámara está abierta para obtener una vista previa básica y capturar imágenes.

7.5.1 Cámara posterior

Una cámara posterior es una cámara ubicada en el lado del dispositivo opuesto a la pantalla; es decir, captura escenas en el lado más alejado del dispositivo, como una cámara tradicional.

Implementaciones en dispositivos:

  • SE RECOMIENDA incluir una cámara posterior.

Si las implementaciones en dispositivos incluyen al menos una cámara posterior, sucederá lo siguiente:

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

Si la cámara incluye flash:

  • [C-2-1] La lámpara de flash NO DEBE encenderse mientras se registra 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 del sistema integrada 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 suele usar para generar imágenes del usuario, como videoconferencias y aplicaciones similares.

Implementaciones en dispositivos:

  • PUEDE incluir una cámara frontal

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

  • [C-1-1] SE DEBE informar la marca de función android.hardware.camera.any y android.hardware.camera.front.
  • [C-1-2] DEBE tener una resolución de, al menos, VGA (640 x 480 píxeles).
  • [C-1-3] NO DEBE usar una cámara frontal como predeterminada para la API de cámara y NO DEBE configurar la API para que considere una cámara frontal como la cámara posterior predeterminada, incluso si es la única cámara del dispositivo.
  • [C-1-5] 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 solicitó de manera explícita que se rote la pantalla de la cámara llamando al método android.hardware.Camera.setDisplayOrientation(). Por el contrario, la vista previa DEBE reflejarse en el eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicita explícitamente que se rote la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation().
  • [C-1-6] NO DEBE duplicar la imagen estática final ni las transmisiones de video capturadas que se devuelven a las devoluciones de llamada de la aplicación ni se guardan en el almacenamiento de medios.
  • [C-1-7] DEBE reflejar la imagen que muestra la vista previa del mismo modo que el flujo de imágenes de vista previa de la cámara.
  • PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras posteriores, según se describe en la sección 7.5.1.

Si el usuario puede rotar las implementaciones de dispositivos (por ejemplo, de forma automática mediante un acelerómetro o de forma manual mediante una entrada del usuario):

  • [C-2-1] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.

7.5.3 Cámara externa

Implementaciones en dispositivos:

  • PUEDE incluir compatibilidad con una cámara externa que no siempre está conectada.

Si las implementaciones de dispositivos incluyen compatibilidad con una cámara externa, sucederá lo siguiente:

  • [C-1-1] SE DEBE declarar las marcas de función android.hardware.camera.external y android.hardware camera.any de la plataforma.
  • [C-1-2] DEBE ser compatible con la clase de video USB (UVC 1.0 o superior) si la cámara externa se conecta a través del puerto USB.
  • SE RECOMIENDA admitir compresiones de video como MJPEG para permitir la transferencia de transmisiones de alta calidad sin codificación (es decir, transmisiones de imagen sin procesar o comprimidas de forma independiente).
  • PUEDE admitir varias cámaras.
  • PUEDE admitir la codificación de video basada en la cámara. Si es compatible, la implementación del dispositivo DEBE poder acceder a una transmisión MJPEG o sin codificación simultánea (QVGA o superior resolución).

7.5.4. Comportamiento de la API de Camera

Android incluye dos paquetes de API para acceder a la cámara. La nueva API de android.hardware.camera2 expone el control de cámara de nivel inferior a la app, incluidos flujos eficientes de ráfaga o transmisión de copias cero y controles por fotograma de exposición, ganancia, ganancia de balance de blancos, conversión de color, reducción de ruido, nitidez, entre otros.

El paquete de API anterior, android.hardware.Camera, se marcó como obsoleto en Android 5.0, pero debería estar disponible para que lo usen las apps. Las implementaciones en dispositivos Android DEBEN garantizar la compatibilidad continua de la API, tal como se describe en esta sección y en el SDK de Android.

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las API relacionadas con la cámara para todas las cámaras disponibles. Implementaciones en 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 el 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 predeterminado.
  • [C-0-3] DEBE admitir el formato YV12 (como indica la constante android.graphics.ImageFormat.YV12) para las vistas previas de las cámaras frontal y posterior de android.hardware.Camera. (El codificador de video de hardware y la cámara pueden usar cualquier formato de píxeles nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
  • [C-0-4] DEBE admitir los formatos android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como salidas a través de la API de android.media.ImageReader para dispositivos android.hardware.camera2 que anuncian la función REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities.
  • [C-0-5] DE todas formas 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 de hardware o alguna otra función. Por ejemplo, las cámaras sin enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no sea relevante para una cámara sin enfoque automático). Ten en cuenta que esto se aplica a las cámaras frontales; por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API deben “simular” de todos modos, 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. Por el contrario, las implementaciones en dispositivos NO DEBEN respetar ni reconocer las constantes de cadena pasadas al método android.hardware.Camera.setParameters() que no sean las documentadas como constantes en android.hardware.Camera.Parameters. Es decir, las implementaciones en dispositivos DEBEN admitir todos los parámetros estándar de Camera si el hardware lo permite, y NO DEBEN admitir tipos de parámetros personalizados de Camera. Por ejemplo, las implementaciones en 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 la cámara Camera.SCENE_MODE_HDR.
  • [C-0-7] DEBE informar el nivel adecuado de compatibilidad con la propiedad android.info.supportedHardwareLevel, como se describe en el SDK de Android, además de las marcas de funciones del framework adecuadas.
  • [C-0-8] también DEBE declarar sus capacidades individuales de cámara de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar las marcas de función adecuadas. DEBE definir la marca de función si alguno de sus dispositivos de cámara conectados la admite.
  • [C-0-9] SE DEBE transmitir el intent Camera.ACTION_NEW_PICTURE cada vez que la cámara toma una nueva foto y la entrada de la imagen se agrega a la tienda de contenido multimedia.
  • [C-0-10] SE DEBE transmitir el intent Camera.ACTION_NEW_VIDEO cada vez que la cámara graba un nuevo video y la entrada de la imagen se agrega a la tienda de contenido multimedia.

7.5.5 Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o posterior, estas cámaras son las siguientes:

  • [C-1-1] 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 mantiene 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 principales horizontales como a los principales verticales.

7.6 Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Implementaciones en dispositivos:

  • [C-0-1] DEBE incluir un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos. Además, DEBE tener la capacidad de descargar archivos individuales de al menos 100 MB de tamaño a la ubicación predeterminada de “caché”.

7.6.2. Almacenamiento compartido de la aplicación

Implementaciones en dispositivos:

  • [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, también denominado “almacenamiento externo compartido”, “almacenamiento compartido de la aplicación” o por la ruta de Linux “/sdcard” en la que está activada.
  • [C-0-2] DEBE configurarse con el almacenamiento compartido activado de forma predeterminada, es decir, “listo para usar”, sin importar si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (p.ej., ranura de tarjeta de Secure Digital).
  • [C-0-3] SE DEBE activar el almacenamiento compartido de la aplicación directamente en la ruta de acceso de Linux sdcard o incluir un vínculo simbólico de Linux de sdcard al punto de activación real.
  • [C-0-4] SE DEBE aplicar el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido, como se documenta en el SDK. De lo contrario, la aplicación que obtenga ese permiso DEBE poder escribir en el almacenamiento compartido.

Las implementaciones en dispositivos PUEDEN cumplir con los requisitos mencionados de alguna de las siguientes maneras:

  • un almacenamiento extraíble al que el usuario puede acceder, como una ranura de tarjeta Secure Digital (SD).
  • una parte del almacenamiento interno (no extraíble), como se implementó en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones de dispositivos usan almacenamiento extraíble para cumplir con los requisitos anteriores, sucederá lo siguiente:

  • [C-1-1] DEBE implementar un aviso o una interfaz de usuario emergente que advierta al usuario cuando no se insertó un medio de almacenamiento en la ranura.
  • [C-1-2] DEBE incluir un medio de almacenamiento con formato FAT (por ejemplo, una tarjeta SD) o aparecer en la caja y otro material disponible en el momento de la compra que indica que el medio de almacenamiento se debe comprar por separado.

Si las implementaciones de dispositivos usan una proporción del almacenamiento no extraíble para cumplir con los requisitos anteriores, sucederá lo siguiente:

  • SE DEBE usar la implementación de 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 incluyen varias rutas de acceso de almacenamiento compartido (como una ranura para tarjeta SD y un almacenamiento interno compartido), hacen lo siguiente:

  • [C-3-1] DEBE permitir que solo las aplicaciones de Android preinstaladas y con privilegios tengan el permiso WRITE_EXTERNAL_STORAGE para escribir en el almacenamiento externo secundario, excepto cuando se escribe en sus directorios específicos del paquete o dentro del URI que se muestra cuando se activa el intent ACTION_OPEN_DOCUMENT_TREE.

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB, sucederá lo siguiente:

  • [C-3-1] DEBE proporcionar un mecanismo para acceder a los datos en el almacenamiento compartido de la aplicación desde una computadora host.
  • SE RECOMIENDA exponer el contenido de ambas rutas de almacenamiento de forma transparente a través del servicio de escáner de contenido multimedia de Android y android.provider.MediaStore.
  • PUEDE utilizar el almacenamiento masivo de USB, pero SE DEBE utilizar el Protocolo de transferencia de medios para cumplir con este requisito.

Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y admiten el Protocolo de transferencia de medios, harán lo siguiente:

  • DEBE ser compatible con el host de MTP de Android de referencia, Android File Transfer.
  • SE DEBE informar una clase de dispositivo USB de 0x00.
  • SE DEBE informar que la interfaz USB es "MTP".

7.6.3. Almacenamiento adoptable

Si se espera que el dispositivo sea móvil, a diferencia de la televisión, las implementaciones en dispositivos son las siguientes:

  • [SR] SE RECOMIENDA ENRENDER A implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlos accidentalmente puede provocar la pérdida o corrupción de datos.

Si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimento de la batería o alguna otra cubierta protectora, las implementaciones del dispositivo:

7.7 USB

Si las implementaciones de dispositivos tienen un puerto USB, tienen las siguientes características:

  • SE DEBE admitir el modo de periférico USB y el modo de host USB.

7.7.1 Modo periférico USB

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo periférico:

  • [C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
  • [C-1-2] SE DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo USB estándar 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 tipo C y DEBE detectar cambios en el anuncio si admiten USB tipo C.
  • [SR] El puerto DEBE usar el factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
  • [SR] El puerto SE DEBE ubicar en la parte inferior del dispositivo (según la orientación natural) o permitir la rotación de la pantalla del software para todas las 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 ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
  • [SR] SE DEBE implementar la compatibilidad para generar una corriente de 1.5 A durante el pitido en el puerto HS y el tráfico, como se especifica en la especificación de la carga de batería USB, revisión 1.2. Se RECOMIENDA ENRENDER que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
  • [SR] SE RECOMIENDA ENRENDER no admitir métodos de carga patentados que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o que alteren los roles de receptor o fuente, por lo que podría causar problemas de interoperabilidad con cargadores o dispositivos compatibles con los métodos estándar de USB Power Delivery. Si bien se dice que esto se recomienda encarecidamente, en versiones futuras de Android es posible que REQUISITOS que todos los dispositivos tipo C sean compatibles con una interoperabilidad completa con cargadores tipo C estándar.
  • [SR] SE RECOMIENDA ENRENDER QUE admita Power Delivery en el intercambio de datos y funciones de batería cuando sea compatible con el modo de host USB y USB tipo C.
  • SE RECOMIENDA admitir Power Delivery para la carga de alto voltaje y compatibilidad con modos alternativos, como visualización de salida.
  • SE DEBE implementar la API de Android Open Accessory (AOA) y las especificaciones tal como se documenta en la documentación del SDK de Android.

En el caso de implementaciones en dispositivos que incluyan un puerto USB, debes implementar la especificación AOA:

  • [C-2-1] DEBE declarar compatibilidad con la función de hardware android.hardware.usb.accessory.
  • [C-2-2] La clase de almacenamiento masivo USB DEBE incluir la cadena "android" al final de la descripción de la interfaz iInterface cadena del almacenamiento masivo USB

7.7.2. Modo de host USB

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

  • [C-1-1] DEBE implementar la API del host de 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] SE DEBE implementar la compatibilidad para conectar periféricos USB estándar; en otras palabras, DEBEN realizar una de las siguientes acciones:
    • Tener un puerto tipo C integrado en el dispositivo o enviar cables que adapten un puerto de propiedad del dispositivo a un puerto USB tipo C estándar (dispositivo USB tipo C).
    • Tener un puerto tipo A integrado en el dispositivo o enviar cables que adapten un puerto propio del dispositivo a un puerto USB tipo A estándar.
    • Tener un puerto micro-AB en el dispositivo que SE DEBE enviar con un cable que se adapte a un puerto estándar tipo A.
  • [C-1-3] NO DEBE enviarse con un adaptador que convierta de puertos USB tipo A o micro-AB a un puerto tipo C (receptáculo).
  • [SR] RECOMIENDA implementar la clase de audio USB como se indica en la documentación del SDK de Android.
  • SE DEBE admitir la carga del dispositivo periférico USB conectado mientras se encuentra en modo host. Se debe anunciar una corriente de fuente de al menos 1.5 A, como se especifica en la sección Parámetros de terminación de la Revisión 1.2 de especificaciones del cable USB tipo C y conector para conectores USB tipo C, o el uso del rango de corriente de salida del puerto de carga descendente(CDP) como se indica en las Especificaciones de carga de la batería USB, revisión 1.2 para los conectores micro-USB.
  • SE DEBE implementar y admitir estándares USB tipo C.

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host y la clase de audio USB, sucederá lo siguiente:

  • [C-2-1] DEBE admitir la clase USB HID.
  • [C-2-2] DEBE admitir la detección y asignación de los siguientes campos de datos HID especificados en las tablas de uso de HID USB y la Solicitud de uso de comandos por voz a las constantes KeyEvent como se muestra a continuación:
    • Página de uso (0xC) ID de uso (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Página de uso (0xC) ID de uso (0x0E9): KEYCODE_VOLUME_UP
    • Página de uso (0xC) ID de uso (0x0EA): KEYCODE_VOLUME_DOWN
    • Página de uso (0xC) ID de uso (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host y el framework de acceso al almacenamiento (SAF), sucederá lo siguiente:

  • [C-3-1] DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia multimedia) conectado de forma remota y permitir el acceso a su contenido a través de los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT. .

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo de host y un USB tipo C, sucederá lo siguiente:

  • [C-4-1] DEBE implementar la funcionalidad del puerto de rol dual según se define en la especificación de USB tipo C (sección 4.5.1.3.3).
  • [SR] SE RECOMIENDA ENRENDER que sea compatible con DisplayPort, SE DEBE admitir las tasas de datos de SuperSpeed de USB, y SE RECOMIENDA ENCIMAMENTE para admitir Power Delivery en el intercambio de datos y funciones.
  • [SR] SE RECOMIENDA ENERCMENTE NO admitir el modo de accesorio del adaptador de audio como se describe en el Apéndice A de la Revisión 1.2 de la Especificación de cables USB tipo C y conector.
  • SE DEBE implementar el modelo Try.* que sea más adecuado para el factor de forma del dispositivo. Por ejemplo, un dispositivo de mano DEBE implementar el modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

Si las implementaciones en dispositivos incluyen un micrófono, sucederá lo siguiente:

  • [C-1-1] DEBE informar la constante de función android.hardware.microphone.
  • [C-1-2] DEBE cumplir con los requisitos de grabación de audio de la sección 5.4.
  • [C-1-3] DEBE cumplir con los requisitos de latencia de audio de la sección 5.6.
  • [SR] SE RECOMIENDA ENERGENTE para admitir la grabación casi ultrasónica, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos omiten un micrófono, sucederán lo siguiente:

  • [C-2-1] NO DEBE informar la constante de función android.hardware.microphone.
  • [C-2-2] SE DEBE implementar la API de grabación de audio al menos como no-ops, según la sección 7.

7.8.2. Salida de audio

Si las implementaciones de dispositivos incluyen un altavoz o un puerto de salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 3.5 mm de 4 conductores o un puerto de modo host USB que usa una clase de audio USB, sucederá 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 de la sección 5.6.
  • [SR] SE RECOMIENDA ESTAR EN FUNDAMENTO para admitir la reproducción casi ultrasónica, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos no incluyen un puerto de salida de audio o bocina, sucederá lo siguiente:

  • [C-2-1] NO DEBE informar la función android.hardware.audio.output.
  • [C-2-2] SE DEBE implementar, al menos, las API relacionadas con la Salida de audio como no-ops.

A los efectos de esta sección, un "puerto de salida" es una interfaz física, como un conector de audio de 3.5 mm, un puerto HDMI o un puerto en modo host USB con clase de audio USB. La compatibilidad con la salida de audio a través de protocolos de radio, como Bluetooth, Wi-Fi o red móvil, no califica como incluir un "puerto de salida".

7.8.2.1. Puertos de audio analógicos

Para que la implementación de un dispositivo sea compatible con auriculares y otros accesorios de audio mediante el conector de audio de 3.5 mm en todo el ecosistema de Android, al menos uno de estos debe ser un conector de audio de 3.5 mm de 4 conductores.

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

  • [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con un micrófono.
  • [C-1-2] DEBE admitir conectores de audio TRRS con el orden de pines CTIA.
  • [C-1-3] DEBE admitir la detección y la asignación de códigos de teclas para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
    • 70 ohm o menos: KEYCODE_HEADSETHOOK
    • 210-290 ohm: KEYCODE_VOLUME_UP
    • 360-680 ohm: KEYCODE_VOLUME_DOWN
  • [C-1-4] DEBE activar ACTION_HEADSET_PLUG al insertar un enchufe, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
  • El [C-1-5] DEBE ser capaz de conducir al menos 150 mV ± 10% del voltaje de salida en una impedancia de bocina de 32 ohm.
  • [C-1-6] DEBE tener una compensación de voltaje del micrófono entre 1.8 V y 2.9 V.
  • [SR] SE RECOMIENDA ENERCMENTE detectar y asignar el código de clave para el siguiente rango de impedancia equivalente entre el micrófono y los conductores de tierra en el enchufe de audio:
    • 110-180 ohm: KEYCODE_VOICE_ASSIST
  • SE RECOMIENDA admitir enchufes de audio con el orden de pines de OMTP.
  • DEBE admitir la grabación de audio de auriculares estéreo con un micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm de 4 conductores y admiten un micrófono, y transmiten el android.intent.action.HEADSET_PLUG con el micrófono de valor adicional establecido en 1, suceden lo siguiente:

  • [C-2-1] DEBE admitir la detección del micrófono en el accesorio de audio conectado.

7.8.3. Casi ultrasónica

El audio casi ultrasónico está en la banda de entre 18.5 kHz y 20 kHz.

Implementaciones en dispositivos:

  • SE DEBE informar correctamente la compatibilidad de la función 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 los siguientes requisitos:

  • [C-1-1] La potencia de respuesta del micrófono en la banda de 18.5 kHz a 20 kHz DEBE ser como máximo 15 dB por debajo de la respuesta a 2 kHz.
  • [C-1-2] La relación señal-ruido no ponderada del micrófono superior a 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS no DEBE ser inferior a 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es "true", haz lo siguiente:

  • [C-2-1] La respuesta media de la bocina en 18.5 kHz a 20 kHz no DEBE ser inferior a 40 dB por debajo de la respuesta a 2 kHz.

7.9 Realidad virtual

Android incluye API e instalaciones para crear aplicaciones de "realidad virtual" (RV), incluidas experiencias de RV móvil de alta calidad. Las implementaciones en dispositivos DEBEN implementar adecuadamente estas APIs y comportamientos, como se detalla en esta sección.

7.9.1 Modo de realidad virtual

Android admite el modo RV, una función que controla la renderización estereoscópica de notificaciones e inhabilita los componentes monoculares de la IU del sistema mientras una aplicación de RV está enfocada en el usuario.

7.9.2. Realidad virtual con alto rendimiento

Si las implementaciones de dispositivos identifican la compatibilidad con RV de alto rendimiento durante períodos más prolongados para los usuarios a través de la marca de función android.hardware.vr.high_performance, harán lo siguiente:

  • [C-1-1] DEBE tener al menos 2 núcleos físicos.
  • [C-1-2] DEBE declarar android.software.vr.mode feature.
  • [C-1-3] DEBE admitir el modo de rendimiento sostenido.
  • [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
  • [C-1-5] DEBE admitir el nivel de hardware de Vulkan 0, y SE DEBE admitir el nivel de hardware de Vulkan 1.
  • [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 y exponer las extensiones en la lista de extensiones EGL disponibles.
  • [C-1-7] La GPU y la pantalla DEBEN sincronizar el acceso al búfer frontal compartido, de modo que se muestre la renderización ocular alternativa del contenido de RV a 60 fps con dos contextos de renderización sin artefactos de seccionamiento visibles.
  • [C-1-8] DEBE implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, GL_EXT_EGL_image_array, GL_EXT_external_buffer y exponer las extensiones en la lista de extensiones de GL disponibles.
  • [C-1-9] SE DEBE implementar compatibilidad con las marcas AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER y AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA de AHardwareBuffer, como se describe en el NDK.
  • [C-1-10] DEBE implementar compatibilidad para AHardwareBuffers con más de una capa.
  • [C-1-11] DEBE ser compatible con la decodificación H.264 de al menos 3840 x 2160 a 30 fps-40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps-10 Mbps o 2 instancias de 1920 x 1080 a 60 fps-20 Mbps).
  • [C-1-12] DEBE ser compatible con HEVC y VP9. DEBE ser capaz de decodificar al menos 1920 x 1080 a 30 fps-10 Mbps y DEBERÍA ser capaz de decodificar 3840 x 2160 a 30 fps-20 Mbps (equivalente a 4 instancias de 1920 x 10 fps).
  • [C-1-13] DEBE admitir la API de HardwarePropertiesManager.getDeviceTemperatures y devolver valores precisos para la temperatura cutánea.
  • El [C-1-14] DEBE tener una pantalla incorporada, y su resolución DEBE ser de al menos FullHD(1080p) y SE RECOMIENDA ES IMPORTANTE PARA SER QuadHD (1440p) o superior.
  • [C-1-15] La pantalla DEBE actualizar al menos 60 Hz en modo RV.
  • [C-1-16] La latencia de la pantalla (según se mide en el tiempo de cambio de Gris a Gris, Blanco a Negro y Negro a Blanco) DEBE ser ≤ 6 milisegundos.
  • [C-1-17] La pantalla DEBE admitir un modo de baja persistencia con una persistencia menor o igual a 5 milisegundos. La persistencia se define como la cantidad de tiempo durante el cual un píxel emite luz.
  • [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE (sección 7.4.3).
  • [C-1-19] DEBE admitir e informar 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-1-20] DEBE admitir el tipo de canal directo TYPE_HARDWARE_BUFFER para todos los tipos de canales directos mencionados anteriormente.
  • [SR] SE RECOMIENDA ENERCMENTE admitir la función android.hardware.sensor.hifi_sensors y DEBEN cumplir con los requisitos relacionados con el giroscopio, el acelerómetro y el magnetómetro de android.hardware.hifi_sensors.
  • PUEDE proporcionar un núcleo exclusivo a la aplicación en primer plano y PUEDE admitir la API de Process.getExclusiveCores para que se devuelvan los números de los núcleos de la CPU que son exclusivos de la aplicación superior en primer plano. Si se admite un núcleo exclusivo, el núcleo DEBE no permitir que se ejecuten otros procesos del espacio del usuario (excepto los controladores de dispositivos que utilice la aplicación), pero PUEDE permitir que se ejecuten algunos procesos de kernel según sea necesario.

8. Rendimiento y potencia

Algunos criterios mínimos de rendimiento y energía son fundamentales para la experiencia del usuario y afectan las suposiciones de referencia que los desarrolladores tendrían al desarrollar una app.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si hay ciertos requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta coherentes para aplicaciones y juegos. Las implementaciones de dispositivos, según el tipo, 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 la E/S de archivos

Proporcionar un modelo de referencia común para un rendimiento coherente de acceso a los 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 ayudaría en el diseño de su software. Las implementaciones de dispositivos, según el tipo, PUEDEN tener ciertos requisitos que se describen en la sección 2 para las siguientes operaciones de lectura y escritura:

  • Rendimiento de la escritura secuencial. Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 10 MB.
  • Rendimiento de escritura aleatoria. Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 4 KB.
  • Rendimiento de la 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

Android incluye los modos de ahorro de energía App Standby y Descanso para optimizar el uso de la batería. [SR] SE RECOMIENDA QUE todas las apps exentas de estos modos sean visibles para el usuario final. [SR] SE RECOMIENDA ESCALAMENTE que la activación, el mantenimiento, los algoritmos de activación y el uso de la configuración global del sistema de estos modos de ahorro de energía NO se desvíen del Proyecto de código abierto de Android.

Además de los modos de ahorro de energía, las implementaciones de dispositivos Android PUEDEN implementar cualquiera o todos los 4 estados de energía suspendida, tal como se define en la Interfaz avanzada de configuración y energía (Advanced Configuration and Power Interface, ACPI).

Si las implementaciones de dispositivos implementan los estados de energía de S3 y S4, según lo definido por el ACPI, hacen lo siguiente:

  • [C-1-1] Solo DEBE ingresar estos estados al cerrar una tapa que sea parte física del dispositivo.

8.4. Contabilidad del consumo de energía

Una contabilización e informes más precisos del consumo de energía le proporciona 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 en dispositivos:

  • [SR] SE RECOMIENDA ELIMINARMENTE proporcionar un perfil de energía por componente que defina el valor de consumo actual de cada componente de hardware y el consumo aproximado de batería causado por los componentes a lo largo del tiempo, como se documenta en el sitio del Proyecto de código abierto de Android.
  • [SR] SE RECOMIENDA ENRENDER que informe todos los valores de consumo de energía en miliamperios por hora (mAh).
  • [SR] SE RECOMIENDA INFORMAR EL Consumo de energía de la CPU por cada UID de proceso. El Proyecto de código abierto de Android cumple con los requisitos a través de la implementación del módulo de kernel uid_cputime.
  • [SR] SE RECOMIENDA ELIMINARSE para que el 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 si no es posible atribuir el uso de energía de un componente de hardware a una aplicación.

8.5. Rendimiento coherente

El rendimiento puede fluctuar considerablemente en el caso de las apps de alto rendimiento que se ejecutan durante un tiempo prolongado, ya sea debido a que las otras apps se ejecutan en segundo plano o a la limitación de la CPU debido a los límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea compatible, la aplicación en primer plano de la parte superior pueda solicitar que el sistema optimice la asignación de los recursos para abordar esas fluctuaciones.

Implementaciones en dispositivos:

Si las implementaciones de dispositivos informan compatibilidad con el Modo de rendimiento sostenido, deben hacer lo siguiente:

  • [C-1-1] DEBE proporcionar un nivel constante de rendimiento a la aplicación en primer plano durante al menos 30 minutos, cuando la aplicación lo solicite.
  • [C-1-2] DEBE respetar la API de Window.setSustainedPerformanceMode() y otras APIs relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, sucederán lo siguiente:

  • SE DEBE proporcionar al menos un núcleo exclusivo que la aplicación superior en primer plano pueda reservar.

Si las implementaciones de dispositivos permiten reservar un núcleo exclusivo para la aplicación superior en primer plano, sucederá lo siguiente:

  • [C-2-1] SE DEBE informar a través del método de la API Process.getExclusiveCores() los números de ID de los núcleos exclusivos que la aplicación superior en primer plano puede reservar.
  • [C-2-2] No DEBE permitir ningún proceso de espacio del usuario, excepto los controladores de dispositivo utilizados por la aplicación para ejecutarse en núcleos exclusivos, pero PUEDE permitir que algunos procesos de kernel se ejecuten según sea necesario.

Si las implementaciones en dispositivos no admiten un núcleo exclusivo, sucederá lo siguiente:

9. Compatibilidad del modelo de seguridad

Implementaciones en dispositivos:

  • [C-0-1] DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android según 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 descritos en las siguientes subsecciones.

9.1 Permisos

Implementaciones en 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 hacer cumplir cada permiso definido como se describe en la documentación del SDK; no se puede omitir, alterar ni ignorar ningún permiso.

  • PUEDES agregar permisos adicionales, siempre que las nuevas strings de ID del permiso no estén en el espacio de nombres android.\*.

  • [C-0-2] Los permisos con una protectionLevel de PROTECTION_FLAG_PRIVILEGED solo DEBEN otorgarse a las apps precargadas en las rutas de acceso con privilegios de la imagen del sistema y dentro del subconjunto de los permisos explícitamente permitidos para cada app. La implementación del AOSP cumple con este requisito, ya que lee y respeta los permisos incluidos en la lista de entidades permitidas de cada app de los archivos de la ruta etc/permissions/ y usando la ruta de acceso system/priv-app como ruta con privilegios.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 las solicitan durante el tiempo de ejecución.

Implementaciones en dispositivos:

  • [C-0-3] DEBE mostrar una interfaz dedicada para que el usuario decida si otorga los permisos de tiempo de ejecución solicitados y también proporcionar una interfaz para que el usuario administre los permisos de tiempo de ejecución.
  • [C-0-4] DEBE tener una única implementación de ambas interfaces de usuario.
  • [C-0-5] NO DEBE otorgar ningún permiso de tiempo de ejecución a las aplicaciones preinstaladas, a menos que ocurra lo siguiente:
  • El consentimiento del usuario se puede obtener antes de que la aplicación lo utilice.
  • Los permisos de tiempo de ejecución están asociados con un patrón de intent para el cual la aplicación preinstalada está configurada como controlador predeterminado.

Si las implementaciones de dispositivos incluyen una app preinstalada o desean permitir que apps de terceros accedan a las estadísticas de uso, deben hacer lo siguiente:

  • Se RECOMIENDA [C-1-1] proporcionar un mecanismo al que el usuario pueda acceder para otorgar o revocar el acceso a las estadísticas de uso en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS para las apps que declaran el permiso android.permission.PACKAGE_USAGE_STATS.

Si las implementaciones de dispositivos impiden que alguna app, incluidas las preinstaladas, acceda a las estadísticas de uso, hará lo siguiente:

  • [C-2-1] DEBE tener una actividad que controle el patrón de intents android.settings.ACTION_USAGE_ACCESS_SETTINGS, pero DEBE implementarlo como una no-op, es decir, que tenga un comportamiento equivalente a cuando el usuario rechaza el acceso.

9.2 UID y aislamiento de procesos

Implementaciones en dispositivos:

  • [C-0-1] DEBE ser compatible con el modelo de zona de pruebas de aplicaciones de 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 como el mismo ID de usuario de Linux, siempre que las aplicaciones estén debidamente firmadas y construidas, como se define en la referencia de seguridad y permisos.

9.3 Permisos del sistema de archivos

Implementaciones en dispositivos:

Entornos de ejecución alternativos

Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de permisos y seguridad de Android, incluso si incluyen entornos de tiempo de ejecución que ejecutan aplicaciones con algún otro software o tecnología que no sea el formato ejecutable Dalvik o el código nativo. En otras palabras:

  • [C-0-1] Los entornos de ejecución alternativos DEBEN ser aplicaciones de Android y cumplir con el modelo de seguridad estándar de Android, como se describe en otras secciones de la sección 9.

  • [C-0-2] A los entornos de ejecución alternativos NO DEBEN otorgarse acceso a recursos protegidos por permisos no solicitados en el archivo AndroidManifest.xml del tiempo de ejecución a través del mecanismo <uses-permission>.

  • [C-0-3] Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones usen funciones protegidas por permisos de Android restringidos a aplicaciones del sistema.

  • [C-0-4] Los tiempos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android, y las aplicaciones instaladas con un tiempo de ejecución alternativo NO DEBEN reutilizar la zona de pruebas de ninguna otra aplicación instalada en el dispositivo, excepto a través de los mecanismos estándar de Android de ID de usuario compartido y certificado de firma.

  • [C-0-5] Los tiempos de ejecución alternativos NO DEBEN iniciarse con las zonas de pruebas correspondientes a otras aplicaciones de Android, ni deben conceder o recibir acceso a ellas.

  • [C-0-6] Los entornos de ejecución alternativos NO DEBEN iniciarse con otras aplicaciones, otorgarse ni otorgarse privilegios del superusuario (raíz) ni de ningún otro ID de usuario.

  • [C-0-7] Cuando los archivos .apk de entornos de ejecución alternativos se incluyen en la imagen del sistema de las implementaciones de dispositivos, se DEBEN firmar con una clave distinta de la que se usa para firmar otras aplicaciones incluidas con las implementaciones del dispositivo.

  • [C-0-8] Al instalar aplicaciones, los tiempos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que utiliza la aplicación.

  • [C-0-9] Cuando una aplicación necesita usar un recurso de dispositivo para el que hay un permiso de Android correspondiente (como Cámara, GPS, etc.), el tiempo de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.

  • [C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, DEBE enumerar todos los permisos que tiene el propio tiempo de ejecución cuando se instala cualquier aplicación que usa ese tiempo de ejecución.

  • Los entornos de ejecución alternativos DEBEN instalar las apps a través de PackageManager en zonas de pruebas independientes de Android (ID de usuario de Linux, etc.).

  • Los tiempos de ejecución alternativos PUEDEN proporcionar una única zona de pruebas de Android compartida por todas las aplicaciones que utilizan el tiempo de ejecución alternativo.

9.5 Compatibilidad multiusuario

Android admite varios usuarios y admite el aislamiento total de los usuarios.

  • PUEDEN POSIBLES implementaciones en dispositivos, pero NO DEBEN habilitar la función multiusuario si usan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones en dispositivos incluyen varios usuarios, sucederá lo siguiente:

  • [C-1-1] DEBE cumplir con los siguientes requisitos relacionados con la compatibilidad con multiusuario.
  • [C-1-2] DEBE, para cada usuario, 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.
  • [C-1-3] DEBE tener directorios de almacenamiento de aplicaciones compartidos separados y aislados (también conocido como /sdcard) para cada instancia de usuario.
  • [C-1-4] SE DEBE asegurarse de que las aplicaciones que son propiedad de un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer ni escribir en los archivos que son propiedad de cualquier otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
  • [C-1-5] DEBE encriptar el contenido de la tarjeta SD cuando el multiusuario esté habilitado con una clave almacenada solo en medios no extraíbles al que solo puede acceder el sistema si las implementaciones de dispositivos usan medios extraíbles para las APIs de almacenamiento externo. Como esto hará que el contenido multimedia no sea legible para una PC host, las implementaciones del dispositivo deberán cambiar a MTP o un sistema similar para proporcionarles a las PC host acceso a los datos del usuario actual.

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

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

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

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

9.6 Advertencia de SMS premium

Android incluye compatibilidad con la advertencia de usuarios sobre cualquier mensaje SMS premium saliente. Los SMS premium son mensajes de texto enviados a un servicio registrado con un operador que puede generar un cargo al usuario.

Si las implementaciones de dispositivos declaran compatibilidad con android.hardware.telephony, sucederá 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 ascendente proporciona una implementación que cumple con este requisito.

9.7 Funciones de seguridad del kernel

La zona de pruebas de Android incluye funciones que utilizan el sistema de control de acceso obligatorio (MAC) Security-Enhanced Linux (SELinux), la zona de pruebas seccomp y otras funciones de seguridad en el kernel de Linux. Implementaciones en dispositivos:

  • [C-0-1] SE DEBE mantener la compatibilidad con las aplicaciones existentes, incluso cuando SELinux o cualquier otra función de seguridad se implemente debajo del framework de Android.
  • [C-0-2] NO DEBE tener una interfaz de usuario visible cuando se detecta una infracción de seguridad y la bloquea correctamente la función de seguridad implementada debajo del framework de Android, pero PUEDE tener una interfaz de usuario visible cuando se produce una violación de la seguridad desbloqueada que resulta en un exploit exitoso.
  • [C-0-3] NO DEBE permitir que el usuario o el desarrollador de la app puedan configurar SELinux o cualquier otra función de seguridad implementada debajo del framework de Android.
  • [C-0-4] NO DEBE permitir que una aplicación que pueda afectar a otra a través de una API (como una API de administración de dispositivos) configure una política que robe la compatibilidad.
  • [C-0-5] SE DEBE dividir el framework de medios en varios procesos para que sea posible otorgar acceso de manera más específica a cada proceso, como se describe en el sitio del Proyecto de código abierto de Android.
  • [C-0-6] DEBE implementar un mecanismo de zona de pruebas de aplicaciones de kernel que permita filtrar llamadas al sistema usando una política configurable de programas multiproceso. El Proyecto de código abierto de Android ascendente cumple este requisito al habilitar seccomp-BPF con sincronización de grupo de subprocesos (TSYNC), como se describe en la sección de configuración de kernel de source.android.com.

Las funciones de integridad del kernel y de autoprotección son esenciales para la seguridad de Android. Implementaciones en dispositivos:

  • [C-0-7] DEBE implementar protecciones contra el desbordamiento del búfer de la pila del kernel (p.ej., CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] DEBEN implementar protecciones estrictas de memoria de kernel en las que el código ejecutable es de solo lectura, los datos de solo lectura no se pueden ejecutar ni escribir, y los datos que admiten escritura no son ejecutables (p.ej., CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
  • [SR] SE RECOMIENDA ENRENDER 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).
  • [SR} SE RECOMIENDA COMPLETAMENTE implementar la verificación de límites de tamaño de objeto estático y dinámico de las copias entre el espacio del usuario y el espacio de kernel (p.ej., CONFIG_HARDENED_USERCOPY).
  • [SR] SE RECOMIENDA EJECUTAR no ejecutar nunca la memoria del espacio del usuario cuando se ejecute en el kernel (p.ej., PXN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] SE RECOMIENDA Nunca leer ni escribir la memoria del espacio del usuario en el kernel fuera de las APIs de acceso de usercopy normales (p.ej., número PAN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] SE RECOMIENDA ENRENDER aleatorizar el diseño del código del kernel y la memoria, y evitar exposiciones que comprometan la aleatorización (p.ej., CONFIG_RANDOMIZE_BASE con entropía de bootloader a través de /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

Si las implementaciones de dispositivos usan un kernel de Linux, sucederán lo siguiente:

  • [C-1-1] DEBE implementar SELinux.
  • [C-1-2] DEBE configurar SELinux en el modo de aplicación global.
  • [C-1-3] SE DEBE configurar todos los dominios en modo de aplicación forzosa. No se permiten dominios en modo permisivo, incluidos dominios específicos de un dispositivo o proveedor.
  • [C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas de nuncaallow presentes dentro de la carpeta del sistema o de la política proporcionada en el Proyecto de código abierto de Android (AOSP) ascendente, y la política DEBE compilar con todas las reglas de tipo “Neverallow” presentes, tanto para dominios SELinux del AOSP como para dominios específicos de dispositivos o proveedores.
  • DEBE conservar la política de SELinux predeterminada proporcionada en la carpeta sistema/sepolicy del Proyecto de código abierto de Android ascendente y solo agregar más a esta política para su propia configuración específica del dispositivo.

Si las implementaciones de dispositivos usan un kernel distinto de Linux, suceden lo siguiente:

  • [C-2-1] DEBE usar un sistema de control de acceso obligatorio equivalente a SELinux.

9.8 Privacidad

9.8.1 Historial de uso

Android almacena el historial de selecciones del usuario y lo administra mediante UsageStatsManager.

Implementaciones en dispositivos:

  • [C-1-1] DEBE mantener un período razonable de retención de dicho historial del usuario.
  • [SR] SE RECOMIENDA IMPORTANTEMENTE mantener el período de retención de 14 días según la configuración predeterminada en la implementación de AOSP.

9.8.2. Grabando

Si las implementaciones de dispositivos incluyen funcionalidades en el sistema que capturan el contenido que se muestra en la pantalla o graban la transmisión de audio que se reproduce en el dispositivo, deben hacer lo siguiente:

  • [C-1-1] DEBE tener una notificación continua al usuario siempre que esta funcionalidad esté habilitada y que se esté capturando o grabando de forma activa.

Si las implementaciones de dispositivos incluyen un componente habilitado listo para usar que es capaz de grabar audio ambiental para inferir información útil sobre el contexto del usuario, sucederá lo siguiente:

  • [C-2-1] NO DEBE almacenar en el almacenamiento persistente integrado en el dispositivo ni transmitir desde el dispositivo el audio grabado sin procesar ni ningún formato que pueda volver a convertirse al audio original o a un facsímil, excepto con el consentimiento explícito del usuario.

9.8.3 Conectividad

Si las implementaciones de dispositivos tienen un puerto USB compatible con el modo periférico USB, sucederá lo siguiente:

  • [C-1-1] DEBE presentar una interfaz de usuario en la que se 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 en dispositivos:

  • [C-0-1] SE DEBE preinstalar los mismos certificados raíz para el almacén de la autoridad certificadora (CA) de confianza del sistema que se proporcionan en el Proyecto de código abierto de Android ascendente.
  • [C-0-2] SE DEBE enviar con un almacén de AC raíz de usuario vacío.
  • [C-0-3] SE DEBE mostrar una advertencia al usuario en la que se indique que se puede supervisar el tráfico de red, cuando se agrega una AC raíz del usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones de los dispositivos:

  • [C-1-1] DEBE mostrar una advertencia al usuario en la que se indique lo siguiente:
    • Es posible que ese tráfico de red esté supervisado.
    • Ese tráfico de red se enruta a través de la aplicación VPN específica que proporciona la VPN.

Si las implementaciones de dispositivos tienen un mecanismo, habilitado listo para usar 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, precargar un servicio de VPN con android.permission.CONTROL_VPN otorgado), hacen lo siguiente:

  • [C-2-1] SE DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de Device Policy haya habilitado la VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage() , en cuyo caso el usuario no necesita dar su consentimiento por separado, pero solo DEBE recibir una notificación.

Si las implementaciones de dispositivos implementan una indicación visual de usuario para activar la función “VPN siempre activada” de una app de VPN de terceros, sucederá lo siguiente:

  • [C-3-1] SE DEBE inhabilitar esta indicación visual del usuario para las apps que no admiten el servicio VPN siempre activo en el archivo AndroidManifest.xml configurando el atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON en false.

9.9 Encriptación del almacenamiento de datos

Si las implementaciones de dispositivos admiten una pantalla de bloqueo segura como se describe en la sección 9.11.1, sucederá lo siguiente:

  • [C-1-1] DEBE admitir la encriptación de almacenamiento de datos privados de la aplicación (/data partition), así como la partición de almacenamiento compartido de la aplicación (/sdcard partition) si es una parte permanente del dispositivo no extraíble.

Si las implementaciones de dispositivos admiten una pantalla de bloqueo segura como se describe en la sección 9.11.1 y admiten la encriptación de almacenamiento de datos con un rendimiento criptográfico del Estándar de encriptación avanzada (AES) superior a 50 MiB/s, sucederá lo siguiente:

  • [C-2-1] SE DEBE habilitar la encriptación de almacenamiento de datos de forma predeterminada en el momento en que el usuario completa la experiencia de configuración integrada. Si las implementaciones de dispositivos ya se lanzaron en una versión anterior de Android con la encriptación inhabilitada de forma predeterminada, esos dispositivos no podrán cumplir con el requisito a través de una actualización de software del sistema y, por lo tanto, PODRÍAN estar exentos.

  • SE RECOMIENDA cumplir con el requisito de encriptación de almacenamiento de datos anterior implementando la Encriptación basada en archivos (FBE).

9.9.1 Inicio directo

Implementaciones en dispositivos:

  • [C-0-1] DEBE implementar las APIs de modo de inicio directo incluso si no son compatibles con la encriptación de almacenamiento.

  • [C-0-2] Los intents ACTION_LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED DEBEN transmitirse para indicar a las aplicaciones con reconocimiento de inicio directo que las ubicaciones de almacenamiento de Device Encrypted (DE) y Credential Encrypted (CE) están disponibles para el usuario.

9.9.2. Encriptación basada en archivos

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

  • [C-1-1] DEBE iniciarse sin solicitar credenciales al usuario y permitir que las apps compatibles con el inicio directo accedan al almacenamiento de dispositivo encriptado (DE) después de que se transmita el mensaje ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] Solo DEBE permitir el acceso al almacenamiento de Credential Encrypted (CE) después de que el usuario haya desbloqueado el dispositivo proporcionando sus credenciales (p. ej., contraseña, PIN, patrón o huella dactilar) y se haya transmitido el mensaje ACTION_USER_UNLOCKED.
  • [C-1-3] NO DEBE ofrecer ningún método para desbloquear el almacenamiento protegido por CE sin las credenciales proporcionadas por el usuario.
  • [C-1-4] DEBE admitir el inicio verificado y asegurarse de que las claves DE estén vinculadas criptográficamente a la raíz de confianza del hardware del dispositivo.
  • [C-1-5] DEBE admitir la encriptación de contenido de archivos usando AES con una longitud de clave de 256 bits en modo XTS.

  • [C-1-6] DEBE admitir la encriptación de nombres de archivos usando AES con una longitud de clave de 256 bits en modo CBC-CTS.

  • Claves que protegen las áreas de almacenamiento CE y DE:

  • [C-1-7] DEBE vincularse criptográficamente a un almacén de claves guardado en hardware.

  • [C-1-8] Las claves CE DEBEN estar vinculadas a las credenciales de la pantalla de bloqueo de un usuario.
  • [C-1-9] Las claves CE DEBEN estar vinculadas a una contraseña predeterminada cuando el usuario no especifica las credenciales de la pantalla de bloqueo.

  • [C-1-10] DEBE ser única y diferente; en otras palabras, ninguna clave CE o DE del usuario coincide con ninguna de las teclas CE o DE de otro usuario.

  • SE DEBE permitir que las apps esenciales precargadas (p.ej., Alarma, Teléfono, Messenger) reconozcan el inicio directo.

  • PUEDE admitir cifrados, longitudes de clave y modos alternativos para el contenido de los archivos y la encriptación de nombres de archivos, pero DEBE usar los cifrados, las longitudes de clave y los modos admitidos de forma obligatoria de forma predeterminada.

El proyecto ascendente de código abierto de Android proporciona una implementación preferida de esta función que se basa en la función de encriptación ext4 del kernel de Linux.

9.9.3 Encriptación de disco completo

Si las implementaciones de dispositivos admiten la encriptación de disco completo (FDE), sucederá lo siguiente:

  • [C-1-1] SE DEBE usar AES con una clave de 128 bits (o superior) y un modo diseñado para almacenamiento (por ejemplo, AES-XTS, AES-CBC-ESSIV).
  • [C-1-2] SE DEBE usar una contraseña predeterminada para unir la clave de encriptación y NO DEBE escribir la clave de encriptación en el almacenamiento en ningún momento sin estar encriptada.
  • [C-1-3] DEBE AES encriptar la clave de encriptación de forma predeterminada, a menos que el usuario la rechace explícitamente, salvo cuando está en uso activo, con las credenciales de la pantalla de bloqueo ampliadas mediante un algoritmo de estiramiento lento (por ejemplo, PBKDF2 o scrypt).
  • [C-1-4] El algoritmo de ampliación de contraseñas predeterminado anterior DEBE vincularse criptográficamente a ese almacén de claves cuando el usuario no especifica las credenciales de la pantalla de bloqueo o inhabilita el uso de la contraseña para la encriptación y el dispositivo proporciona un almacén de claves guardado en hardware.
  • [C-1-5] NO DEBE enviar la clave de encriptación fuera del dispositivo (incluso cuando está unida con la contraseña del usuario o con una clave vinculada a hardware).

El proyecto upstream de código abierto de Android proporciona una implementación preferida de esta función, según la función dm-crypt del kernel de Linux.

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan que el estado de la integridad del dispositivo sea transparente. Implementaciones en dispositivos:

  • [C-0-1] DEBE informar correctamente a través del método PersistentDataBlockManager.getFlashLockState() de la API del sistema si el estado del bootloader permite la instalación de la imagen del sistema. El estado FLASH_LOCK_UNKNOWN está reservado para las implementaciones en dispositivos que se actualizan desde una versión anterior de Android en la que no existía este nuevo método de API del sistema.

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si la implementación de un dispositivo admite la función, sucederá lo siguiente:

  • [C-1-1] SE DEBE declarar la marca de función de la plataforma android.software.verified_boot.
  • [C-1-2] SE DEBE verificar cada secuencia de inicio.
  • [C-1-3] DEBE iniciar la verificación desde una clave de hardware inmutable que es la raíz de confianza y avanzar 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] DEBEN 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 claves públicas (RSA-2048).
  • [C-1-6] NO DEBE permitir que el inicio se complete cuando falla la verificación del sistema, a menos que el usuario dé su consentimiento para intentar iniciar de todos modos, en cuyo caso, los datos de cualquier bloque de almacenamiento no verificado no DEBEN usarse.
  • [C-1-7] NO DEBE permitir que se modifiquen particiones verificadas en el dispositivo, a menos que el usuario haya desbloqueado explícitamente el cargador de inicio.
  • [SR] Si hay varios chips discretos en el dispositivo (p.ej., radio o procesador de imágenes especializado), se RECOMIENDA EL proceso de inicio de cada uno de ellos para verificar cada etapa durante el inicio.
  • [SR] SE RECOMIENDA ELECTRÓNICO usar el almacenamiento de manipulación evidente, es decir, cuando se desbloquea el bootloader. El almacenamiento a prueba de sabotajes significa que el cargador de inicio puede detectar si el almacenamiento se manipuló desde el interior del HLOS (sistema operativo de alto nivel).
  • [SR] SE RECOMIENDA ELIMINARMENTE solicitar al usuario, mientras usa el dispositivo, y requerir una confirmación física antes de permitir la transición del modo bloqueado del cargador de inicio al modo desbloqueado del cargador de inicio.
  • [SR] SE RECOMIENDA ELIMINARMENTE para implementar la protección contra reversiones de HLOS (p.ej., el inicio y las particiones del sistema) y usar el almacenamiento de manipulación evidente para almacenar los metadatos usados con el fin de determinar la versión mínima permitida del SO.
  • SE DEBE implementar la protección contra reversión para cualquier componente con firmware persistente (p.ej., módem, cámara) y DEBERÍA usar almacenamiento a prueba de manipulaciones para almacenar los metadatos usados para determinar la versión mínima permitida.

El Proyecto de código abierto de Android ascendente proporciona una implementación preferida de esta función en el repositorio de external/avb/, que se puede integrar en el cargador de inicio que se usa para cargar Android.

Si las implementaciones de dispositivos informan la marca de función android.hardware.ram.normal , sucederá lo siguiente:

  • [C-2-1] DEBE admitir el inicio verificado para la integridad del dispositivo.

Si ya se lanzó la implementación de un dispositivo sin admitir el inicio verificado en una versión anterior de Android, estos dispositivos no podrán admitir esta función con una actualización de software del sistema y, por lo tanto, quedarán exentos del requisito.

9.11. Claves y credenciales

El sistema Android Keystore permite a los desarrolladores de apps almacenar claves criptográficas en un contenedor y usarlas en operaciones criptográficas a través de la API de KeyChain o la API de Keystore. Implementaciones en dispositivos:

  • [C-0-1] DEBE permitir al menos la importación de más de 8,192 claves.
  • [C-0-2] La autenticación de la pantalla de bloqueo DEBE intentos con límite de frecuencia y DEBE tener un algoritmo de retirada exponencial. Si supera los 150 intentos fallidos, la demora DEBE ser de al menos 24 horas por intento.
  • No se DEBE limitar la cantidad de claves que se pueden generar.

Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, hace lo siguiente:

  • [C-1-1] SE DEBE hacer una copia de seguridad de la implementación del almacén de claves con hardware seguro.
  • [C-1-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC y funciones hash de la familia MD5, SHA1 y SHA-2 para admitir adecuadamente los algoritmos compatibles del sistema Android Keystore en un área aislada de forma segura del código que se ejecuta en el kernel y superior. El aislamiento seguro DEBE bloquear todos los posibles mecanismos mediante los cuales el kernel o el código del espacio del usuario podrían acceder al estado interno del entorno aislado, incluida la DMA. El Proyecto de código abierto de Android (AOSP) ascendente cumple este requisito mediante la implementación de Trusty, pero otra solución basada en ARM TrustZone o una implementación segura revisada por terceros de un aislamiento adecuado basado en un hipervisor son opciones alternativas.
  • [C-1-3] SE DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislado y solo cuando se realiza correctamente, se deben permitir el uso de claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android ascendente ofrece la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para cumplir con este requisito.
  • [C-1-4] DEBE admitir la certificación de claves cuando la clave de firma de la certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse entre una gran cantidad de dispositivos 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, PUEDE usar una clave diferente por 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, ese dispositivo estará exento del requisito de tener un almacén de claves con copia de seguridad en hardware, a menos que declare la función android.hardware.fingerprint que requiera un almacén de claves con copia de seguridad en hardware.

9.11.1 Pantalla de bloqueo protegida

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

  • [C-1-1] DEBE indicar al usuario en la interfaz de usuario de pantalla de bloqueo y configuración para situaciones en las que el bloqueo automático de la pantalla se aplaza o el agente de confianza puede desbloquearlo. Para cumplir con el requisito, AOSP muestra una descripción de texto para los menús "Configuración de bloqueo automático" y "El botón de encendido bloquea la configuración de forma instantánea", además de un ícono distinguible en la pantalla de bloqueo.
  • [C-1-2] DEBE respetar e implementar por completo todas las APIs de agente de confianza en la clase DevicePolicyManager, como la constante KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-1-3] NO DEBE implementar por completo la función TrustAgentService.addEscrowToken() en un dispositivo que se utiliza como el dispositivo personal principal (p.ej., portátil), pero PUEDE implementar por completo la función en las implementaciones de dispositivos que se suelen compartir.
  • [C-1-4] SE DEBE encriptar los tokens que agrega TrustAgentService.addEscrowToken() antes de almacenarlos en el dispositivo.
  • [C-1-5] NO DEBE almacenar la clave de encriptación en el dispositivo.
  • [C-1-6] DEBE informar al usuario sobre las implicaciones de seguridad antes de habilitar el token de custodia para desencriptar el almacenamiento de datos.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo, entonces, para que dicho método de autenticación se trate como una forma segura de bloquear la pantalla, deben hacer lo siguiente:

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo si se basan en un secreto conocido, para que dicho método de autenticación se trate como una forma segura de bloquear la pantalla, sucederá lo siguiente:

  • [C-3-1] La entropía de la longitud más corta permitida de entradas DEBE ser superior a 10 bits.
  • [C-3-2] La entropía máxima de todas las entradas posibles DEBE ser mayor que 18 bits.
  • [C-3-3] No DEBE reemplazar ninguno de los métodos de autenticación existentes (PIN,patrón, contraseña) implementados y proporcionados en el AOSP.
  • [C-3-4] SE DEBE inhabilitar cuando la aplicación del controlador de política de dispositivo (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_SOMETHING.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo a partir de un token físico o la ubicación, entonces, para que dicho método de autenticación se considere una forma segura de bloquear la pantalla, sucederá lo siguiente:

  • [C-4-1] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales que se base en un secreto conocido y cumpla con los requisitos para que se lo trate como una pantalla de bloqueo segura.
  • [C-4-2] SE DEBE inhabilitar y permitir que la autenticación principal solo desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política con los métodos DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_UNSPECIFIED.
  • [C-4-3] Se DEBE cuestionar al usuario para que realice la autenticación principal (p.ej., PIN, patrón o contraseña) al menos una vez cada 72 horas o menos.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo según datos biométricos, para que dicho método de autenticación se trate como una forma segura de bloquear la pantalla, deben hacer lo siguiente:

  • El [C-5-1] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales que se base en un secreto conocido y cumpla con los requisitos para que se lo trate como una pantalla de bloqueo segura.
  • [C-5-2] SE DEBE inhabilitar y permitir que la autenticación principal solo desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de la función de bloqueo de teclado llamando al método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • El [C-5-3] DEBE tener una tasa de aceptación falsa que sea igual o superior a la que se requiere para un sensor de huellas dactilares, tal como se describe en la sección 7.3.10. De lo contrario, DEBE inhabilitarse y permitir que la autenticación principal solo desbloquee la pantalla 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_BIOMETRIC_WEAK.
  • [SR] SE RECOMIENDA ENcarecidamente tener tasas de aceptación de falsificación de identidad y impostores que sean iguales o superiores a los requeridos para un sensor de huellas dactilares, como se describe en la sección 7.3.10.

Si las tasas de aceptación de falsificación de identidad y impostores no son iguales o mayores que las requeridas para un sensor de huellas dactilares, como se describe en la sección 7.3.10 y la aplicación del controlador de política de dispositivo (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, haz lo siguiente:

  • [C-6-1] DEBE inhabilitar estos métodos biométricos y permitir que solo la autenticación principal desbloquee la pantalla.
  • [C-6-2] SE DEBE solicitar al usuario la autenticación principal (p.ej., PIN, patrón o contraseña) al menos una vez cada 72 horas o menos.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo y si dicho método de autenticación se usará para desbloquear el bloqueo de teclado, pero no se considerará como una pantalla de bloqueo segura, sucederá lo siguiente:

9.12. Eliminación de Datos

Todas las implementaciones en dispositivos:

  • [C-0-1] DEBE proporcionarles a los usuarios un mecanismo para restablecer la configuración de fábrica.
  • [C-0-2] SE DEBE borrar todos los datos generados por el usuario. Es decir, todos los datos, excepto los siguientes:
    • La imagen del sistema
    • Cualquier archivo del sistema operativo que requiere la imagen del sistema
  • [C-0-3] SE DEBE borrar los datos de manera tal que satisfaga los estándares relevantes de la industria, como NIST SP800-88.
  • [C-0-4] DEBE activar el proceso de "restablecimiento de la configuración de fábrica" anterior cuando la app del controlador de política de dispositivo del usuario principal llama a la API de DevicePolicyManager.wipeData().
  • PUEDE proporcionar una opción de limpieza de datos rápida que lleve a cabo solo una eliminación lógica de datos.

9.13 Modo de inicio seguro

Android ofrece un modo de inicio seguro, que permite a los usuarios iniciar en un modo en el que solo se permite la ejecución de apps preinstaladas del sistema y se inhabilitan todas las apps de terceros. Este modo, conocido como "modo de inicio seguro", proporciona al usuario la capacidad de desinstalar apps de terceros potencialmente dañinas.

Las implementaciones en dispositivos son las siguientes:

  • [SR] SE RECOMIENDA COMPLETAMENTE implementar el modo de inicio seguro.

Si las implementaciones de dispositivos implementan el modo de inicio seguro, harán lo siguiente:

  • [C-1-1] DEBE brindarle al usuario la opción de ingresar al Modo de inicio seguro de una manera que no se pueda interrumpir con las apps de terceros instaladas en el dispositivo, excepto cuando la app de terceros es un controlador de Device Policy y haya establecido la marca UserManager.DISALLOW_SAFE_BOOT como verdadera.

  • [C-1-2] DEBE permitir que el usuario desinstale apps de terceros en el modo seguro.

  • SE DEBE ofrecerles al usuario la opción de ingresar al modo de inicio seguro desde el menú de inicio mediante un flujo de trabajo diferente al de un inicio normal.

9.14. Aislamiento de sistemas para vehículos

Se espera que los dispositivos Android Automotive intercambien datos con subsistemas críticos del vehículo usando la HAL del vehículo para enviar y recibir mensajes a través de redes del vehículo, como CAN bus.

El intercambio de datos puede protegerse implementando funciones de seguridad debajo de las capas del framework de Android para evitar la interacción maliciosa o involuntaria con estos subsistemas.

10. Pruebas de compatibilidad de software

Las implementaciones en dispositivos DEBEN superar todas las pruebas que se describen en esta sección.

Sin embargo, ten en cuenta que ningún paquete de prueba de software es completamente completo. Por este motivo, SE RECOMIENDA EJECUTAR a los implementadores de dispositivos realizar la cantidad mínima de cambios posible en la referencia y la implementación preferida de Android a partir del Proyecto de código abierto de Android. Esto minimizará el riesgo de introducir errores que creen incompatibilidades que requieran reelaboración y posibles actualizaciones del dispositivo.

10.1 Conjunto de pruebas de compatibilidad (CTS)

Las implementaciones del dispositivo DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el Proyecto de código abierto de Android con el software de envío final del dispositivo. Además, los implementadores de dispositivos DEBEN utilizar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible, y DEBEN garantizar la compatibilidad en casos de ambigüedad en 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. Como cualquier software, el CTS puede contener errores. Se realizará un control de versiones del CTS independientemente de esta definición de compatibilidad, y se podrán lanzar varias revisiones del CTS para Android 8.1. Las implementaciones del dispositivo DEBEN pasar la versión más reciente del CTS disponible en el momento en que se completa el software del dispositivo.

10.2. Verificador del CTS

Las implementaciones en dispositivos DEBEN ejecutar correctamente todos los casos aplicables en el verificador del CTS. El verificador del CTS se incluye con el Conjunto de pruebas de compatibilidad y está diseñado para que lo ejecute un operador humano a fin de probar funciones que un sistema automatizado no pueda probar, como el funcionamiento correcto de la cámara y los sensores.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluidos algunos que son opcionales. Las implementaciones del dispositivo DEBEN superar todas las pruebas de hardware que poseen; por ejemplo, si un dispositivo posee un acelerómetro, DEBEN ejecutar correctamente el caso de prueba del acelerómetro en el verificador del CTS. PUEDEN omitirse o omitirse los casos de prueba de las funciones indicadas como opcionales en este Documento de definición de compatibilidad.

Todos los dispositivos y las compilaciones DEBEN ejecutar correctamente el verificador del CTS, 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 verificador del CTS en compilaciones que difieren solo de maneras triviales. Específicamente, las implementaciones en dispositivos que difieren de una que aprobó el verificador del CTS solo por el conjunto de configuraciones regionales incluidas, marcas, etc. PUEDEN omitir la prueba del verificador del CTS.

11. Software actualizable

Las implementaciones del dispositivo DEBEN incluir un mecanismo para reemplazar todo el software del sistema. No es necesario que el mecanismo realice actualizaciones “en vivo”, es decir, PUEDE ser necesario reiniciar el dispositivo.

Se puede utilizar cualquier método, siempre que pueda reemplazar todo el software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques cumplirá con este requisito:

  • Descargas “inalámbricas” con actualización sin conexión mediante el reinicio
  • "Conexión mediante dispositivo móvil" se actualiza a través de USB desde una PC host.
  • "Sin conexión" se actualiza a través del reinicio y la actualización desde un archivo en almacenamiento extraíble.

Sin embargo, si la implementación del dispositivo incluye compatibilidad con una conexión de datos no medida, como el perfil 802.11 o Bluetooth PAN (red de área personal), DEBE admitir descargas inalámbricas con actualización sin conexión a través del reinicio.

El mecanismo de actualización utilizado DEBE admitir actualizaciones sin limpiar los datos del usuario. Es decir, el mecanismo de actualización DEBE preservar los datos privados y los datos compartidos de la aplicación. Ten en cuenta que el software upstream de Android incluye un mecanismo de actualización que cumple con este requisito.

Para las implementaciones en 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 sea idéntica al resultado esperado después de una actualización inalámbrica. La implementación inalámbrica basada en bloques del Proyecto de código abierto de Android ascendente, agregado a partir de Android 5.1, cumple con este requisito.

Además, las implementaciones en dispositivos DEBEN admitir las actualizaciones del sistema A/B. AOSP implementa esta función mediante la HAL de control de inicio.

Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro de su ciclo de vida razonable del producto que se determina en consulta con el Equipo de compatibilidad de Android para afectar la compatibilidad de aplicaciones de terceros, el implementador de dispositivos DEBE corregir el error a través de una actualización de software disponible que pueda aplicarse al mecanismo descrito anteriormente.

Android incluye funciones que permiten que la app del propietario del dispositivo (si está presente) controle la instalación de actualizaciones del sistema. Para facilitar este proceso, el subsistema de actualización del sistema para dispositivos que informan android.software.device_admin 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 de esta versión, consulta lo siguiente:

Para obtener un resumen de los cambios realizados en las secciones de persona:

  1. Introducción
  2. Tipos de dispositivos
  3. Software
  4. Empaquetado de la aplicación
  5. Multimedia
  6. Herramientas y opciones para desarrolladores
  7. Compatibilidad de hardware
  8. Rendimiento y potencia
  9. Modelo de seguridad
  10. Pruebas de compatibilidad de software
  11. Software actualizable
  12. Registro de cambios del documento
  13. Comunicarte con nosotros

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 estéticos o relacionados con la compilación.

Para una mejor visualización, adjunta 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 de Android y solicitar aclaraciones o plantear problemas que creas que no se tratan en el documento.