Definición de compatibilidad de Android 9

1. Introducción

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

El uso de los verbos “DEBER”, “NO DEBER”, “REQUERIR”, “DEBEN”, “NO DEBEN”, “DEBEN”, “NO DEBEN”, “RECOMENDAR”, “PUEDEN” y “OPCIONAL” se realiza de acuerdo con el estándar del IETF definido en RFC2119.

En el uso que se hace de este documento, un "implementador de dispositivos" o "implementador" es una persona o organización que desarrolla una solución de hardware o software que ejecuta Android 9. Una “implementación de dispositivos” o “implementación” es la solución de hardware y software que se desarrolló.

Para que se consideren compatibles con Android 9, las implementaciones del dispositivo DEBEN cumplir con los requisitos que se presentan en esta definición de compatibilidad, incluidos los documentos que se incorporan como referencia.

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

Por este motivo, el Proyecto de código abierto de Android es la implementación de referencia y preferida de Android. SE RECOMIENDA ENFATICAMENTE a los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente "upstream" disponible en el Proyecto de código abierto de Android. Si bien, en teoría, algunos componentes se pueden reemplazar por implementaciones alternativas, SE RECOMIENDA NO seguir esta práctica, ya que aprobar las pruebas de software será mucho más difícil. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento total con la implementación estándar de Android, incluido el conjunto de pruebas de compatibilidad y más allá de este. Por último, ten en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

Muchos de los recursos a los que se hace referencia en este documento se derivan directamente o indirectamente del SDK de Android y serán funcionalmente idénticos a la información de la documentación de ese SDK. En cualquier caso en el que esta definición de compatibilidad o el conjunto de pruebas de compatibilidad no coincidan con la documentación del SDK, la documentación del SDK se considerará oficial. Cualquier detalle técnico que se proporcione en los recursos vinculados a lo largo de este documento se considerará parte de esta Definición de Compatibilidad.

1.1 Estructura del documento

1.1.1. Requisitos por tipo de dispositivo

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

Todos los demás requisitos, que se aplican de forma universal a cualquier implementación de dispositivos Android, se enumeran en las secciones posteriores a la Sección 2. En este documento, se hace referencia a estos requisitos como "Requisitos principales".

1.1.2. ID del requisito

El ID de requisito se asigna para los requisitos OBLIGATORIOS.

• El ID se asigna solo para los requisitos OBLIGATORIOS.
• Los requisitos ALTAMENTE RECOMENDADOS se marcan como [SR], pero no se les asigna un ID.
• El ID consta de lo siguiente : ID de tipo de dispositivo, ID de estado y ID de requisito (p.ej., C-0-1).

Cada ID se define de la siguiente manera:

• ID de tipo de dispositivo (obtén más información en 2. Tipos de dispositivos).
  • C: Núcleo (requisitos que se aplican a cualquier implementación de dispositivos Android)
  • H: Dispositivo de mano Android
  • T: Dispositivo Android Television
  • A: Implementación de Android Automotive
  • Pestaña: Implementación de tablets Android
• ID de la condición
  • Cuando el requisito es incondicional, este ID se establece como 0.
  • Cuando el requisito es condicional, se asigna 1 para la 1ª condición y la cantidad aumenta en 1 dentro de la misma sección y el mismo tipo de dispositivo.
• ID del requisito
  • Este ID comienza en 1 y aumenta de a 1 dentro de la misma sección y la misma condición.

1.1.3. ID del requisito en la sección 2

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

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

2. Tipos de dispositivos

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

En esta sección, se describen esos tipos de dispositivos, así como los requisitos y las recomendaciones adicionales aplicables a cada uno.

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

2.1 Configuraciones de dispositivos

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

2.2. Requisitos de dispositivos portátiles

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

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

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

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

2.2.1. Hardware

Implementaciones de dispositivos portátiles:

• [7.1.1.1/H-0-1] DEBE tener una pantalla de al menos 6.35 cm (2.5") de tamaño diagonal físico.
• [7.1.1.3/H-SR] SE RECOMIENDA ENFATICAMENTE proporcionar a los usuarios una indicación visual para cambiar el tamaño de la pantalla (densidad de pantalla).

Si las implementaciones de dispositivos portátiles afirman admitir pantallas de alto rango dinámico a través de Configuration.isScreenHdr() , deben cumplir con los siguientes requisitos:

• [7.1.4.5/H-1-1] DEBEN anunciar la compatibilidad con las extensiones EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace y VK_EXT_hdr_metadata.

Implementaciones de dispositivos portátiles:

• [7.1.5/H-0-1] DEBE incluir compatibilidad con el modo de compatibilidad de aplicaciones heredadas, tal como lo implementa el código fuente abierto de Android upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los activadores o umbrales en los que se activa el modo de compatibilidad ni alterar el comportamiento del modo de compatibilidad.
• [7.2.1/H-0-1] DEBE incluir compatibilidad con aplicaciones de editores de métodos de entrada (IME) de terceros.
• [7.2.3/H-0-1] DEBE proporcionar las funciones de Inicio, Recientes y Atrás.
• [7.2.3/H-0-2] DEBE enviar el evento normal y de mantener presionado de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano. El sistema NO DEBE consumir estos eventos y PUEDEN activarse fuera del dispositivo Android (p.ej., un teclado de hardware externo conectado al dispositivo Android).
• [7.2.4/H-0-1] DEBE admitir la entrada de la pantalla táctil.
• [7.2.4/H-SR] SE RECOMIENDA ENFATICAMENTE que inicies la app de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService, o una actividad que controle el ACTION_ASSIST cuando se mantenga presionada la tecla KEYCODE_MEDIA_PLAY_PAUSE o KEYCODE_HEADSETHOOK si la actividad en primer plano no controla esos eventos de mantener presionada la tecla.
• [7.3.1/H-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos portátiles incluyen un acelerómetro de 3 ejes, tienen las siguientes características:

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

Si las implementaciones de dispositivos portátiles incluyen un giroscopio, tienen las siguientes características:

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

Implementaciones de dispositivos de mano que pueden realizar una llamada de voz y que indican cualquier valor que no sea PHONE_TYPE_NONE en getPhoneType:

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

Implementaciones de dispositivos portátiles:

• [7.3.12/H-SR] SE RECOMIENDA para admitir el sensor de postura con 6 grados de libertad.
• [7.4.3/H] DEBE incluir compatibilidad con Bluetooth y Bluetooth LE.

Si las implementaciones de dispositivos portátiles incluyen una conexión con medición, tienen las siguientes características:

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

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles declaran compatibilidad solo con una ABI de 32 bits, haz lo siguiente:

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

• [7.6.1/H-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 592 MB si la pantalla predeterminada usa resoluciones de búfer de trama de hasta HD+ (p.ej., HD, WSVGA).

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

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

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

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

• [7.6.1/H-6-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si la pantalla predeterminada usa resoluciones de búfer de trama de hasta HD+ (p.ej., HD, WSVGA).

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

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

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

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

• [7.6.1/H-9-1] DEBE declarar la marca de función android.hardware.ram.low.
• [7.6.1/H-9-2] DEBE tener al menos 1.1 GB de almacenamiento no volátil para los datos privados de la aplicación (también conocida como partición "/data").

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

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

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos de mano incluyen un puerto USB compatible con el modo periférico, tienen las siguientes características:

• [7.7.1/H-1-1] DEBEN implementar la API de Android Open Accessory (AOA).

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles pueden cumplir con todos los requisitos de rendimiento para admitir el modo de realidad virtual y lo incluyen, deben cumplir con los siguientes requisitos:

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

2.2.2. Multimedia

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

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

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

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

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

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

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

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

2.2.3. Software

Implementaciones de dispositivos portátiles:

• [3.2.3.1/H-0-1] DEBE tener una aplicación que controle los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE y ACTION_CREATE_DOCUMENT como se describe en los documentos del SDK y proporcionarle al usuario indicaciones visuales para acceder a los datos del proveedor de documentos mediante la API de DocumentsProvider.
• [3.4.1/H-0-1] DEBE proporcionar una implementación completa de la API de android.webkit.Webview.
• [3.4.2/H-0-1] DEBE incluir una aplicación de navegador independiente para la navegación web del usuario general.
• [3.8.1/H-SR] SE RECOMIENDA ENFATICAMENTE implementar un selector predeterminado que admita la fijación en la app de atajos, widgets y widgetFeatures.
• [3.8.1/H-SR] SE RECOMIENDA ENFATICAMENTE implementar un selector predeterminado que proporcione acceso rápido a los accesos directos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager.
• [3.8.1/H-SR] SE RECOMIENDA ENFATICAMENTE que incluyas una app de selector predeterminado que muestre insignias para los íconos de la app.
• [3.8.2/H-SR] SE RECOMIENDA ENFATICAMENTE admitir widgets de apps de terceros.
• [3.8.3/H-0-1] DEBEN permitir que las apps de terceros notifiquen a los usuarios sobre eventos importantes a través de las clases de API Notification y NotificationManager.
• [3.8.3/H-0-2] DEBEN admitir notificaciones enriquecidas.
• [3.8.3/H-0-3] DEBE admitir notificaciones emergentes.
• [3.8.3/H-0-4] DEBE incluir un panel de notificaciones que le permita al usuario controlar directamente (p.ej., responder, posponer, descartar o bloquear) las notificaciones a través de indicaciones visuales, como botones de acción o el panel de control, tal como se implementa en el AOSP.
• [3.8.3/H-0-5] DEBE mostrar las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el panel de notificaciones.
• [3.8.3/H-SR] SE RECOMIENDA ENFATICAMENTE que se muestre la primera opción proporcionada a través de RemoteInput.Builder setChoices() en la pantalla de notificaciones sin interacción adicional del usuario.
• [3.8.3/H-SR] SE RECOMIENDA MUY FUERTEMENTE que se muestren todas las opciones proporcionadas a través de RemoteInput.Builder setChoices() en el panel de notificaciones cuando el usuario expanda todas las notificaciones en el panel de notificaciones.
• [3.8.4/H-SR] SE RECOMIENDA ENFATICAMENTE implementar un asistente en el dispositivo para controlar la acción de asistencia.

Si las implementaciones de dispositivos de mano admiten la acción de asistencia, hacen lo siguiente:

• [3.8.4/H-SR] SE RECOMIENDA ENFATICAMENTE usar la interacción designada de mantener presionada la tecla HOME para iniciar la app de asistencia, como se describe en la sección 7.2.3. DEBE iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService, o una actividad que controle el intent ACTION_ASSIST.

Si las implementaciones de dispositivos de mano Android admiten una pantalla de bloqueo, deben cumplir con los siguientes requisitos:

• [3.8.10/H-1-1] DEBEN mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación multimedia.

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

• [3.9/H-1-1] DEBEN implementar la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android.
• [3.9/H-1-2] DEBEN declarar la compatibilidad con los perfiles administrados a través de la marca de función android.software.managed_users, excepto cuando el dispositivo esté configurado para informar que tiene poca RAM o para que asigne almacenamiento interno (no extraíble) como almacenamiento compartido.

Implementaciones de dispositivos portátiles:

• [3.10/H-0-1] DEBE admitir servicios de accesibilidad de terceros.
• [3.10/H-SR] SE RECOMIENDA ENFATICAMENTE que se carguen previamente servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de Accesibilidad con interruptores y TalkBack (para los idiomas compatibles con el motor de texto a voz preinstalado) o que la superen, como se indica en el proyecto de código abierto de TalkBack.
• [3.11/H-0-1] DEBE admitir la instalación de motores de TTS de terceros.
• [3.11/H-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un motor de TTS que admita los idiomas disponibles en el dispositivo.
• [3.13/H-SR] SE RECOMIENDA ENFATICAMENTE incluir un componente de IU de Configuración rápida.

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

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

2.2.4. Rendimiento y energía

• [8.1/H-0-1] Latencia de fotogramas coherente. La latencia de fotogramas incoherente o la demora para renderizar fotogramas NO DEBEN ocurrir más de 5 veces por segundo y DEBEN ser inferiores a 1 fotograma por segundo.
• [8.1/H-0-2] Latencia de la interfaz de usuario. Las implementaciones de dispositivos DEBEN garantizar una experiencia del usuario de baja latencia mediante el desplazamiento de una lista de 10,000 entradas de lista, como lo define el Conjunto de pruebas de compatibilidad de Android (CTS), en menos de 36 segundos.
• [8.1/H-0-3] Cambio de tareas. Cuando se inician varias aplicaciones, volver a iniciar una aplicación que ya se está ejecutando DEBE tardar menos de 1 segundo.

Implementaciones de dispositivos portátiles:

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

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

• [8.3/H-1-1] DEBE proporcionar indicaciones visuales para que el usuario habilite o inhabilite la función de ahorro de batería.
• [8.3/H-1-2] DEBEN proporcionar indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.

Implementaciones de dispositivos portátiles:

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

Si las implementaciones de dispositivos portátiles incluyen una pantalla o una salida de video, deben cumplir con los siguientes requisitos:

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

2.2.5. Modelo de seguridad

Implementaciones de dispositivos portátiles:

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

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

• [9.11/H-1-1] DEBE permitir que el usuario elija el tiempo de espera de suspensión más corto, que es un tiempo de transición del estado desbloqueado al estado bloqueado, de 15 segundos o menos.
• [9.11/H-1-2] DEBE proporcionar indicaciones visuales para el usuario para ocultar las notificaciones y deshabilitar todas las formas de autenticación, excepto la autenticación principal que se describe en 9.11.1 Pantalla de bloqueo segura. El AOSP cumple con el requisito como modo de bloqueo.

2.3. Requisitos de la televisión

Un dispositivo Android Television hace referencia a una implementación de dispositivo Android que es una interfaz de entretenimiento para consumir contenido multimedia digital, películas, juegos, apps o TV en vivo para usuarios que se encuentran a unos tres metros de distancia (una "interfaz de usuario de sillón reclinable" o "de 10 pies").

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

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

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

2.3.1. Hardware

Implementaciones de dispositivos de TV:

• [7.2.2/T-0-1] DEBE admitir el pad direccional.
• [7.2.3/T-0-1] DEBEN proporcionar las funciones de Inicio y Atrás.
• [7.2.3/T-0-2] DEBE enviar el evento de presión normal y prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.
• [7.2.6.1/T-0-1] DEBE incluir compatibilidad con controles de juegos y declarar la marca de función android.hardware.gamepad.
• [7.2.7/T] DEBE proporcionar un control remoto desde el que los usuarios puedan acceder a las entradas de navegación no táctil y teclas de navegación principales.

Si las implementaciones de dispositivos de TV incluyen un giroscopio, tienen las siguientes características:

• [7.3.4/T-1-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.

Implementaciones de dispositivos de TV:

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

Si las implementaciones de dispositivos de TV incluyen un puerto USB que admite el modo host, deben cumplir con los siguientes requisitos:

• [7.5.3/T-1-1] DEBE incluir compatibilidad con una cámara externa que se conecte a través de este puerto USB, pero que no necesariamente esté siempre conectada.

Si las implementaciones de dispositivos de TV son de 32 bits, haz lo siguiente:

• [7.6.1/T-1-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si se usa alguna de las siguientes densidades:

  • 400 dpi o superior en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

Si las implementaciones de dispositivos de TV son de 64 bits, haz lo siguiente:

• [7.6.1/T-2-1] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se usa alguna de las siguientes densidades:

  • 400 dpi o superior en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

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

Implementaciones de dispositivos de TV:

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

2.3.2. Multimedia

Las implementaciones de dispositivos de TV DEBEN admitir los siguientes formatos de codificación de audio:

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

Las implementaciones de dispositivos de TV DEBEN admitir los siguientes formatos de codificación de video:

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

Implementaciones de dispositivos de TV:

• [5.2.2/T-SR] SE RECOMIENDA ENFATICAMENTE que admitan la codificación H.264 de videos con resolución de 720p y 1080p a 30 fotogramas por segundo.

Las implementaciones de dispositivos de TV DEBEN admitir los siguientes formatos de decodificación de video:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos de TV admitan los siguientes formatos de decodificación de video:

• [5.3.1/T-SR] MPEG-2

Las implementaciones de dispositivos de TV DEBEN admitir la decodificación H.264, como se detalla en el artículo 5.3.4, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:

• [5.3.4.4/T-1-1] HD 1080p a 60 fotogramas por segundo con perfil de Baseline
• [5.3.4.4/T-1-2] HD 1080p a 60 fotogramas por segundo con perfil principal
• [5.3.4.4/T-1-3] HD 1080p a 60 fotogramas por segundo con nivel de perfil alto 4.2

Las implementaciones de dispositivos de TV con decodificadores de hardware H.265 DEBEN admitir la decodificación de H.265, como se detalla en el artículo 5.3.5, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:

• [5.3.5.4/T-1-1] HD 1080p a 60 fotogramas por segundo con nivel de perfil principal 4.1

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

• [5.3.5.5/T-2-1] DEBE admitir el perfil de decodificación UHD a 60 fotogramas por segundo con el perfil de nivel principal Main10 de nivel 5.

Las implementaciones de dispositivos de TV DEBEN admitir la decodificación de VP8, como se detalla en el artículo 5.3.6, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:

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

Las implementaciones de dispositivos de TV con decodificadores de hardware VP9 DEBEN admitir la decodificación de VP9, como se detalla en el artículo 5.3.7, con velocidades de fotogramas y resoluciones de video estándar hasta las siguientes:

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

Si las implementaciones de dispositivos de TV con decodificadores de hardware VP9 admiten la decodificación de VP9 y el perfil de decodificación UHD, hacen lo siguiente:

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

Implementaciones de dispositivos de TV:

• [5.5.3/T-0-1] DEBE incluir compatibilidad con el volumen principal del sistema y la atenuación del volumen de salida de audio digital en las salidas compatibles, excepto para la salida de transferencia de audio comprimido (en la que no se realiza la decodificación de audio en el dispositivo).
• [5.8/T-0-1] DEBE configurar el modo de salida HDMI para seleccionar la resolución máxima que se puede admitir con una frecuencia de actualización de 50 Hz o 60 Hz para todas las pantallas con cable.
• [5.8/T-SR] SE RECOMIENDA ENFATICAMENTE que se proporcione un selector de frecuencia de actualización HDMI configurable por el usuario para todas las pantallas con cable.
• [5.8/T-SR] SE RECOMIENDA ENFATICAMENTE que admitan la decodificación simultánea de transmisiones seguras. Como mínimo, se RECOMIENDA ENFATICAMENTE la decodificación simultánea de dos transmisiones.
• [5.8] DEBE configurar la frecuencia de actualización del modo de salida HDMI en 50 Hz o 60 Hz, según la frecuencia de actualización de video de la región en la que se vende el dispositivo para todas las pantallas con cable.

Si las implementaciones de dispositivos de TV admiten la decodificación UHD y son compatibles con pantallas externas, tienen las siguientes características:

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

Si las implementaciones de dispositivos de TV no admiten la decodificación de UHD, pero sí las pantallas externas, sucede lo siguiente:

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

2.3.3. Software

Implementaciones de dispositivos de TV:

• [3/T-0-1] DEBEN declarar las funciones android.software.leanback y android.hardware.type.television.
• [3.4.1/T-0-1] DEBE proporcionar una implementación completa de la API de android.webkit.Webview.

Si las implementaciones de dispositivos Android TV admiten una pantalla de bloqueo,deben cumplir con los siguientes requisitos:

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

Implementaciones de dispositivos de TV:

• [3.8.14/T-SR] SE RECOMIENDA ENFATICAMENTE que admitan el modo Multiventana de pantalla en pantalla (PIP).
• [3.10/T-0-1] DEBE admitir servicios de accesibilidad de terceros.
• [3.10/T-SR] SE RECOMIENDA ENFATICAMENTE que se carguen previamente servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de Accesibilidad con interruptores y TalkBack (para los idiomas compatibles con el motor de texto a voz preinstalado) o que la superen, como se proporciona en el proyecto de código abierto de TalkBack.

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

• [3.11/T-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un motor de TTS compatible con los idiomas disponibles en el dispositivo.
• [3.11/T-1-1] DEBE admitir la instalación de motores de TTS de terceros.

Implementaciones de dispositivos de TV:

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

2.3.4. Rendimiento y energía

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

Si las implementaciones de dispositivos de TV incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o extienden las funciones que se incluyen en AOSP, deben cumplir con los siguientes requisitos:

• [8.3/T-1-1] DEBE proporcionar indicaciones visuales para que el usuario habilite y deshabilite la función de ahorro de batería.
• [8.3/T-1-2] DEBE proporcionar indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.

Implementaciones de dispositivos de TV:

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

2.4. Requisitos del reloj

Un dispositivo Android Watch hace referencia a una implementación de dispositivo Android diseñada para usarse en el cuerpo, tal vez en la muñeca.

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

• Tener una pantalla con una longitud diagonal física de entre 1.1 y 2.5 pulgadas
• Tener un mecanismo para llevarlo en el cuerpo

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

2.4.1. Hardware

Mira las implementaciones de dispositivos:

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

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

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

• [7.3.1/W-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un acelerómetro de 3 ejes.

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

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

• [7.6.1/W-0-2] DEBE tener al menos 416 MB de memoria disponible para el kernel y el espacio de usuario.

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

• [7.8.2/W] PUEDE, pero NO DEBE tener salida de audio.

2.4.2. Multimedia

No hay requisitos adicionales.

2.4.3. Software

Mira las implementaciones de dispositivos:

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

Mira las implementaciones de dispositivos:

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

Mira las implementaciones de dispositivos que declaran la marca de función android.hardware.audio.output:

• [3.10/W-1-1] DEBE admitir servicios de accesibilidad de terceros.
• [3.10/W-SR] SE RECOMIENDA ENFATICAMENTE que se carguen previamente servicios de accesibilidad en el dispositivo que sean comparables con la funcionalidad de los servicios de accesibilidad de Accesibilidad con interruptores y TalkBack (para los idiomas compatibles con el motor de texto a voz preinstalado) o que la superen, como se proporciona en el proyecto de código abierto de TalkBack.

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

• [3.11/W-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un motor de TTS compatible con los idiomas disponibles en el dispositivo.

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

2.4.4. Rendimiento y energía

Si las implementaciones de dispositivos de reloj incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o extienden las funciones que se incluyen en AOSP, deben cumplir con los siguientes requisitos:

• [8.3/W-SR] SE RECOMIENDA ENFATICAMENTE que se proporcionen indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Doze.
• [8.3/W-SR] SE RECOMIENDA ENFATICAMENTE proporcionar indicaciones visuales para que el usuario habilite o inhabilite la función de ahorro de batería.

Mira las implementaciones de dispositivos:

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

2.5. Requisitos de Automotive

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

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

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

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

2.5.1. Hardware

Implementaciones de dispositivos para la industria automotriz:

• [7.1.1.1/A-0-1] DEBE tener una pantalla de al menos 6 pulgadas de tamaño diagonal físico.

• [7.1.1.1/A-0-2] DEBE tener un diseño de tamaño de pantalla de al menos 750 dp × 480 dp.

• [7.2.3/A-0-1] DEBE proporcionar la función de inicio y PUEDE proporcionar las funciones Atrás y Recientes.

• [7.2.3/A-0-2] DEBE enviar el evento de presión normal y prolongada de la función Atrás (KEYCODE_BACK) a la aplicación en primer plano.

• [7.3.1/A-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un acelerómetro de 3 ejes.

Si las implementaciones de dispositivos para la industria automotriz incluyen un acelerómetro de 3 ejes, tienen las siguientes características:

• [7.3.1/A-1-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.
• [7.3.1/A-1-2] DEBEN cumplir con el sistema de coordenadas de sensores de automóviles de Android.

Si las implementaciones de dispositivos para la industria automotriz incluyen un giroscopio, tienen las siguientes características:

• [7.3.4/A-1-1] DEBE poder informar eventos hasta una frecuencia de al menos 100 Hz.

Implementaciones de dispositivos para la industria automotriz:

• [7.3.11/A-0-1] DEBE proporcionar el equipo actual como SENSOR_TYPE_GEAR.

Implementaciones de dispositivos para la industria automotriz:

• [7.3.11.2/A-0-1] DEBE admitir el modo día/noche definido como SENSOR_TYPE_NIGHT.
• [7.3.11.2/A-0-2] El valor de la marca SENSOR_TYPE_NIGHT DEBE ser coherente con el modo día/noche del panel y DEBE basarse en la entrada del sensor de luz ambiental.

• El sensor de luz ambiente subyacente PUEDE ser el mismo que el fotómetro.

• [7.3.11.4/A-0-1] DEBE proporcionar la velocidad del vehículo como se define en SENSOR_TYPE_CAR_SPEED.

• [7.3.11.5/A-0-1] DEBE proporcionar el estado del freno de estacionamiento como se define en SENSOR_TYPE_PARKING_BRAKE.

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

• [7.4.3/A-0-2] Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles de Bluetooth:
  • Llamadas telefónicas con el perfil de manos libres (HFP)
  • Reproducción de contenido multimedia a través del perfil de distribución de audio (A2DP)
  • Control de reproducción de contenido multimedia a través del perfil de control remoto (AVRCP)
  • Uso compartido de contactos con el Perfil de acceso a la libreta de direcciones (PBAP)

• [7.4.3/A-SR] SE RECOMIENDA ENFÉCTIVAMENTE que admitan el Perfil de Acceso a Mensajes (MAP).

• [7.4.5/A] DEBE incluir compatibilidad con la conectividad de datos basada en redes móviles.

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

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

Implementaciones de dispositivos para la industria automotriz:

• [7.6.1/A] DEBE formatear la partición de datos para ofrecer un rendimiento y una longevidad mejorados en el almacenamiento flash, por ejemplo, con el sistema de archivos f2fs.

Si las implementaciones de dispositivos para la industria automotriz proporcionan almacenamiento externo compartido a través de una parte del almacenamiento interno no extraíble, cumplen con los siguientes requisitos:

• [7.6.1/A-SR] SE RECOMIENDA ENFATICAMENTE reducir la sobrecarga de E/S en las operaciones que se realizan en el almacenamiento externo, por ejemplo, con SDCardFS.

Si las implementaciones de dispositivos para la industria automotriz son de 32 bits, haz lo siguiente:

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

  • 280 dpi o menos en pantallas pequeñas o normales
  • ldpi o inferior en pantallas extragrandes
  • mdpi o inferior en pantallas grandes

• [7.6.1/A-1-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 608 MB si se usa alguna de las siguientes densidades:

  • xhdpi o superior en pantallas pequeñas o normales
  • hdpi o superior en pantallas grandes
  • mdpi o superior en pantallas extragrandes

• [7.6.1/A-1-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 896 MB si se usa alguna de las siguientes densidades:

  • 400 dpi o superior en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

• [7.6.1/A-1-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1,344 MB si se usa alguna de las siguientes densidades:

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

Si las implementaciones de dispositivos para la industria automotriz son de 64 bits, haz lo siguiente:

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

  • 280 dpi o menos en pantallas pequeñas o normales
  • ldpi o inferior en pantallas extragrandes
  • mdpi o inferior en pantallas grandes

• [7.6.1/A-2-2] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 944 MB si se usa alguna de las siguientes densidades:

  • xhdpi o superior en pantallas pequeñas o normales
  • hdpi o superior en pantallas grandes
  • mdpi o superior en pantallas extragrandes

• [7.6.1/A-2-3] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1280 MB si se usa alguna de las siguientes densidades:

  • 400 dpi o superior en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes

• [7.6.1/A-2-4] La memoria disponible para el kernel y el espacio de usuario DEBE ser de al menos 1824 MB si se usa alguna de las siguientes densidades:

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

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

Implementaciones de dispositivos para la industria automotriz:

• [7.7.1/A] DEBE incluir un puerto USB compatible con el modo periférico.

Implementaciones de dispositivos para la industria automotriz:

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

Implementaciones de dispositivos para la industria automotriz:

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

2.5.2. Multimedia

Las implementaciones de dispositivos para vehículos DEBEN admitir la siguiente codificación de audio:

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

Las implementaciones de dispositivos para vehículos DEBEN admitir la siguiente codificación de video:

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

Las implementaciones de dispositivos para vehículos DEBEN admitir la siguiente decodificación de video:

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

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos para vehículos admitan la siguiente decodificación de video:

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

2.5.3. Software

Implementaciones de dispositivos para la industria automotriz:

• [3/A-0-1] DEBE declarar la función android.hardware.type.automotive.

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

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

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

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

• [3.8.4/A-SR] Se recomienda implementar un asistente en el dispositivo para controlar la acción de asistencia.

• [3.13/A-SR] SE RECOMIENDA ENFATICAMENTE que incluyas un componente de IU de Configuración rápida.

Si las implementaciones de dispositivos para la industria automotriz incluyen un botón de pulsar para hablar, deben cumplir con los siguientes requisitos:

• [3.8.4/A-1-1] DEBE usar una presión breve del botón Push-to-Talk como la interacción designada para iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService.

Implementaciones de dispositivos para la industria automotriz:

• [3.14/A-0-1] DEBE incluir un framework de IU para admitir apps de terceros que usen las APIs de contenido multimedia, como se describe en el artículo 3.14.

2.5.4. Rendimiento y energía

Si las implementaciones de dispositivos para Automotive incluyen funciones para mejorar la administración de energía del dispositivo que se incluyen en AOSP o extienden las funciones que se incluyen en AOSP, deben cumplir con los siguientes requisitos:

• [8.3/A-1-1] DEBE proporcionar indicaciones visuales para que el usuario habilite y deshabilite la función de ahorro de batería.
• [8.3/A-1-2] DEBE proporcionar indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Descanso.

Implementaciones de dispositivos para la industria automotriz:

• [8.2/A-0-1] DEBE informar la cantidad de bytes leídos y escritos en el almacenamiento no volátil por cada UID de proceso para que las estadísticas estén disponibles para los desarrolladores a través de la API del sistema android.car.storagemonitoring.CarStorageMonitoringManager. El Proyecto de código abierto de Android cumple con el requisito a través del módulo del kernel uid_sys_stats.
• [8.4/A-0-1] DEBE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del proyecto de código abierto de Android.
• [8.4/A-0-2] DEBEN informar todos los valores de consumo de energía en miliamperios-hora (mAh).
• [8.4/A-0-3] DEBE informar el consumo de energía de la CPU por UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo de kernel uid_cputime.
• [8.4/A] DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo de energía del componente de hardware a una aplicación.
• [8.4/A-0-4] DEBE hacer que este consumo de energía esté disponible para el desarrollador de la app a través del comando de shell adb shell dumpsys batterystats.

2.5.5. Modelo de seguridad

Si las implementaciones de dispositivos de Automotive admiten varios usuarios, deben cumplir con los siguientes requisitos:

• [9.5/A-1-1] DEBE incluir una cuenta de invitado que permita todas las funciones que proporciona el sistema del vehículo sin que el usuario deba acceder a ella.

Si las implementaciones de dispositivos para la industria automotriz admiten una pantalla de bloqueo segura, deben cumplir con los siguientes requisitos:

• [9.9.2/A-1-1] DEBE admitir la encriptación por claves de autenticación específicas del usuario. La encriptación basada en archivos (FBE) es una forma de hacerlo.

Implementaciones de dispositivos para la industria automotriz:

• [9.14/A-0-1] DEBE controlar los mensajes de los subsistemas de vehículos del framework de Android, p.ej., permitir tipos de mensajes y fuentes de mensajes permitidos.
• [9.14/A-0-2] DEBE supervisar los ataques de denegación del servicio desde el framework de Android o las apps de terceros. Esto protege contra el software malicioso que inunda la red del vehículo con tráfico, lo que puede provocar que los subsistemas del vehículo funcionen mal.

2.6. Requisitos de las tablets

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

• Por lo general, se sostiene con ambas manos.
• No tiene una configuración de libro o convertible.
• Cualquier implementación de teclado físico que se use con el dispositivo DEBE conectarse mediante una conexión estándar.
• Tiene una fuente de alimentación que proporciona movilidad, como una batería.
• Tiene un tamaño físico diagonal de la pantalla de entre 7 y 18 pulgadas.

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

2.4.1. Hardware

Tamaño de la pantalla

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

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

Las densidades de pantalla que se indican para pantallas pequeñas o normales en los requisitos de las computadoras de mano no se aplican a las tablets.

Modo periférico USB (Sección 7.7.1)

Si las implementaciones de dispositivos de tablet incluyen un puerto USB que admite el modo periférico, tienen las siguientes características:

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

Modo de realidad virtual (Sección 7.9.1)

Rendimiento alto de realidad virtual (sección 7.9.2)

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

3. Software

3.1. Compatibilidad de APIs administradas

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

Implementaciones de dispositivos:

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

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

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

• [C-0-4] DEBEN seguir manteniendo las APIs presentes y comportarse de manera razonable, incluso cuando se omiten algunas funciones de hardware para las que Android incluye APIs. Consulta la sección 7 para conocer los requisitos específicos de esta situación.

• [C-0-5] DEBEN restringir el uso de APIs ocultas por parte de apps de terceros, definidas como APIs en el espacio de nombres de Android decoradas con la anotación @hidden, pero no con @SystemAPI o @TestApi, como se describe en los documentos del SDK y enviar cada una de las APIs ocultas en las mismas listas restringidas que se proporcionan a través de la lista provisional y los archivos de lista de entidades rechazadas en la ruta de acceso prebuilts/runtime/appcompat/ para la rama de nivel de API adecuada en el AOSP. Sin embargo, tienen las siguientes características:

  • SI, si una API oculta no está presente o se implementa de forma diferente en la implementación del dispositivo, mueve la API oculta a la lista de entidades rechazadas o omítela de todas las listas restringidas.
  • SI ES POSIBLE, si aún no existe una API oculta en el AOSP, agrégala a cualquiera de las listas restringidas.
  • PUEDE implementar un mecanismo de actualización dinámica que mueva una API oculta de una lista restringida a una menos restrictiva, excepto la lista de entidades permitidas.

3.1.1. Extensiones de Android

Android incluye la compatibilidad para extender las APIs administradas y, al mismo tiempo, mantener la misma versión del nivel de API.

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

3.1.2. Biblioteca de Android

Debido a la baja del cliente HTTP de Apache, las implementaciones de dispositivos tienen las siguientes características:

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

La implementación de AOSP cumple con estos requisitos.

3.2. Compatibilidad de API flexible

Además de las APIs administradas de la sección 3.1, Android también incluye una API “flexible” significativa solo para el tiempo de ejecución, en forma de intents, permisos y aspectos similares de las aplicaciones para Android que no se pueden aplicar en el momento de la compilación de la aplicación.

3.2.1. Permisos

• [C-0-1] Los implementadores de dispositivos DEBEN admitir y aplicar todas las constantes de permisos, como se documenta en la página de referencia de permisos. Ten en cuenta que en la sección 9 se enumeran requisitos adicionales relacionados con el modelo de seguridad de Android.

3.2.2. Parámetros de compilación

Las APIs de Android incluyen una serie de constantes en la clase android.os.Build que tienen como objetivo describir el dispositivo actual.

• [C-0-1] Para proporcionar valores coherentes y significativos en todas las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que DEBEN cumplir las implementaciones de dispositivos.

Parámetro	Detalles
VERSION.RELEASE	Es la versión del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en 9.
VERSION.SDK	Es la versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. Para Android 9, este campo DEBE tener el valor de número entero 9_INT.
VERSION.SDK_INT	Es la versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de la aplicación de terceros. Para Android 9, este campo DEBE tener el valor de número entero 9_INT.
VERSION.INCREMENTAL	Es un valor que elige el implementador del dispositivo y que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO SE DEBE volver a usar para diferentes compilaciones que se ponen a disposición de los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de código fuente se usó para generar la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
JUEGOS DE MESA	Es un valor que elige el implementador del dispositivo que identifica el hardware interno específico que usa el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SEGURIDAD	Es un valor que refleja el nombre de la marca asociado con el dispositivo tal como lo conocen los usuarios finales. DEBEN estar en un formato legible por humanos y DEBEN representar al fabricante del dispositivo o la marca de la empresa con la que se comercializa el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
SUPPORTED_32_BIT_ABIS	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
SUPPORTED_64_BIT_ABIS	Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
CPU_ABI	Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
CPU_ABI2	Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa.
DISPOSITIVO	Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código que identifica la configuración de las funciones de hardware y el diseño industrial del dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. Este nombre de dispositivo NO DEBE cambiar durante la vida útil del producto.
FINGERPRINT	Es una cadena que identifica de forma inequívoca esta compilación. DEBE ser legible por humanos. DEBE seguir esta plantilla: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Por ejemplo: acme/myproduct/     mydevice:9/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 dactilar de compilación por otro carácter, como el guion bajo ("_"). El valor de este campo DEBE poder codificarse como ASCII de 7 bits.
HARDWARE	Es el nombre del hardware (de la línea de comandos del kernel o /proc). DEBE ser legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
ORGANIZADOR	Es una cadena que identifica de forma exclusiva el host en el que se compiló la compilación, en formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
ID	Es un identificador que elige el implementador del dispositivo para hacer referencia a una versión específica, en formato legible por humanos. Este campo puede ser el mismo que android.os.Build.VERSION.INCREMENTAL, pero DEBE ser un valor lo suficientemente significativo para que los usuarios finales distingan entre compilaciones de software. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
FABRICANTE	Es el nombre comercial del fabricante del equipo original (OEM) del producto. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
MODELO.	Es un valor que elige el implementador del dispositivo y que contiene el nombre del dispositivo tal como lo conoce el usuario final. DEBE ser el mismo nombre con el que se comercializa y vende el dispositivo a los usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía (""). Este campo NO DEBE cambiar durante la vida útil del producto.
PRODUCTO	Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código del producto específico (SKU) que DEBE ser único dentro de la misma marca. DEBEN ser legibles por humanos, pero no necesariamente están destinados a que los usuarios finales los vean. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. Este nombre del producto NO DEBE cambiar durante la vida útil del producto.
SERIAL	DEBE mostrar el valor "UNKNOWN".
ETIQUETAS	Es una lista de etiquetas separadas por comas que elige el implementador del dispositivo y que distingue aún más la compilación. 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	Es un valor que representa la marca de tiempo de la compilación.
TIPO	Es un valor que elige el implementador del dispositivo y que especifica la configuración del entorno de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas del entorno de ejecución de Android: user, userdebug o eng.
USUARIO	Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía ("").
SECURITY_PATCH	Es un valor que indica el nivel de 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 [AAAA-MM-DD] y coincidir con una cadena definida en el boletín de seguridad público de Android o en el aviso de seguridad de Android, por ejemplo, "2015-11-01".
BASE_OS	Es un valor que representa el parámetro FINGERPRINT de la compilación que, en términos generales, es idéntico a esta, excepto por los parches proporcionados en el Boletín de seguridad pública de Android. DEBE informar el valor correcto y, si no existe tal compilación, informar una cadena vacía ("").
BOOTLOADER	Es un valor que elige el implementador del dispositivo y que identifica la versión específica del bootloader interno que se usa en el dispositivo, en formato legible por humanos. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-]+$”.
getRadioVersion()	DEBE (ser o mostrar) un valor que elija el implementador del dispositivo que identifique la versión específica de radio o módem interna que se usa en el dispositivo, en formato legible por humanos. Si un dispositivo no tiene ningún radio o módem interno, DEBE mostrar NULL. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.
getSerial()	DEBE (ser o devolver) un número de serie de hardware, que DEBE estar disponible y ser único en todos los dispositivos con el mismo MODELO y FABRICANTE. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9._-,]+$”.

3.2.3. Compatibilidad con intents

3.2.3.1. Intents de la aplicación principales

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

• [C-0-1] Las implementaciones de 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 de Android en AOSP:

  • Reloj de escritorio
  • Navegador
  • Calendario
  • Contactos
  • Galería
  • GlobalSearch
  • Selector
  • Música
  • Configuración

3.2.3.2. Resolución de intents

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

• [C-0-2] Los implementadores de 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 a estos patrones y asuman el control de ellos. Esta prohibición incluye específicamente, pero no se limita a, inhabilitar la interfaz de usuario "Selector" que permite al usuario elegir entre varias aplicaciones que controlan el mismo patrón de intent.

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

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

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

• [C-0-4] DEBE intentar validar cualquier filtro de intents realizando los pasos de validación definidos en la especificación de Vínculos de recursos digitales, tal como lo implementa el Administrador de paquetes en el proyecto de código abierto de Android upstream.
• [C-0-5] DEBE intentar validar los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de URI validados correctamente como controladores de apps predeterminados para sus URIs.
• PUEDEN establecer filtros de intents de URI específicos como controladores de apps predeterminados para sus URIs, si se verifican correctamente, pero otros filtros de URI candidatos no pasan la verificación. Si una implementación de dispositivo hace esto, DEBE proporcionar al usuario las anulaciones de patrones por URI adecuadas en el menú de configuración.
• DEBEN proporcionar al usuario controles de Vínculos de app por app en Configuración de la siguiente manera:
  • [C-0-6] El usuario DEBE poder anular de forma integral el comportamiento predeterminado de los vínculos de apps para que una app se abra siempre, siempre pregunte o nunca se abra, lo que se debe aplicar a todos los filtros de intents de URI candidatos por igual.
  • [C-0-7] El usuario DEBE poder ver una lista de los filtros de intents de URI candidatos.
  • La implementación del dispositivo PUEDE proporcionarle al usuario la capacidad de anular filtros de intents de URI candidatos específicos que se verificaron correctamente, por filtro de intents.
  • [C-0-8] La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intents de URI candidato específicos si la implementación del dispositivo permite que algunos filtros de intents de URI candidato se verifiquen correctamente, mientras que otros pueden fallar.

3.2.3.3. Espacios de nombres de intents

• [C-0-1] Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que respete ningún intent nuevo o patrones de intent de transmisión con una ACTION, CATEGORY o alguna otra cadena clave en el espacio de nombres android. o com.android.
• [C-0-2] Los implementadores de dispositivos NO DEBEN incluir componentes de Android que respeten ningún intent nuevo o patrones de intent de transmisión con una ACTION, CATEGORY o alguna otra cadena clave en un espacio de paquete que pertenezca a otra organización.
• [C-0-3] Los implementadores de dispositivos NO DEBEN alterar ni extender ninguno de los patrones de intents que usan las apps principales que se indican en la sección 3.2.3.1.
• Las implementaciones de dispositivos PUEDEN incluir patrones de intents que usan espacios de nombres asociados de forma clara y evidente con su propia organización. Esta prohibición es análoga a la especificada para las clases del lenguaje Java en la sección 3.6.

3.2.3.4. Intents de transmisión

Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intents que les notifican los cambios en el entorno de hardware o software.

Implementaciones de dispositivos:

• [C-0-1] DEBE transmitir los intents de transmisión pública en respuesta a los eventos del sistema adecuados, como se describe en la documentación del SDK. Ten en cuenta que este requisito no entra en conflicto con el artículo 3.5, ya que la limitación para las aplicaciones en segundo plano también se describe en la documentación del SDK.

3.2.3.5. Configuración predeterminada de la app

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

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

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

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

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

• [C-2-1] DEBE proporcionar un menú de configuración que llame al intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar un diálogo que cambie la aplicación de SMS predeterminada.

• [C-2-2] DEBE respetar el intent android.telecom.action.CHANGE_DEFAULT_DIALER para mostrar un diálogo que le permita al usuario cambiar la aplicación de Teléfono predeterminada.

  • DEBEN usar la IU de la app de teléfono predeterminada que selecciona el usuario para las llamadas entrantes y salientes, excepto las llamadas de emergencia, que usarían la app de teléfono preinstalada.

• [C-2-3] DEBE respetar la intención android.telecom.action.CHANGE_PHONE_ACCOUNTS para proporcionar al usuario indicaciones visuales para configurar el ConnectionServices asociado con el PhoneAccounts, así como una PhoneAccount predeterminada que el proveedor de servicios de telecomunicaciones usará para realizar llamadas salientes. La implementación de AOSP cumple con este requisito, ya que incluye un menú "Calling Accounts option" en el menú de configuración "Calls".

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

• [C-3-1] DEBE respetar la intención android.settings.NFC_PAYMENT_SETTINGS para mostrar un menú de configuración de la app predeterminado para Toca y paga.

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

• [C-4-1] DEBE respetar la intención android.settings.ACTION_VOICE_INPUT_SETTINGS para mostrar un menú de configuración predeterminado de la app para la entrada de voz y la asistencia.

3.2.4. Actividades en pantallas secundarias

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

• [C-1-1] DEBE establecer la marca de función android.software.activities_on_secondary_displays.
• [C-1-2] DEBE garantizar la compatibilidad de la API similar a una actividad que se ejecuta en la pantalla principal.
• [C-1-3] DEBE ubicar la actividad nueva en la misma pantalla que la actividad que la inició, cuando la actividad nueva se inicia sin especificar una pantalla de destino a través de la API de ActivityOptions.setLaunchDisplayId().
• [C-1-4] DEBEN destruirse todas las actividades cuando se quita una pantalla con la marca Display.FLAG_PRIVATE.
• [C-1-5] DEBEN cambiar el tamaño de todas las actividades en un VirtualDisplay según corresponda si se cambia el tamaño de la pantalla.
• PUEDE mostrar un IME (editor de método de entrada, un control de usuario que permite ingresar texto) en la pantalla principal cuando un campo de entrada de texto se enfoca en una pantalla secundaria.
• DEBE implementar el enfoque de entrada en la pantalla secundaria independientemente de la pantalla principal, cuando se admitan entradas táctiles o de teclas.
• DEBE tener android.content.res.Configuration que corresponde a esa pantalla para mostrarse, funcionar correctamente y mantener la compatibilidad si se inicia una actividad en la pantalla secundaria.

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

• [C-2-1] NO SE DEBEN permitir actividades que no se puedan cambiar de tamaño (que tengan resizeableActivity=false en AndroidManifest.xml) ni apps que se orienten al nivel de API 23 o versiones anteriores en 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, haz lo siguiente:

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

3.3. Compatibilidad con la API nativa

La compatibilidad con el código nativo es un desafío. Por este motivo, los implementadores de dispositivos tienen las siguientes características:

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

3.3.1. Interfaces binarias de la aplicación

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

Implementaciones de dispositivos:

• [C-0-1] DEBEN ser compatibles con una o más ABI definidas y deben implementar la compatibilidad con el NDK de Android.
• [C-0-2] DEBE incluir compatibilidad con el código que se ejecuta en el entorno administrado para llamar al código nativo con la semántica estándar de la interfaz nativa de Java (JNI).
• [C-0-3] DEBE ser compatible con la fuente (es decir, compatible con el encabezado) y con el código binario (para la ABI) con cada biblioteca obligatoria de la siguiente lista.
• [C-0-5] DEBE informar con precisión la interfaz binaria de aplicación (ABI) nativa que admite el dispositivo a través de los parámetros android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS y android.os.Build.SUPPORTED_64_BIT_ABIS, cada uno de los cuales es una lista separada por comas de ABIs ordenadas de la más a la menos preferida.

• [C-0-6] DEBE informar, a través de los parámetros anteriores, un subconjunto de la siguiente lista de ABI y NO DEBE informar ninguna ABI que no esté en la lista.

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (compatibilidad con audio nativo de AAudio)

  • libandroid.so (compatibilidad con actividades nativas de Android)
  • libc (biblioteca C)
  • libcamera2ndk.so
  • libdl (vinculador dinámico)
  • libEGL.so (administración nativa de la superficie de OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (registro de Android)
  • libmediandk.so (compatibilidad con APIs de contenido multimedia nativas)
  • libm (biblioteca matemática)
  • libneuralnetworks.so (API de Neural Networks)
  • libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
  • libOpenSLES.so (Compatibilidad con audio de OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (Compatibilidad mínima con C++)
  • libvulkan.so (Vulkan)
  • libz (compresión zlib)
  • Interfaz de JNI

• [C-0-8] NO DEBES agregar ni quitar las funciones públicas de las bibliotecas nativas mencionadas anteriormente.

• [C-0-9] DEBE enumerar las bibliotecas adicionales que no son de AOSP expuestas directamente a apps de terceros en /vendor/etc/public.libraries.txt.
• [C-0-10] NO DEBE exponer ninguna otra biblioteca nativa, implementada y proporcionada en AOSP como bibliotecas del sistema, a apps de terceros orientadas al nivel de API 24 o versiones posteriores, ya que están reservadas.
• [C-0-11] DEBES exportar todos los símbolos de función de OpenGL ES 3.1 y el 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 el artículo 7.1.4.1 se describen con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.
• [C-0-12] DEBES exportar símbolos de función para los símbolos de función principales de Vulkan 1.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 el artículo 7.1.4.2 se describen con más detalle los requisitos para cuando se espera la implementación completa de cada función correspondiente.
• DEBE compilarse con el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android upstream.

Ten en cuenta que es posible que las versiones futuras de Android admitan ABI adicionales.

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

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

• [C-3-1] TAMBIÉN DEBE admitir armeabi-v7a y notificar su compatibilidad, ya que armeabi solo es para la retrocompatibilidad con apps anteriores.

Si las implementaciones de dispositivos informan la compatibilidad con la ABI de armeabi-v7a, para las apps que usan esta ABI, sucede lo siguiente:

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

  • Features:, seguida de una lista de las funciones opcionales de la CPU ARMv7 que admite el dispositivo.
  • CPU architecture:, seguido de un número entero que describe la arquitectura ARM más reciente compatible con el dispositivo (p.ej., “8” para dispositivos ARMv8).

• [C-2-2] SIEMPRE DEBEN mantener disponibles las siguientes operaciones, incluso en el caso de que la ABI se implemente en una arquitectura ARMv8, ya sea a través de la compatibilidad con CPU nativa o a través de la emulación de software:

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

• [C-2-3] DEBE incluir compatibilidad con la extensión Advanced SIMD (también conocida como NEON).

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

Si las implementaciones de dispositivos proporcionan una implementación completa de la API de android.webkit.Webview, hacen 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 upstream en la rama de Android 9 para la implementación de la API de android.webkit.WebView.

• [C-1-3] La cadena de usuario-agente que informa WebView DEBE tener este formato:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • El valor de la cadena $(VERSION) DEBE ser el mismo que el valor de android.os.Build.VERSION.RELEASE.
  • La cadena $(MODEL) PUEDE estar vacía, pero, si no lo está, DEBE tener el mismo valor que android.os.Build.MODEL.
  • SE PUEDE omitir "Build/$(BUILD)", pero si está presente, la cadena $(BUILD) DEBE ser igual al valor de android.os.Build.ID.
  • El valor de la cadena $(CHROMIUM_VER) DEBE ser la versión de Chromium en el proyecto de código abierto de Android upstream.
  • Las implementaciones de dispositivos PUEDEN omitir Mobile en la cadena del usuario-agente.

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

3.4.2. Compatibilidad del navegador

Si las implementaciones de dispositivos incluyen una aplicación de navegador independiente para la navegación web general, tienen las siguientes características:

• [C-1-1] DEBE admitir cada una de estas APIs asociadas con HTML5:
  • operación sin conexión o de caché de la aplicación
  • Etiqueta<video>
  • geolocation
• [C-1-2] DEBE admitir la API de WebStorage de HTML5/W3C y DEBE admitir la API de IndexedDB de HTML5/W3C. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer IndexedDB sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.
• PUEDE enviar una cadena de usuario-agente personalizada en la aplicación independiente del navegador.
• DEBE implementar la compatibilidad con la mayor cantidad posible de HTML5 en la aplicación de navegador independiente (ya sea que se base en la aplicación de navegador WebKit upstream o en un reemplazo de terceros).

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

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

3.5. Compatibilidad de comportamiento de la API

Implementaciones de dispositivos:

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

Los comportamientos de cada uno de los tipos de API (administrados, flexibles, nativos y web) deben ser coherentes con la implementación preferida del proyecto de código abierto de Android upstream. Estas son algunas áreas específicas de compatibilidad:

• [C-0-1] Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent estándar.
• [C-0-2] Los dispositivos NO DEBEN alterar el ciclo de vida ni la semántica del ciclo de vida de un tipo particular de componente del sistema (como Service, Activity, ContentProvider, etcétera).
• [C-0-3] Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.
• Los dispositivos NO DEBEN alterar las limitaciones aplicadas a las aplicaciones en segundo plano. Más específicamente, para las apps en segundo plano:
  • [C-0-4] DEBEN dejar de ejecutar las devoluciones de llamada que registra la app para recibir resultados de GnssMeasurement y GnssNavigationMessage.
  • [C-0-5] DEBEN establecer un límite de frecuencia para la frecuencia de 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 se orienta al nivel de API 25 o una versión posterior, NO DEBE permitir el registro de receptores de emisión para las transmisiones implícitas de intents estándar de Android en el manifiesto de la app, a menos que el intent de emisión requiera un permiso "signature" o "signatureOrSystem" protectionLevel o esté en la lista de exenciones.
  • [C-0-7] Si la app se orienta al nivel de API 25 o superior, DEBE detener los servicios en segundo plano de la app, tal como si la app hubiera llamado al método stopSelf() de los servicios, a menos que la app se coloque en una lista de entidades permitidas temporal para controlar una tarea que el usuario pueda ver.
  • [C-0-8] Si la app se orienta al nivel de API 25 o versiones posteriores, DEBEN liberar los bloqueos de activación que contiene.
• [C-0-9] Los dispositivos DEBEN mostrar los siguientes proveedores de seguridad como los primeros siete valores del array del método Security.getProviders(), en el orden y con los nombres (como los muestra Provider.getName()) y las clases determinados, a menos que la app haya modificado la lista a través de insertProviderAt() o removeProvider(). Es POSIBLE que los dispositivos devuelvan proveedores adicionales después de la lista de proveedores especificada a continuación.
  1. AndroidNSSP: android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL: com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider: sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround: android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC: com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE: com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore: android.security.keystore.AndroidKeyStoreProvider

La lista anterior no es exhaustiva. El conjunto de pruebas de compatibilidad (CTS) prueba partes significativas de la plataforma para verificar la compatibilidad de comportamiento, pero no todas. Es responsabilidad del implementador garantizar la compatibilidad de comportamiento con el Proyecto de código abierto de Android. Por este motivo, los implementadores de dispositivos DEBEN usar el código fuente disponible a través del Proyecto de código abierto de Android siempre que sea posible, en lugar de volver a implementar partes significativas del sistema.

3.5.1. Restricción en segundo plano

Si las implementaciones de dispositivos implementan las restricciones de apps que se incluyen en AOSP o las extienden, hacen lo siguiente:

• [C-SR] SE RECOMIENDA ENFATICAMENTE que se proporcione una indicación visual para que el usuario pueda ver la lista de apps restringidas.
• [C-1-2] DEBE proporcionar indicaciones visuales para que el usuario active o desactive las restricciones en cada app.
• [C-1-3] NO DEBE aplicar restricciones automáticamente sin evidencia de un comportamiento deficiente del estado del sistema, pero PUEDE aplicar las restricciones en las apps cuando se detecta un comportamiento deficiente del estado del sistema, como bloqueos de activación atascados, servicios de larga duración y otros criterios. Los implementadores de dispositivos PUEDEN determinar los criterios, pero DEBEN estar relacionados con el impacto de la app en el estado del sistema. NO DEBEN usarse otros criterios que no se relacionen únicamente con el estado del sistema, como la falta de popularidad de la app en el mercado.
• [C-1-4] NO DEBE aplicar restricciones de apps automáticamente cuando un usuario las desactivó de forma manual y PUEDE sugerirle al usuario que aplique restricciones de apps.
• [C-1-5] DEBEN informar a los usuarios si se aplican restricciones a una app automáticamente.
• [C-1-6] DEBE mostrar true para ActivityManager.isBackgroundRestricted() cuando la app restringida llame a esta API.
• [C-1-7] NO DEBE restringir la app en primer plano que el usuario usa de forma explícita.
• [C-1-8] DEBEN suspender las restricciones en una app que se convierte en la aplicación en primer plano principal cuando el usuario comienza a usar de forma explícita la app que solía estar restringida.

3.6. Espacios de nombres de la API

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

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

Es decir, tienen las siguientes características:

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

Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero estas modificaciones deben cumplir con los siguientes requisitos:

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

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

• [C-0-5] NO DEBE estar en un espacio de nombres que pertenezca a otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* ni a uno similar: solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a los espacios de nombres de otras empresas.
• [C-0-6] DEBEN empaquetarse en una biblioteca compartida de Android para que solo las apps que las usen de forma explícita (a través del mecanismo <uses-library>) se vean afectadas por el aumento del uso de memoria de esas APIs.

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

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

3.7. Compatibilidad con el entorno de ejecución

Implementaciones de dispositivos:

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

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

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

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

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

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

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Selector (pantalla principal)

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

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

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

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

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

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

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

Si las implementaciones de dispositivos implementan un selector predeterminado que proporciona acceso rápido a los accesos directos adicionales que proporcionan las apps de terceros a través de la API de ShortcutManager, hacen lo siguiente:

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

Si las implementaciones de dispositivos incluyen una app de selector predeterminada que muestra insignias para los íconos de la app, estas deben cumplir con los siguientes requisitos:

• [C-5-1] DEBE respetar el método de la API de NotificationChannel.setShowBadge(). En otras palabras, muestra una indicación visual asociada con el ícono de la app si el valor se establece como true y no muestres ningún esquema de insignias de íconos de apps cuando todos los canales de notificaciones de la app hayan establecido el valor como false.
• PUEDEN anular las insignias del ícono de la app con su esquema de insignias propietario cuando las aplicaciones de terceros indican compatibilidad con el esquema de insignias propietario a través del uso de APIs propietarias, pero DEBEN usar los recursos y valores proporcionados a través de las APIs de insignias de notificaciones que se describen en el SDK, como las APIs de Notification.Builder.setNumber() y 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, pueden hacer lo siguiente:

• [C-1-1] DEBE declarar la compatibilidad con la función de plataforma android.software.app_widgets.
• [C-1-2] DEBE incluir compatibilidad integrada con AppWidgets y exponer indicaciones visuales de la interfaz de usuario para agregar, configurar, ver y quitar AppWidgets directamente desde el selector.
• [C-1-3] DEBE ser capaz de renderizar widgets de 4 × 4 en el tamaño de cuadrícula estándar. Consulta las Pautas de diseño de widgets de apps en la documentación del SDK de Android para obtener más información.
• PUEDE admitir widgets de aplicaciones en la pantalla de bloqueo.

Si las implementaciones de dispositivos admiten widgets de apps de terceros y la fijación de atajos en la app, hacen lo siguiente:

• [C-2-1] DEBE informar true para AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] DEBE tener una indicación visual para el usuario antes de agregar un atajo solicitado por las apps a través del método de la API de AppWidgetManager.requestPinAppWidget().

3.8.3. Notificaciones

Android incluye las APIs de Notification y NotificationManager, que permiten que los desarrolladores de apps de terceros notifiquen a los usuarios sobre eventos importantes y atraigan su atención con los componentes de hardware (p.ej., sonido, vibración y luz) y las funciones de software (p.ej., panel de notificaciones y barra del sistema) del dispositivo.

3.8.3.1. Presentación de notificaciones

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

• [C-1-1] DEBE admitir notificaciones que usen funciones de hardware, como se describe en la documentación del SDK y, en la medida de lo posible, con el hardware de implementación del dispositivo. Por ejemplo, si una implementación de dispositivo incluye un vibrador, DEBE implementar correctamente las APIs de vibración. Si una implementación de dispositivo carece de hardware, las APIs correspondientes DEBEN implementarse como no-ops. Este comportamiento se detalla en la sección 7.
• [C-1-2] DEBEN renderizar correctamente todos los recursos (íconos, archivos de animación, etc.) que se proporcionan en las APIs o en la guía de estilo de íconos de la barra de estado o del sistema, aunque PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de código abierto de Android de referencia.
• [C-1-3] DEBEN cumplir y aplicar correctamente los comportamientos descritos para las APIs para actualizar, quitar y agrupar notificaciones.
• [C-1-4] DEBE proporcionar el comportamiento completo de la API de NotificationChannel documentada en el SDK.
• [C-1-5] DEBE proporcionar una indicación visual para el usuario para bloquear y modificar la notificación de una app de terceros determinada por cada canal y nivel de paquete de la app.
• [C-1-6] TAMBIÉN DEBE proporcionar una indicación visual para el usuario para mostrar los canales de notificación borrados.
• [C-1-7] DEBEN renderizar correctamente todos los recursos (imágenes, calcomanías, íconos, etcétera) proporcionados a través de Notification.MessagingStyle junto con el texto de la notificación sin interacción adicional del usuario. Por ejemplo, DEBEN mostrar todos los recursos, incluidos los íconos proporcionados a través de android.app.Person en una conversación grupal que se configure a través de setGroupConversation.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que muestres automáticamente una indicación visual para el usuario para bloquear la notificación de una app de terceros determinada por cada canal y nivel de paquete de la app después de que el usuario descarte esa notificación varias veces.
• DEBE admitir notificaciones enriquecidas.
• DEBE presentar algunas notificaciones de prioridad más alta como notificaciones de atención.
• DEBE tener una indicación visual para el usuario para posponer las notificaciones.
• SOLO PUEDEN administrar la visibilidad y el tiempo en que las apps de terceros pueden notificar a los usuarios sobre eventos importantes para mitigar problemas de seguridad, como la distracción del conductor.

Si las implementaciones de dispositivos admiten notificaciones enriquecidas, pueden hacer lo siguiente:

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

Si las implementaciones de dispositivos admiten notificaciones de atención, estas tienen las siguientes características:

• [C-3-1] DEBE usar la vista y los recursos de notificaciones de atención como se describe en la clase de API de Notification.Builder cuando se presentan notificaciones de atención.
• [C-3-2] DEBE mostrar las acciones proporcionadas a través de Notification.Builder.addAction() junto con el contenido de la notificación sin interacción adicional del usuario, como se describe en el SDK.

3.8.3.2. Servicio de objeto de escucha de notificaciones

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

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

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

Si las implementaciones de dispositivos tienen una indicación visual para que el usuario posponga las notificaciones, deben cumplir con los siguientes requisitos:

• [C-2-1] DEBE reflejar el estado de la notificación pospuesta correctamente a través de las APIs estándar, como NotificationListenerService.getSnoozedNotifications().
• [C-2-2] DEBE hacer que esta indicación visual para el usuario esté disponible para posponer las notificaciones de cada app de terceros instalada, a menos que provengan de servicios persistentes o en primer plano.

3.8.3.3. DND (No interrumpir)

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

• [C-1-1] DEBE implementar una actividad que responda al intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, que, para las implementaciones con UI_MODE_TYPE_NORMAL, DEBE ser una actividad en la que el usuario pueda otorgar o denegar el acceso de la app a la configuración de la política de No interrumpir.
• [C-1-2] DEBE mostrar las reglas de No interrumpir automáticamente creadas por las aplicaciones junto con las reglas predefinidas y creadas por el usuario cuando la implementación del dispositivo haya proporcionado un medio para que el usuario otorgue o deniegue el acceso de las apps de terceros a la configuración de la política de No interrumpir.
• [C-1-3] DEBE respetar los valores de suppressedVisualEffects que se pasan a través de NotificationManager.Policy y, si una app configuró alguna de las marcas SUPPRESSED_EFFECT_SCREEN_OFF o SUPPRESSED_EFFECT_SCREEN_ON, DEBE indicarle al usuario que se suprimen los efectos visuales en el menú de configuración de No interrumpir.

3.8.4. Buscar

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

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

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

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

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

• El comportamiento predeterminado DEBE ser mostrar resultados y sugerencias de motores 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 Asistente, hacen lo siguiente:

• [C-2-1] DEBE indicar claramente al usuario final cuándo se comparte el contexto de una de las siguientes maneras:
  • Cada vez que la app de asistencia accede al contexto, se muestra una luz blanca alrededor de los bordes de la pantalla que cumple o supera la duración y el brillo de la implementación del proyecto de código abierto de Android.
  • Para la app de asistencia preinstalada, proporciona una indicación visual al usuario a menos de dos navegaciones del menú de configuración predeterminado de la entrada de voz y la app de asistencia, y solo comparte el contexto cuando el usuario invoca explícitamente la app de asistencia a través de una palabra clave o una entrada de tecla de navegación de asistencia.
• [C-2-2] La interacción designada para iniciar la app de asistencia, como se describe en la sección 7.2.3, DEBE iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa VoiceInteractionService, o una actividad que controle el intent ACTION_ASSIST.

3.8.5. Alertas y notificaciones emergentes

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

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:

• [C-1-1] DEBE proporcionar una indicación visual para el usuario para bloquear una app de mostrar ventanas de alerta que usen TYPE_APPLICATION_OVERLAY . La implementación de AOSP cumple con este requisito porque tiene controles en la barra de notificaciones.

• [C-1-2] DEBE respetar la API de Toast y mostrar los 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 que los desarrolladores de aplicaciones pueden usar si desean que coincidan con el aspecto y comportamiento del tema Holo, tal como lo define el SDK de Android.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:

• [C-1-1] NO DEBE alterar ninguno de los atributos del tema Holo expuestos a las aplicaciones.
• [C-1-2] DEBEN admitir la familia de temas "Material" y NO DEBEN alterar ninguno de los atributos de temas de Material ni sus recursos expuestos a las aplicaciones.

Android también incluye una familia de temas "Predeterminado del dispositivo" como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si desean que coincidan con el aspecto del tema del dispositivo, tal como lo define el implementador del dispositivo.

• Las implementaciones de dispositivos PUEDEN modificar los atributos del tema predeterminado del dispositivo expuestos a las aplicaciones.

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

Si las implementaciones de dispositivos incluyen una barra de estado del sistema, deben cumplir con los siguientes requisitos:

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

3.8.7. Fondos de pantalla animados

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

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

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

Si las implementaciones de dispositivos implementan fondos de pantalla animados, hacen lo siguiente:

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

3.8.8. Cambio de actividad

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

Es POSIBLE que las implementaciones de dispositivos que incluyan la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, alteren la interfaz.

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

• [C-1-1] DEBE admitir al menos 7 actividades mostradas.
• DEBE mostrar al menos el título de 4 actividades a la vez.
• [C-1-2] DEBE implementar el comportamiento de fijación de pantalla y proporcionarle al usuario un menú de configuración para activar o desactivar la función.
• DEBE mostrar el color de resaltado, el ícono y el título de la pantalla en Recientes.
• DEBE mostrar un indicador de cierre ("x"), pero PUEDE retrasarlo hasta que el usuario interactúe con las pantallas.
• DEBE implementar un atajo para cambiar fácilmente a la actividad anterior.
• DEBE activar la acción de cambio rápido entre las dos apps que se usaron más recientemente cuando se presiona dos veces la tecla de función de apps recientes.
• DEBE activar el modo multiventana de pantalla dividida, si es compatible, cuando se mantiene presionada la tecla de funciones recientes.
• PUEDE mostrar contenido reciente afiliado como un grupo que se mueve junto.
• [SR] SE RECOMIENDA ENFATICAMENTE usar la interfaz de usuario de Android upstream (o una interfaz similar basada en miniaturas) para la pantalla de descripción general.

3.8.9. Administración de entradas

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

Si las implementaciones de dispositivos permiten que los usuarios usen métodos de entrada de terceros en el dispositivo, deben cumplir con los siguientes requisitos:

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

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

• [C-2-1] DEBEN implementar por completo las APIs de AutofillService y AutofillManager, y respetar el intent android.settings.REQUEST_SET_AUTOFILL_SERVICE para mostrar un menú de configuración predeterminado de la app para habilitar y deshabilitar el autocompletado y cambiar el servicio de autocompletado predeterminado del usuario.

3.8.10. Control de contenido multimedia en la pantalla de bloqueo

La API de cliente de control remoto dejó de estar disponible a partir de Android 5.0 en favor de la plantilla de notificación multimedia, que permite que las aplicaciones multimedia se integren con los controles de reproducción que se muestran en la pantalla de bloqueo.

3.8.11. Protectores de pantalla (anteriormente, Pantallas fantásticas)

Android incluye compatibilidad con protectores de pantalla interactivos, que antes se denominaban Pantallas de sueños. Los protectores de pantalla permiten que los usuarios interactúen con las aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o en una estación de carga. Los dispositivos Android Watch PUEDEN implementar protectores de pantalla, 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) que puede proporcionar las coordenadas de ubicación,

• [C-1-2] DEBE mostrar el estado actual de la ubicación en el menú Ubicación de Configuración.
• [C-1-3] NO DEBE mostrar los modos de ubicación en el menú Ubicación de Configuración.

3.8.13. Unicode y fuente

Android incluye compatibilidad con los caracteres de emoji definidos en Unicode 10.0.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:

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

Si las implementaciones de dispositivos incluyen un IME, hacen lo siguiente:

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

3.8.14. Multiventanas

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

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

Si las implementaciones de dispositivos admiten los modos multiventana y de pantalla dividida, hacen lo siguiente:

• [C-2-1] DEBE precargar un selector ajustable de tamaño como predeterminado.
• [C-2-2] DEBE recortar la actividad anclada de una multiventana de pantalla dividida, pero DEBE mostrar parte de su contenido si la app del selector es la ventana enfocada.
• [C-2-3] DEBE respetar los valores declarados de AndroidManifestLayout_minWidth y AndroidManifestLayout_minHeight de la aplicación del selector de terceros y no anularlos cuando se muestra contenido de la actividad en la estación de carga.

Si las implementaciones de dispositivos admiten modos multiventana y modo multiventana con pantalla en pantalla, hacen lo siguiente:

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

3.8.15. Corte de pantalla

Android admite un recorte de pantalla, como se describe en el documento del SDK. La API de DisplayCutout define un área en el borde de la pantalla que no es funcional para mostrar contenido.

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

• [C-1-1] SOLO debe tener recortes en los bordes cortos del dispositivo. Por el contrario, si la relación de aspecto del dispositivo es 1.0 (1:1), NO DEBEN tener recortes.
• [C-1-2] NO DEBE tener más de un corte por borde.
• [C-1-3] DEBE respetar las marcas de recorte de pantalla que establece la app a través de la API de WindowManager.LayoutParams, como se describe en el SDK.
• [C-1-4] DEBE informar valores correctos para todas las métricas de recorte definidas en la API de DisplayCutout.

3.9. Administración del dispositivo

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

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

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

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

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

• [C-1-1] DEBE admitir la inscripción de un cliente de políticas de dispositivos (DPC) como una app de propietario del dispositivo, como se describe a continuación:
  • Cuando la implementación del dispositivo aún no tiene datos del usuario configurados, sucede lo siguiente:
    • [C-1-3] DEBE informar true para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] DEBE inscribir la aplicación de DPC como la app del propietario del dispositivo en respuesta a la acción de intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] DEBE inscribir la aplicación de DPC como la app del propietario del dispositivo si el dispositivo declara compatibilidad con la comunicación de campo cercano (NFC) a través de la marca de función android.hardware.nfc y recibe un mensaje NFC que contiene un registro con el tipo MIME MIME_TYPE_PROVISIONING_NFC.
  • Cuando la implementación del dispositivo tiene datos del usuario, hace lo siguiente:
    • [C-1-6] DEBE informar false para DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] Ya NO DEBE inscribir ninguna aplicación de DPC como la app del propietario del dispositivo.
• [C-1-2] DEBEN requerir alguna acción afirmativa durante el proceso de aprovisionamiento para dar su consentimiento a que la app se configure como propietario del dispositivo. El consentimiento puede ser a través de la acción del usuario o por algún medio programático durante el aprovisionamiento, pero NO DEBE estar codificado ni impedir el uso de otras apps del propietario del dispositivo.

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

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

3.9.1.2 Aprovisionamiento de perfiles administrados

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

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

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

• [C-1-3] DEBEN proporcionar los siguientes indicadores visuales para el usuario en la configuración para indicarle cuando el controlador de políticas de dispositivo (DPC) inhabilitó una función del sistema en particular:

  • Un ícono coherente o algún otro indicador visual para el usuario (por ejemplo, el ícono de información de AOSP upstream) que represente cuando un administrador de dispositivos restringe un parámetro de configuración en particular.
  • Un mensaje de explicación breve, como el que proporciona el administrador de dispositivos a través de setShortSupportMessage.
  • El ícono de la aplicación del DPC

Compatibilidad con el perfil administrado 3.9.2

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

• [C-1-1] DEBEN 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 de AOSP upstream) para representar las aplicaciones y los widgets administrados, y otros elementos de la IU con insignias, como Recientes y Notificaciones.
• [C-1-4] DEBE mostrar un ícono de notificación (similar a la insignia de trabajo upstream de AOSP) para indicar cuándo el usuario está en una aplicación de perfil administrado.
• [C-1-5] DEBE mostrar una notificación breve que indique que el usuario está en el perfil administrado si el dispositivo se activa (ACTION_USER_PRESENT) y la aplicación en primer plano está dentro del perfil administrado.
• [C-1-6] Cuando existe un perfil administrado, DEBE mostrarse una indicación visual en el "Selector" de intents para permitir que el usuario reenvíe el intent del perfil administrado al usuario principal o viceversa, si el Controlador de políticas de dispositivos lo habilita.
• [C-1-7] Cuando existe un perfil administrado, DEBE exponer los siguientes indicadores visuales para el usuario principal y el perfil administrado:
  • Contabilización independiente de la batería, la ubicación, los datos móviles y el uso de almacenamiento para el usuario principal y el perfil administrado.
  • Administración independiente de las aplicaciones de VPN instaladas en el usuario principal o el perfil administrado
  • Administración independiente de las aplicaciones instaladas en el usuario principal o el perfil administrado
  • Administración independiente de las cuentas dentro del usuario principal o el perfil administrado
• [C-1-8] DEBEN garantizar que el selector, los contactos y las aplicaciones de mensajería preinstalados puedan buscar y consultar la información del emisor del perfil administrado (si existe) junto con la del perfil principal, si el controlador de políticas de dispositivos lo permite.
• [C-1-9] DEBE garantizar que cumpla con todos los requisitos de seguridad aplicables para un dispositivo con varios usuarios habilitados (consulta la sección 9.5), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.
• [C-1-10] DEBE admitir la capacidad 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.
  • Las implementaciones de dispositivos DEBEN respetar el intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD y mostrar una interfaz para configurar una credencial de pantalla de bloqueo independiente para el perfil administrado.
  • Las credenciales de la pantalla de bloqueo del perfil administrado DEBEN usar los mismos mecanismos de almacenamiento y administración de credenciales que el perfil superior, como se documenta en el sitio del proyecto de código abierto de Android.
  • Las políticas de contraseña del DPC DEBEN aplicarse solo a las credenciales de la pantalla de bloqueo del perfil administrado, a menos que se llame a la instancia DevicePolicyManager que muestra getParentProfileInstance.
• Cuando los contactos del perfil administrado se muestran en el registro de llamadas preinstalado, la IU durante la llamada, las notificaciones de llamadas en curso y perdidas, los contactos y las apps de mensajería, DEBEN tener la misma insignia que se usa para indicar las aplicaciones del perfil administrado.

3.9.3 Asistencia para usuarios administrados

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

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

3.10. Accesibilidad

Android proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar por sus dispositivos con mayor facilidad. Además, Android proporciona APIs de la plataforma que permiten que las implementaciones de servicios de accesibilidad reciban devoluciones de llamada para eventos del usuario y del sistema, y generen mecanismos de comentarios alternativos, como texto a voz, comentarios táctiles y navegación con trackball o mando de dirección.

Si las implementaciones de dispositivos admiten servicios de accesibilidad de terceros, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE proporcionar una implementación del framework de accesibilidad de Android, como se describe en la documentación del SDK de las APIs de accesibilidad.
• [C-1-2] DEBE generar eventos de accesibilidad y entregar el AccessibilityEvent adecuado a todas las implementaciones registradas de AccessibilityService, 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 y deshabilitar los servicios de accesibilidad de terceros junto con los servicios de accesibilidad preinstalados.
• [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 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Ten en cuenta que, para las implementaciones de dispositivos sin barra de navegación del sistema, este requisito no se aplica, pero las implementaciones de dispositivos DEBEN proporcionar una indicación visual para el usuario para controlar estos servicios de accesibilidad.

Si las implementaciones de dispositivos incluyen servicios de accesibilidad preinstalados, tienen las siguientes características:

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

3.11. Text-to-Speech

Android incluye APIs que permiten que las aplicaciones usen servicios de texto a voz (TTS) y que los proveedores de servicios proporcionen implementaciones de servicios de TTS.

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

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

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

• [C-2-1] DEBE proporcionar indicaciones visuales para que el usuario seleccione un motor de TTS para usarlo a nivel del sistema.

3.12. Framework de entrada de TV

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

Si las implementaciones de dispositivos admiten TIF, tienen las siguientes características:

• [C-1-1] DEBE declarar la función de plataforma android.software.live_tv.
• [C-1-2] DEBE admitir todas las APIs de TIF para que se pueda instalar y usar en el dispositivo una aplicación que use estas APIs y el servicio de entradas de terceros basadas en TIF.

3.13. Configuración rápida

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

Si las implementaciones de dispositivos incluyen un componente de IU de Configuración rápida, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE permitir que el usuario agregue o quite las tarjetas proporcionadas a través de las APIs de quicksettings desde una app de terceros.
• [C-1-2] NO DEBE agregar automáticamente una tarjeta de una app de terceros directamente a la Configuración rápida.
• [C-1-3] DEBE mostrar todas las tarjetas agregadas por el usuario de apps de terceros junto con las tarjetas de configuración rápida proporcionadas por el sistema.

3.14. IU de contenido multimedia

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

• [C-1-1] DEBEN mostrar los íconos de MediaItem y los íconos de notificaciones sin modificaciones.
• [C-1-2] DEBE mostrar los elementos que describe MediaSession, p.ej., metadatos, íconos e imágenes.
• [C-1-3] DEBE mostrar el título de la app.
• [C-1-4] DEBE tener un panel lateral o algún otro mecanismo para presentar la jerarquía de MediaBrowser y proporcionar indicaciones visuales para el usuario sobre la jerarquía de MediaBrowser.
• [C-1-5] DEBE considerar el doble toque de KEYCODE_HEADSETHOOK o KEYCODE_MEDIA_PLAY_PAUSE como KEYCODE_MEDIA_NEXT para MediaSession.Callback#onMediaButtonEvent.

3.15. Apps instantáneas

Las implementaciones de dispositivos DEBEN satisfacer los siguientes requisitos:

• [C-0-1] Solo se DEBEN otorgar permisos a las apps instantáneas que tengan el android:protectionLevel configurado como "instant".
• [C-0-2] Las apps instantáneas NO DEBEN interactuar con las apps instaladas a través de intents implícitos, a menos que se cumpla una de las siguientes condiciones:
  • El filtro de patrones de intents del componente está expuesto y tiene CATEGORY_BROWSABLE.
  • La acción es una de las siguientes: ACTION_SEND, ACTION_SENDTO o ACTION_SEND_MULTIPLE.
  • El objetivo se expone de forma explícita con android:visibleToInstantApps.
• [C-0-3] Las apps instantáneas NO DEBEN interactuar de forma explícita con las apps instaladas, a menos que el componente se exponga a través de android:visibleToInstantApps.
• [C-0-4] Las apps instaladas NO DEBEN ver detalles sobre las apps instantáneas en el dispositivo, a menos que la app instantánea se conecte de forma explícita a la aplicación instalada.

3.16. Sincronización de dispositivos complementarios

Android incluye compatibilidad con la vinculación de dispositivos complementarios para administrar de forma más eficaz la asociación con dispositivos complementarios y proporciona la API de CompanionDeviceManager para que las apps accedan a esta función.

Si las implementaciones de dispositivos admiten la función de vinculación de dispositivos complementarios, hacen lo siguiente:

• [C-1-1] DEBE declarar la marca de función FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] DEBES asegurarte de que las APIs del paquete android.companion estén implementadas por completo.
• [C-1-3] DEBEN proporcionar indicaciones visuales para que el usuario seleccione o confirme que hay un dispositivo complementario presente y en funcionamiento.

3.17. Apps pesadas

Si las implementaciones de dispositivos declaran la función FEATURE_CANT_SAVE_STATE, hacen lo siguiente:

• [C-1-1] DEBE tener solo una app instalada que especifique cantSaveState ejecutándose en el sistema a la vez. Si el usuario abandona una app de este tipo sin salir de ella de forma explícita (por ejemplo, presionando el botón de inicio mientras sale de una actividad activa del sistema, en lugar de presionar atrás cuando no quedan actividades activas en el sistema), las implementaciones de dispositivos DEBEN priorizar esa app en la RAM, como lo hacen con otros elementos que se espera que permanezcan en ejecución, como los servicios en primer plano. Mientras una app de este tipo está en segundo plano, el sistema puede aplicarle funciones de administración de energía, como limitar el acceso a la CPU y a la red.
• [C-1-2] DEBE proporcionar una indicación visual de la IU para elegir la app que no participará en el mecanismo normal de guardado y restablecimiento del estado una vez que el usuario inicie una segunda app declarada con el atributo cantSaveState.
• [C-1-3] NO DEBEN aplicarse otros cambios en la política a las apps que especifican cantSaveState, como cambiar el rendimiento de la CPU o cambiar la priorización de programación.

Si las implementaciones de dispositivos no declaran la función FEATURE_CANT_SAVE_STATE, sucede lo siguiente:

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

4. Compatibilidad de empaquetado de aplicaciones

Implementaciones de dispositivos:

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

Implementaciones de dispositivos:

• [C-0-2] DEBE admitir la verificación de archivos ".apk" con el esquema de firma de APK v3 , el esquema de firma de APK v2 y la firma de JAR.
• [C-0-3] NO DEBE extender los formatos .apk, manifiesto de Android, código de bytes de Dalvik ni código de bytes de RenderScript de manera tal que se impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.

• [C-0-4] NO DEBE permitir que apps que no sean el "instalador de registro" actual del paquete desinstalen la app de forma silenciosa sin ninguna confirmación del usuario, como se documenta en el SDK para el permiso DELETE_PACKAGE. Las únicas excepciones son la app del verificador de paquetes del sistema que controla el intent PACKAGE_NEEDS_VERIFICATION y la app del administrador de almacenamiento que controla el intent ACTION_MANAGE_STORAGE.

• [C-0-5] DEBE tener una actividad que controle el intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

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

• DEBE proporcionar una indicación visual para el usuario para otorgar o revocar el permiso de instalación de apps de fuentes desconocidas por aplicación, pero PUEDE optar por implementar esto como una operación sin efecto 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 esos casos, DEBEN indicarle al usuario por qué no se presenta esa opción.

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

• DEBE proporcionar una indicación visual para que el usuario elija desinstalar o iniciar una aplicación en el diálogo de advertencia.

5. Compatibilidad multimedia

Implementaciones de dispositivos:

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

Implementaciones de dispositivos:

• DEBEN apuntar a la latencia mínima del códec, en otras palabras, deben cumplir con lo siguiente:
  • NO DEBE consumir ni almacenar búferes de entrada ni devolver búferes de entrada solo una vez procesados.
  • NO DEBE retener los búferes decodificados por más tiempo de lo especificado en el estándar (p.ej., SPS).
  • NO DEBE retener los búferes codificados más tiempo del que requiere la estructura de GOP.

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

Ten en cuenta que ni Google ni la Open Handset Alliance hacen ninguna representación de que estos códecs no tengan patentes de terceros. Se advierte a quienes tengan la intención de usar este código fuente en productos de hardware o software que las implementaciones de este código, incluido en software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes relevantes.

5.1. Códecs multimedia

5.1.1. Codificación de audio

Consulta más detalles en 5.1.3. Audio Codecs Details.

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

• [C-1-1] PCM/WAVE

5.1.2. Decodificación de audio

Consulta más detalles en 5.1.3. Audio Codecs Details.

Si las implementaciones de dispositivos declaran compatibilidad con la función android.hardware.audio.output, deben admitir la decodificación de los siguientes formatos de audio:

• [C-1-1] Perfil AAC de MPEG-4 (AAC LC)
• [C-1-2] Perfil HE AAC de MPEG-4 (AAC+)
• [C-1-3] Perfil HE AACv2 de MPEG-4 (AAC+ mejorado)
• [C-1-4] AAC ELD (AAC mejorado de bajo retraso)
• [C-1-11] xHE-AAC (perfil HE AAC extendido ISO/IEC 23003-3, que incluye el perfil de Baseline de USAC y el perfil de control de rango dinámico ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

• [C-2-1] La decodificación DEBE realizarse sin una reducción de canales (p.ej., una transmisión AAC 5.0 se debe decodificar a cinco canales de PCM, una transmisión AAC 5.1 se debe decodificar a seis canales de PCM).
• [C-2-2] Los metadatos de rango dinámico DEBEN ser como se define en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3 y las claves de DRC android.media.MediaFormat para configurar los comportamientos relacionados con el rango dinámico del decodificador de audio. Las claves de DRC de AAC se introdujeron en la API 21 y son: 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.

Cuando se decodifica audio USAC, MPEG-D (ISO/IEC 23003-4):

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

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

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

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

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

5.1.3. Detalles de los códecs de audio

Formato/códec	Detalles	Formatos de tipos de archivo o contenedores compatibles
Perfil AAC de MPEG-4 (AAC LC)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 8 a 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC sin procesar de ADTS (.aac, no se admite ADIF) MPEG-TS (.ts, no admite búsquedas)
Perfil HE AAC de MPEG-4 (AAC+)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz.
Perfil HE AACv2 de MPEG-4 (AAC+ mejorado)	Compatibilidad con contenido mono/estéreo/5.0/5.1 con tasas de muestreo estándar de 16 a 48 kHz.
AAC ELD (AAC mejorado de bajo retraso)	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 a 48 kHz
USAC	Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 7.35 a 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	De 4.75 a 12.2 Kbps con muestreo a 8 kHz	3GPP (.3gp)
AMR-WB	9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz
FLAC	Mono/estéreo (sin multicanal). Tasas de muestreo de hasta 48 kHz (pero se RECOMIENDA hasta 44.1 kHz en dispositivos con salida de 44.1 kHz, ya que el reductor 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.	Tipo 0 y 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0 y versiones posteriores)
PCM/WAVE	PCM lineal de 16 bits (el límite de las tasas depende del hardware). Los dispositivos DEBEN admitir tasas de muestreo para la grabación de PCM sin procesar a frecuencias de 8,000, 11,025, 16,000 y 44,100 Hz.	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

5.1.4. Codificación de imágenes

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

Las implementaciones de dispositivos DEBEN admitir la codificación de las siguientes imágenes:

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

5.1.5. Decodificación de imágenes

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

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

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Sin procesar
• [C-0-7] HEIF (HEIC)

5.1.6. Detalles de los códecs de imagen

Formato/códec	Detalles	Formatos de tipos de archivo o contenedores compatibles
JPEG	Básica + progresiva	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Sin procesar		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Imagen, colección de imágenes o secuencia de imágenes	HEIF (.heif), HEIC (.heic)

5.1.7. Códecs de video

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

Si las implementaciones de dispositivos incluyen un decodificador o codificador de video, haz lo siguiente:

• [C-1-1] Los códecs de video DEBEN admitir tamaños de búfer de bytes de entrada y salida que admitan la trama comprimida y descomprimida más grande posible, según lo indiquen el estándar y la configuración, pero que tampoco asignen recursos en exceso.

• [C-1-2] Los codificadores y decodificadores de video DEBEN admitir 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, hacen lo siguiente:

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

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

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

5.1.8. Lista de códecs de video

Formato/códec	Detalles	Tipos de archivo y formatos de contenedor compatibles
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, solo audio AAC, no admite búsquedas, Android 3.0 y versiones posteriores)
H.265 HEVC	Consulta la sección 5.3 para obtener más detalles.	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.	WebM (.webm) Matroska (.mkv)
VP9	Consulta la sección 5.3 para obtener más detalles.	WebM (.webm) Matroska (.mkv)

5.2. Codificación de video

Si las implementaciones de dispositivos admiten cualquier codificador de video y lo ponen a disposición de apps de terceros, hacen lo siguiente:

• NO DEBE ser, en dos ventanas deslizantes, superior al ~15% de la tasa de bits entre intervalos intrafotogramas (fotogramas I).
• NO DEBE ser superior al 100% de la tasa de bits en un período deslizante de 1 segundo.

Si las implementaciones de dispositivos incluyen una pantalla incorporada con una longitud diagonal de al menos 6.35 cm (2.5") o incluyen un puerto de salida de video o declaran la compatibilidad con una cámara a través de la marca de función android.hardware.camera.any, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE incluir la compatibilidad con al menos uno de los codificadores de video VP8 o H.264 y ponerlo a disposición de las aplicaciones de terceros.
• DEBE admitir codificadores de video VP8 y H.264, y ponerlos a disposición de aplicaciones de terceros.

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

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

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

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

5.2.1. H.263

Si las implementaciones de dispositivos admiten codificadores H.263 y los ponen a disposición de apps de terceros, hacen lo siguiente:

• [C-1-1] DEBE admitir el nivel 45 del perfil de Baseline.
• 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, hacen lo siguiente:

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

Si las implementaciones de dispositivos informan la compatibilidad con la codificación H.264 para videos de resolución 720p o 1080p a través de las APIs de contenido multimedia, deben cumplir con los siguientes requisitos:

• [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 × 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	20 fps	30 fps	30 fps	30 fps
Tasa de bits del video	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

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

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

Si las implementaciones de dispositivos informan la compatibilidad con la codificación VP8 para videos de resolución 720p o 1080p a través de las APIs de contenido multimedia, deben cumplir con los siguientes requisitos:

• [C-2-1] DEBE admitir los perfiles de codificación de la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30 fps
Tasa de bits del video	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

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

• DEBE admitir la escritura de archivos Matroska WebM.

5.3. Decodificación de video

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

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

Si las implementaciones de dispositivos declaran compatibilidad con el decodificador Dolby Vision a través de HDR_TYPE_DOLBY_VISION , hacen 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] DEBE establecer el índice de pista de las capas básicas retrocompatibles (si las hay) de modo que sea igual al índice de pista de la capa combinada de Dolby Vision.

5.3.1. MPEG-2

Si las implementaciones de dispositivos admiten decodificadores MPEG-2, tienen las siguientes características:

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

5.3.2. H.263

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

• [C-1-1] DEBE admitir los perfiles de Baseline de nivel 30 y 45.

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

• [C-1-1] DEBE admitir el perfil principal nivel 3.1 y el perfil de Baseline. La compatibilidad con ASO (ordenación de segmentos arbitraria), FMO (ordenación de macrobloques flexible) y RS (slices redundantes) es OPCIONAL.
• [C-1-2] DEBE ser capaz de decodificar videos con los perfiles de SD (definición estándar) que se indican en la siguiente tabla y codificados con el perfil básico y el perfil principal nivel 3.1 (incluidos 720p30).
• DEBE ser capaz de decodificar videos con los perfiles HD (alta definición) como se indica en la siguiente tabla.

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

• [C-2-1] DEBE admitir los perfiles de decodificación de video HD 720p que se indican en la siguiente tabla.
• [C-2-2] DEBE admitir los perfiles de decodificación de video HD 1080p que se muestran en la siguiente tabla.

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 × 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	60 fps	30 fps (60 fps en televisión)
Tasa de bits del video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

• [C-1-1] DEBE admitir el nivel principal del perfil principal de nivel 3 y los perfiles de decodificación de video SD, como se indica en la siguiente tabla.
• DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla.
• [C-1-2] DEBE admitir los perfiles de decodificación HD como se indica en la siguiente tabla si hay un decodificador de hardware.

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

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

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p	UHD
Resolución de video	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 × 2160 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps	30/60 FPS (60 FPS en televisores con decodificación de hardware H.265)	60 fps
Tasa de bits del video	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3.6. VP8

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

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

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

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

	SD (baja calidad)	SD (alta calidad)	HD: 720p	HD: 1080p
Resolución de video	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Velocidad de fotogramas del video	30 fps	30 fps	30 fps (60 fps en televisión)	30 (60 fps en televisión)
Tasa de bits del video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

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

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

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

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

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

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

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

5.4. Grabación de audio

Si bien algunos de los requisitos que se describen en esta sección se indican como DEBER desde Android 4.3, se planea que la definición de compatibilidad de las versiones futuras los cambie a DEBE. Se RECOMIENDAN ALTAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos que se indican como DEBEN, de lo contrario, no podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.

5.4.1. Captura de audio sin procesar

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

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

  • Formato: PCM lineal, 16 bits
  • Tasas de muestreo: 8000, 11025, 16000, 44100 Hz
  • Canales: Mono

• [C-1-2] DEBE capturar a tasas de muestreo superiores sin aumento de la tasa de muestreo.

• [C-1-3] DEBE incluir un filtro antialiasing adecuado cuando las tasas de muestreo anteriores se capturan con reducción de muestras.

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

  • Formato: PCM lineal, 16 bits
  • Tasas de muestreo: 22,050 y 48,000 Hz
  • Canales: Estéreo

Si las implementaciones de dispositivos permiten la captura de contenido de audio sin procesar con calidad de radio AM y DVD, deben cumplir con los siguientes requisitos:

• [C-2-1] DEBE capturar sin aumento de la muestra en cualquier relación superior a 16000:22050 o 44100:48000.
• [C-2-2] DEBE incluir un filtro de antialiasing adecuado para cualquier aumento o disminución de la muestra.

5.4.2. Captura para el reconocimiento de voz

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

• [C-1-1] DEBE capturar la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION en una de las tasas de muestreo, 44100 y 48000.
• [C-1-2] DEBE inhabilitar, de forma predeterminada, cualquier procesamiento de audio de reducción de ruido cuando se graba una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
• [C-1-3] DEBE inhabilitar, de forma predeterminada, cualquier control de ganancia automático cuando se grabe una transmisión de audio desde la fuente de audio AudioSource.VOICE_RECOGNITION.
• DEBE grabar la transmisión de audio de reconocimiento de voz con características de amplitud aproximadamente planas en comparación con la frecuencia: específicamente, ±3 dB, de 100 Hz a 4,000 Hz.
• DEBE grabar la transmisión de audio de reconocimiento de voz con la sensibilidad de entrada establecida de modo que una fuente de nivel de potencia de sonido (SPL) de 90 dB a 1,000 Hz genere un RMS de 2,500 para muestras de 16 bits.
• DEBE grabar la transmisión de audio de reconocimiento de voz para que los niveles de amplitud de PCM sigan de forma lineal los cambios de SPL de entrada en un rango de al menos 30 dB, de -18 dB a +12 dB en relación con 90 dB SPL en el micrófono.
• DEBE grabar la transmisión de audio de reconocimiento de voz con una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.

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

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

5.4.3. Captura para el desvío de la reproducción

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

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

• [C-1-1] DEBE implementar correctamente la fuente de audio REMOTE_SUBMIX para que, cuando una aplicación use la API de android.media.AudioRecord para grabar desde esta fuente de audio, capture una combinación de 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 la compatibilidad para permitir que las apps reproduzcan audio a través del periférico de salida de audio, como se define en la sección 7.8.2.

5.5.1. Reproducción de audio sin procesar

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

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

  • Formato: PCM lineal, 16 bits, 8 bits, flotante
  • Canales: Mono, estéreo y configuraciones multicanal válidas con hasta 8 canales
  • Tasas de muestreo (en Hz):
    • 8000, 11025, 16000, 22050, 32000, 44100 y 48000 en las configuraciones de canal anteriores
    • 96,000 en mono y estéreo

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

  • Tasas de muestreo: 24000, 48000

5.5.2. Efectos de audio

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

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

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

5.5.3. Volumen de salida de audio

Implementaciones de dispositivos para la industria automotriz:

• DEBE permitir ajustar el volumen de audio por separado para cada transmisión de audio con el tipo de contenido o el uso que se define en AudioAttributes y el uso de audio para vehículos que se define públicamente en android.car.CarAudioManager.

5.6. Latencia de audio

La latencia de audio es la demora que se produce cuando una señal de audio pasa por un sistema. Muchas clases de aplicaciones dependen de latencias cortas para lograr efectos de sonido en tiempo real.

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

• latencia de salida. Es el intervalo entre el momento en que una aplicación escribe una trama de datos codificados en PCM y el momento en que el sonido correspondiente se presenta al entorno en un transductor integrado en el dispositivo o la señal sale del dispositivo a través de un puerto y se puede observar de forma externa.
• latencia de salida fría. Es la latencia de salida del primer fotograma, cuando el sistema de salida de audio estuvo inactivo y apagado antes de la solicitud.
• latencia de salida continua. Es la latencia de salida para los fotogramas posteriores, después de que el dispositivo reproduce audio.
• latencia de entrada. Es el intervalo entre el momento en que el entorno presenta un sonido al dispositivo en un transductor integrado o cuando la señal ingresa al dispositivo a través de un puerto y el momento en que una aplicación lee la trama correspondiente de datos codificados en PCM.
• entrada perdida. Es la parte inicial de un indicador de entrada que no se puede usar o no está disponible.
• latencia de entrada fría. Es la suma del tiempo de entrada perdido y la latencia de entrada para el primer fotograma, cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
• latencia de entrada continua. Es la latencia de entrada para los fotogramas posteriores, mientras el dispositivo captura audio.
• jitter de salida en frío. La variabilidad entre mediciones independientes de los valores de latencia de salida fría.
• jitter de entrada en frío. Es la variabilidad entre mediciones independientes de los valores de latencia de entrada fría.
• latencia de ida y vuelta continua. Es la suma de la latencia de entrada continua más la latencia de salida continua más un período de búfer. El período de búfer permite que la app procese la señal y mitigue la diferencia de fase entre las transmisiones de entrada y salida.
• API de cola de búfer PCM de OpenSL ES El conjunto de APIs de OpenSL ES relacionadas con PCM en el NDK de Android.
• API de audio nativo de AAudio. Es el conjunto de APIs de AAudio dentro del NDK de Android.
• Marca de tiempo. Es un par que consta de una posición de fotogramas relativa dentro de una transmisión y la hora estimada en la que ese fotograma entra o sale de la canalización de procesamiento de audio en el extremo asociado. Consulta también AudioTimestamp.

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

• [C-SR] Latencia de salida en frío de 100 milisegundos o menos
• [C-SR] Latencia de salida continua de 45 milisegundos o menos
• [C-SR] Minimiza el jitter de salida en frío
• [C-SR] La marca de tiempo de salida que muestran AudioTrack.getTimestamp y AAudioStream_getTimestamp es precisa dentro de un margen de +/- 1 ms.

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

• [C-SR] SE RECOMIENDA ENFATICAMENTE informar el audio de baja latencia declarando la marca de función android.hardware.audio.low_latency.
• [C-SR] SE RECOMIENDA ALTAMENTE cumplir con los requisitos de audio de baja latencia a través de la API de AAudio.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que, para las transmisiones que muestran AAUDIO_PERFORMANCE_MODE_LOW_LATENCY desde AAudioStream_getPerformanceMode(), el valor que muestra AAudioStream_getFramesPerBurst() sea menor o igual que el valor que muestra android.media.AudioManager.getProperty(String) para la clave de propiedad AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Si las implementaciones de dispositivos no cumplen con los requisitos de audio de baja latencia a través de la cola de búfer PCM de OpenSL ES y las APIs de audio nativo de AAudio, sucede 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 ENFATICAMENTE que cumplan con los siguientes requisitos de audio de entrada:

• [C-SR] Latencia de entrada en frío de 100 milisegundos o menos.
• [C-SR] Latencia de entrada continua de 30 milisegundos o menos.
• [C-SR] Latencia de ida y vuelta continua de 50 milisegundos o menos.
• [C-SR] Se minimizó el jitter de entrada en frío.
• [C-SR] Se limitó el error en las marcas de tiempo de entrada, como las muestra AudioRecord.getTimestamp o AAudioStream_getTimestamp, a +/- 1 ms.

5.7. Protocolos de red

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

Si las implementaciones de dispositivos incluyen un decodificador de audio o video, hacen lo siguiente:

• [C-1-1] DEBE admitir todos los códecs y formatos de contenedor obligatorios de la sección 5.1 a través de HTTP(S).

• [C-1-2] DEBE admitir los formatos de segmentos multimedia que se muestran en la tabla de formatos de segmentos multimedia que aparece a continuación a través del protocolo de borrador de transmisión HTTP en vivo, versión 7.

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

Formatos de segmentos de medios

Formatos de segmentos	Referencias	Compatibilidad con códecs obligatorios
Flujo de transporte MPEG-2	ISO 13818	Códecs de video: H264 AVC MPEG-4 SP MPEG-2 Consulta la sección 5.1.3 para obtener detalles sobre H264 AVC, MPEG2-4 SP y MPEG-2. Códecs de audio: AAC Consulta la sección 5.1.1 para obtener detalles sobre el AAC y sus variantes.
AAC con enmarcado ADTS y etiquetas ID3	ISO 13818-7	Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes.
WebVTT	WebVTT

RTSP (RTP, SDP)

Nombre del perfil	Referencias	Compatibilidad con códecs obligatorios
H264 AVC	RFC 6184	Consulta la sección 5.1.3 para obtener detalles sobre el AVC H264.
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 más información sobre AMR-NB.
AMR-WB	RFC 4867	Consulta la sección 5.1.1 para obtener detalles sobre AMR-WB.
MP4V-ES	RFC 6416	Consulta la sección 5.1.3 para obtener detalles sobre MPEG-4 SP.
mpeg4-generic	RFC 3640	Consulta la sección 5.1.1 para obtener detalles sobre AAC y sus variantes.
MP2T	RFC 2250	Consulta MPEG-2 Transport Stream en HTTP Live Streaming para obtener más información.

5.8. Secure Media

Si las implementaciones de dispositivos admiten una salida de video segura y son compatibles con superficies seguras, hacen lo siguiente:

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

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

• [C-2-1] DEBE proteger el vínculo con un mecanismo criptográficamente sólido, como HDCP 2.x o superior, para las pantallas conectadas a través de protocolos inalámbricos, como Miracast.

Si las implementaciones de dispositivos declaran compatibilidad con Display.FLAG_SECURE y con pantallas externas con cable, hacen lo siguiente:

• [C-3-1] DEBE admitir HDCP 1.2 o una versión posterior para todas las pantallas externas conectadas a través de un puerto con cable al que el usuario pueda acceder.

5.9. Interfaz digital de instrumentos musicales (MIDI)

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

• [C-1-1] DEBEN admitir MIDI a través de todos los transportes de hardware compatibles con MIDI para los que proporcionan conectividad genérica no MIDI, en los que dichos transportes son los siguientes:

  • Modo host USB, sección 7.7
  • Modo de periférico USB, sección 7.7
  • MIDI a través de Bluetooth LE que actúa en el rol central, sección 7.4.3

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

5.10. Audio profesional

Si las implementaciones de dispositivos informan compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager, hacen lo siguiente:

• [C-1-1] DEBE informar la compatibilidad con la función android.hardware.audio.low_latency.
• [C-1-2] DEBE tener la latencia de audio de ida y vuelta continua, como se define en la sección 5.6 Latencia de audio, DEBE ser de 20 milisegundos o menos y DEBE ser de 10 milisegundos o menos en, al menos, una ruta de acceso compatible.
• [C-1-3] DEBEN incluir puertos USB compatibles con 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] DEBEN cumplir con las latencias y los requisitos de audio USB con la cola de búfer PCM de OpenSL ES y las APIs de audio nativo de AAudio.
• [SR] SE RECOMIENDA ENFATICAMENTE proporcionar un nivel de rendimiento de la CPU constante mientras el audio está activo y la carga de la CPU varía. Esto se debe probar con el commit 1bd6391 de SimpleSynth. La app de SimpleSynth debe ejecutarse con los siguientes parámetros y lograr cero subdesbordamientos después de 10 minutos:
  • Ciclos de trabajo: 200,000
  • Carga variable: ACTIVADA (este parámetro cambiará entre el 100% y el 10% del valor de los ciclos de trabajo cada 2 segundos y está diseñado para probar el comportamiento del regulador de la CPU)
  • Carga estabilizada: DESACTIVADA
• DEBE minimizar la imprecisión y la deriva del reloj de audio en relación con la hora estándar.
• DEBE minimizar la deriva del reloj de audio en relación con el CLOCK_MONOTONIC de la CPU cuando ambos están activos.
• DEBE minimizar la latencia de audio en los transductores integrados en el dispositivo.
• DEBE minimizar la latencia de audio a través del audio digital USB.
• DEBE documentar las mediciones de latencia de audio en todas las rutas.
• DEBE minimizar el jitter en los tiempos de entrada de la devolución de llamada de finalización del búfer de audio, ya que esto afecta el porcentaje utilizable del ancho de banda completo de la CPU por parte de la devolución de llamada.
• DEBE proporcionar cero subrutinas de audio (salida) o superrutinas (entrada) en condiciones de uso normales con la latencia informada.
• DEBE proporcionar una diferencia de latencia entre canales de cero.
• DEBE minimizar la latencia promedio de MIDI en todos los transportes.
• DEBE minimizar la variabilidad de la latencia de MIDI bajo carga (jitter) en todos los transportes.
• DEBE proporcionar marcas de tiempo MIDI precisas en todos los transportes.
• DEBE minimizar el ruido de la señal de audio en los transductores integrados en el dispositivo, incluido el período inmediatamente después del inicio en frío.
• DEBE proporcionar una diferencia de reloj de audio cero entre los lados de entrada y salida de los extremos correspondientes, cuando ambos están activos. Algunos ejemplos de extremos correspondientes incluyen el micrófono y la bocina integrados en el dispositivo, o la entrada y salida del conector de audio.
• DEBE controlar las devoluciones de llamada de finalización del búfer de audio para los lados de entrada y salida de los extremos correspondientes en el mismo subproceso cuando ambos estén activos y entrar a la devolución de llamada de salida inmediatamente después de la devolución de la devolución de llamada de entrada. O bien, si no es posible controlar las devoluciones de llamada en el mismo subproceso, ingresa la devolución de llamada de salida poco después de ingresar la devolución de llamada de entrada para permitir que la aplicación tenga un tiempo coherente de los lados de entrada y salida.
• DEBE minimizar la diferencia de fase entre el almacenamiento en búfer de audio de HAL para los lados de entrada y salida de los extremos correspondientes.
• DEBE minimizar la latencia táctil.
• DEBE minimizar la variabilidad de la latencia táctil bajo carga (jitter).
• DEBE tener una latencia de entrada táctil a salida de audio de menos o igual que 40 ms.

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

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

Si las implementaciones de dispositivos incluyen un conector de audio de 3.5 mm de 4 conductores, deben cumplir con los siguientes requisitos:

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

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

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

Si las implementaciones de dispositivos incluyen un puerto HDMI, deben cumplir con los siguientes requisitos:

• [C-4-1] DEBE admitir la salida en estéreo y ocho canales con una profundidad de 20 bits o 24 bits y 192 kHz sin pérdida de profundidad de bits ni remuestreo, en al menos una configuración.

5.11. Captura para sin procesar

Android incluye compatibilidad con la grabación de audio sin procesar a través de la fuente de audio android.media.MediaRecorder.AudioSource.UNPROCESSED. En OpenSL ES, se puede acceder a él con el parámetro de configuración predeterminado de registro SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si las implementaciones de dispositivos intentan admitir fuentes de audio sin procesar y ponerlas a disposición de apps de terceros, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE informar la compatibilidad a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DEBEN presentar características de amplitud en relación con la frecuencia aproximadamente planas en el rango de frecuencia media: específicamente, ±10 dB de 100 Hz a 7,000 Hz para cada micrófono que se use para grabar la fuente de audio sin procesar.

• [C-1-3] DEBEN mostrar niveles de amplitud en el rango de baja frecuencia: específicamente, de ±20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencia media de cada micrófono que se usa para grabar la fuente de audio sin procesar.

• [C-1-4] DEBEN mostrar niveles de amplitud en el rango de alta frecuencia: específicamente, de ±30 dB de 7000 Hz a 22 KHz en comparación con el rango de frecuencia media de cada micrófono que se usa para grabar la fuente de audio sin procesar.

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

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

• [C-1-7] DEBE tener una distorsión armónica total (THD) inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en cada micrófono que se use para grabar la fuente de audio sin procesar.

• 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 de acceso, excepto un multiplicador de nivel para llevar el nivel al rango deseado. En otras palabras:

• [C-1-8] Si hay algún procesamiento de señal presente en la arquitectura por algún motivo, DEBE inhabilitarse y, de manera efectiva, no debe introducir ningún retraso ni latencia adicional en la ruta de la señal.
• [C-1-9] Si bien el multiplicador de nivel puede estar en la ruta, NO DEBE introducir demoras ni latencia en la ruta de señal.

Todas las mediciones de SPL se realizan directamente al lado del micrófono en prueba. En el caso de varias configuraciones de micrófonos, estos requisitos se aplican a cada micrófono.

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

• [C-2-1] DEBE mostrar null para el método de la API de AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) para indicar correctamente la falta de compatibilidad.
• [SR] aún se RECOMIENDA ALTAMENTE que satisfaga la mayor cantidad posible de requisitos de la ruta de la señal para la fuente de grabación sin procesar.

6. Compatibilidad de las herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Implementaciones de dispositivos:

• [C-0-1] DEBEN admitir las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android.

• Android Debug Bridge (adb)

  • [C-0-2] DEBE admitir adb como se documenta en el SDK de Android y los comandos de shell que se proporcionan en el AOSP, que pueden usar los desarrolladores de apps, incluidos dumpsys y cmd stats.
  • [C-0-3] NO DEBE alterar el formato ni el contenido de los eventos del sistema del dispositivo (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) registrados a través del comando dumpsys.
  • [C-0-10] DEBE registrar, sin omisión, y hacer que los siguientes eventos sean accesibles y estén disponibles para el comando de shell cmd stats y la clase de API del sistema StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] DEBE tener el daemon de adb del dispositivo inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar el puente de depuración de Android.
  • [C-0-5] DEBE admitir adb seguro. Android incluye compatibilidad con adb seguro. El adb seguro habilita adb en hosts autenticados conocidos.

  • [C-0-6] DEBE proporcionar un mecanismo que permita que adb se conecte desde una máquina host. Por ejemplo:

    • Las implementaciones de dispositivos sin un puerto USB compatible 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, lo que permite que los desarrolladores se conecten al dispositivo con el protocolo adb.

• Servicio de Dalvik Debug Monitor (ddms)

  • [C-0-7] DEBE admitir todas las funciones de ddms como se documenta en el SDK de Android. Como ddms usa adb, la compatibilidad con ddms DEBE estar inactiva de forma predeterminada, pero DEBE ser compatible cada vez que el usuario haya activado el puente de depuración de Android, como se indicó anteriormente.
• Monkey
  • [C-0-8] DEBE incluir el framework de Monkey y ponerlo a disposición de las aplicaciones para que lo usen.
• SysTrace
  • [C-0-9] DEBE admitir la herramienta systrace como se documenta en el SDK de Android. Systrace debe estar inactivo de forma predeterminada y DEBE haber un mecanismo al que el usuario pueda acceder para activarlo.

Si las implementaciones de dispositivos informan la compatibilidad con Vulkan 1.0 o versiones posteriores a través de las marcas de función android.hardware.vulkan.version, hacen lo siguiente:

• [C-1-1] DEBE proporcionar una indicación para que el desarrollador de la app habilite o inhabilite las capas de depuración de GPU.
• [C-1-2] Cuando las capas de depuración de la GPU están habilitadas, DEBEN enumerar las capas en las bibliotecas proporcionadas por herramientas externas (es decir, que no forman parte del paquete de la plataforma o la aplicación) que se encuentran en el directorio base de las aplicaciones depurables para admitir los métodos de la API vkEnumerateInstanceLayerProperties() y vkCreateInstance().

6.2. Opciones para desarrolladores

Android incluye compatibilidad para que los desarrolladores configuren parámetros relacionados con el desarrollo de aplicaciones.

Las implementaciones de dispositivos DEBEN proporcionar una experiencia coherente para las Opciones para desarrolladores. Para ello, deben cumplir con los siguientes requisitos:

• [C-0-1] DEBE respetar el intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar la configuración relacionada con el desarrollo de la aplicación. La implementación de Android upstream oculta el menú de Opciones para desarrolladores de forma predeterminada y permite que los usuarios inicien las Opciones para desarrolladores después de presionar siete (7) veces el elemento de menú Configuración > Acerca del dispositivo > Número de compilación.
• [C-0-2] DEBE ocultar las Opciones para desarrolladores de forma predeterminada.
• [C-0-3] DEBE proporcionar un mecanismo claro que no dé un tratamiento preferencial a una app de terceros en lugar de a otra para habilitar las Opciones para desarrolladores. DEBES proporcionar un documento o sitio web público y visible que describa cómo habilitar las Opciones para desarrolladores. Este documento o sitio web DEBE poder vincularse desde los documentos del SDK de Android.
• DEBE tener una notificación visual continua para el usuario cuando se habilitan las Opciones para desarrolladores y la seguridad del usuario es un problema.
• PUEDE limitar temporalmente el acceso al menú de opciones para desarrolladores ocultando o inhabilitando visualmente el menú para evitar distracciones en situaciones en las que la seguridad del usuario es un problema.

7. Compatibilidad de hardware

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

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

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

• [C-0-2] Aún DEBEN presentarse las definiciones de clases completas (como se documenta en el SDK) para las APIs de los componentes.
• [C-0-3] Los comportamientos de la API DEBEN implementarse como no-ops de alguna manera razonable.
• [C-0-4] Los métodos de la API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
• [C-0-5] Los métodos de la API DEBEN mostrar implementaciones sin operaciones de clases en las que la documentación del SDK no permita valores nulos.
• [C-0-6] Los métodos de la API NO DEBEN generar excepciones que no estén documentadas en la documentación del SDK.
• [C-0-7] Las implementaciones de dispositivos DEBEN informar de forma coherente información precisa de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella digital de compilación.

Un ejemplo típico de una situación en la que se aplican estos requisitos es la API de telefonía: incluso en dispositivos que no son teléfonos, estas APIs deben implementarse como no operaciones razonables.

7.1. Pantalla y gráficos

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

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

• tamaño diagonal físico. Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
• puntos por pulgada (dpi). Es la cantidad de píxeles que abarca un intervalo lineal horizontal o vertical de 1". Cuando se enumeran los valores de dpi, tanto los horizontales como los verticales deben estar dentro del rango.
• relación de aspecto. Es la proporción de los píxeles de la dimensión más larga a la dimensión más corta de la pantalla. Por ejemplo, una pantalla de 480 × 854 píxeles sería 854/480 = 1.779, o aproximadamente "16:9".
• píxeles independientes de la densidad (dp) La unidad de píxeles virtual se normaliza a una pantalla de 160 dpi y se calcula de la siguiente manera: píxeles = dp × (densidad/160).

7.1.1. Configuración de la pantalla

7.1.1.1. Tamaño y forma de la pantalla

El framework de la IU de Android admite una variedad de diferentes tamaños de diseño de pantalla lógicos y permite que las aplicaciones consulten el tamaño del diseño de pantalla de la configuración actual a través de Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK y Configuration.smallestScreenWidthDp.

Implementaciones de dispositivos:

• [C-0-1] DEBE informar el tamaño de diseño correcto para Configuration.screenLayout, como se define en la documentación del SDK de Android. Específicamente, las implementaciones de dispositivos DEBEN informar las dimensiones de pantalla correctas de píxeles independientes de la densidad (dp) lógicas, como se indica a continuación:

  • Los dispositivos con Configuration.uiMode establecido como cualquier valor que no sea UI_MODE_TYPE_WATCH y que informen un tamaño small para Configuration.screenLayout DEBEN tener al menos 426 dp x 320 dp.
  • Los dispositivos que informan un tamaño normal para Configuration.screenLayout DEBEN tener al menos 480 dp × 320 dp.
  • Los dispositivos que informan un tamaño large para Configuration.screenLayout DEBEN tener al menos 640 dp x 480 dp.
  • Los dispositivos que informan un tamaño xlarge para Configuration.screenLayout DEBEN tener al menos 960 dp × 720 dp.

• [C-0-2] DEBE respetar correctamente la compatibilidad declarada de las aplicaciones con los tamaños de pantalla a través del atributo <supports-screens> en AndroidManifest.xml, como se describe en la documentación del SDK de Android.

• PUEDE tener una pantalla con esquinas redondeadas.

Si las implementaciones de dispositivos admiten UI_MODE_TYPE_NORMAL y tienen una pantalla con esquinas redondeadas, hacen lo siguiente:

• [C-1-1] DEBE garantizar que el radio de las esquinas redondeadas sea inferior o igual a 38 dp.
• DEBE incluir indicaciones visuales para el usuario para cambiar al modo de pantalla con las esquinas rectangulares.

7.1.1.2. Relación de aspecto de la pantalla

Si bien no hay restricciones para el valor de la relación de aspecto de la pantalla física, la relación de aspecto de la pantalla lógica en la que se renderizan las apps de terceros, como se puede deducir 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 de dispositivos con Configuration.uiMode establecido como UI_MODE_TYPE_NORMAL DEBEN tener un valor de relación de aspecto entre 1.3333 (4:3) y 1.86 (aproximadamente 16:9), a menos que se considere que la app está lista para estirarse más si cumple con una de las siguientes condiciones:

  • La app declaró que admite una relación de aspecto de pantalla más grande a través del valor de metadatos android.max_aspect.
  • La app declara que se puede cambiar de tamaño a través del atributo android:resizeableActivity.
  • La app se orienta al nivel de API 24 o uno superior y no declara un android:MaxAspectRatio que restrinja la relación de aspecto permitida.

• [C-0-2] Las implementaciones de dispositivos con Configuration.uiMode establecido 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 segmentar los recursos de la aplicación.

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

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

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

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

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

7.1.2. Métricas de Display

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:

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

Si las implementaciones de dispositivos no incluyen una pantalla incorporada o una salida de video, tienen las siguientes características:

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

7.1.3. Orientación de pantalla

Implementaciones de dispositivos:

• [C-0-1] DEBEN informar qué orientaciones de pantalla admiten (android.hardware.screen.portrait o android.hardware.screen.landscape) y DEBEN informar al menos una orientación compatible. Por ejemplo, un dispositivo con una pantalla horizontal de orientación fija, como una televisión o una laptop, SOLO DEBE informar android.hardware.screen.landscape.
• [C-0-2] DEBE informar el valor correcto de la orientación actual del dispositivo cada vez que se consulte a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() o de otras APIs.

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

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

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

OpenGL ES 7.1.4.1

Implementaciones de dispositivos:

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

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:

• [C-1-1] DEBE admitir OpenGL ES 1.1 y 2.0, como se indica y detalla en la documentación del SDK de Android.
• [SR] SE RECOMIENDA ENFATICAMENTE que admitan OpenGL ES 3.1.
• DEBE ser compatible con OpenGL ES 3.2.

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

• [C-2-1] DEBEN informar a través de las APIs administradas y nativas de OpenGL ES cualquier otra extensión de OpenGL ES que hayan implementado y, a la inversa, NO DEBEN informar cadenas de extensión que no admitan.
• [C-2-2] DEBE admitir las extensiones EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage y EGL_ANDROID_recordable.
• [SR] SE RECOMIENDA ENFATICAMENTE que admitan EGL_KHR_partial_update.
• DEBE informar con precisión a través del método getString() cualquier formato de compresión de texturas que admita, que suele ser específico del proveedor.

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

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

Si las implementaciones de dispositivos admiten OpenGL ES 3.2, hacen lo siguiente:

• [C-4-1] DEBE admitir el Android Extension Pack para OpenGL ES en su totalidad.

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

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

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

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

Vulkan 7.1.4.2

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

Si las implementaciones de dispositivos admiten OpenGL ES 3.1, hacen lo siguiente:

• [SR] SE RECOMIENDA ENFATICAMENTE que incluyas compatibilidad con Vulkan 1.1.

Si las implementaciones de dispositivos incluyen una pantalla o una salida de video, tienen las siguientes características:

• DEBE incluir compatibilidad con Vulkan 1.1.

Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.0, hacen lo siguiente:

• [C-1-1] DEBE informar el valor entero correcto con las marcas de función android.hardware.vulkan.level y android.hardware.vulkan.version.
• [C-1-2] DEBE enumerar, al menos, un VkPhysicalDevice para la API nativa de Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] DEBE implementar completamente las APIs de Vulkan 1.0 para cada VkPhysicalDevice enumerado.
• [C-1-4] DEBEN enumerar las capas contenidas en bibliotecas nativas nombradas como libVkLayer*.so en el directorio de bibliotecas nativas del paquete de la aplicación a través de las APIs nativas de Vulkan vkEnumerateInstanceLayerProperties() y vkEnumerateDeviceLayerProperties() .
• [C-1-5] NO DEBE enumerar capas proporcionadas por bibliotecas fuera del paquete de la aplicación ni proporcionar otras formas de rastrear o interceptar la API de Vulkan, a menos que la aplicación tenga el atributo android:debuggable establecido como true.
• [C-1-6] DEBEN informar todas las cadenas de extensión que admiten a través de las APIs nativas de Vulkan y, a la inversa, NO DEBEN informar cadenas de extensión que no admiten correctamente.
• [C-1-7] DEBE admitir las extensiones VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain y VK_KHR_incremental_present.

Si las implementaciones de dispositivos no incluyen compatibilidad con Vulkan 1.0, sucede lo siguiente:

• [C-2-1] NO DEBES 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().

Si las implementaciones de dispositivos incluyen compatibilidad con Vulkan 1.1, hacen lo siguiente:

• [C-3-1] DEBE exponer compatibilidad con los tipos de semáforo y control externos SYNC_FD.
• [SR] SE RECOMIENDA URGENTEMENTE que admitas la extensión VK_ANDROID_external_memory_android_hardware_buffer.

RenderScript 7.1.4.3

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

7.1.4.4 Aceleración de gráficos 2D

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

Implementaciones de dispositivos:

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

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

Implementaciones de dispositivos:

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

7.1.4.5 Pantallas de amplia gama de colores

Si las implementaciones de dispositivos reclaman compatibilidad con pantallas de amplia gama a través de Configuration.isScreenWideColorGamut() , hacen lo siguiente:

• [C-1-1] DEBE tener una pantalla calibrada en color.
• [C-1-2] DEBE tener una pantalla cuya gama cubra la gama de colores sRGB por completo en el espacio xyY de CIE 1931.
• [C-1-3] DEBE tener una pantalla cuya gama tenga un área de al menos el 90% de DCI-P3 en el espacio xyY de CIE 1931.
• [C-1-4] DEBE admitir OpenGL ES 3.1 o 3.2 y notificarlo correctamente.
• [C-1-5] DEBEN anunciar la compatibilidad con las extensiones EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 y EGL_KHR_gl_colorspace_display_p3.
• [SR] Se RECOMIENDA ENFATICAMENTE admitir GL_EXT_sRGB.

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

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

7.1.5. Modo de compatibilidad de aplicaciones heredadas

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

7.1.6. Tecnología de la pantalla

La plataforma de Android incluye APIs que permiten que las aplicaciones rendericen gráficos enriquecidos en 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 de dispositivos:

• [C-0-1] DEBE admitir pantallas capaces de renderizar gráficos en color de 16 bits.
• DEBE admitir pantallas capaces de mostrar gráficos en color de 24 bits.
• [C-0-2] DEBE admitir pantallas capaces de renderizar animaciones.
• [C-0-3] DEBEN 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 píxeles DEBE ser casi cuadrada (1.0) con una tolerancia de entre el 10 y el 15%.

7.1.7. Pantallas secundarias

Android incluye compatibilidad con pantallas secundarias para habilitar las funciones de uso compartido de contenido multimedia y las APIs para desarrolladores para acceder a pantallas externas.

Si las implementaciones de dispositivos admiten una pantalla externa a través de una conexión de pantalla adicional con cable, inalámbrica o integrada, cumplen con los siguientes requisitos:

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

7.2. Dispositivos de entrada

Implementaciones de dispositivos:

• [C-0-1] DEBE incluir un mecanismo de entrada, como una pantalla táctil o una navegación no táctil, para navegar entre los elementos de la IU.

7.2.1. Teclado

Si las implementaciones de dispositivos incluyen compatibilidad con aplicaciones de editores de métodos de entrada (IME) de terceros, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE declarar la marca de función android.software.input_methods.
• [C-1-2] DEBEN implementar completamente Input Management Framework
• [C-1-3] DEBE tener un teclado de software preinstalado.

Implementaciones de dispositivos: * [C-0-1] NO DEBEN incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.keyboard (QWERTY o 12 teclas). * DEBE incluir implementaciones adicionales del teclado en pantalla. * PUEDE incluir un teclado de hardware.

7.2.2. Navegación no táctil

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

Implementaciones de dispositivos:

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

Si las implementaciones de dispositivos carecen de navegaciones sin tacto, sucede lo siguiente:

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

7.2.3. Teclas de navegación

Las funciones Inicio, Recientes y Atrás, que suelen proporcionarse a través de una interacción con un botón físico exclusivo o una parte distinta de la pantalla táctil, son esenciales para el paradigma de navegación de Android y, por lo tanto, para las implementaciones de dispositivos:

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

Si se proporcionan las funciones Inicio, Recientes o Atrás, estas tienen las siguientes características:

• [C-1-1] DEBE ser accesible con una sola acción (p.ej., presionar, hacer doble clic o hacer un gesto) cuando se pueda acceder a cualquiera de ellas.
• [C-1-2] DEBE proporcionar una indicación clara de qué acción única activaría cada función. Algunos ejemplos de este tipo de indicaciones son tener un ícono visible impreso en el botón, mostrar un ícono de software en la parte de la barra de navegación de la pantalla o guiar al usuario a través de un flujo de demostración paso a paso durante la experiencia de configuración lista para usar.

Implementaciones de dispositivos:

• [SR] SE RECOMIENDA NO proporcionar el mecanismo de entrada para la función de menú, ya que dejó de estar disponible a favor de la barra de acciones desde Android 4.0.

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

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

Si las implementaciones de dispositivos no proporcionan la función de menú, para la retrocompatibilidad, deben hacer lo siguiente: * [C-3-1] DEBEN hacer que la función de menú esté disponible para las aplicaciones cuando targetSdkVersion sea inferior a 10, ya sea con 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, deben cumplir con los siguientes requisitos: * [C-4-1] DEBEN permitir el acceso a la función Assist con una sola acción (p.ej., presionar, hacer doble clic o hacer un gesto) cuando se puede acceder a otras teclas de navegación. * [SR] SE RECOMIENDA ENFATICAMENTE usar la función de mantener presionado la pantalla principal como interacción designada.

Si las implementaciones de dispositivos usan una parte distinta de la pantalla para mostrar las teclas de navegación, hacen lo siguiente:

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

7.2.4. Entrada táctil

Android incluye compatibilidad con una variedad de sistemas de entrada de punteros, como pantallas táctiles, paneles táctiles y dispositivos de entrada táctil falsos. Las implementaciones de dispositivos basadas en pantallas táctiles están asociadas con una pantalla de modo que el usuario tenga la impresión de manipular directamente los elementos en pantalla. Dado que el usuario toca directamente la pantalla, el sistema no requiere ningún indicador adicional para indicar los objetos que se manipulan.

Implementaciones de dispositivos:

• DEBE tener algún tipo de sistema de entrada de puntero (como un mouse o una pantalla táctil).
• DEBE admitir punteros con seguimiento completamente independiente.

Si las implementaciones de dispositivos incluyen una pantalla táctil (de un solo toque o mejor), deben cumplir con los siguientes requisitos:

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

Si las implementaciones de dispositivos incluyen una pantalla táctil que puede hacer un seguimiento de más de un toque, deben cumplir con los siguientes requisitos:

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

Si las implementaciones de dispositivos no incluyen una pantalla táctil (y solo dependen de un dispositivo de puntero) y cumplen con los requisitos de toques falsos de la sección 7.2.5, deben cumplir con los siguientes requisitos:

• [C-3-1] NO DEBE informar ninguna marca de función que comience con android.hardware.touchscreen y DEBE informar solo 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 controla un cursor en pantalla se aproxima al toque, pero requiere que el usuario primero apunte o enfoque y, luego, haga clic. Muchos dispositivos de entrada, como el mouse, el panel táctil, el mouse aéreo basado en giroscopio, el puntero giroscópico, el joystick y el panel táctil multitáctil, pueden admitir interacciones táctiles falsas. Android incluye la constante de función android.hardware.faketouch, que corresponde a un dispositivo de entrada no táctil (basado en punteros) de alta fidelidad, como un mouse o un panel táctil que puede emular de forma adecuada la entrada táctil (incluida la compatibilidad con gestos básicos) y que indica que el dispositivo admite un subconjunto emulado de la funcionalidad de la pantalla táctil.

Si las implementaciones de dispositivos no incluyen una pantalla táctil, pero incluyen otro sistema de entrada de puntero que desean poner a disposición, deben cumplir con los siguientes requisitos:

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

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

• [C-1-1] DEBE informar las posiciones absolutas de la pantalla X e Y de la ubicación del puntero y mostrar un puntero visual en la pantalla.
• [C-1-2] DEBE informar el evento táctil con el código de acción que especifica el cambio de estado que se produce en el puntero cuando se mueve hacia abajo o hacia arriba en la pantalla.
• [C-1-3] DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios emular el toque en un objeto en la pantalla.
• [C-1-4] DEBE admitir el puntero hacia abajo, el puntero hacia arriba, el puntero hacia abajo y, luego, el puntero hacia arriba en el mismo lugar de un objeto en la pantalla dentro de un umbral de tiempo, lo que permite a los usuarios emular el doble toque en un objeto en la pantalla.
• [C-1-5] DEBE admitir el puntero hacia abajo en un punto arbitrario de la pantalla, el movimiento del puntero a cualquier otro punto arbitrario de la pantalla, seguido de un puntero hacia arriba, lo que permite a los usuarios emular un arrastre táctil.
• [C-1-6] DEBE admitir el puntero hacia abajo y, luego, permitir que los usuarios muevan rápidamente el objeto a una posición diferente en la pantalla y, luego, el puntero hacia arriba en la pantalla, lo que permite que los usuarios lancen un objeto en la pantalla.
• [C-1-7] DEBE informar TOUCHSCREEN_NOTOUCH para el campo de la API de Configuration.touchscreen.

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

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

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

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

7.2.6. Compatibilidad con controles de juegos

7.2.6.1. Asignaciones de botones

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

• [C-1-1] DEBE tener un controlador incorporado o enviarse con un controlador independiente en la caja, que proporcione los medios para ingresar todos los eventos que se indican en las tablas que aparecen a continuación.
• [C-1-2] DEBE ser capaz de asignar eventos HID a sus constantes view.InputEvent asociadas de Android, como se indica en las tablas que se indican a continuación. La implementación de Android upstream incluye la implementación de controles de juegos que satisfacen este requisito.

Botón	Uso de HID2	Botón de Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pad direccional hacia arriba1 Pad direccional hacia abajo1	0x01 0x00393	AXIS_HAT_Y4
Pad direccional izquierdo1 Pad direccional derecho1	0x01 0x00393	AXIS_HAT_X4
Botón del hombro izquierdo1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Botón de hombro derecho1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Hacer clic en el joystick izquierdo1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Presiona el joystick derecho1.	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Página principal1	0x0c 0x0223	KEYCODE_HOME (3)
Atrás1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Los usos de HID anteriores deben declararse dentro de una AC de Game pad (0x01 0x0005).

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

4 MotionEvent

Controles analógicos1	Uso de HID	Botón de Android
Gatillo izquierdo	0x02 0x00C5	AXIS_LTRIGGER
Activador derecho	0x02 0x00C4	AXIS_RTRIGGER
Joystick izquierdo	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick derecho	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

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 en particular que tiene una API correspondiente para desarrolladores externos, la implementación del dispositivo DEBE implementar esa API como se describe en la documentación del SDK de Android y la documentación de código abierto de Android sobre sensores.

Implementaciones de dispositivos:

• [C-0-1] DEBE informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager.
• [C-0-2] DEBE mostrar una lista precisa de los sensores compatibles a través de SensorManager.getSensorList() y métodos similares.
• [C-0-3] DEBEN comportarse de manera razonable para todas las demás APIs de sensores (por ejemplo, devolviendo true o false según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamando a objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etcétera).

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

• [C-1-1] DEBE informar todas las mediciones del sensor con los valores relevantes del Sistema Internacional de Unidades (métrica) para cada tipo de sensor, como se define en la documentación del SDK de Android.
• [C-1-2] DEBE informar los datos del sensor con una latencia máxima de 100 milisegundos + 2 × sample_time en el caso de un sensor transmitido 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 de filtrado.
• [C-1-3] DEBE informar la primera muestra del sensor en un plazo de 400 milisegundos + 2 × sample_time desde que se activa el sensor. Se acepta que esta muestra tenga una precisión de 0.

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

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

• [C-1-5] DEBE garantizar que la transmisión de eventos del sensor NO impida que la CPU del dispositivo entre en un estado de suspensión o se active desde un estado de suspensión.

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

La lista anterior no es exhaustiva. El comportamiento documentado del SDK de Android y la documentación de código abierto de Android sobre los sensores se debe considerar como fuente de autoridad.

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

Implementaciones de dispositivos:

• DEBEN implementar estos tipos de sensores, cuando incluyen los sensores físicos previos que se describen en tipos de sensores.

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

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

7.3.1. Acelerómetro

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

Si las implementaciones de dispositivos incluyen un acelerómetro de 3 ejes, tienen las siguientes características:

• [C-1-1] DEBE poder informar eventos hasta una frecuencia de, al menos, 50 Hz.
• [C-1-2] DEBE implementar y generar informes sobre el sensor TYPE_ACCELEROMETER.
• [C-1-3] DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android.
• [C-1-4] DEBE ser capaz de medir desde la caída libre hasta cuatro veces la gravedad(4 g) o más en cualquier eje.
• [C-1-5] DEBEN tener una resolución de al menos 12 bits.
• [C-1-6] DEBE tener una desviación estándar no superior a 0.05 m/s², donde la desviación estándar se debe calcular por eje en muestras recopiladas durante un período de al menos 3 segundos a la tasa de muestreo más rápida.
• [SR] se RECOMIENDAN ENFÉMTICAMENTE para implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION.
• [SR] SE RECOMIENDA ENFATICAMENTE implementar el sensor TYPE_ACCELEROMETER_UNCALIBRATED si la calibración del acelerómetro en línea está disponible.
• DEBE implementar los sensores compuestos TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR y TYPE_STEP_COUNTER como se describe en el documento del SDK de Android.
• DEBE informar eventos de hasta 200 Hz como mínimo.
• DEBE tener una resolución de al menos 16 bits.
• DEBEN calibrarse durante el uso si las características cambian durante el ciclo de vida y se compensan, y deben conservar los parámetros de compensación entre los reinicios del dispositivo.
• DEBE tener compensación de temperatura.
• TAMBIÉN DEBE implementar el sensor TYPE_ACCELEROMETER_UNCALIBRATED.

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

• [C-2-1] La suma de su consumo de energía SIEMPRE DEBE ser inferior a 4 mW.
• DEBEN ser inferiores a 2 mW y 0.5 mW cuando el dispositivo está en condiciones dinámicas o estáticas.

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

• [C-3-1] DEBE implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
• DEBE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR.
• [SR] Se RECOMIENDA ENFÉCTIVAMENTE que los dispositivos Android existentes y nuevos implementen 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, hacen lo siguiente:

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

7.3.2. Magnetómetro

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

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes, tienen las siguientes características:

• [C-1-1] DEBE implementar el sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] DEBE poder informar eventos hasta una frecuencia de al menos 10 Hz y DEBE informar eventos hasta al menos 50 Hz.
• [C-1-3] DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android.
• [C-1-4] DEBE ser capaz de medir entre -900 µT y +900 µT en cada eje antes de saturarse.
• [C-1-5] DEBE tener un valor de compensación de hierro duro inferior a 700 µT y DEBE tener un valor inferior a 200 µT, si se coloca el magnetómetro lejos de campos magnéticos dinámicos (inducidos por la corriente) y estáticos (inducidos por el imán).
• [C-1-6] DEBE tener una resolución igual o más densa que 0.6 µT.
• [C-1-7] DEBE admitir la calibración y compensación en línea del sesgo de hierro duro y preservar los parámetros de compensación entre los reinicios del dispositivo.
• [C-1-8] DEBE tener aplicada la compensación de hierro dulce. La calibración se puede realizar durante el uso o la producción del dispositivo.
• [C-1-9] DEBE tener una desviación estándar, calculada por eje en muestras recopiladas durante un período de al menos 3 segundos a la tasa de muestreo más rápida, no superior a 1.5 µT. DEBE tener una desviación estándar no superior a 0.5 µT.
• DEBE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Se RECOMIENDA ENFÉCTIVAMENTE que los dispositivos Android existentes y nuevos implementen el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

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

Si las implementaciones de dispositivos incluyen un magnetómetro de 3 ejes y un acelerómetro, hacen lo siguiente:

• PUEDE implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementaciones de dispositivos:

• DEBE incluir un receptor GPS/GNSS.

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

• [C-1-1] DEBE admitir salidas de ubicación a una velocidad de al menos 1 Hz cuando se solicite a través de LocationManager#requestLocationUpdate.
• [C-1-2] DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, multitrayecto insignificante, HDOP inferior o igual a 2) en un plazo de 10 segundos (tiempo de primera corrección rápido) cuando esté conectado a una conexión a Internet de 0.5 Mbps o una velocidad de datos más rápida. Por lo general, este requisito se cumple mediante el uso de alguna forma de técnica de GPS/GNSS asistida o prevista para minimizar el tiempo de bloqueo del GPS/GNSS (los datos de asistencia incluyen la hora de referencia, la ubicación de referencia y la efeméride o el reloj satelital).
  • [C-1-6] Después de realizar ese cálculo de ubicación, las implementaciones de dispositivos DEBEN determinar su ubicación, en cielo abierto, en un plazo de 5 segundos, cuando se reinicien las solicitudes de ubicación, hasta una hora después del cálculo de ubicación inicial, incluso cuando la solicitud posterior se realice sin una conexión de datos o después de un ciclo de encendido.

• En condiciones de cielo abierto después de determinar la ubicación, mientras esté detenido o se mueva con menos de 1 metro por segundo cuadrado de aceleración:

  • [C-1-3] DEBEN poder determinar la ubicación dentro de un radio de 20 metros y la velocidad dentro de un radio de 0.5 metros por segundo, al menos el 95% del tiempo.
  • [C-1-4] DEBE hacer un seguimiento simultáneo y generar informes a través de GnssStatus.Callback de al menos 8 satélites de una constelación.
  • DEBE poder hacer un seguimiento simultáneo de al menos 24 satélites, de varias constelaciones (p.ej., GPS + al menos uno de Glonass, Beidou o Galileo).
  • [C-1-5] DEBE informar la generación de la tecnología GNSS a través de la API de prueba "getGnssYearOfHardware".
  • [SR] Se siguen mostrando resultados normales de la ubicación del GPS/GNSS durante una llamada telefónica de emergencia.
  • [SR] Informa las mediciones del GNSS de todas las constelaciones a las que se les hizo un seguimiento (como se informa en los mensajes de GnssStatus), excepto por SBAS.
  • [SR] Informe de AGC y frecuencia de medición del GNSS.
  • [SR] Informa todas las estimaciones de precisión (incluidos el rumbo, la velocidad y la vertical) como parte de cada ubicación GPS/GNSS.
  • [SR] SE RECOMIENDA ENFATICAMENTE que cumplan con la mayor cantidad posible de los requisitos obligatorios adicionales para los dispositivos que informan el año "2016" o "2017" a través de la API de Test LocationManager.getGnssYearOfHardware().

Si las implementaciones de dispositivos incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, y la API de prueba LocationManager.getGnssYearOfHardware() informa el año "2016" o una versión posterior, sucede lo siguiente:

• [C-2-1] DEBEN informar las mediciones de GNSS en cuanto se encuentren, incluso si aún no se informa una ubicación calculada a partir del GPS/GNSS.
• [C-2-2] DEBEN informar las pseudorangos y las tasas de pseudorangos del GNSS que, en condiciones de cielo abierto después de determinar la ubicación, mientras están detenidos o se mueven con menos de 0.2 metros por segundo cuadrado de aceleración, son suficientes para calcular la posición dentro de 20 metros y la velocidad dentro de 0.2 metros por segundo, al menos el 95% del tiempo.

Si las implementaciones de dispositivos incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, y la API de prueba LocationManager.getGnssYearOfHardware() informa el año "2017" o una versión posterior, sucede lo siguiente:

• [C-3-1] DEBE seguir proporcionando resultados normales de ubicación GPS/GNSS durante una llamada telefónica de emergencia.
• [C-3-2] DEBEN informar las mediciones del GNSS de todas las constelaciones a las que se les hace un seguimiento (como se informa en los mensajes de GnssStatus), excepto por el SBAS.
• [C-3-3] DEBEN informar la AGC y la frecuencia de la medición del GNSS.
• [C-3-4] DEBEN informar todas las estimaciones de precisión (incluidos el rumbo, la velocidad y la vertical) como parte de cada ubicación GPS/GNSS.

Si las implementaciones de dispositivos incluyen un receptor de GPS/GNSS y reportan la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, y la API de prueba LocationManager.getGnssYearOfHardware() informa el año "2018" o una versión posterior, hacen lo siguiente:

• [C-4-1] DEBE seguir proporcionando salidas normales de GPS/GNSS a las aplicaciones durante una llamada de sesión de emergencia iniciada por la red basada en una estación móvil (MS).
• [C-4-2] DEBEN informar las posiciones y las mediciones a las APIs de GNSS Location Provider.

7.3.4. Giroscopio

Implementaciones de dispositivos:

• DEBE incluir un giroscopio (sensor de cambio angular).
• NO 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, tienen las siguientes características:

• [C-1-1] DEBE poder informar eventos hasta una frecuencia de, al menos, 50 Hz.
• [C-1-2] DEBE implementar el sensor TYPE_GYROSCOPE y también DEBE implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] DEBEN ser capaces de medir 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 DEBE tener una resolución de 16 bits o más.
• [C-1-5] DEBEN tener compensación de temperatura.
• [C-1-6] DEBEN calibrarse y compensarse durante el uso, y preservar los parámetros de compensación entre los reinicios del dispositivo.
• [C-1-7] DEBE tener una variación no superior a 1e-7 rad^2 / s^2 por Hz (variación por Hz o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero DEBE estar restringida por este valor. En otras palabras, si mides la variación del giroscopio a una tasa de muestreo de 1 Hz, NO DEBE ser superior a 1e-7 rad^2/s^2.
• [SR] Se RECOMIENDA ENFÉCTIVAMENTE que los dispositivos Android existentes y nuevos implementen el sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• [SR] SE RECOMIENDA ENFATICAMENTE que el error de calibración sea inferior a 0.01 rad/s cuando el dispositivo esté inmóvil a temperatura ambiente.
• DEBE 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, hacen lo siguiente:

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

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

• [C-3-1] DEBE implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION.
• [SR] Se RECOMIENDA ENFÉCTIVAMENTE que los dispositivos Android existentes y nuevos implementen el sensor TYPE_GAME_ROTATION_VECTOR.
• DEBE implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barómetro

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

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

• [C-1-1] DEBE implementar y generar informes sobre el sensor TYPE_PRESSURE.
• [C-1-2] DEBE poder entregar eventos a 5 Hz o más.
• [C-1-3] DEBEN tener compensación de temperatura.
• [SR] SE RECOMIENDA ENFATICAMENTE que se puedan informar mediciones de presión en el rango de 300 hPa a 1100 hPa.
• DEBE tener una precisión absoluta de 1 hPa.
• DEBE tener una precisión relativa de 0.12 hPa en un rango de 20 hPa (equivalente a una precisión de aproximadamente 1 m en un cambio de aproximadamente 200 m sobre el nivel del mar).

7.3.6. Termómetro

Implementaciones de dispositivos: * PUEDEN incluir un termómetro ambiente (sensor de temperatura). * PUEDE, PERO NO DEBE, incluir un sensor de temperatura de la CPU.

Si las implementaciones de dispositivos incluyen un termómetro ambiente (sensor de temperatura), tienen las siguientes características:

• [C-1-1] DEBE definirse como SENSOR_TYPE_AMBIENT_TEMPERATURE y DEBE medir la temperatura ambiente (habitación o cabina del vehículo) desde la que el usuario interactúa con el dispositivo en grados Celsius.
• [C-1-2] DEBE definirse como SENSOR_TYPE_TEMPERATURE.
• [C-1-3] DEBE medir la temperatura de la CPU del dispositivo.
• [C-1-4] NO DEBE 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 de dispositivos PUEDEN incluir un fotómetro (sensor de luz ambiente).

7.3.8. Sensor de proximidad

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

Si las implementaciones de dispositivos incluyen un sensor de proximidad, tienen las siguientes características:

• [C-1-1] DEBE medir la proximidad de un objeto en la misma dirección que la pantalla. Es decir, el sensor de proximidad DEBE estar orientado para detectar objetos cerca de la pantalla, ya que el objetivo principal de este tipo de sensor es detectar un teléfono que el usuario está usando. Si las implementaciones de dispositivos incluyen un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API.
• [C-1-2] 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, hacen lo siguiente:

• [C-1-1] DEBE identificar la capability a través de la marca de feature android.hardware.sensor.hifi_sensors.

Si las implementaciones de dispositivos declaran android.hardware.sensor.hifi_sensors, hacen lo siguiente:

• [C-2-1] DEBE tener un sensor TYPE_ACCELEROMETER que cumpla con los siguientes requisitos:

  • DEBE tener un rango de medición de al menos -8 g y +8 g, y DEBE tener un rango de medición de al menos -16 g y +16 g.
  • DEBE tener una resolución de medición de al menos 2048 LSB/g.
  • DEBE tener una frecuencia de medición mínima de 12.5 Hz o menos.
  • DEBE tener una frecuencia de medición máxima de 400 Hz o superior. DEBE admitir SensorDirectChannel RATE_VERY_FAST.
  • DEBE tener un ruido de medición no superior a 400 μg/√Hz.
  • DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 3,000 eventos del sensor.
  • DEBE tener un consumo de energía por lotes no superior a 3 mW.
  • [C-SR] SE RECOMIENDA ENFATICAMENTE tener un ancho de banda de medición de 3 dB de al menos el 80% de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
  • DEBE tener una caminata aleatoria de aceleración inferior a 30 μg √Hz probada a temperatura ambiente.
  • DEBE tener un cambio de sesgo en relación con la temperatura de ≤ ± 1 mg/°C.
  • DEBE tener una no linealidad de la línea de mejor ajuste de ≤ 0.5% y un cambio de sensibilidad en función de la temperatura de ≤ 0.03%/°C.
  • DEBE tener una sensibilidad en el eje transversal inferior al 2.5 % y una variación de la sensibilidad en el eje transversal inferior al 0.2% en el rango de temperatura de funcionamiento del dispositivo.

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

• [C-2-3] DEBE tener un sensor TYPE_GYROSCOPE que cumpla con los siguientes requisitos:

  • DEBE tener un rango de medición de al menos -1,000 y +1,000 dps.
  • DEBEN tener una resolución de medición de al menos 16 LSB/dps.
  • DEBE tener una frecuencia de medición mínima de 12.5 Hz o menos.
  • DEBE tener una frecuencia de medición máxima de 400 Hz o superior. DEBE admitir SensorDirectChannel RATE_VERY_FAST.
  • DEBE tener un ruido de medición no superior a 0.014°/s/√Hz.
  • [C-SR] SE RECOMIENDA ENFATICAMENTE tener un ancho de banda de medición de 3 dB de al menos el 80% de la frecuencia de Nyquist y un espectro de ruido blanco dentro de este ancho de banda.
  • DEBE tener una caminata aleatoria de tasa inferior a 0.001 °/s √Hz probada a temperatura ambiente.
  • DEBE tener un cambio de sesgo en función de la temperatura de ≤ +/- 0.05 °/ s / °C.
  • DEBE tener un cambio de sensibilidad en función de la temperatura de ≤ 0.02% / °C.
  • DEBE tener una no linealidad de la línea de mejor ajuste de ≤ 0.2%.
  • DEBE tener una densidad de ruido de ≤ 0.007 °/s/√Hz.
  • DEBE tener un error de calibración inferior a 0.002 rad/s en un rango de temperatura de 10 a 40 °C cuando el dispositivo está inmóvil.
  • DEBE tener una sensibilidad a la gravedad inferior a 0.1°/s/g.
  • DEBE tener una sensibilidad en los ejes cruzados inferior al 4.0 % y una variación de sensibilidad en los ejes cruzados inferior al 0.3% en el rango de temperatura de funcionamiento del dispositivo.

• [C-2-4] DEBE tener un TYPE_GYROSCOPE_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GYROSCOPE.

• [C-2-5] DEBE tener un sensor TYPE_GEOMAGNETIC_FIELD que cumpla con los siguientes requisitos:

  • DEBEN tener un rango de medición de al menos -900 y +900 μT.
  • DEBE tener una resolución de medición de al menos 5 LSB/uT.
  • DEBEN tener una frecuencia de medición mínima de 5 Hz o menos.
  • DEBEN tener una frecuencia de medición máxima de 50 Hz o superior.
  • DEBE tener un ruido de medición no superior a 0.5 uT.

• [C-2-6] DEBE tener un TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que TYPE_GEOMAGNETIC_FIELD y, además, cumplir con lo siguiente:

  • DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 600 eventos del sensor.
  • [C-SR] SE RECOMIENDA ENFATICAMENTE tener un espectro de ruido blanco de 1 Hz a, al menos, 10 Hz cuando la tasa de informes es de 50 Hz o superior.

• [C-2-7] DEBE tener un sensor TYPE_PRESSURE que cumpla con los siguientes requisitos:

  • DEBE tener un rango de medición de al menos 300 y 1,100 hPa.
  • DEBE tener una resolución de medición de al menos 80 LSB/hPa.
  • DEBEN tener una frecuencia de medición mínima de 1 Hz o menos.
  • DEBEN tener una frecuencia de medición máxima de 10 Hz o superior.
  • DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
  • DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 300 eventos del sensor.
  • DEBE tener un consumo de energía por lotes no superior a 2 mW.
• [C-2-8] DEBE tener un sensor TYPE_GAME_ROTATION_VECTOR que cumpla con los siguientes requisitos:
  • DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 300 eventos del sensor.
  • DEBE tener un consumo de energía por lotes no superior a 4 mW.
• [C-2-9] DEBE tener un sensor TYPE_SIGNIFICANT_MOTION que cumpla con los siguientes requisitos:
  • DEBE tener un consumo de energía no superior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando está en movimiento.
• [C-2-10] DEBE tener un sensor TYPE_STEP_DETECTOR que cumpla con los siguientes requisitos:
  • DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 100 eventos del sensor.
  • DEBE tener un consumo de energía no superior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando está en movimiento.
  • DEBE tener un consumo de energía por lotes no superior a 4 mW.
• [C-2-11] DEBE tener un sensor TYPE_STEP_COUNTER que cumpla con los siguientes requisitos:
  • DEBE tener un consumo de energía no superior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando está en movimiento.
• [C-2-12] DEBE tener un sensor TILT_DETECTOR que cumpla con los siguientes requisitos:
  • DEBE tener un consumo de energía no superior a 0.5 mW cuando el dispositivo está estático y 1.5 mW cuando está en movimiento.
• [C-2-13] La marca de tiempo del evento del mismo evento físico que informan el acelerómetro, el giroscopio y el magnetómetro DEBE estar dentro de un rango de 2.5 milisegundos. La marca de tiempo del evento del mismo evento físico que informan el acelerómetro y el giroscopio DEBE estar dentro de 0.25 milisegundos entre sí.
• [C-2-14] DEBEN tener marcas de tiempo de eventos del sensor de giroscopio en la misma base de tiempo que el subsistema de la cámara y dentro de un error de 1 milisegundo.
• [C-2-15] DEBEN entregar muestras a las aplicaciones en un plazo de 5 milisegundos a partir del momento en que los datos están disponibles en cualquiera de los sensores físicos anteriores.
• [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 se mueve cuando se habilita cualquier combinación de los siguientes sensores:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] PUEDE tener un sensor TYPE_PROXIMITY, pero, si está presente, DEBE tener una capacidad de búfer mínima de 100 eventos del sensor.

Ten en cuenta que todos los requisitos de consumo de energía de esta sección no incluyen el consumo de energía del procesador de aplicaciones. Incluye la energía que consume toda la cadena de sensores: el sensor, cualquier circuito de soporte, cualquier sistema de procesamiento de sensores dedicado, etcétera.

Si las implementaciones de dispositivos incluyen compatibilidad directa con sensores, tienen las siguientes características:

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

7.3.10. Sensores biométricos

7.3.10.1. Sensores de huellas dactilares

Si las implementaciones de dispositivos incluyen una pantalla de bloqueo segura, tienen las siguientes características:

• DEBE incluir un sensor de huellas dactilares.

Si las implementaciones de dispositivos incluyen un sensor de huellas dactilares y lo ponen a disposición de apps de terceros, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE declarar la 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 un porcentaje de aceptación falso no superior al 0.002%.
• [SR] SE RECOMIENDA ENFÉCTIVAMENTE que tengas una tasa de aceptación de falsificaciones y suplantación de identidad no superior al 7%.
• [C-1-4] DEBEN divulgar que este modo puede ser menos seguro que una contraseña, un PIN o un patrón seguros, y enumerar claramente los riesgos de habilitarlo, si los porcentajes de aceptación de falsificaciones y suplantación de identidad son superiores al 7%.
• [C-1-5] DEBE limitar la tasa de intentos durante al menos 30 segundos después de cinco intentos falsos de verificación de huellas dactilares.
• [C-1-6] DEBE tener una implementación de almacén de claves respaldada por hardware y realizar la coincidencia de huellas digitales en un entorno de ejecución confiable (TEE) o en un chip con un canal seguro al TEE.
• [C-1-7] DEBEN tener todos los datos de huellas dactilares identificables encriptados y autenticados de forma criptográfica, de modo que no se puedan adquirir, leer ni alterar fuera del TEE, o un chip con un canal seguro al TEE, 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 que se agregue una huella dactilar sin establecer primero una cadena de confianza, lo que implica que el usuario debe confirmar una credencial de dispositivo existente o agregar una nueva (PIN, patrón o contraseña) que esté protegida por el TEE. La implementación del proyecto de código abierto de Android proporciona el mecanismo en el framework para hacerlo.
• [C-1-9] NO DEBE permitir que las aplicaciones de terceros distingan entre huellas digitales individuales.
• [C-1-10] DEBE respetar la marca DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] Cuando se actualice desde una versión anterior a Android 6.0, DEBE migrar de forma segura los datos de huellas dactilares para cumplir con los requisitos anteriores o quitarlos.
• [C-1-12] DEBEN quitar por completo todos los datos de huellas dactilares identificables de un usuario cuando se quita su cuenta (incluso mediante un restablecimiento de la configuración de fábrica).
• [C-1-13] El Procesador de Aplicaciones NO DEBE permitir el acceso no encriptado a datos de huellas dactilares identificables ni a ningún dato derivado de ellos (como incorporaciones).
• [SR] SE RECOMIENDA ENFATICAMENTE tener un porcentaje de rechazo falso inferior al 10%, medido en el dispositivo.
• [SR] SE RECOMIENDA ENFÉCTIVAMENTE 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.
• DEBE usar el ícono de huella digital de Android que se proporciona en el Proyecto de código abierto de Android.

7.3.10.2. Otros sensores biométricos

Si las implementaciones de dispositivos incluyen uno o más sensores biométricos que no se basan en huellas dactilares y los ponen a disposición de apps de terceros, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE tener un porcentaje de aceptación falso no superior al 0.002%.
• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE que tengas una tasa de aceptación de falsificaciones y suplantación de identidad no superior al 7%.
• [C-1-2] DEBEN divulgar que este modo puede ser menos seguro que una contraseña, un PIN o un patrón seguros, y enumerar claramente los riesgos de habilitarlo, si los porcentajes de aceptación de falsificaciones y suplantación de identidad son superiores al 7%.
• [C-1-3] DEBE limitar la tasa de intentos durante al menos 30 segundos después de cinco pruebas falsas para la verificación biométrica, en las que una prueba falsa es una con una calidad de captura adecuada (ACQUIRED_GOOD) que no coincide con una biométrica registrada.
• [C-1-4] DEBE tener una implementación de almacén de claves respaldada por hardware y realizar la coincidencia biométrica en un TEE o en un chip con un canal seguro al TEE.
• [C-1-5] DEBEN tener todos los datos identificables encriptados y autenticados de forma criptográfica, de modo que no se puedan adquirir, leer ni alterar fuera del TEE, o bien un chip con un canal seguro al TEE, como se documenta en los lineamientos de implementación del sitio del Proyecto de código abierto de Android.
• [C-1-6] DEBE evitar que se agreguen nuevas biometrías sin establecer primero una cadena de confianza. Para ello, el usuario debe confirmar la credencial existente o agregar una nueva (PIN, patrón o contraseña) del dispositivo que esté protegida por el TEE. La implementación del proyecto de código abierto de Android proporciona el mecanismo en el framework para hacerlo.
• [C-1-7] NO DEBE permitir que las aplicaciones de terceros distingan entre las inscripciones biométricas.
• [C-1-8] DEBE respetar la marca individual de esa biométrica (p. ej., DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE o DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-9] DEBEN quitar por completo todos los datos biométricos identificables de un usuario cuando se quita su cuenta (incluso mediante un restablecimiento de la configuración de fábrica).
• [C-1-10] NO DEBE permitir que el Procesador de Aplicaciones acceda a datos biométricos identificables ni a datos derivados de ellos (como incorporaciones) sin encriptación fuera del contexto del TEE.
• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE tener una tasa de rechazo falsa inferior al 10%, según se mida en el dispositivo.
• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE tener una latencia inferior a 1 segundo, medida desde el momento en que se detecta la biométrica hasta que se desbloquea la pantalla, para cada biométrica registrada.

7.3.11. Sensores exclusivos de Android Automotive

Los sensores específicos para la industria automotriz se definen en android.car.CarSensorManager API.

7.3.11.1. Cambio actual

Consulta la Sección 2.5.1 para conocer los requisitos específicos de los dispositivos.

7.3.11.2. Modo noche día

Consulta la Sección 2.5.1 para conocer los requisitos específicos de los dispositivos.

7.3.11.3. Estado de conducción

Este requisito dejó de estar disponible.

7.3.11.4. Velocidad de las ruedas

Consulta la Sección 2.5.1 para conocer los requisitos específicos de los dispositivos.

7.3.11.5. Freno de estacionamiento

Consulta la Sección 2.5.1 para conocer los requisitos específicos de los dispositivos.

7.3.12. Sensor de pose

Implementaciones de dispositivos:

• PUEDE admitir un sensor de pose con 6 grados de libertad.

Si las implementaciones de dispositivos admiten el sensor de pose con 6 grados de libertad, hacen lo siguiente:

• [C-1-1] DEBE implementar y generar informes sobre el sensor TYPE_POSE_6DOF.
• [C-1-2] DEBE ser más preciso que el vector de rotación solo.

7.4. Conectividad de datos

7.4.1. Telefonía

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

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

Si las implementaciones de dispositivos incluyen telefonía GSM o CDMA, tienen las siguientes características:

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

Si las implementaciones de dispositivos no incluyen hardware de telefonía, sucede lo siguiente:

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

7.4.1.1. Compatibilidad con el bloqueo de números

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

• [C-1-1] DEBE incluir compatibilidad con el bloqueo de números.
• [C-1-2] DEBE implementar completamente BlockedNumberContract y la API correspondiente, como se describe en la documentación del SDK.
• [C-1-3] DEBE bloquear todas las llamadas y los mensajes de un número de teléfono en "BlockedNumberProvider" sin ninguna interacción con las apps. La única excepción es cuando se levanta temporalmente el bloqueo de números, como se describe en la documentación del SDK.
• [C-1-4] NO DEBE escribir en el proveedor de registros de llamadas de la plataforma para una llamada bloqueada.
• [C-1-5] NO DEBE escribir 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 devuelve el método TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NO DEBE permitir que los usuarios secundarios vean ni editen los números bloqueados en el dispositivo, ya que la plataforma de Android supone que el usuario principal tiene el control total de los servicios de telefonía, una sola instancia, en el dispositivo. TODA la IU relacionada con el bloqueo DEBE estar oculta para los usuarios secundarios, y la lista de bloqueos DEBE respetarse.
• DEBE migrar los números bloqueados al proveedor cuando un dispositivo se actualiza a Android 7.0.

7.4.1.2. API de Telecom

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

• [C-1-1] DEBE admitir las APIs de ConnectionService que se describen en el SDK.
• [C-1-2] DEBE mostrar una nueva llamada entrante y proporcionar una indicación visual para que el usuario la acepte o rechace cuando esté en una llamada en curso que realice una app de terceros que no admita la función de poner en espera especificada a través de CAPABILITY_SUPPORT_HOLD.

• [C-SR] SE RECOMIENDA ENFATICAMENTE que se notifique al usuario que, si contesta una llamada entrante, se descartará una llamada en curso.

  La implementación de AOSP cumple con estos requisitos mediante una notificación de atención que le indica al usuario que, si contesta una llamada entrante, se finalizará la otra.

• [C-SR] SE RECOMIENDA ENFATICAMENTE que se cargue previamente la app de dialer predeterminada que muestra una entrada del registro de llamadas y el nombre de una app de terceros en su registro de llamadas cuando la app de terceros establece la clave de extras EXTRA_LOG_SELF_MANAGED_CALLS en su PhoneAccount en true.

• [C-SR] SE RECOMIENDA ENFATICAMENTE que se controlen los eventos KEYCODE_MEDIA_PLAY_PAUSE y KEYCODE_HEADSETHOOK de los auriculares de audio para las APIs de android.telecom de la siguiente manera:
  • Llama a Connection.onDisconnect() cuando se detecte una presión breve del evento de tecla durante una llamada en curso.
  • Llama a Connection.onAnswer() cuando se detecte una presión breve del evento de tecla durante una llamada entrante.
  • Llama a Connection.onReject() cuando se detecte una presión prolongada del evento de tecla durante una llamada entrante.
  • Activa o desactiva el estado de silenciamiento de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementaciones de dispositivos:

• DEBE incluir compatibilidad con una o más formas de 802.11.

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

• [C-1-1] DEBE implementar la API de Android correspondiente.
• [C-1-2] DEBE informar la marca de función de hardware android.hardware.wifi.
• [C-1-3] DEBE implementar la API de multidifusión como se describe en la documentación del SDK.
• [C-1-4] DEBE admitir DNS multicast (mDNS) y NO DEBE filtrar paquetes mDNS (224.0.0.251) en ningún momento de la operación, lo que incluye lo siguiente:
  • Incluso cuando la pantalla no está en un estado activo.
  • Para implementaciones de dispositivos Android TV, incluso en estados de energía en espera.
• [C-1-5] NO DEBE tratar la llamada al método de la API de WifiManager.enableNetwork() como una indicación suficiente para cambiar el Network activo actualmente que se usa de forma predeterminada para el tráfico de la aplicación y que muestran los métodos de la API de ConnectivityManager, como getActiveNetwork y registerDefaultNetworkCallback. En otras palabras, solo PUEDEN inhabilitar el acceso a Internet que proporciona cualquier otro proveedor de red (p.ej., datos móviles) si validan correctamente que la red Wi-Fi proporciona acceso a Internet.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que, cuando se llame al método de la API ConnectivityManager.reportNetworkConnectivity(), se vuelva a evaluar el acceso a Internet en el Network y, una vez que la evaluación determine que el Network actual ya no proporciona acceso a Internet, se cambie a cualquier otra red disponible (p.ej., datos móviles) que proporcione acceso a Internet.
• [C-SR] SE RECOMIENDA ENFATICAMENTE aleatorizar la dirección MAC de origen y el número de secuencia de los fotogramas de solicitud de sondeo, una vez al comienzo de cada análisis, mientras el STA está desconectado.
  • Cada grupo de tramas de solicitud de sondeo que comprende un análisis debe usar una dirección MAC coherente (NO DEBE aleatorizar la dirección MAC a la mitad de un análisis).
  • El número de secuencia de la solicitud de sondeo debe iterarse de forma normal (secuencial) entre las solicitudes de sondeo en un análisis.
  • El número de secuencia de la solicitud de sondeo debe aleatorizarse entre la última solicitud de sondeo de un análisis y la primera solicitud de sondeo del siguiente análisis.
• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE que, mientras el STA esté desconectado, se permitan solo los siguientes elementos en los tramas de solicitud de sondeo:
  • Conjunto de parámetros de SSID (0)
  • Conjunto de parámetros de DS (3)

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

• [C-2-1] DEBE proporcionar una indicación visual para el usuario para habilitar o inhabilitar el valor leído a través del método de API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi directo

Implementaciones de dispositivos:

• DEBE incluir compatibilidad con Wi-Fi Direct (Wi-Fi entre pares).

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Direct, tienen las siguientes características:

• [C-1-1] DEBE implementar la API de Android correspondiente como se describe en la documentación del SDK.
• [C-1-2] DEBE informar la función de hardware android.hardware.wifi.direct.
• [C-1-3] DEBE admitir el funcionamiento normal de Wi-Fi.
• [C-1-4] DEBE admitir operaciones de Wi-Fi y Wi-Fi Direct de forma simultánea.

7.4.2.2. Configuración de vínculo directo con túnel Wi-Fi

Implementaciones de dispositivos:

• DEBE incluir compatibilidad con la configuración de vínculo directo con túnel Wi-Fi (TDLS), como se describe en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad con TDLS y la API de WiFiManager habilita TDLS, sucede lo siguiente:

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

7.4.2.3. Reconocimiento de Wi-Fi

Implementaciones de dispositivos:

• DEBE incluir compatibilidad con Reconocimiento de Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y exponen la funcionalidad a apps de terceros, hacen lo siguiente:

• [C-1-1] DEBE implementar las APIs de WifiAwareManager como se describe en la documentación del SDK.
• [C-1-2] DEBE declarar la marca de función android.hardware.wifi.aware.
• [C-1-3] DEBE admitir operaciones de Wi-Fi y Wi-Fi Aware de forma simultánea.
• [C-1-4] DEBE aleatorizar la dirección de la interfaz de administración de Wi-Fi Aware en intervalos de no más de 30 minutos y cada vez que se habilita Wi-Fi Aware.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Aware y Wi-Fi Location como se describe en la Sección 7.4.2.5 y exponen estas funciones a apps de terceros, deben cumplir con lo siguiente:

• [C-2-1] DEBE implementar las APIs de descubrimiento orientadas a la ubicación: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm y onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Implementaciones de dispositivos:

• DEBE incluir compatibilidad con Wi-Fi Passpoint.

Si las implementaciones de dispositivos incluyen compatibilidad con Wi-Fi Passpoint, tienen las siguientes características:

• [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 admitir el estándar IEEE 802.11u, específicamente relacionado con el descubrimiento y la selección de redes, como el servicio de anuncios genéricos (GAS) y el protocolo de consulta de red de acceso (ANQP).

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

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

7.4.2.5. Ubicación Wi-Fi (tiempo de ida y vuelta de Wi-Fi: RTT)

Implementaciones de dispositivos:

• DEBE incluir compatibilidad con la Ubicación Wi-Fi.

Si las implementaciones de dispositivos incluyen compatibilidad con la Ubicación Wi-Fi y exponen la funcionalidad a apps de terceros, hacen lo siguiente:

• [C-1-1] DEBE implementar las APIs de WifiRttManager como se describe en la documentación del SDK.
• [C-1-2] DEBE declarar la marca de función android.hardware.wifi.rtt.
• [C-1-3] DEBE aleatorizar la dirección MAC de origen para cada ráfaga de RTT que se ejecute mientras la interfaz Wi-Fi en la que se ejecuta la RTT no esté asociada a un punto de acceso.

7.4.3. Bluetooth

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

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

Si las implementaciones de dispositivos admiten HFP, A2DP y AVRCP, hacen lo siguiente:

• DEBE admitir al menos 5 dispositivos conectados en total.

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

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

Android incluye compatibilidad con Bluetooth y Bluetooth de bajo consumo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo, tienen las siguientes características:

• [C-2-1] DEBES declarar las funciones de la plataforma relevantes (android.hardware.bluetooth y android.hardware.bluetooth_le, respectivamente) y, luego, implementar las APIs de la plataforma.
• DEBE implementar perfiles Bluetooth relevantes, como A2DP, AVRCP, OBEX, HFP, etc., según corresponda al dispositivo.

Si las implementaciones de dispositivos incluyen compatibilidad con Bluetooth de bajo consumo, tienen las siguientes características:

• [C-3-1] DEBE declarar la función de hardware android.hardware.bluetooth_le.
• [C-3-2] DEBEN habilitar las APIs de Bluetooth basadas en GATT (perfil de atributo genérico) como se describe en la documentación del SDK y en android.bluetooth.
• [C-3-3] DEBE informar el valor correcto para BluetoothAdapter.isOffloadedFilteringSupported() para indicar si se implementó la lógica de filtrado para las clases de la API de ScanFilter.
• [C-3-4] DEBE informar el valor correcto de BluetoothAdapter.isMultipleAdvertisementSupported() para indicar si se admite la publicidad de bajo consumo.
• DEBE admitir la transferencia de la lógica de filtrado al chipset Bluetooth cuando se implemente la API de ScanFilter.
• DEBE admitir la transferencia del análisis por lotes al conjunto de chips Bluetooth.

• DEBE admitir varios anuncios con al menos 4 posiciones.

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

Si las implementaciones de dispositivos admiten Bluetooth LE y lo usan para el escaneo de ubicación, hacen lo siguiente:

• [C-4-1] DEBE proporcionar una indicación visual para el usuario para habilitar o inhabilitar el valor leído a través de la API de System BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4. Comunicación de campo cercano

Implementaciones de dispositivos:

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

Si las implementaciones de dispositivos incluyen hardware NFC y planean ponerlo a disposición de apps de terceros, deben cumplir con los siguientes requisitos:

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

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

• [C-1-3] DEBEN ser capaces de transmitir y recibir datos a través de los siguientes estándares y protocolos de igual a igual:

  • ISO 18092
  • LLCP 1.2 (definido por el NFC Forum)
  • SDP 1.0 (definido por NFC Forum)
  • Protocolo de envío de NDEF
  • SNEP 1.0 (definido por el NFC Forum)
• [C-1-4] DEBE incluir compatibilidad con Android Beam y DEBE habilitar Android Beam de forma predeterminada.
• [C-1-5] DEBE poder enviar y recibir con Android Beam cuando esta función está habilitada o cuando se activa otro modo P2P de NFC propietario.
• [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 con 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 de NPP. Los mensajes que recibe el servidor de NPP DEBEN procesarse de la misma manera que el servidor predeterminado de SNEP.
• [C-1-9] DEBE implementar un cliente SNEP y tratar de enviar NDEF P2P saliente al servidor SNEP predeterminado cuando Android Beam esté habilitado. Si no se encuentra un 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 NDEF P2P saliente con android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback y android.nfc.NfcAdapter.enableForegroundNdefPush.
• DEBE usar un gesto o una confirmación en pantalla, como "Tocar para transmitir", antes de enviar mensajes NDEF P2P salientes.
• [C-1-11] DEBE admitir la transferencia de conexión NFC a Bluetooth cuando el dispositivo admita el perfil de inserción de objetos Bluetooth.
• [C-1-12] DEBE admitir la transferencia de conexión a Bluetooth cuando se usa android.nfc.NfcAdapter.setBeamPushUris, mediante la implementación de las especificaciones “Connection Handover version 1.2” y “Bluetooth Secure Simple Pairing Using NFC version 1.0” del NFC Forum. Dicha implementación DEBE implementar el servicio LLCP de transferencia con el nombre de servicio “urn:nfc:sn:handover” para intercambiar la solicitud de transferencia o seleccionar registros a través de NFC, y DEBE usar el perfil de Push de objetos Bluetooth para la transferencia de datos real de Bluetooth. Por motivos heredados (para seguir siendo compatibles con dispositivos Android 4.1), la implementación DEBE aceptar solicitudes GET de SNEP para intercambiar la solicitud de entrega o seleccionar registros a través de NFC. Sin embargo, una implementación NO DEBE enviar solicitudes GET de SNEP para realizar la entrega de la conexión.
• [C-1-13] DEBE sondear todas las tecnologías compatibles mientras está en modo de descubrimiento de NFC.
• DEBE estar en modo de descubrimiento de NFC mientras el dispositivo está activo con la pantalla activa y la pantalla de bloqueo desbloqueada.
• DEBE ser capaz de leer el código de barras y la URL (si está codificada) de los productos de código de barras NFC Thinfilm.

Ten en cuenta que los vínculos disponibles públicamente no están disponibles para las especificaciones de JIS, ISO y NFC Forum mencionadas anteriormente.

Android incluye compatibilidad con el modo de emulación de tarjeta de host (HCE) de NFC.

Si las implementaciones de dispositivos incluyen un chipset de controlador NFC capaz de HCE (para NfcA o NfcB) y admiten el enrutamiento de ID de aplicación (AID), hacen lo siguiente:

• [C-2-1] DEBE informar la constante de función android.hardware.nfc.hce.
• [C-2-2] DEBE admitir las APIs de NFC HCE, como se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen un chipset de controlador de NFC capaz de HCE para NfcF y también implementan la función para aplicaciones de terceros, deben cumplir con los siguientes requisitos:

• [C-3-1] DEBE informar la constante de función android.hardware.nfc.hcef.
• [C-3-2] DEBEN implementar las APIs de emulación de tarjetas NfcF como se define en el SDK de Android.

Si las implementaciones de dispositivos incluyen compatibilidad general con NFC como se describe en esta sección y admiten tecnologías MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF en MIFARE Classic) en el rol de lector/escritor, cumplen con los siguientes requisitos:

• [C-4-1] DEBEN implementar las APIs de Android correspondientes según lo documenta el SDK de Android.
• [C-4-2] DEBE informar la función com.nxp.mifare del mé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 de dispositivos:

• [C-0-1] DEBE incluir compatibilidad con una o más formas de redes de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir compatibilidad con al menos un estándar de datos capaz de alcanzar 200 Kbit/s o más. Algunos ejemplos de tecnologías que cumplen con este requisito son EDGE, HSPA, EV-DO, 802.11g, Ethernet y PAN de Bluetooth.
• TAMBIÉN DEBE incluir compatibilidad con al menos un estándar de datos inalámbricos común, como 802.11 (Wi-Fi), cuando un estándar de red física (como Ethernet) es la conexión de datos principal.
• PUEDE implementar más de una forma de conectividad de datos.
• [C-0-2] DEBE incluir una pila de redes IPv6 y admitir la comunicación IPv6 con las APIs administradas, como java.net.Socket y java.net.URLConnection, así como las APIs nativas, como los sockets AF_INET6.
• [C-0-3] DEBE habilitar IPv6 de forma predeterminada.
• DEBEN garantizar que la comunicación IPv6 sea tan confiable como la IPv4, por ejemplo:
  • [C-0-4] DEBE mantener la conectividad IPv6 en el modo Doze.
  • [C-0-5] La limitación de velocidad NO DEBE hacer que el dispositivo pierda la conectividad IPv6 en ninguna red compatible con IPv6 que use duraciones de RA de al menos 180 segundos.
• [C-0-6] DEBEN proporcionar a las aplicaciones de terceros conectividad IPv6 directa a la red cuando se conectan a una red IPv6, sin ninguna forma de traducción de direcciones o puertos que se realice de forma local en el dispositivo. Tanto las APIs administradas, como Socket#getLocalAddress o Socket#getLocalPort, como las APIs de NDK, como getsockname() o IPV6_PKTINFO, DEBEN mostrar la dirección IP y el puerto que se usan realmente para enviar y recibir paquetes en la red.

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

Si las implementaciones de dispositivos admiten Wi-Fi, hacen lo siguiente:

• [C-1-1] DEBE admitir la operación de pila doble y solo IPv6 en Wi-Fi.

Si las implementaciones de dispositivos admiten Ethernet, tienen las siguientes características:

• [C-2-1] DEBE admitir la operación de pila doble en Ethernet.

Si las implementaciones de dispositivos admiten datos móviles, hacen lo siguiente:

• DEBE admitir el funcionamiento de IPv6 (solo IPv6 y, posiblemente, pila doble) en redes móviles.

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

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

7.4.6. Configuración de sincronización

Implementaciones de dispositivos:

• [C-0-1] DEBE tener la configuración de sincronización automática principal activada de forma predeterminada para que el método getMasterSyncAutomatically() muestre “true”.

7.4.7. Ahorro de datos

Si las implementaciones de dispositivos incluyen una conexión con medición, tienen las siguientes características:

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

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

• [C-1-1] DEBE admitir todas las APIs de la clase ConnectivityManager, como se describe en la documentación del SDK.
• [C-1-2] DEBE proporcionar una interfaz de usuario en la configuración que controle la intención Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, lo que permite a los usuarios agregar aplicaciones a la lista de entidades permitidas o quitarlas de ella.

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

• [C-2-1] 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 implementarlo como una operación no operativa.

7.4.8. Elementos seguros

Si las implementaciones de dispositivos admiten elementos seguros compatibles con la API de Open Mobile y los ponen a disposición de las apps de terceros, hacen lo siguiente:

• [C-1-1] DEBE enumerar los lectores de elementos seguros disponibles cuando se llame al método android.se.omapi.SEService.getReaders().

7.5. Cámaras

Si las implementaciones de dispositivos incluyen al menos una cámara, hacen lo siguiente:

• [C-1-1] DEBE declarar la marca de función android.hardware.camera.any.
• [C-1-2] DEBE ser posible que una aplicación asigne simultáneamente 3 mapas de bits RGBA_8888 iguales al tamaño de las imágenes que produce el sensor de cámara de mayor resolución del dispositivo, mientras la cámara está abierta para obtener una vista previa básica y capturar imágenes fijas.

7.5.1. Cámara posterior

Una cámara posterior es una cámara que se encuentra en el lado del dispositivo opuesto a la pantalla; es decir, captura imágenes de escenas en el extremo opuesto del dispositivo, como una cámara tradicional.

Implementaciones de dispositivos:

• DEBE incluir una cámara posterior.

Si las implementaciones de dispositivos incluyen al menos una cámara posterior, deben cumplir con los siguientes requisitos:

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

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

• [C-2-1] La lámpara del flash NO DEBE estar encendida mientras se haya registrado una instancia de android.hardware.Camera.PreviewCallback en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado el flash de forma explícita 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 en el 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 que se encuentra en el mismo lado del dispositivo que la pantalla; es decir, una cámara que se suele usar para capturar imágenes del usuario, como en videoconferencias y aplicaciones similares.

Implementaciones de dispositivos:

• PUEDE incluir una cámara frontal.

Si las implementaciones de dispositivos incluyen al menos una cámara frontal, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE informar las marcas de función android.hardware.camera.any y android.hardware.camera.front.
• [C-1-2] DEBEN tener una resolución de al menos VGA (640 x 480 píxeles).
• [C-1-3] NO DEBE usar una cámara frontal como la predeterminada de la API de Camera y NO DEBE configurar la API para que trate una cámara frontal como la cámara posterior predeterminada, incluso si es la única cámara del dispositivo.
• [C-1-4] La vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación especificada por la aplicación cuando esta solicitó explícitamente que la pantalla de la cámara se rotara mediante una llamada al método android.hardware.Camera.setDisplayOrientation(). Por el contrario, la vista previa DEBE duplicarse a lo largo del eje horizontal predeterminado del dispositivo cuando la aplicación actual no solicite de forma explícita que se rote la pantalla de la cámara mediante una llamada al método android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NO DEBE duplicar las imágenes estáticas capturadas o las transmisiones de video finales que se devuelven a las devoluciones de llamada de la aplicación o se confirman en el almacenamiento de contenido multimedia.
• [C-1-6] DEBE duplicar la imagen que muestra la vista posterior de la misma manera que el flujo de imágenes de vista previa de la cámara.
• PUEDE incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras posteriores, como se describe en la sección 7.5.1.

Si el usuario puede rotar las implementaciones de dispositivos (por ejemplo, automáticamente a través de un acelerómetro o de forma manual a través de la entrada del usuario), haz lo siguiente:

• [C-2-1] La vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.

7.5.3. Cámara externa

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

• [C-1-1] DEBE declarar las marcas de funciones de la plataforma android.hardware.camera.external y android.hardware camera.any.
• [C-1-2] DEBE admitir la clase de video USB (UVC 1.0 o superior) si la cámara externa se conecta a través del puerto host USB.
• [C-1-3] DEBE aprobar las pruebas de CTS de la cámara con un dispositivo de cámara externa física conectado. Los detalles de las pruebas de CTS de la cámara están disponibles en source.android.com.
• DEBE admitir compresiones de video, como MJPEG, para permitir la transferencia de transmisiones sin codificar de alta calidad (es decir, transmisiones de imágenes sin procesar o comprimidas de forma independiente).
• PUEDE admitir varias cámaras.
• PUEDE admitir codificación de video basada en la cámara.

Si se admite la codificación de video basada en la cámara, haz lo siguiente:

• [C-2-1] La implementación del dispositivo DEBE poder acceder a una transmisión simultánea sin codificar o MJPEG (QVGA o una resolución superior).

7.5.4. Comportamiento de la API de Camera

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

El paquete de API anterior, android.hardware.Camera, está marcado como obsoleto en Android 5.0, pero aún debería estar disponible para que lo usen las apps. Las implementaciones de dispositivos Android DEBEN garantizar la compatibilidad continua de la API, como se describe en esta sección y en el SDK de Android.

Todas las funciones que son comunes entre la clase android.hardware.Camera obsoleta y el paquete más reciente android.hardware.camera2 DEBEN tener un rendimiento y una calidad equivalentes en ambas APIs. Por ejemplo, con una configuración equivalente, la velocidad y la precisión del enfoque automático deben ser idénticas, y la calidad de las imágenes capturadas debe ser la misma. Las funciones que dependen de las diferentes semánticas de las dos APIs no tienen que tener la misma velocidad o calidad, pero DEBEN coincidir lo más cerca posible.

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara, para todas las cámaras disponibles. Implementaciones de dispositivos:

• [C-0-1] DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para los datos de vista previa proporcionados a las devoluciones de llamada de la aplicación cuando una aplicación nunca llamó 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 valor predeterminado.
• [C-0-3] DEBE admitir el formato YV12 (como se indica con la constante android.graphics.ImageFormat.YV12) para las vistas previas de la cámara, tanto frontal como posterior, para android.hardware.Camera. (El codificador de video y la cámara de hardware pueden usar cualquier formato de píxeles nativo, pero la implementación del dispositivo DEBE admitir la conversión a YV12).
• [C-0-4] DEBE admitir los formatos android.hardware.ImageFormat.YUV_420_888 y android.hardware.ImageFormat.JPEG como salidas a través de la API de android.media.ImageReader para dispositivos android.hardware.camera2 que anuncien la función REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE en android.request.availableCapabilities.
• [C-0-5] SIEMPRE DEBES implementar la API de la cámara completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático de hardware o alguna otra función. Por ejemplo, las cámaras que no tienen enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no sea relevante para una cámara que no tiene enfoque automático). Ten en cuenta que esto se aplica a las cámaras frontales. Por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API aún deben ser "falsas", como se describe.
• [C-0-6] DEBE reconocer y respetar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters. Por el contrario, las implementaciones de dispositivos NO DEBEN respetar ni reconocer constantes de cadenas que se pasen al método android.hardware.Camera.setParameters(), excepto las documentadas como constantes en android.hardware.Camera.Parameters. Es decir, las implementaciones de dispositivos DEBEN admitir todos los parámetros de cámara estándar si el hardware lo permite y NO DEBEN admitir tipos de parámetros de cámara personalizados. Por ejemplo, las implementaciones de dispositivos que admiten la captura de imágenes con técnicas de imágenes de alto rango dinámico (HDR) DEBEN admitir el parámetro de cámara Camera.SCENE_MODE_HDR.
• [C-0-7] DEBE informar el nivel de compatibilidad adecuado con la propiedad android.info.supportedHardwareLevel como se describe en el SDK de Android y las marcas de función del framework adecuadas.
• [C-0-8] TAMBIÉN DEBE declarar las capacidades individuales de la cámara de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar las marcas de función adecuadas. DEBE definir la marca de función si alguno de sus dispositivos de cámara conectados admite la función.
• [C-0-9] DEBE transmitir el intent Camera.ACTION_NEW_PICTURE cada vez que la cámara tome una foto nueva y se haya agregado la entrada de la foto a la tienda de contenido multimedia.
• [C-0-10] DEBE transmitir el intent Camera.ACTION_NEW_VIDEO cada vez que la cámara grabe un video nuevo y se haya agregado la entrada de la foto a la tienda de contenido multimedia.
• [C-SR] SE RECOMIENDA ENFATICAMENTE admitir un dispositivo de cámara lógico que enumere la capability CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA para dispositivos con varias cámaras orientadas en la misma dirección, que consisten en cada cámara física orientada en esa dirección, siempre y cuando el framework admita el tipo de cámara física y CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL para las cámaras físicas sea LIMITED, FULL o LEVEL_3.

7.5.5. Orientación de la cámara

Si las implementaciones de dispositivos tienen una cámara frontal o posterior, estas deben cumplir con los siguientes requisitos:

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

7.6. Memoria y almacenamiento

7.6.1. Memoria y almacenamiento mínimos

Implementaciones de dispositivos:

• [C-0-1] DEBEN incluir un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos y DEBEN ser capaces de descargar archivos individuales de al menos 100 MB de tamaño en la ubicación predeterminada de "caché".

7.6.2. Almacenamiento compartido de la aplicación

Implementaciones de dispositivos:

• [C-0-1] DEBE ofrecer almacenamiento para que lo compartan las aplicaciones, también conocido como "almacenamiento externo compartido", "almacenamiento compartido de la aplicación" o por la ruta de acceso de Linux "/sdcard" en la que se activa.
• [C-0-2] DEBE configurarse con el almacenamiento compartido activado de forma predeterminada, es decir, "listo para usar", independientemente de si el almacenamiento se implementa en un componente de almacenamiento interno o en un medio de almacenamiento extraíble (p.ej., ranura para tarjeta Secure Digital).
• [C-0-3] DEBE activar el almacenamiento compartido de la aplicación directamente en la ruta de acceso de Linux sdcard o incluir un vínculo simbólico de Linux desde sdcard hasta el punto de activación real.
• [C-0-4] DEBE aplicar el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido, como se documenta en el SDK. De lo contrario, cualquier aplicación que obtenga ese permiso DEBE poder escribir en el almacenamiento compartido.

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

• Almacenamiento extraíble al que el usuario pueda acceder, como una ranura para tarjeta Secure Digital (SD)
• Es una parte del almacenamiento interno (no extraíble) tal como se implementa en el Proyecto de código abierto de Android (AOSP).

Si las implementaciones de dispositivos usan almacenamiento extraíble para satisfacer los requisitos anteriores, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE implementar una interfaz de usuario emergente o de notificación breve que le advierta al usuario cuando no haya un medio de almacenamiento insertado en la ranura.
• [C-1-2] DEBEN incluir un medio de almacenamiento con formato FAT (p.ej., una tarjeta SD) o indicar en la caja y en el otro material disponible en el momento de la compra que el medio de almacenamiento se debe comprar por separado.

Si las implementaciones de dispositivos usan una parte del almacenamiento no extraíble para satisfacer los requisitos anteriores, deben cumplir con lo siguiente:

• DEBE usar la implementación de AOSP del almacenamiento compartido de la aplicación interna.
• PUEDE compartir el espacio de almacenamiento con los datos privados de la aplicación.

Si las implementaciones de dispositivos incluyen varias rutas de acceso de almacenamiento compartido (como una ranura para tarjeta SD y un almacenamiento interno compartido), hacen lo siguiente:

• [C-2-1] DEBEN permitir solo aplicaciones para Android preinstaladas y con privilegios con 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 con compatibilidad con el modo periférico USB, hacen lo siguiente:

• [C-3-1] DEBE proporcionar un mecanismo para acceder a los datos del almacenamiento compartido de la aplicación desde una computadora host.
• DEBE exponer el contenido de ambas rutas de almacenamiento de forma transparente a través del servicio de escáner de contenido multimedia de Android y android.provider.MediaStore.
• PUEDE usar el almacenamiento masivo USB, pero DEBE usar el Protocolo de transferencia de contenido multimedia para cumplir con este requisito.

Si las implementaciones de dispositivos tienen un puerto USB con modo periférico USB y admiten el Protocolo de transferencia de contenido multimedia, hacen lo siguiente:

• DEBE ser compatible con el host de MTP de Android de referencia, Android File Transfer.
• DEBE informar una clase de dispositivo USB de 0x00.
• DEBE informar un nombre de interfaz USB de “MTP”.

7.6.3. Almacenamiento adoptable

Si se espera que el dispositivo sea móvil, a diferencia de la televisión, las implementaciones de dispositivos son las siguientes:

• [SR] SE RECOMIENDA ENFATICAMENTE implementar el almacenamiento adoptable en una ubicación estable a largo plazo, ya que desconectarlo accidentalmente puede provocar la pérdida o corrupción de datos.

Si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimiento de la batería o en otra cubierta protectora, las implementaciones del dispositivo son las siguientes:

• [SR] SE RECOMIENDA IMPLEMENTAR el almacenamiento adoptable.

7.7. USB

Si las implementaciones de dispositivos tienen un puerto USB, tienen las siguientes características:

• DEBE admitir el modo periférico USB y el modo host USB.

7.7.1. Modo periférico USB

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

• [C-1-1] El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
• [C-1-2] DEBE informar el valor correcto de iSerialNumber en el descriptor de dispositivo estándar USB a través de android.os.Build.SERIAL.
• [C-1-3] DEBEN detectar los cargadores de 1.5 A y 3.0 A según el estándar de resistencia de tipo C y DEBEN detectar cambios en el anuncio si son compatibles con USB tipo C.
• [SR] El puerto DEBE usar un factor de forma USB micro-B, micro-AB o tipo C. Se RECOMIENDA ALTAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a las versiones futuras de la plataforma.
• [SR] El puerto DEBE estar ubicado en la parte inferior del dispositivo (según la orientación natural) o habilitar la rotación de pantalla de software para todas las apps (incluida la pantalla principal) para que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto en la parte inferior. Se RECOMIENDA ALTAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
• [SR] DEBE implementar la compatibilidad para extraer una corriente de 1.5 A durante el tráfico y el chirp de HS, como se especifica en la especificación de carga de baterías USB, revisión 1.2. Se RECOMIENDA ALTAMENTE 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 NO admitir métodos de carga propietarios que modifiquen el voltaje de Vbus más allá de los niveles predeterminados o alteren los roles de sink o fuente, ya que esto puede generar problemas de interoperabilidad con los cargadores o dispositivos que admiten los métodos estándar de entrega de energía USB. Si bien esto se indica como "RECOMENDADO", en versiones futuras de Android, es posible que exijamos que todos los dispositivos tipo C admitan la interoperabilidad completa con los cargadores tipo C estándar.
• [SR] SE RECOMIENDA ENFÉCTIVAMENTE admitir la entrega de energía para el intercambio de roles de datos y energía cuando admiten USB tipo C y modo host USB.
• DEBE admitir la entrega de energía para la carga de alto voltaje y la compatibilidad con modos alternativos, como la salida de pantalla.
• DEBE implementar la API y la especificación de Android Open Accessory (AOA) como se documenta en la documentación del SDK de Android.

Si las implementaciones de dispositivos incluyen un puerto USB y la especificación de AOA, hacen lo siguiente:

• [C-2-1] DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.accessory.
• [C-2-2] La clase de almacenamiento masivo en USB DEBE incluir la cadena "android" al final de la cadena iInterface de la descripción de la interfaz del almacenamiento masivo en USB.

7.7.2. Modo de host USB

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo host, tienen las siguientes características:

• [C-1-1] DEBE implementar la API de host USB de Android como se documenta en el SDK de Android y DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.host.
• [C-1-2] DEBEN implementar compatibilidad para conectar periféricos USB estándar. En otras palabras, DEBEN hacer lo siguiente:
  • Tener un puerto tipo C integrado en el dispositivo o enviarlo con cables que adapten un puerto propietario integrado en el dispositivo a un puerto USB tipo C estándar (dispositivo USB tipo C)
  • Tener un puerto tipo A integrado en el dispositivo o enviar con cables que adapten un puerto propietario integrado en el dispositivo a un puerto USB tipo A estándar
  • Tener un puerto micro-AB integrado en el dispositivo, que DEBE enviarse con un cable que se adapte a un puerto estándar tipo A
• [C-1-3] NO DEBE enviarse con un adaptador que convierta los puertos USB tipo A o micro-AB en un puerto tipo C (receptáculo).
• [SR] SE RECOMIENDA ENFATICAMENTE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
• DEBE admitir la carga del dispositivo periférico USB conectado en modo host y anunciar una corriente de fuente de al menos 1.5 A, como se especifica en la sección Parámetros de terminación de la especificación de la versión 1.2 del cable y conector USB tipo C para conectores USB tipo C o usar el rango de corriente de salida del puerto descendente de carga(CDP) como se especifica en las especificaciones de carga de baterías USB, versión 1.2 para conectores Micro-AB.
• DEBEN implementar y admitir los estándares USB tipo C.

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y la clase de audio USB, hacen lo siguiente:

• [C-2-1] DEBE admitir la clase HID USB.
• [C-2-2] DEBE admitir la detección y asignación de los siguientes campos de datos HID especificados en las tablas de uso de HID USB y la solicitud de uso de comandos por voz a las constantes KeyEvent de la siguiente manera:
  • ID de uso de la página de uso (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • ID de uso de la página de uso (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • ID de uso de la página de uso (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID de uso de la página de uso (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Si las implementaciones de dispositivos incluyen un puerto USB que admite el modo host y el framework de acceso al almacenamiento (SAF), hacen lo siguiente:

• [C-3-1] DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia multimedia) conectado de forma remota y permitir el acceso a su contenido a través de los intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT y ACTION_CREATE_DOCUMENT. .

Si las implementaciones de dispositivos incluyen un puerto USB compatible con el modo host y USB tipo C, deben cumplir con los siguientes requisitos:

• [C-4-1] DEBE implementar la funcionalidad de puerto de doble función según se define en la especificación USB Type-C (sección 4.5.1.3.3).
• [SR] SE RECOMIENDA ENFÉCTIVAMENTE que admita DisplayPort, DEBE admitir velocidades de datos SuperSpeed USB y SE RECOMIENDA ENFÉCTIVAMENTE que admita la entrega de energía para el intercambio de roles de datos y energía.
• [SR] SE RECOMIENDA NO admitir el modo de accesorio de adaptador de audio, como se describe en el Apéndice A de la Especificación de cables y conectores USB tipo C, revisión 1.2.
• DEBE implementar el modelo Try.* que sea más adecuado para el factor de forma del dispositivo. Por ejemplo, un dispositivo portátil DEBE implementar el modelo Try.SNK.

7.8. Audio

7.8.1. Micrófono

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

• [C-1-1] DEBE informar la constante de función android.hardware.microphone.
• [C-1-2] DEBEN cumplir con los requisitos de grabación de audio de la sección 5.4.
• [C-1-3] DEBEN cumplir con los requisitos de latencia de audio de la sección 5.6.
• [SR] SE RECOMIENDA ENFATICAMENTE que admitan la grabación de ultrasonido cercano, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos omiten un micrófono, sucede lo siguiente:

• [C-2-1] NO DEBE informar la constante de función android.hardware.microphone.
• [C-2-2] DEBE implementar la API de grabación de audio, al menos como no-ops, según la sección 7.

7.8.2. Salida de audio

Si las implementaciones de dispositivos incluyen una bocina o un puerto de salida de audio/multimedia para un periférico de salida de audio, como un conector de audio de 4 conductores de 3.5 mm o un puerto de modo host USB con clase de audio USB, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE informar la constante de función android.hardware.audio.output.
• [C-1-2] DEBEN cumplir con los requisitos de reproducción de audio de la sección 5.5.
• [C-1-3] DEBEN cumplir con los requisitos de latencia de audio de la sección 5.6.
• [SR] SE RECOMIENDA ENFATICAMENTE admitir la reproducción de ultrasonido cercano, como se describe en la sección 7.8.3.

Si las implementaciones de dispositivos no incluyen una bocina o un puerto de salida de audio, sucede lo siguiente:

• [C-2-1] NO DEBE informar la función android.hardware.audio.output.
• [C-2-2] DEBEN implementar las APIs relacionadas con la salida de audio como no-ops como mínimo.

A los efectos de esta sección, un "puerto de salida" es una interfaz física, como un conector de audio de 3.5 mm, HDMI o un puerto de modo host USB con clase de audio USB. La compatibilidad con la salida de audio a través de protocolos basados en radio, como Bluetooth, Wi-Fi o red celular, no califica como la inclusión de un "puerto de salida".

7.8.2.1. Puertos de audio analógicos

Para ser compatibles con los auriculares y otros accesorios de audio que usan el conector de audio de 3.5 mm en todo el ecosistema de Android, si las implementaciones de dispositivos incluyen uno o más puertos de audio analógico, deben cumplir con los siguientes requisitos:

• [C-SR] SE RECOMIENDA ENFATICAMENTE que al menos uno de los puertos de audio sea un conector de audio de 4 conductores de 3.5 mm.

Si las implementaciones de dispositivos tienen un conector de audio de 3.5 mm de 4 conductores, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono.
• [C-1-2] DEBEN admitir conectores de audio TRRS con el orden de asignación de pines CTIA.
• [C-1-3] DEBE admitir la detección y la asignación a los códigos de teclas para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de masa en el enchufe de audio:
  • 70 ohmios o menos: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DEBE activar ACTION_HEADSET_PLUG cuando se inserta un enchufe, pero solo después de que todos los contactos del enchufe toquen sus segmentos relevantes en el conector.
• [C-1-5] DEBE ser capaz de generar al menos 150 mV ± 10% de voltaje de salida en una impedancia de bocina de 32 ohmios.
• [C-1-6] DEBE tener un voltaje de polarización del micrófono de entre 1.8 V y 2.9 V.
• [C-1-7] DEBE detectar y asignar al código de tecla el siguiente rango de impedancia equivalente entre el micrófono y los conductores de masa en el enchufe de audio:
  • 110-180 ohmios: KEYCODE_VOICE_ASSIST
• [C-SR] SE RECOMIENDA ENFATICAMENTE admitir enchufes de audio con el orden de pines OMTP.
• [C-SR] SE RECOMIENDA ENFATICAMENTE admitir la grabación de audio desde auriculares estéreo con micrófono.

Si las implementaciones de dispositivos tienen un conector de audio de 4 conductores de 3.5 mm y admiten un micrófono, y transmiten el android.intent.action.HEADSET_PLUG con el micrófono de valor adicional establecido como 1, hacen lo siguiente:

• [C-2-1] DEBE admitir la detección de micrófono en el accesorio de audio conectado.

7.8.3. Ultrasonido de proximidad

El audio cercano al ultrasonido es la banda de 18.5 kHz a 20 kHz.

Implementaciones de dispositivos:

• DEBEN informar correctamente la compatibilidad con la función de audio de ultrasonido cercano a través de la API de AudioManager.getProperty de la siguiente manera:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND es "verdadero", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED DEBEN cumplir con los siguientes requisitos:

• [C-1-1] La respuesta de potencia promedio del micrófono en la banda de 18.5 kHz a 20 kHz DEBE ser de no más de 15 dB por debajo de la respuesta a 2 kHz.
• [C-1-2] La relación señal a ruido sin ponderar del micrófono de 18.5 kHz a 20 kHz para un tono de 19 kHz a -26 dBFS DEBE ser de al menos 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND es "true", haz lo siguiente:

• [C-2-1] La respuesta promedio del altavoz en el rango de 18.5 kHz a 20 kHz DEBE ser de al menos 40 dB por debajo de la respuesta a 2 kHz.

7.9. Realidad virtual

Android incluye APIs y herramientas para compilar aplicaciones de "realidad virtual" (RV), incluidas experiencias de RV para dispositivos móviles de alta calidad. Las implementaciones de dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.

7.9.1. Modo de realidad virtual

Android incluye compatibilidad con el Modo VR, una función que controla la renderización estereoscópica de las notificaciones y que inhabilita los componentes de la IU del sistema monocular mientras una aplicación de VR tiene el enfoque del usuario.

7.9.2. Modo de realidad virtual: Alto rendimiento

Si las implementaciones de dispositivos admiten el modo de RV, hacen lo siguiente:

• [C-1-1] DEBE tener al menos 2 núcleos físicos.
• [C-1-2] DEBE declarar la función android.hardware.vr.high_performance.
• [C-1-3] DEBE admitir el modo de rendimiento sostenido.
• [C-1-4] DEBE ser compatible con OpenGL ES 3.2.
• [C-1-5] DEBE admitir android.hardware.vulkan.level 0.
• DEBE admitir android.hardware.vulkan.level 1 o una versión posterior.
• [C-1-6] DEBES implementar EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace y exponer las extensiones en la lista de extensiones de EGL disponibles.
• [C-1-8] DEBE implementar GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures y exponer las extensiones en la lista de extensiones de GL disponibles.
• [C-SR] SE RECOMIENDA ENFATICAMENTE implementar GL_EXT_external_buffer, GL_EXT_EGL_image_array y exponer las extensiones en la lista de extensiones de GL disponibles.
• [C-SR] SE RECOMIENDA URGENTEMENTE que admitan Vulkan 1.1.
• [C-SR] SE RECOMIENDA ENFATICAMENTE implementar VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing y VK_KHR_shared_presentable_image, y exponerlos en la lista de extensiones de Vulkan disponibles.
• [C-SR] SE RECOMIENDA ENFATICAMENTE exponer al menos una familia de colas de Vulkan en la que flags contenga VK_QUEUE_GRAPHICS_BIT y VK_QUEUE_COMPUTE_BIT, y queueCount sea de al menos 2.
• [C-1-7] La GPU y la pantalla DEBEN poder sincronizar el acceso al búfer frontal compartido para que se muestre la renderización de ojos alternos del contenido de VR a 60 fps con dos contextos de renderización sin artefactos de seccionamientos visibles.
• [C-1-9] DEBE implementar la compatibilidad con las marcas AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA y AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, como se describe en el NDK.
• [C-1-10] DEBE implementar la compatibilidad con AHardwareBuffer con cualquier combinación de las marcas de uso AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT para, al menos, los siguientes formatos: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] SE RECOMIENDA ENFATICAMENTE admitir la asignación de AHardwareBuffer con más de una capa y las marcas y formatos especificados en C-1-10.
• [C-1-11] DEBE admitir la decodificación de H.264 de al menos 3,840 x 2,160 a 30 fps, comprimido a un promedio de 40 Mbps (equivalente a 4 instancias de 1,920 x 1,080 a 30 fps y 10 Mbps o 2 instancias de 1,920 x 1,080 a 60 fps y 20 Mbps).
• [C-1-12] DEBE admitir HEVC y VP9, DEBE ser capaz de decodificar al menos 1,920 x 1,080 a 30 fps comprimidos a un promedio de 10 Mbps y DEBE ser capaz de decodificar 3,840 x 2,160 a 30 fps-20 Mbps (equivalente a 4 instancias de 1,920 x 1,080 a 30 fps-5 Mbps).
• [C-1-13] DEBE admitir la API de HardwarePropertiesManager.getDeviceTemperatures y mostrar valores precisos de la temperatura de la piel.
• [C-1-14] DEBE tener una pantalla incorporada y su resolución DEBE ser de al menos 1920 x 1080.
• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE que tengas una resolución de pantalla de al menos 2560 × 1440.
• [C-1-15] La pantalla DEBE actualizarse a al menos 60 Hz mientras está en modo VR.
• [C-1-17] La pantalla DEBE admitir un modo de baja persistencia con una persistencia de ≤ 5 milisegundos, que se define como la cantidad de tiempo durante la cual un píxel emite luz.
• [C-1-18] DEBE ser compatible con Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE sección 7.4.3.
• [C-1-19] DEBE admitir y registrar correctamente el tipo de canal directo para todos los siguientes tipos de sensores predeterminados:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] SE RECOMIENDA ENFATICAMENTE admitir el tipo de canal directo TYPE_HARDWARE_BUFFER para todos los tipos de canales directos mencionados anteriormente.
• [C-1-21] DEBE cumplir con los requisitos relacionados con el giroscopio, el acelerómetro y el magnetómetro para android.hardware.hifi_sensors, como se especifica en la sección 7.3.9.
• [C-SR] SE RECOMIENDA ENFATICAMENTE admitir la función android.hardware.sensor.hifi_sensors.
• [C-1-22] DEBE tener una latencia de extremo a extremo de movimiento a fotones no superior a 28 milisegundos.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que la latencia de movimiento a fotones de extremo a extremo no sea superior a 20 milisegundos.
• [C-1-23] DEBE tener una relación de primer fotograma, que es la relación entre el brillo de los píxeles en el primer fotograma después de una transición de negro a blanco y el brillo de los píxeles blancos en estado estable, de al menos el 85%.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que tengan una relación de primer fotograma de al menos el 90%.
• PUEDE proporcionar un núcleo exclusivo a la aplicación en primer plano y PUEDE admitir la API de Process.getExclusiveCores para mostrar los números de los núcleos de CPU que son exclusivos de la aplicación en primer plano superior.

Si se admite el núcleo exclusivo, este hace lo siguiente:

• [C-2-1] NO DEBE permitir que se ejecuten otros procesos de espacio de usuario (excepto los controladores de dispositivos que usa la aplicación), pero PUEDE permitir que se ejecuten algunos procesos del kernel según sea necesario.

8. Rendimiento y energía

Algunos criterios mínimos de rendimiento y energía son fundamentales para la experiencia del usuario y afectan las suposiciones de referencia que tendrían los desarrolladores cuando desarrollan una app.

8.1. Coherencia de la experiencia del usuario

Se puede proporcionar una interfaz de usuario fluida al usuario final si existen ciertos requisitos mínimos para garantizar una velocidad de fotogramas y tiempos de respuesta coherentes para las aplicaciones y los juegos. Según el tipo de dispositivo, las implementaciones de dispositivos PUEDEN tener requisitos medibles para la latencia de la interfaz de usuario y el cambio de tareas, como se describe en la sección 2.

8.2. Rendimiento de acceso a la E/S de archivos

Proporcionar un modelo de referencia común para un rendimiento de acceso a archivos coherente en el almacenamiento de datos privados de la aplicación (partición /data) permite a los desarrolladores de apps establecer una expectativa adecuada que ayudaría a su diseño de software. Según el tipo de dispositivo, las implementaciones de dispositivos PUEDEN tener ciertos requisitos que se describen en la sección 2 para las siguientes operaciones de lectura y escritura:

• Rendimiento de escritura secuencial: Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 10 MB.
• Rendimiento de las operaciones de escritura aleatoria Se mide escribiendo un archivo de 256 MB con un búfer de escritura de 4 KB.
• Rendimiento de lectura secuencial: Se mide leyendo un archivo de 256 MB con un búfer de escritura de 10 MB.
• Rendimiento de lectura aleatoria Se mide leyendo un archivo de 256 MB con un búfer de escritura de 4 KB.

8.3. Modos de ahorro de energía

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

• [C-1-1] NO DEBE desviarse de la implementación de AOSP para los algoritmos de activación, mantenimiento y activación, y el uso de la configuración del sistema global de los modos de ahorro de energía de App Standby y Doze.
• [C-1-2] NO DEBE desviarse de la implementación de AOSP para usar la configuración global y administrar la limitación de tareas, alarmas y redes para las apps en cada bucket de modo de espera de apps.
• [C-1-3] NO DEBE desviarse de la implementación de AOSP para la cantidad de buckets de App Standby que se usan para App Standby.
• [C-1-4] DEBE implementar buckets de App Standby y Descanso como se describe en Administración de energía.
• [C-1-5] DEBE mostrar true para PowerManager.isPowerSaveMode() cuando el dispositivo está en modo de ahorro de energía.
• [C-SR] SE RECOMIENDA ENFATICAMENTE proporcionar indicaciones visuales para que el usuario habilite o inhabilite la función de ahorro de batería.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que se proporcionen indicaciones visuales para el usuario para mostrar todas las apps que están exentas de los modos de ahorro de energía de App Standby y Doze.

Además de los modos de ahorro de energía, las implementaciones de dispositivos Android PUEDEN implementar cualquiera de los 4 estados de energía de suspensión o todos ellos, según se define en la Interfaz avanzada de configuración y energía (ACPI).

Si las implementaciones de dispositivos implementan los estados de energía S4 como los define el ACPI, hacen lo siguiente:

• [C-1-1] DEBE ingresar a este estado solo después de que el usuario haya realizado una acción explícita para poner el dispositivo en un estado inactivo (p.ej., cerrando una tapa que forma parte físicamente del dispositivo o apagando un vehículo o una televisión) y antes de que el usuario vuelva a activar el dispositivo (p.ej., abriendo la tapa o volviendo a encender el vehículo o la televisión).

Si las implementaciones de dispositivos implementan los estados de energía S3 como los define el ACPI, hacen lo siguiente:

• [C-2-1] DEBE cumplir con C-1-1 anterior o DEBE ingresar al estado S3 solo cuando las aplicaciones de terceros no necesiten los recursos del sistema (p.ej., la pantalla o la CPU).

  Por el contrario, DEBEN salir del estado S3 cuando las aplicaciones de terceros necesiten los recursos del sistema, como se describe en este SDK.

  Por ejemplo, mientras las aplicaciones de terceros solicitan mantener la pantalla encendida a través de FLAG_KEEP_SCREEN_ON o mantener la CPU en ejecución a través de PARTIAL_WAKE_LOCK, el dispositivo NO DEBE entrar en el estado S3, a menos que, como se describe en C-1-1, el usuario haya tomado medidas explícitas para poner el dispositivo en un estado inactivo. Por el contrario, en un momento en el que se activa una tarea que las apps de terceros implementan a través de JobScheduler o se entrega Firebase Cloud Messaging a apps de terceros, el dispositivo DEBE salir del estado S3, a menos que el usuario lo haya puesto en un estado inactivo. Estos no son ejemplos exhaustivos, y AOSP implementa indicadores de activación extensos que activan un despertar desde este estado.

8.4. Contabilización del consumo de energía

Una contabilización y generación de informes más precisa del consumo de energía le proporciona al desarrollador de la app los incentivos y las herramientas para optimizar el patrón de uso de energía de la aplicación.

Implementaciones de dispositivos:

• [SR] SE RECOMIENDA ENFATICAMENTE proporcionar un perfil de energía por componente que defina el valor de consumo actual para cada componente de hardware y la descarga de batería aproximada que causan los componentes con el tiempo, como se documenta en el sitio del proyecto de código abierto de Android.
• [SR] SE RECOMIENDA ENFATICAMENTE informar todos los valores de consumo de energía en miliamperios-hora (mAh).
• [SR] SE RECOMIENDA ENFATICAMENTE informar el consumo de energía de la CPU por UID de cada proceso. El Proyecto de código abierto de Android cumple con el requisito a través de la implementación del módulo de kernel uid_cputime.
• [SR] SE RECOMIENDA ENFATICAMENTE que el desarrollador de la app haga que este uso de energía esté disponible a través del comando de shell adb shell dumpsys batterystats.
• DEBE atribuirse al componente de hardware en sí si no se puede atribuir el consumo de energía del componente de hardware a una aplicación.

8.5. Rendimiento coherente

El rendimiento puede fluctuar de forma significativa en el caso de las apps de alto rendimiento de larga duración, ya sea debido a otras apps que se ejecutan en segundo plano o a la limitación de la CPU debido a los límites de temperatura. Android incluye interfaces programáticas para que, cuando el dispositivo sea capaz, la aplicación en primer plano superior pueda solicitar que el sistema optimice la asignación de los recursos para abordar esas fluctuaciones.

Implementaciones de dispositivos:

• [C-0-1] DEBE informar la compatibilidad con el modo de rendimiento sostenido con precisión a través del método de la API de PowerManager.isSustainedPerformanceModeSupported().

• DEBE admitir el modo de rendimiento sostenido.

Si las implementaciones de dispositivos informan compatibilidad con el modo de rendimiento sostenido, hacen lo siguiente:

• [C-1-1] DEBE proporcionarle a la aplicación en primer plano un nivel de rendimiento coherente durante al menos 30 minutos, cuando la app lo solicite.
• [C-1-2] DEBE cumplir con la API de Window.setSustainedPerformanceMode() y otras APIs relacionadas.

Si las implementaciones de dispositivos incluyen dos o más núcleos de CPU, hacen lo siguiente:

• DEBE proporcionar al menos un núcleo exclusivo que la aplicación en primer plano superior pueda reservar.

Si las implementaciones de dispositivos admiten reservar un núcleo exclusivo para la aplicación en primer plano superior, hacen lo siguiente:

• [C-2-1] DEBE informar a través del método de la API de Process.getExclusiveCores() los números de ID de los núcleos exclusivos que puede reservar la aplicación en primer plano superior.
• [C-2-2] NO DEBE permitir que ningún proceso de espacio de usuario, excepto los controladores de dispositivos que usa la aplicación, se ejecute en los núcleos exclusivos, pero PUEDE permitir que algunos procesos del kernel se ejecuten según sea necesario.

Si las implementaciones de dispositivos no admiten un núcleo exclusivo, sucede lo siguiente:

• [C-3-1] DEBE mostrar una lista vacía a través del método de la API Process.getExclusiveCores().

9. Compatibilidad de modelos de seguridad

Implementaciones de dispositivos:

• [C-0-1] DEBE implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, tal como se define en el documento de referencia de seguridad y permisos de las APIs en la documentación para desarrolladores de Android.

• [C-0-2] DEBE admitir la instalación de aplicaciones con firma propia sin requerir permisos ni certificados adicionales de terceros o autoridades. Específicamente, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad que se describen en las siguientes subsecciones.

9.1. Permisos

Implementaciones de dispositivos:

• [C-0-1] DEBE admitir el modelo de permisos de Android, tal como se define en la documentación para desarrolladores de Android. Específicamente, DEBEN aplicar cada permiso definido como se describe en la documentación del SDK. No se pueden omitir, alterar ni ignorar permisos.

• PUEDE agregar permisos adicionales, siempre y cuando las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.\*.

• [C-0-2] Los permisos con un protectionLevel de PROTECTION_FLAG_PRIVILEGED SOLO DEBEN otorgarse a las apps preinstaladas en las rutas de acceso privilegiadas de la imagen del sistema y dentro del subconjunto de los permisos de la lista de entidades permitidas de forma explícita para cada app. La implementación de AOSP cumple con este requisito leyendo y respetando los permisos de la lista de entidades permitidas de cada app de los archivos en la ruta de acceso etc/permissions/ y usando la ruta de acceso system/priv-app como la ruta de acceso privilegiada.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 los solicitan durante el tiempo de ejecución.

Implementaciones de dispositivos:

• [C-0-3] DEBE mostrar una interfaz dedicada para que el usuario decida si otorgar los permisos de tiempo de ejecución solicitados y también proporcionar una interfaz para que el usuario administre los permisos de tiempo de ejecución.
• [C-0-4] DEBE tener una y solo una implementación de ambas interfaces de usuario.
• [C-0-5] NO DEBE otorgar ningún permiso de tiempo de ejecución a las apps preinstaladas, a menos que se cumplan las siguientes condiciones:
  • Se puede obtener el consentimiento del usuario antes de que la aplicación lo use.
  • Los permisos de tiempo de ejecución están asociados con un patrón de intent para el que la aplicación preinstalada se establece como el controlador predeterminado.
• [C-0-6] DEBE otorgar el permiso android.permission.RECOVER_KEYSTORE solo a las apps del sistema que registren un agente de recuperación protegido de forma correcta. Un agente de recuperación protegido de forma adecuada se define como un agente de software integrado en el dispositivo que se sincroniza con un almacenamiento remoto fuera del dispositivo, que está equipado con hardware seguro con una protección equivalente o más fuerte que la que se describe en el Servicio de Key Vault de Google Cloud para evitar ataques de fuerza bruta en el factor de conocimiento de la pantalla de bloqueo.

Si las implementaciones de dispositivos incluyen una app preinstalada o desean permitir que las apps de terceros accedan a las estadísticas de uso, deben cumplir con los siguientes requisitos:

• [SR] SE RECOMIENDA ENFATICAMENTE proporcionar un mecanismo accesible para el usuario para otorgar o revocar el acceso a las estadísticas de uso en respuesta al intent android.settings.ACTION_USAGE_ACCESS_SETTINGS para las apps que declaran el permiso android.permission.PACKAGE_USAGE_STATS.

Si las implementaciones de dispositivos tienen la intención de no permitir que ninguna app, incluidas las preinstaladas, acceda a las estadísticas de uso, deben cumplir con lo siguiente:

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

9.2. Aislamiento de UID y procesos

Implementaciones de dispositivos:

• [C-0-1] DEBE admitir el modelo de zona de pruebas de aplicaciones de Android, en el que cada aplicación se ejecuta como un UID de estilo Unix único y en un proceso independiente.
• [C-0-2] DEBE admitir la ejecución de varias aplicaciones como el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas y compiladas correctamente, como se define en la referencia de seguridad y permisos.

9.3. Permisos del sistema de archivos

Implementaciones de dispositivos:

• [C-0-1] DEBE admitir el modelo de permisos de acceso a archivos de Android, como se define en la referencia de seguridad y permisos.

9.4. Entornos de ejecución alternativos

Las implementaciones de dispositivos DEBEN mantener la coherencia del modelo de permisos y seguridad de Android, incluso si incluyen entornos de ejecución que ejecutan aplicaciones con algún otro software o tecnología que no sea el formato ejecutable de Dalvik o el código nativo. En otras palabras:

• [C-0-1] Los tiempos de ejecución alternativos DEBEN ser aplicaciones para Android y cumplir con el modelo de seguridad estándar de Android, como se describe en la sección 9.

• [C-0-2] NO DEBEN otorgarse acceso a los recursos protegidos por permisos que no se solicitaron en el archivo AndroidManifest.xml del entorno de ejecución a través del mecanismo <uses-permission> a los entornos de ejecución alternativos.

• [C-0-3] Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones usen funciones protegidas por permisos de Android restringidos a las aplicaciones del sistema.

• [C-0-4] Los tiempos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android, y las aplicaciones instaladas que usan un tiempo de ejecución alternativo NO DEBEN volver a usar la zona de pruebas de ninguna otra app instalada en el dispositivo, excepto a través de los mecanismos estándar de Android de ID de usuario compartido y certificado de firma.

• [C-0-5] Los tiempos de ejecución alternativos NO DEBEN iniciarse con acceso a las zonas de pruebas correspondientes a otras aplicaciones para Android, ni otorgarlo ni recibirlo.

• [C-0-6] Los tiempos de ejecución alternativos NO DEBEN iniciarse con privilegios del superusuario (root) ni otorgarlos a otras aplicaciones, ni otorgarles privilegios a otras aplicaciones.

• [C-0-7] Cuando los archivos .apk de tiempos de ejecución alternativos se incluyen en la imagen del sistema de las implementaciones de dispositivos, DEBEN firmarse con una clave distinta de la que se usa para firmar otras aplicaciones incluidas con las implementaciones de dispositivos.

• [C-0-8] Cuando se instalan aplicaciones, los entornos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de Android que usa la aplicación.

• [C-0-9] Cuando una aplicación necesita usar un recurso de dispositivo para el que hay un permiso de Android correspondiente (como la cámara, el GPS, etcétera), el entorno de ejecución alternativo DEBE informar al usuario que la aplicación podrá acceder a ese recurso.

• [C-0-10] Cuando el entorno de ejecución no registra las capacidades de la aplicación de esta manera, DEBE enumerar todos los permisos que tiene el entorno de ejecución cuando se instala cualquier aplicación que lo use.

• Los entornos de ejecución alternativos DEBEN instalar apps a través de PackageManager en zonas de pruebas de Android independientes (IDs de usuario de Linux, etcétera).

• Los entornos de ejecución alternativos PUEDEN proporcionar una sola zona de pruebas de Android que comparten todas las aplicaciones que usan el entorno de ejecución alternativo.

9.5. Compatibilidad con varios usuarios

Android incluye compatibilidad con varios usuarios y proporciona compatibilidad con el aislamiento total de usuarios.

• Las implementaciones de dispositivos PUEDEN, pero NO DEBEN, habilitar el modo multiusuario si usan medios extraíbles para el almacenamiento externo principal.

Si las implementaciones de dispositivos incluyen varios usuarios, estos pueden hacer lo siguiente:

• [C-1-1] DEBEN cumplir con los siguientes requisitos relacionados con la compatibilidad con varios usuarios.
• [C-1-2] DEBE implementar, para cada usuario, 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 de las APIs.
• [C-1-3] DEBEN tener directorios de almacenamiento de aplicaciones compartidos (también conocidos como /sdcard) separados y aislados para cada instancia de usuario.
• [C-1-4] DEBEN garantizar que las aplicaciones que son propiedad de un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer ni escribir en los archivos que pertenecen a ningún otro usuario, incluso si los datos de ambos usuarios se almacenan en el mismo volumen o sistema de archivos.
• [C-1-5] DEBE encriptar el contenido de la tarjeta SD cuando se habilita el modo multiusuario con una clave almacenada solo en medios no extraíbles a los que solo pueda acceder el sistema si las implementaciones de dispositivos usan medios extraíbles para las APIs de almacenamiento externo. Como esto hará que una PC host no pueda leer el contenido multimedia, las implementaciones de dispositivos deberán cambiar a MTP o a un sistema similar para proporcionar a las PCs host acceso a los datos del usuario actual.

Si las implementaciones de dispositivos incluyen varios usuarios y no declaran la marca de función android.hardware.telephony, sucede 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, hacen lo siguiente:

• [C-3-1] NO DEBE admitir perfiles restringidos, pero DEBE alinearse con la implementación de controles de AOSP para habilitar o inhabilitar que otros usuarios accedan a las llamadas de voz y los SMS.

9.6. Advertencia sobre SMS premium

Android incluye compatibilidad para advertir a los usuarios sobre cualquier mensaje SMS premium saliente. Los SMS premium son mensajes de texto que se envían a un servicio registrado con un operador que puede cobrar un cargo al usuario.

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

• [C-1-1] DEBE advertir a los usuarios antes de enviar un mensaje SMS a números identificados por expresiones regulares definidas en el archivo /data/misc/sms/codes.xml del dispositivo. El Proyecto de código abierto de Android upstream proporciona una implementación que satisface este requisito.

9.7. Funciones de seguridad

Las implementaciones de dispositivos DEBEN garantizar el cumplimiento de las funciones de seguridad en el kernel y la plataforma, como se describe a continuación.

La zona de pruebas de Android incluye funciones que usan el sistema de control de acceso obligatorio (MAC) de Security-Enhanced Linux (SELinux), la zona de pruebas de seccomp y otras funciones de seguridad en el kernel de Linux. Implementaciones de dispositivos:

• [C-0-1] DEBE mantener la compatibilidad con las aplicaciones existentes, incluso cuando 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 violación de seguridad y la función de seguridad implementada debajo del framework de Android la bloquea correctamente, pero PUEDE tener una interfaz de usuario visible cuando se produce una violación de seguridad desbloqueada que genera un exploit exitoso.
• [C-0-3] NO DEBE permitir que el usuario o el desarrollador de la app configuren SELinux ni ninguna otra función de seguridad implementada debajo del framework de Android.
• [C-0-4] NO DEBE permitir que una aplicación que pueda afectar a otra aplicación a través de una API (como una API de administración de dispositivos) configure una política que rompa la compatibilidad.
• [C-0-5] DEBE dividir el framework multimedia en varios procesos para que sea posible otorgar acceso más limitado a cada proceso, como se describe en el sitio del proyecto de código abierto de Android.
• [C-0-6] DEBE implementar un mecanismo de zona de pruebas de aplicaciones de kernel que permita filtrar las llamadas al sistema con una política configurable desde programas de varios subprocesos. El Proyecto de código abierto de Android upstream cumple con este requisito habilitando seccomp-BPF con sincronización de grupos de subprocesos (TSYNC), como se describe en la sección Configuración del kernel de source.android.com.

Las funciones de integridad del kernel y autoprotección son fundamentales para la seguridad de Android. Implementaciones de dispositivos:

• [C-0-7] DEBEN implementar protecciones contra desbordamientos de búfer de pila del kernel (p.ej., CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] DEBEN implementar protecciones estrictas de memoria del kernel en las que el código ejecutable sea de solo lectura, los datos de solo lectura no sean ejecutables ni escribibles, y los datos escribibles no sean ejecutables (p.ej., CONFIG_DEBUG_RODATA o CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DEBE implementar la verificación de límites de tamaño de objetos estáticos y dinámicos de las copias entre el espacio de usuario y el espacio del kernel (p.ej., CONFIG_HARDENED_USERCOPY) en dispositivos que se envían originalmente con el nivel de API 28 o versiones posteriores.
• [C-0-10] NO DEBE ejecutar memoria de espacio de usuario cuando se ejecuta en el modo de kernel (p.ej., PXN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se envían originalmente con el nivel de API 28 o superior.
• [C-0-11] NO DEBE leer ni escribir memoria de espacio de usuario en el kernel fuera de las APIs de acceso normales de copia de usuario (p.ej., PAN de hardware o emulado a través de CONFIG_CPU_SW_DOMAIN_PAN o CONFIG_ARM64_SW_TTBR0_PAN) en dispositivos que se envían originalmente con el nivel de API 28 o versiones posteriores.
• [C-0-12] DEBE implementar el aislamiento de la tabla de páginas del kernel en todos los dispositivos que se envían originalmente con el nivel de API 28 o versiones posteriores (p.ej., CONFIG_PAGE_TABLE_ISOLATION o "CONFIG_UNMAP_KERNEL_AT_EL0").
• [SR] SE RECOMIENDA ENFATICAMENTE que los datos del kernel que se escriben solo durante la inicialización se marquen como de solo lectura después de la inicialización (p.ej., __ro_after_init).
• [SR] SE RECOMIENDA ENFATICAMENTE aleatorizar el diseño del código y la memoria del kernel, y evitar exposiciones que comprometan la aleatorización (p.ej., CONFIG_RANDOMIZE_BASE con entropía del bootloader a través de /chosen/kaslr-seed Device Tree node o EFI_RNG_PROTOCOL).

Si las implementaciones de dispositivos usan un kernel de Linux, hacen lo siguiente:

• [C-1-1] DEBE implementar SELinux.
• [C-1-2] DEBE configurar SELinux en el modo de aplicación forzosa global.
• [C-1-3] DEBEN configurar todos los dominios en modo de aplicación forzosa. No se permiten dominios de modo permisivo, incluidos los dominios específicos de un dispositivo o proveedor.
• [C-1-4] NO DEBE modificar, omitir ni reemplazar las reglas de neverallow presentes en la carpeta system/sepolicy proporcionada en el Proyecto de código abierto de Android (AOSP) upstream, y la política DEBE compilarse con todas las reglas de neverallow presentes, tanto para los dominios de SELinux de AOSP como para los dominios específicos del dispositivo o el proveedor.
• [C-1-5] DEBEN ejecutar aplicaciones de terceros orientadas al nivel de API 28 o versiones posteriores en zonas de pruebas de SELinux por aplicación con restricciones de SELinux por aplicación en el directorio de datos privados de cada aplicación.
• DEBE retener la política predeterminada de SELinux proporcionada en la carpeta system/sepolicy del Proyecto de código abierto de Android upstream y solo agregar más a esta política para su propia configuración específica del dispositivo.

Si las implementaciones de dispositivos ya se lanzaron en una versión anterior de Android y no pueden cumplir con los requisitos [C-1-1] y [C-1-5] a través de una actualización de software del sistema, PUEDEN estar exentos de estos requisitos.

Si las implementaciones de dispositivos usan un kernel que no es Linux, sucede lo siguiente:

• [C-2-1] DEBEN usar un sistema de control de acceso obligatorio que sea equivalente a SELinux.

Android contiene varias funciones de defensa en profundidad que son fundamentales para la seguridad de los dispositivos.

Implementaciones de dispositivos:

• [C-SR] SE RECOMIENDA NO inhabilitar la integridad del flujo de control (CFI) ni la limpieza de desbordamiento de enteros (IntSan) en los componentes que la tienen habilitada.
• [C-SR] SE RECOMIENDA ENFATICAMENTE habilitar CFI y IntSan para cualquier componente adicional del espacio de usuario sensible a la seguridad, como se explica en CFI y IntSan.

9.8. Privacidad

9.8.1. Historial de uso

Android almacena el historial de las elecciones del usuario y lo administra a través de UsageStatsManager.

Implementaciones de dispositivos:

• [C-0-1] DEBE mantener un período de retención razonable de ese historial de usuario.
• [SR] SE RECOMIENDA ENFATICAMENTE mantener el período de retención de 14 días como se configuró de forma predeterminada en la implementación de AOSP.

Android almacena los eventos del sistema con los identificadores StatsLog y administra ese historial a través de StatsManager y la API de IncidentManager del sistema.

Implementaciones de dispositivos:

• [C-0-2] SOLO debes incluir los campos marcados con DEST_AUTOMATIC en el informe de incidentes creado por la clase de la API del sistema IncidentManager.
• [C-0-3] NO DEBES usar los identificadores de eventos del sistema para registrar ningún otro evento que no se describa en los documentos del SDK de StatsLog. Si se registran eventos del sistema adicionales, PUEDEN usar un identificador de átomo diferente en el rango de 100,000 a 200,000.

9.8.2. Grabando

Implementaciones de dispositivos:

• [C-0-1] NO DEBE precargar ni distribuir componentes de software listos para usar que envíen información privada del usuario (p.ej., pulsaciones de teclas, texto que se muestra en la pantalla) desde el dispositivo sin su consentimiento o sin borrar las notificaciones en curso.

Si las implementaciones de dispositivos incluyen funciones en el sistema que capturan el contenido que se muestra en la pantalla o graban la transmisión de audio que se reproduce en el dispositivo, hacen lo siguiente:

• [C-1-1] DEBE tener una notificación continua para el usuario cada vez que esta funcionalidad esté habilitada y esté capturando o grabando de forma activa.

Si las implementaciones de dispositivos incluyen un componente habilitado de forma predeterminada, capaz de grabar audio ambiental para inferir información útil sobre el contexto del usuario, hacen lo siguiente:

• [C-2-1] NO DEBE almacenar en el almacenamiento persistente del dispositivo ni transmitir desde el dispositivo el audio sin procesar grabado ni ningún formato que pueda volver a convertirse en el audio original o en un facsímil cercano, excepto con el consentimiento explícito del usuario.

9.8.3. Conectividad

Si las implementaciones de dispositivos tienen un puerto USB con compatibilidad con el modo periférico USB, hacen lo siguiente:

• [C-1-1] DEBE presentar una interfaz de usuario que solicite el consentimiento del usuario antes de permitir el acceso al contenido del almacenamiento compartido a través del puerto USB.

9.8.4. Tráfico de red

Implementaciones de dispositivos:

• [C-0-1] DEBEN preinstalar los mismos certificados raíz para el almacén de la autoridad certificadora (AC) de confianza del sistema como se proporciona en el proyecto de código abierto de Android upstream.
• [C-0-2] DEBE enviarse con un almacén de AC raíz del usuario vacío.
• [C-0-3] DEBE mostrar una advertencia al usuario que indique que se puede supervisar el tráfico de red cuando se agrega una AC raíz del usuario.

Si el tráfico del dispositivo se enruta a través de una VPN, las implementaciones del dispositivo hacen lo siguiente:

• [C-1-1] DEBE mostrar una advertencia al usuario que indique lo siguiente:
  • Es posible que se supervise ese tráfico de red.
  • Ese tráfico de red se enruta a través de la aplicación de VPN específica que proporciona la VPN.

Si las implementaciones de dispositivos tienen un mecanismo, habilitado de forma predeterminada, que enruta el tráfico de datos de red a través de un servidor proxy o una puerta de enlace de VPN (por ejemplo, la carga previa de un servicio de VPN con android.permission.CONTROL_VPN otorgado), hacen lo siguiente:

• [C-2-1] DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de políticas de dispositivos lo habilite a través de DevicePolicyManager.setAlwaysOnVpnPackage() , en cuyo caso el usuario no necesita proporcionar un consentimiento independiente, pero DEBE recibir una notificación.

Si las implementaciones de dispositivos implementan una indicación visual para el usuario para activar la función "VPN siempre activada" de una app de VPN de terceros, deben cumplir con los siguientes requisitos:

• [C-3-1] DEBES inhabilitar esta indicación visual para el usuario en el archivo AndroidManifest.xml para las apps que no admiten el servicio de VPN siempre activada configurando el atributo SERVICE_META_DATA_SUPPORTS_ALWAYS_ON como false.

9.9. Encriptación de almacenamiento de datos

Si el rendimiento de la criptografía del estándar de encriptación avanzada (AES), medido con la tecnología AES de mayor rendimiento disponible en el dispositivo (p.ej., las extensiones de criptografía ARM), supera los 50 MiB/s, las implementaciones del dispositivo hacen lo siguiente:

• [C-1-1] DEBE admitir la encriptación de almacenamiento de datos de los datos privados de la aplicación (partición /data), así como la partición de almacenamiento compartido de la aplicación (partición /sdcard) si es una parte permanente y no extraíble del dispositivo, excepto para las implementaciones de dispositivos que suelen compartirse (p.ej., una televisión).
• [C-1-2] DEBE habilitar la encriptación de almacenamiento de datos de forma predeterminada cuando el usuario haya completado la experiencia de configuración lista para usar, excepto en las implementaciones de dispositivos que suelen compartirse (p.ej., televisores).

Si el rendimiento de la criptografía AES es igual o inferior a 50 MiB/s, las implementaciones de dispositivos PUEDEN usar Adiantum-XChaCha12-AES en lugar de la forma de AES que se indica en cualquiera de los siguientes casos: AES-256-XTS en la Sección 9.9.2 [C-1-5]; AES-256 en el modo CBS-CTS en la Sección 9.9.2 [C-1-6]; AES en la Sección 9.9.3 [C-1-1]; AES en la Sección 9.9.3 [C-1-3].

Si las implementaciones de dispositivos ya se lanzaron en una versión anterior de Android y no pueden cumplir con el requisito mediante una actualización de software del sistema, ES POSIBLE que se eximan de los requisitos anteriores.

Implementaciones de dispositivos:

• DEBE cumplir con el requisito de encriptación de almacenamiento de datos anterior mediante la implementación de la encriptación basada en archivos (FBE).

9.9.1. Inicio directo

Implementaciones de dispositivos:

• [C-0-1] DEBEN implementar las APIs del modo de inicio directo, incluso si no admiten la encriptación del almacenamiento.

• [C-0-2] Los intents ACTION_LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED DEBEN transmitirse para indicar a las aplicaciones compatibles con el inicio directo que las ubicaciones de almacenamiento encriptadas por dispositivo (DE) y encriptadas por credenciales (CE) están disponibles para el usuario.

9.9.2. Encriptación basada en archivos

Si las implementaciones de dispositivos admiten FBE, hacen 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 encriptado del dispositivo (DE) después de que se transmita el mensaje ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] SOLO DEBE permitir el acceso al almacenamiento encriptado por credenciales (CE) después de que el usuario desbloquee el dispositivo proporcionando sus credenciales (p. ej., una contraseña, un PIN, un patrón o una huella dactilar) y se transmita 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 ni una clave de depósito en garantía registrada.
• [C-1-4] DEBEN admitir el inicio verificado y garantizar que las claves de DE estén vinculadas criptográficamente a la raíz de confianza de hardware del dispositivo.
• [C-1-5] DEBE admitir la encriptación del contenido de los archivos con AES-256-XTS. AES-256-XTS hace referencia al estándar de encriptación avanzada con una longitud de clave de 256 bits, que se opera en modo XTS. La longitud completa de la clave XTS es de 512 bits.

• [C-1-6] DEBE admitir la encriptación de nombres de archivos con AES-256 en modo CBC-CTS.

• Las claves que protegen las áreas de almacenamiento de CE y DE:

• [C-1-7] DEBEN estar vinculados criptográficamente a un almacén de claves con copia de seguridad en hardware.

• [C-1-8] Las claves de CE DEBEN estar vinculadas a las credenciales de la pantalla de bloqueo de un usuario.
• [C-1-9] Las claves de CE DEBEN estar vinculadas a una contraseña predeterminada cuando el usuario no especificó credenciales de pantalla de bloqueo.

• [C-1-10] DEBEN ser únicas y distintas, es decir, ninguna clave de CE o DE de un usuario debe coincidir con las claves de CE o DE de ningún otro usuario.

• [C-1-11] DEBEN usar los algoritmos de cifrado, las longitudes de clave y los modos admitidos de forma obligatoria de forma predeterminada.

• [C-SR] SE RECOMIENDA ENFATICAMENTE encriptar los metadatos del sistema de archivos, como los tamaños de los archivos, la propiedad, los modos y los atributos extendidos (xattrs), con una clave vinculada criptográficamente a la raíz de confianza de hardware del dispositivo.

• DEBE hacer que las apps esenciales preinstaladas (p.ej., Alarm, Phone, Messenger) sean compatibles con el inicio directo.

• PUEDE admitir algoritmos de cifrado alternativos, longitudes de claves y modos para la encriptación de nombres y contenido de archivos.

El proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función basada 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), hacen lo siguiente:

• [C-1-1] DEBE usar AES en un modo diseñado para el almacenamiento (por ejemplo, XTS o CBC-ESSIV) y con una longitud de clave de cifrado de 128 bits o más.
• [C-1-2] 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 encriptarla.
• [C-1-3] DEBE encriptar la clave de encriptación de forma predeterminada, a menos que el usuario inhabilite esta opción de forma explícita, excepto cuando esté en uso activo, con las credenciales de la pantalla de bloqueo estiradas con un algoritmo de estiramiento lento (p.ej., PBKDF2 o scrypt).
• [C-1-4] El algoritmo de estiramiento de contraseña predeterminado anterior DEBE estar vinculado criptográficamente a ese almacén de claves cuando el usuario no haya especificado credenciales de pantalla de bloqueo o haya inhabilitado el uso de la contraseña para la encriptación, y el dispositivo proporcione un almacén de claves con copia de seguridad 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 la clave vinculada al hardware).

El proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función, basada en la función dm-crypt del kernel de Linux.

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan la transparencia del estado de la integridad del dispositivo. Implementaciones de dispositivos:

• [C-0-1] DEBEN informar correctamente a través del método PersistentDataBlockManager.getFlashLockState() de la API del sistema si el estado del bootloader permite la actualización de la imagen del sistema. El estado FLASH_LOCK_UNKNOWN se reserva para las implementaciones de dispositivos que se actualizan desde una versión anterior de Android en la que no existía este nuevo método de la API del sistema.

• [C-0-2] DEBE admitir el inicio verificado para la integridad del dispositivo.

Si las implementaciones de dispositivos ya se lanzaron sin admitir el inicio verificado en una versión anterior de Android y no pueden agregar compatibilidad con esta función con una actualización de software del sistema, es POSIBLE que se eximan del requisito.

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

• [C-1-1] DEBE declarar la marca de función de la plataforma android.software.verified_boot.
• [C-1-2] DEBE realizar la verificación en cada secuencia de inicio.
• [C-1-3] DEBE iniciar la verificación desde una clave de hardware inmutable que sea la raíz de confianza y llegar hasta la partición del sistema.
• [C-1-4] DEBE implementar cada etapa de verificación para verificar 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 seguros 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 se complete el inicio cuando falle la verificación del sistema, a menos que el usuario consienta intentar el inicio de todos modos, en cuyo caso NO DEBEN usarse los datos de los bloques de almacenamiento no verificados.
• [C-1-7] NO DEBE permitir que se modifiquen las particiones verificadas del dispositivo, a menos que el usuario haya desbloqueado explícitamente el bootloader.
• [C-SR] Si hay varios chips discretos en el dispositivo (p.ej., radio, procesador de imágenes especializado), se RECOMIENDA ENFATICAMENTE verificar cada etapa del proceso de inicio de cada uno de esos chips.
• [C-1-8] DEBE usar almacenamiento con evidencia de manipulación para almacenar si el bootloader está desbloqueado. El almacenamiento con evidencia de manipulación significa que el cargador de arranque puede detectar si se manipuló el almacenamiento desde Android.
• [C-1-9] DEBE solicitarle al usuario que confirme físicamente la transición del modo de arranque bloqueado al modo de arranque desbloqueado mientras usa el dispositivo.
• [C-1-10] DEBE implementar la protección contra la reversión para las particiones que usa Android (p.ej., particiones de inicio y del sistema) y usar almacenamiento con evidencia de manipulación para almacenar los metadatos que se usan para determinar la versión mínima permitida del SO.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que verifiques todos los archivos APK de apps con privilegios con una cadena de confianza arraigada en /system, que está protegida por el inicio verificado.
• [C-SR] SE RECOMIENDA ENFATICAMENTE que verifiques los artefactos ejecutables que cargue una app con privilegios desde fuera de su archivo APK (como código cargado de forma dinámica o código compilado) antes de ejecutarlos o que NO los ejecutes en absoluto.
• DEBE implementar la protección contra la reversión para cualquier componente con firmware persistente (p.ej., módem o cámara) y DEBE usar almacenamiento con evidencia de manipulación para almacenar los metadatos que se usan para determinar la versión mínima permitida.

Si las implementaciones de dispositivos ya se lanzaron sin admitir C-1-8 a C-1-10 en una versión anterior de Android y no pueden agregar compatibilidad con estos requisitos con una actualización de software del sistema, es POSIBLE que se eximan de los requisitos.

El Proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función en el repositorio external/avb/, que se puede integrar en el cargador de arranque que se usa para cargar Android.

Implementaciones de dispositivos:

• [C-R] SE RECOMIENDA admitir la API de Configuración de protección de Android.

Si las implementaciones de dispositivos admiten la API de Configuración de protección de Android, hacen lo siguiente:

• [C-3-1] DEBE informar true para la API de ConfirmationPrompt.isSupported().
• [C-3-2] DEBE garantizar que el hardware seguro tome el control total de la pantalla de manera tal que el SO Android no pueda bloquearla sin que el hardware seguro la detecte.
• [C-3-3] DEBE garantizar que el hardware seguro tome el control total de la pantalla táctil.

9.11. Claves y credenciales

El sistema Android Keystore permite que los desarrolladores de apps almacenen claves criptográficas en un contenedor y las usen en operaciones criptográficas a través de la API de KeyChain o la API de Keystore. Implementaciones de dispositivos:

• [C-0-1] DEBE permitir que se importen o generen al menos 8,192 claves.
• [C-0-2] La autenticación de la pantalla de bloqueo DEBE limitar la frecuencia de los intentos y DEBE tener un algoritmo de retirada exponencial. Después de 150 intentos fallidos, la demora DEBE ser de al menos 24 horas por intento.
• NO DEBE limitar la cantidad de claves que se pueden generar.

Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, hace lo siguiente:

• [C-1-1] DEBE crear una copia de seguridad de la implementación del almacén de claves con un entorno de ejecución aislado.
• [C-1-2] DEBE tener implementaciones de algoritmos criptográficos RSA, AES, ECDSA y HMAC, y funciones hash de la familia MD5, SHA1 y SHA-2 para admitir correctamente los algoritmos compatibles del sistema de almacén de claves de Android en un área que esté aislada de forma segura del código que se ejecuta en el kernel y en niveles superiores. El aislamiento seguro DEBE bloquear todos los mecanismos potenciales a través de los cuales el código del kernel o del espacio de usuario pueda acceder al estado interno del entorno aislado, incluida la DMA. El Proyecto de código abierto de Android (AOSP) upstream cumple con este requisito mediante la implementación de Trusty, pero otras opciones alternativas son otra solución basada en TrustZone de ARM o una implementación segura revisada por terceros de un aislamiento adecuado basado en hipervisor.
• [C-1-3] DEBE realizar la autenticación de la pantalla de bloqueo en el entorno de ejecución aislado y, solo cuando se realice correctamente, permitir que se usen las claves vinculadas a la autenticación. Las credenciales de la pantalla de bloqueo DEBEN almacenarse de una manera que permita que solo el entorno de ejecución aislado realice la autenticación de la pantalla de bloqueo. El Proyecto de código abierto de Android ascendente proporciona la capa de abstracción de hardware (HAL) de Gatekeeper y Trusty, que se pueden usar para satisfacer este requisito.
• [C-1-4] DEBE admitir la certificación de claves en la que la clave de firma de certificación está protegida por hardware seguro y la firma se realiza en hardware seguro. Las claves de firma de certificación DEBEN compartirse en una cantidad suficiente 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, SE PUEDE usar una clave diferente para cada 100,000 unidades.
• [C-1-5] DEBE permitir que el usuario elija el tiempo de espera de suspensión para la transición del estado desbloqueado al estado bloqueado, con un tiempo de espera mínimo permitido de hasta 15 segundos.

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

9.11.1. Pantalla de bloqueo segura

La implementación de AOSP sigue un modelo de autenticación por niveles en el que una autenticación principal basada en la fábrica de conocimiento puede estar respaldada por una biométrica secundaria sólida o por modalidades terciarias más débiles.

Implementaciones de dispositivos:

• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE configurar solo uno de los siguientes como método de autenticación principal:
  • Un PIN numérico
  • Una contraseña alfanumérica
  • Un patrón de deslizamiento en una cuadrícula de exactamente 3 × 3 puntos

Ten en cuenta que los métodos de autenticación anteriores se denominan métodos de autenticación principales recomendados en este documento.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación principales recomendados y usan un método de autenticación nuevo como una forma segura de bloquear la pantalla, el método de autenticación nuevo debe cumplir con los siguientes requisitos:

• [C-2-1] DEBE ser el método de autenticación del usuario como se describe en Solicita la autenticación del usuario para el uso de la clave.
• [C-2-2] DEBEN desbloquearse todas las claves para que una app de desarrollador de terceros las use cuando el usuario desbloquee la pantalla de bloqueo segura. Por ejemplo, todas las claves DEBEN estar disponibles para una app de desarrollador externo a través de las APIs relevantes, como createConfirmDeviceCredentialIntent y setUserAuthenticationRequired.

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 y usan un nuevo método de autenticación para que se considere una forma segura de bloquear la pantalla, haz lo siguiente:

• [C-3-1] La entropía de la longitud más corta permitida de las entradas DEBE ser mayor que 10 bits.
• [C-3-2] La entropía máxima de todas las entradas posibles DEBE ser superior a 18 bits.
• [C-3-3] El nuevo método de autenticación NO DEBE reemplazar ninguno de los métodos de autenticación principales recomendados (es decir, PIN, patrón o contraseña) implementados y proporcionados en AOSP.
• [C-3-4] El nuevo método de autenticación DEBE estar inhabilitado cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de calidad de contraseñas 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 principales recomendados para desbloquear la pantalla de bloqueo y usan un nuevo método de autenticación basado en datos biométricos para que se considere una forma segura de bloquear la pantalla, el método nuevo debe cumplir con los siguientes requisitos:

• [C-4-1] DEBEN cumplir con todos los requisitos descritos en la sección 7.3.10.2.
• [C-4-2] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados que se base en un secreto conocido.
• [C-4-3] DEBE estar inhabilitado y solo permitir que la autenticación principal recomendada 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 protección de la clave llamando al método DevicePolicyManager.setKeyguardDisabledFeatures() con cualquiera de las marcas biométricas asociadas (es decir, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE o KEYGUARD_DISABLE_IRIS).
• [C-4-4] DEBE solicitarle al usuario la autenticación principal recomendada (p.ej., PIN, patrón o contraseña) al menos una vez cada 72 horas o menos.
• [C-4-5] DEBE tener una tasa de aceptación falsa igual o más alta que la requerida para un sensor de huellas dactilares, como se describe en la sección 7.3.10, o DEBE estar inhabilitado y solo permitir que la autenticación principal recomendada desbloquee la pantalla cuando la aplicación del controlador de políticas de dispositivos (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.
• [C-SR] SE RECOMIENDA ENFÉCTIVAMENTE que los porcentajes de aceptación de falsificaciones y suplantación de identidad sean iguales o más estrictos que los requeridos para un sensor de huellas dactilares, como se describe en la sección 7.3.10.
• [C-4-6] DEBE tener una canalización de procesamiento segura de modo que una vulneración del sistema operativo o del kernel no pueda permitir que se inyecten datos directamente para autenticar falsamente como el usuario.
• [C-4-7] DEBE estar vinculado a una acción de confirmación explícita (p. ej., presionar un botón) para permitir el acceso a las claves del almacén de claves si la aplicación establece true para KeyGenParameterSpec.Built.setUserAuthenticationRequired() y el dato biométrico es pasivo (p. ej., rostro o iris cuando no existe una señal explícita de intención).
• [C-SR] SE RECOMIENDA ENFATICAMENTE que la acción de confirmación de la biometría pasiva esté protegida de modo que un compromiso del sistema operativo o del kernel no pueda falsificarla. Por ejemplo, esto significa que la acción de confirmación basada en un botón físico se enruta a través de un pin de entrada/salida (GPIO) de uso general de solo entrada de un elemento seguro (SE) que no se puede activar de ninguna otra manera que no sea presionando un botón físico.

Si los métodos de autenticación biométrica no cumplen con las tasas de aceptación de falsificación y suplantación de identidad como se describe en la sección 7.3.10, haz lo siguiente:

• [C-5-1] Los métodos DEBEN estar inhabilitados si la aplicación del controlador de política de dispositivo (DPC) estableció la política de calidad de contraseñas a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Se DEBE solicitar al usuario la autenticación principal recomendada (p. ej., PIN, patrón o contraseña) después de un período de inactividad de 4 horas. El tiempo de espera de inactividad se restablece después de que se confirma correctamente las credenciales del dispositivo.
• [C-5-3] Los métodos NO DEBEN tratarse como una pantalla de bloqueo segura y DEBEN cumplir con los requisitos que comienzan con C-8 en esta sección a continuación.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo y un nuevo método de autenticación se basa en un token físico o la ubicación, haz lo siguiente:

• [C-6-1] DEBEN tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados que se base en un secreto conocido y cumpla con los requisitos para que se considere una pantalla de bloqueo segura.
• [C-6-2] El método nuevo DEBE estar inhabilitado y solo permitir que uno de los métodos de autenticación principales recomendados desbloquee la pantalla cuando la aplicación del controlador de políticas de dispositivos (DPC) haya establecido la política con el método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) o el método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] Se DEBE solicitar al usuario uno de los métodos de autenticación principales recomendados (p.ej., PIN, patrón o contraseña) al menos una vez cada 72 horas o menos.
• [C-6-4] El nuevo método NO DEBE tratarse como una pantalla de bloqueo segura y DEBE seguir las restricciones que se indican en C-8 a continuación.

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

• [C-7-1] DEBE haber una indicación clara en el menú de configuración y en la pantalla de bloqueo cuando el bloqueo del dispositivo se aplaza o cuando los agentes de confianza pueden desbloquearlo. Por ejemplo, AOSP cumple con este requisito mostrando una descripción de texto para los parámetros de configuración "Bloquear automáticamente" y "El botón de encendido bloquea el dispositivo de inmediato" en el menú de configuración y un ícono distinguible en la pantalla de bloqueo.
• [C-7-2] DEBE respetar e implementar por completo todas las APIs del agente de confianza en la clase DevicePolicyManager, como la constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NO DEBE implementar completamente la función TrustAgentService.addEscrowToken() en un dispositivo que se use como dispositivo personal principal (p.ej., un dispositivo de mano), pero PUEDE implementar completamente la función en implementaciones de dispositivos que suelen compartirse (p.ej., Android TV o dispositivos para vehículos).
• [C-7-4] DEBE encriptar todos los tokens almacenados que agregue TrustAgentService.addEscrowToken().
• [C-7-5] NO DEBE almacenar la clave de encriptación en el mismo dispositivo en el que se usa. Por ejemplo, se permite que una clave almacenada en un teléfono desbloquee una cuenta de usuario en una TV.
• [C-7-6] DEBE informar al usuario sobre las implicaciones de seguridad antes de habilitar el token de depósito en garantía para desencriptar el almacenamiento de datos.
• [C-7-7] DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales recomendados.
• [C-7-8] Se DEBE solicitar al usuario uno de los métodos de autenticación principal recomendados (p. ej., PIN, patrón o contraseña) al menos una vez cada 72 horas o menos.
• [C-7-9] Se DEBE solicitar al usuario que ingrese uno de los métodos de autenticación principal recomendados (p. ej., PIN, patrón o contraseña) después de un período de inactividad de 4 horas. El tiempo de espera de inactividad se restablece después de que se confirma correctamente las credenciales del dispositivo.
• [C-7-10] NO DEBE tratarse como una pantalla de bloqueo segura y DEBE seguir las restricciones que se indican en C-8 a continuación.

Si las implementaciones de dispositivos agregan o modifican los métodos de autenticación para desbloquear la pantalla de bloqueo que no es una pantalla de bloqueo segura como se describió anteriormente y usan un nuevo método de autenticación para desbloquear el protector de pantalla, haz lo siguiente:

• [C-8-1] El método nuevo DEBE estar inhabilitado cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de calidad de contraseñas a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NO DEBEN restablecer los temporizadores de vencimiento de contraseñas establecidos por DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NO DEBEN autenticar el acceso a los almacenes de claves cuando la aplicación establece true para KeyGenParameterSpec.Builder.setUserAuthenticationRequired().

9.11.2. StrongBox

El sistema Android Keystore permite a los desarrolladores de apps almacenar claves criptográficas en un procesador seguro dedicado, así como en el entorno de ejecución aislado que se describió anteriormente.

Implementaciones de dispositivos:

• [C-SR] SE RECOMIENDA URGENTEMENTE que admitan StrongBox.

Si las implementaciones de dispositivos admiten StrongBox, hacen lo siguiente:

• [C-1-1] DEBE declarar FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DEBE proporcionar hardware seguro dedicado que se use para respaldar el almacén de claves y proteger la autenticación del usuario.

• [C-1-3] DEBE tener una CPU discreta que no comparta caché, DRAM, coprocesadores ni otros recursos principales con el procesador de aplicaciones (AP).

• [C-1-4] DEBEN garantizar que los periféricos compartidos con el AP no puedan alterar el procesamiento de StrongBox de ninguna manera ni obtener información de StrongBox. El AP PUEDE inhabilitar o bloquear el acceso a StrongBox.

• [C-1-5] DEBE tener un reloj interno con una precisión razonable (+-10%) que sea inmune a la manipulación del AP.

• [C-1-6] DEBE tener un generador de números aleatorios reales que produzca un resultado impredecible y distribuido de forma uniforme.

• [C-1-7] DEBEN tener resistencia a la manipulación, incluida la resistencia contra la penetración física y los errores.

• [C-1-8] DEBE tener resistencia a los canales laterales, incluida la resistencia contra la filtración de información a través de canales laterales de energía, sincronización, radiación electromagnética y radiación térmica.

• [C-1-9] DEBEN tener un almacenamiento seguro que garantice la confidencialidad, integridad, autenticidad, coherencia y actualización del contenido. El almacenamiento NO DEBE poder leerse ni alterarse, excepto según lo permitido por las APIs de StrongBox.

• Para validar el cumplimiento de [C-1-3] a [C-1-9], las implementaciones de dispositivos deben cumplir con lo siguiente:

  • [C-1-10] DEBE incluir el hardware que esté certificado según el perfil de protección de circuitos integrados seguros BSI-CC-PP-0084-2014 o que haya sido evaluado por un laboratorio de pruebas acreditado a nivel nacional que incorpore una evaluación de vulnerabilidad de alto potencial de ataque de acuerdo con la aplicación de los criterios comunes de potencial de ataque a las tarjetas inteligentes.
  • [C-1-11] DEBE incluir el firmware que evalúa un laboratorio de pruebas acreditado a nivel nacional que incorpore la evaluación de vulnerabilidad de alto potencial de ataque de acuerdo con la aplicación de los criterios comunes de potencial de ataque a las tarjetas inteligentes.
  • [C-SR] SE RECOMIENDA ENFATICAMENTE incluir el hardware que se evalúa con un objetivo de seguridad, nivel de garantía de evaluación (EAL) 5, aumentado por AVA_VAN.5. Es probable que la certificación EAL 5 se convierta en un requisito en una versión futura.

• [C-SR] SE RECOMIENDA ENFATICAMENTE que proporcionen resistencia a ataques de personas internas (IAR), lo que significa que una persona interna con acceso a las claves de firma de firmware no puede producir un firmware que haga que StrongBox filtre secretos, omita los requisitos de seguridad funcionales o, de alguna otra manera, habilite el acceso a datos sensibles del usuario. La forma recomendada de implementar IAR es permitir actualizaciones de firmware solo cuando se proporciona la contraseña del usuario principal a través del HAL de IAuthSecret.

9.12. Eliminación de Datos

Todas las implementaciones de dispositivos:

• [C-0-1] DEBEN proporcionar a los usuarios un mecanismo para realizar un "Restablecimiento de la configuración de fábrica".
• [C-0-2] DEBEN 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 requiera la imagen del sistema
• [C-0-3] DEBEN borrar los datos de manera tal que satisfagan los estándares relevantes de la industria, como el NIST SP800-88.
• [C-0-4] DEBE activar el proceso "Restablecimiento de datos de fábrica" anterior cuando la app de controlador de política de dispositivo del usuario principal llame a la API de DevicePolicyManager.wipeData().
• PUEDE proporcionar una opción de limpieza de datos rápida que solo realiza un borrado lógico de datos.

9.13. Modo de inicio seguro

Android proporciona el modo de inicio seguro, que permite a los usuarios iniciar el dispositivo en un modo en el que solo se pueden ejecutar las apps del sistema preinstaladas y se inhabilitan todas las apps de terceros. Este modo, conocido como "Modo de inicio seguro", le brinda al usuario la capacidad de desinstalar apps de terceros potencialmente dañinas.

Las implementaciones de dispositivos son las siguientes:

• [SR] SE RECOMIENDA ENFATICAMENTE implementar el modo de inicio seguro.

Si las implementaciones de dispositivos implementan el modo de inicio seguro, hacen lo siguiente:

• [C-1-1] DEBE proporcionarle al usuario una opción para ingresar al modo de inicio seguro de manera ininterrumpida desde las apps de terceros instaladas en el dispositivo, excepto cuando la app de terceros sea un controlador de políticas de dispositivos y haya establecido la marca UserManager.DISALLOW_SAFE_BOOT como verdadera.

• [C-1-2] DEBE proporcionar al usuario la capacidad de desinstalar cualquier app de terceros en el modo seguro.

• DEBE proporcionarle al usuario una opción para ingresar al modo de inicio seguro desde el menú de inicio con un flujo de trabajo diferente al de un inicio normal.

9.14. Aislamiento del sistema de vehículos automotrices

Se espera que los dispositivos Android Automotive intercambien datos con subsistemas críticos del vehículo mediante el HAL del vehículo para enviar y recibir mensajes a través de redes de vehículos, como el bus CAN.

El intercambio de datos se puede proteger mediante la implementación de funciones de seguridad debajo de las capas del framework de Android para evitar la interacción maliciosa o no intencional con estos subsistemas.

9.15. Planes de suscripción

Los “planes de suscripción” se refieren a los detalles del plan de relación de facturación que proporciona un operador de telefonía celular a través de SubscriptionManager.setSubscriptionPlans().

Todas las implementaciones de dispositivos:

• [C-0-1] DEBEN mostrar los planes de suscripción solo en la app del operador de telefonía celular que los proporcionó originalmente.
• [C-0-2] NO DEBE crear copias de seguridad ni subir planes de suscripción de forma remota.
• [C-0-3] SOLO se deben permitir anulaciones, como SubscriptionManager.setSubscriptionOverrideCongested(), desde la app del operador de telefonía celular que actualmente proporciona planes de suscripción válidos.

10. Pruebas de compatibilidad de software

Las implementaciones de dispositivos DEBEN aprobar todas las pruebas que se describen en esta sección. Sin embargo, ten en cuenta que ningún paquete de prueba de software es completamente exhaustivo. Por este motivo, SE RECOMIENDA ENFATICAMENTE que los implementadores de dispositivos realicen la menor cantidad posible de cambios en la implementación de referencia y preferida de Android disponible en el Proyecto de código abierto de Android. Esto minimizará el riesgo de introducir errores que creen incompatibilidades que requieran retrabajos y posibles actualizaciones de dispositivos.

10.1. Conjunto de pruebas de compatibilidad (CTS)

Implementaciones de dispositivos:

• [C-0-1] DEBE aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el proyecto de código abierto de Android con el software de envío final en el dispositivo.

• [C-0-2] DEBE garantizar la compatibilidad en caso de ambigüedades en CTS y para cualquier nueva implementación de partes del código fuente de referencia.

El CTS está diseñado para ejecutarse en un dispositivo real. Al igual que cualquier software, el CTS puede contener errores. El CTS tendrá control de versiones independiente de esta Definición de Compatibilidad, y es posible que se lancen varias revisiones del CTS para Android 9.

Implementaciones de dispositivos:

• [C-0-3] DEBE aprobar la versión más reciente de CTS disponible en el momento en que se completa el software del dispositivo.

• DEBE usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible.

10.2. Verificador del CTS

El verificador del CTS se incluye en el conjunto de pruebas de compatibilidad y está diseñado para que lo ejecute un operador humano para probar la funcionalidad que un sistema automatizado no puede probar, como el funcionamiento correcto de una cámara y sensores.

Implementaciones de dispositivos:

• [C-0-1] DEBE ejecutar correctamente todos los casos aplicables en el verificador de CTS.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluido algunos que son opcionales.

Implementaciones de dispositivos:

• [C-0-2] DEBEN aprobar todas las pruebas de hardware que tengan. Por ejemplo, si un dispositivo tiene un acelerómetro, DEBE ejecutar correctamente el caso de prueba del acelerómetro en el verificador de CTS.

SE PUEDEN OÍR los casos de prueba de las funciones que se indican como opcionales en este documento de definición de compatibilidad.

• [C-0-2] Cada dispositivo y cada compilación DEBEN ejecutar correctamente el verificador de CTS, como se indicó anteriormente. Sin embargo, como muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten explícitamente el verificador de CTS en compilaciones que solo difieren de forma trivial. Específicamente, las implementaciones de dispositivos que difieren de una implementación que pasó el verificador de CTS solo por el conjunto de configuraciones regionales, desarrollo de la marca, etc., PUEDEN omitir la prueba del verificador de CTS.

11. Software actualizable

• [C-0-1] Las implementaciones de dispositivos DEBEN incluir un mecanismo para reemplazar todo el software del sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, es POSIBLE que se requiera reiniciar el dispositivo. Se puede usar cualquier método, siempre y cuando pueda reemplazar todo el software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques satisfará este requisito:

  • Descargas “inalámbricas (OTA)” con actualización sin conexión mediante el reinicio
  • Actualizaciones “con conexión por cable” a través de USB desde una PC host
  • Actualizaciones “sin conexión” mediante un reinicio y una actualización desde un archivo en el almacenamiento extraíble

• [C-0-2] El mecanismo de actualización que se usa DEBE admitir actualizaciones sin borrar los datos del usuario. Es decir, el mecanismo de actualización DEBE preservar los datos privados y compartidos de la aplicación. Ten en cuenta que el software de Android upstream incluye un mecanismo de actualización que satisface este requisito.

Si las implementaciones de dispositivos incluyen compatibilidad con una conexión de datos sin medición, como 802.11 o el perfil de PAN (red de área personal) de Bluetooth, deben cumplir con los siguientes requisitos:

• [C-1-1] DEBE admitir descargas OTA con actualización sin conexión mediante el reinicio.

En el caso de las implementaciones de dispositivos que se inician con Android 6.0 y versiones posteriores, el mecanismo de actualización DEBE admitir la verificación de que la imagen del sistema sea binaria idéntica al resultado esperado después de una actualización inalámbrica. La implementación OTA basada en bloques en el Proyecto de código abierto de Android upstream, que se agregó desde Android 5.1, satisface este requisito.

Además, las implementaciones de dispositivos DEBEN admitir actualizaciones del sistema A/B. El AOSP implementa esta función con el HAL de control de inicio.

Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro de su vida útil razonable, que se determina en consulta con el equipo de compatibilidad de Android, y que afecta la compatibilidad de las aplicaciones de terceros, haz lo siguiente:

• [C-2-1] El implementador del dispositivo DEBE corregir el error mediante una actualización de software disponible que se pueda aplicar según el mecanismo que se acaba de describir.

Android incluye funciones que permiten que la app del propietario del dispositivo (si está presente) controle la instalación de actualizaciones del sistema. Si el subsistema de actualización del sistema para dispositivos informa android.software.device_admin, hará lo siguiente:

• [C-3-1] DEBE implementar el comportamiento descrito 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:

• Documenta el registro de cambios

Para obtener un resumen de los cambios en las secciones de personas, consulta lo siguiente:

1. Introducción
2. Tipos de dispositivos
3. Software
4. Embalaje de la aplicación
5. Multimedia
6. Herramientas y opciones para desarrolladores
7. Compatibilidad con hardware
8. Rendimiento y potencia
9. Modelo de seguridad
10. Pruebas de compatibilidad de software
11. Software actualizable
12. Registro de cambios de documentos
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 obtener una mejor visualización, agrega los parámetros de URL pretty=full y no-merges a las URLs del registro de cambios.

13. Comunícate con nosotros

Puedes unirte al foro de compatibilidad con Android y solicitar aclaraciones o plantear cualquier problema que creas que no se aborda en el documento.