Definición de compatibilidad de Android 7.0 (N)

Índice

1. Introducción

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

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 una organización que desarrolla una solución de hardware o software que ejecuta Android 7.1. Una “implementación de dispositivos” o “implementación” es la solución de hardware y software desarrollada.

Para que se consideren compatibles con Android 7.1, 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á como fuente de autoridad. 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.

2. Tipos de dispositivos

Si bien el proyecto de código abierto de Android se usó en la implementación de una variedad de tipos de dispositivos y factores de forma, muchos aspectos de la arquitectura y los requisitos de compatibilidad se optimizaron para dispositivos de mano. A partir de Android 5.0, el Proyecto de código abierto de Android tiene como objetivo admitir una variedad más amplia de tipos de dispositivos, como se describe en esta sección.

Dispositivo portátil Android hace referencia a una implementación de dispositivo Android que, por lo general, se usa sosteniéndolo en la mano, como reproductores de mp3, teléfonos y tablets. Implementaciones de dispositivos de mano Android:

  • DEBE tener una pantalla táctil incorporada en el dispositivo.
  • DEBEN tener una fuente de alimentación que proporcione movilidad, como una batería.

El dispositivo Android TV 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 descanso" o "a tres metros de distancia"). Dispositivos Android TV:

  • DEBEN tener una pantalla incorporada O incluir un puerto de salida de video, como VGA, HDMI o un puerto inalámbrico para la pantalla.
  • DEBEN declarar las funciones android.software.leanback y android.hardware.type.television.

Dispositivo de reloj Android hace referencia a una implementación de dispositivo Android diseñada para usarse en el cuerpo, tal vez en la muñeca, y que tiene las siguientes características:

  • DEBEN tener una pantalla con una longitud diagonal física de entre 1.1 y 2.5 pulgadas.
  • DEBE declarar la función android.hardware.type.watch.
  • DEBE admitir uiMode = UI_MODE_TYPE_WATCH .

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

  • DEBE tener una pantalla con una longitud diagonal física igual o superior a 15.2 cm (6 pulgadas).
  • DEBE declarar la función android.hardware.type.automotive.
  • DEBE admitir uiMode = UI_MODE_TYPE_CAR .
  • Las implementaciones de Android Automotive DEBEN admitir todas las APIs públicas del espacio de nombres android.car.*.

Todas las implementaciones de dispositivos Android que no se ajusten a ninguno de los tipos de dispositivos anteriores DEBEN cumplir con todos los requisitos de este documento para ser compatibles con Android 7.1, a menos que se describa explícitamente que el requisito solo se aplica a un tipo de dispositivo Android específico de los mencionados anteriormente.

2.1 Configuraciones de dispositivos

Este es un resumen de las principales diferencias en la configuración de hardware según el tipo de dispositivo. (Las celdas vacías indican que es “POSIBLE”). No se incluyen todas las configuraciones en esta tabla. Consulta las secciones de hardware relevantes para obtener más detalles.

Categoría Función Sección Dispositivo manual Televisión Mirar Automóviles Otro
Entrada Pad direccional 7.2.2. Navegación sin tacto DEBER
Pantalla táctil 7.2.4. Entrada táctil DEBER DEBER DEBE
Micrófono 7.8.1. Micrófono DEBER DEBE DEBER DEBER DEBE
Sensores Acelerómetro 7.3.1 Acelerómetro DEBE DEBE DEBE
GPS 7.3.3. GPS DEBE DEBE
Conectividad Wi-Fi 7.4.2. IEEE 802.11 DEBE DEBE DEBE DEBE
Wi-Fi directo 7.4.2.1. Wi-Fi Direct DEBE DEBE DEBE
Bluetooth 7.4.3. Bluetooth DEBE DEBER DEBER DEBER DEBE
Bluetooth de bajo consumo 7.4.3. Bluetooth DEBE DEBER DEBE DEBE DEBE
Radio móvil 7.4.5. Capacidad de red mínima DEBE
Modo periférico o host USB 7.7. USB DEBE DEBE DEBE
Salida Puertos de salida de audio o bocinas 7.8.2. Salida de audio DEBER DEBER DEBER DEBER

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

Las implementaciones de dispositivos DEBEN admitir o preservar todas las clases, métodos y elementos asociados marcados con la anotación TestApi (@TestApi).

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

Esta definición de compatibilidad permite que las implementaciones de dispositivos omitan algunos tipos de hardware para los que Android incluye APIs. En esos casos, las APIs DEBEN seguir presentes y comportarse de manera razonable. Consulta la sección 7 para conocer los requisitos específicos de esta situación.

3.1.1. Extensiones de Android

Android incluye la compatibilidad para extender las APIs administradas y mantener la misma versión del nivel de API. 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.2. Compatibilidad de API flexible

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

3.2.1. Permisos

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. 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 7.1 .
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 7.1, este campo DEBE tener el valor de número entero 7.1_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 7.1, este campo DEBE tener el valor de número entero 7.1_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 para identificar 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. DEBE estar en un formato legible por humanos y DEBE representar al fabricante del dispositivo o la marca de la empresa con la que se comercializa el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa .
SUPPORTED_32_BIT_ABIS Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa .
SUPPORTED_64_BIT_ABIS Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa .
CPU_ABI Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa .
CPU_ABI2 Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa .
DISPOSITIVO Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código que identifica la configuración de las funciones de hardware y el diseño industrial del dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular “^[a-zA-Z0-9_-]+$”. Este nombre de dispositivo NO DEBE cambiar durante la vida útil del producto.
FINGERPRINT Es una cadena que identifica de forma 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:7.1/LMYXX/3359:userdebug/test-keys

La huella digital NO DEBE incluir caracteres de espacio en blanco. Si otros campos incluidos en la plantilla anterior tienen caracteres de espacio en blanco, DEBEN reemplazarse en la huella 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 ("").
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 ("").
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 su ciclo de vida.
SERIAL 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]{6,20})$”.
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 documentada 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 ("").

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. Las aplicaciones principales de Android son las siguientes:

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

Las implementaciones de dispositivos DEBEN incluir las aplicaciones principales de Android según corresponda o un componente que implemente los mismos patrones de intents definidos por todos los componentes de actividad o servicio de estas aplicaciones principales de Android expuestos a otras aplicaciones, de forma implícita o explícita, a través del atributo android:exported.

3.2.3.2. Resolución de intents

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. La implementación de código abierto de Android upstream lo permite de forma predeterminada. Los implementadores de dispositivos NO DEBEN adjuntar privilegios especiales al uso de estos patrones de intents por parte de las aplicaciones del sistema ni impedir que las aplicaciones de terceros se vinculen a estos patrones y asuman el control de ellos. Esta prohibición incluye específicamente, entre otras, la inhabilitación de la interfaz de usuario "Selector" que permite al usuario elegir entre varias aplicaciones que controlan el mismo patrón de intent.

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:

  • 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.
  • DEBEN intentar validar los filtros de intents durante la instalación de la aplicación y establecer todos los filtros de intents de UIR validados correctamente como controladores de apps predeterminados para sus UIR.
  • 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:
    • El usuario DEBE poder anular de forma integral el comportamiento predeterminado de los vínculos de la app para que esta 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.
    • 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.
    • La implementación del dispositivo DEBE proporcionar a los usuarios la capacidad de ver y anular filtros de intents de URI candidato específicos si la implementación del dispositivo permite que algunos filtros de intents de URI candidato tengan éxito en la verificación, mientras que otros pueden fallar.

3.2.3.3. Espacios de nombres de intents

Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que respete ningún intent nuevo o patrones de intents de transmisión con una ACTION, CATEGORY o alguna otra cadena clave en el espacio de nombres android. o com.android. 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. 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. Los dispositivos compatibles con Android DEBEN transmitir los intents de transmisión pública en respuesta a los eventos del sistema adecuados. Los intents de transmisión se describen en la documentación del SDK.

3.2.3.5. Configuración predeterminada de la app

Android incluye parámetros de configuración que 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.

Implementaciones de dispositivos:

  • DEBE respetar el intent android.settings.HOME_SETTINGS para mostrar un menú de configuración de app predeterminado para la pantalla principal, si la implementación del dispositivo informa android.software.home_screen.
  • 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, si la implementación del dispositivo informa android.hardware.telephony.
  • DEBE respetar el intent android.settings.NFC_PAYMENT_SETTINGS para mostrar un menú de configuración de la app predeterminado para el pago sin contacto, si la implementación del dispositivo informa android.hardware.nfc.hce.
  • 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, si la implementación del dispositivo informa android.hardware.telephony .
  • DEBE respetar el intent android.settings.ACTION_VOICE_INPUT_SETTINGS cuando el dispositivo admita VoiceInteractionService y muestre un menú de configuración predeterminado de la app para la entrada de voz y la asistencia.

3.3. Compatibilidad con la API nativa

La compatibilidad con el código nativo es un desafío. Por este motivo, se RECOMIENDA ENFATICAMENTE que los implementadores de dispositivos usen 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. Las implementaciones de dispositivos DEBEN ser compatibles con una o más ABI definidas y DEBEN implementar la compatibilidad con el NDK de Android, como se indica a continuación.

Si una implementación de dispositivo incluye compatibilidad con una ABI de Android, hace lo siguiente:

  • DEBEN 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).
  • DEBEN ser compatibles con el código fuente (es decir, compatibles con el encabezado) y con objetos binarios (para la ABI) con cada biblioteca requerida de la siguiente lista.
  • DEBE admitir la ABI de 32 bits equivalente si se admite alguna ABI de 64 bits.
  • 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 de ABI separadas por comas ordenadas de la más a la menos preferida.
  • DEBEN informar, a través de los parámetros anteriores, solo las ABI documentadas y descritas en la versión más reciente de la documentación de administración de ABI del NDK de Android y DEBEN incluir compatibilidad con la extensión Advanced SIMD (también conocida como NEON).
  • 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 las versiones futuras del NDK de Android pueden admitir ABI adicionales. Si una implementación de dispositivo no es compatible con una ABI predefinida existente, NO DEBE informar la compatibilidad con ninguna ABI.

Las siguientes APIs de código nativo DEBEN estar disponibles para las apps que incluyen código nativo:

  • 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)
  • 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
  • Compatibilidad con OpenGL, como se describe a continuación

En el caso de las bibliotecas nativas mencionadas anteriormente, la implementación del dispositivo NO DEBE agregar ni quitar las funciones públicas.

Las bibliotecas nativas que no se enumeran anteriormente, pero que se implementan y proporcionan en AOSP como bibliotecas del sistema, están reservadas y NO DEBEN exponerse a apps de terceros que se orienten al nivel de API 24 o versiones posteriores.

Las implementaciones de dispositivos PUEDEN agregar bibliotecas que no sean de AOSP y exponerlas directamente como una API a apps de terceros, pero las bibliotecas adicionales DEBEN estar en /vendor/lib o /vendor/lib64 y DEBEN aparecer en /vendor/etc/public.libraries.txt .

Ten en cuenta que las implementaciones de dispositivos DEBEN incluir libGLESv3.so y, a su vez, DEBEN exportar todos los símbolos de función de OpenGL ES 3.1 y el Android Extension Pack como se define en la versión android-24 del NDK. Aunque todos los símbolos deben estar presentes, solo se deben implementar por completo las funciones correspondientes para las versiones y extensiones de OpenGL ES que realmente admite el dispositivo.

3.3.1.1. Bibliotecas de gráficos

Vulkan es una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento. Las implementaciones de dispositivos, incluso si no incluyen compatibilidad con las APIs de Vulkan, DEBEN satisfacer los siguientes requisitos:

  • SIEMPRE debe proporcionar una biblioteca nativa llamada libvulkan.so que exporte símbolos de función para la API principal de Vulkan 1.0 , así como las extensiones VK_KHR_surface , VK_KHR_android_surface y VK_KHR_swapchain.

Implementaciones de dispositivos, si incluyen compatibilidad con las APIs de Vulkan:

  • DEBE informar uno o más VkPhysicalDevices a través de la llamada a vkEnumeratePhysicalDevices.
  • Cada VkPhysicalDevices enumerado DEBE implementar completamente la API de Vulkan 1.0.
  • DEBEN informar las marcas de funciones PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL y PackageManager#FEATURE_VULKAN_HARDWARE_VERSION correctas.
  • DEBEN enumerar las capas contenidas en las bibliotecas nativas llamadas libVkLayer*.so en el directorio de bibliotecas nativas del paquete de la aplicación a través de las funciones vkEnumerateInstanceLayerProperties y vkEnumerateDeviceLayerProperties en libvulkan.so.
  • 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=”true”.

Implementaciones de dispositivos, si no incluyen compatibilidad con las APIs de Vulkan:

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

La arquitectura ARMv8 da de baja varias operaciones de la CPU, incluidas algunas que se usan en el código nativo existente. En dispositivos ARM de 64 bits, las siguientes operaciones obsoletas DEBEN permanecer disponibles para el código ARM nativo de 32 bits, 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 de CP15ISB, CP15DSB y CP15DMB

Las versiones heredadas del NDK de Android usaban /proc/cpuinfo para descubrir las funciones de la CPU desde el código nativo ARM de 32 bits. Para garantizar la compatibilidad con las aplicaciones compiladas con este NDK, los dispositivos DEBEN incluir las siguientes líneas en /proc/cpuinfo cuando las aplicaciones ARM de 32 bits las 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 alta compatible del dispositivo (p.ej., “8” para dispositivos ARMv8).

Estos requisitos solo se aplican cuando las aplicaciones ARM de 32 bits leen /proc/cpuinfo. Los dispositivos NO DEBEN alterar /proc/cpuinfo cuando lo leen aplicaciones ARM o no ARM de 64 bits.

3.4. Compatibilidad web

3.4.1. Compatibilidad con WebView

Los dispositivos Android Watch PUEDEN, pero todas las demás implementaciones de dispositivos DEBEN proporcionar una implementación completa de la API de android.webkit.Webview.

La función de plataforma android.software.webview DEBE informarse en cualquier dispositivo que proporcione una implementación completa de la API de android.webkit.WebView y NO DEBE informarse en dispositivos sin una implementación completa de la API. La implementación de código abierto de Android usa código del proyecto Chromium para implementar android.webkit.WebView . Debido a que no es factible desarrollar un paquete de pruebas integral para un sistema de renderización web, los implementadores de dispositivos DEBEN usar la compilación upstream específica de Chromium en la implementación de WebView. Más precisamente:

  • Las implementaciones de android.webkit.WebView del dispositivo DEBEN basarse en la compilación de Chromium del proyecto de código abierto de Android upstream para Android 7.1. Esta compilación incluye un conjunto específico de correcciones de funcionalidad y seguridad para WebView.

  • La cadena de usuario-agente que informa WebView DEBE tener el siguiente 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.
    • El valor de la cadena $(MODEL) DEBE ser el mismo que el valor de android.os.Build.MODEL.
    • El valor de la cadena $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID.
    • El valor de la cadena $(CHROMIUM_VER) DEBE ser la versión de Chromium en el proyecto de código abierto de Android 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

Las implementaciones de Android Television, Watch y Android Automotive PUEDEN omitir una aplicación de navegador, pero DEBEN admitir los patrones de intents públicos como se describe en la sección 3.2.3.1 . Todos los demás tipos de implementaciones de dispositivos DEBEN incluir una aplicación de navegador independiente para la navegación web general del usuario.

El navegador independiente PUEDE basarse en una tecnología de navegador que no sea WebKit. Sin embargo, incluso si se usa una aplicación de navegador alternativa, el componente android.webkit.WebView proporcionado a las aplicaciones de terceros DEBE basarse en WebKit, como se describe en la sección 3.4.1 .

Las implementaciones PUEDEN enviar una cadena de usuario-agente personalizada en la aplicación independiente del navegador.

La aplicación de navegador independiente (ya sea basada en la aplicación de navegador WebKit upstream o en un reemplazo de terceros) DEBE incluir compatibilidad con la mayor cantidad posible de HTML5. Como mínimo, las implementaciones de dispositivos DEBEN admitir cada una de estas APIs asociadas con HTML5:

Además, las implementaciones de dispositivos DEBEN admitir la API de webstorage de HTML5/W3C y DEBEN admitir la API de IndexedDB de HTML5/W3C . Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer IndexedDB en lugar de webstorage, se espera que IndexedDB se convierta en un componente obligatorio en una versión futura de Android.

3.5. Compatibilidad de comportamiento de la API

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:

  • Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un intent estándar.
  • 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.).
  • Los dispositivos NO DEBEN cambiar la semántica de un permiso estándar.

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.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.*
  • com.android.*

Entre las modificaciones prohibidas, se incluyen las siguientes :

  • Las implementaciones de dispositivos NO DEBEN 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.
  • Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las APIs, pero esas modificaciones NO DEBEN afectar el comportamiento declarado ni la firma en lenguaje Java de ninguna API expuesta públicamente.
  • Los implementadores de dispositivos NO DEBEN agregar ningún elemento expuesto públicamente (como clases o interfaces, o campos o métodos a clases o interfaces existentes) a las APIs 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. En otras palabras, los implementadores de dispositivos NO DEBEN exponer APIs nuevas ni alterar las APIs existentes en los espacios de nombres mencionados anteriormente. Los implementadores de dispositivos PUEDEN realizar modificaciones solo internas, pero esas modificaciones NO DEBEN promocionarse ni exponerse a los desarrolladores.

Los implementadores de dispositivos PUEDEN agregar APIs personalizadas, pero estas NO DEBEN estar en un espacio de nombres que pertenezca a otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* o a uno similar: solo Google puede hacerlo. Del mismo modo, Google NO DEBE agregar APIs a los espacios de nombres de otras empresas. Además, si una implementación de dispositivo incluye APIs personalizadas fuera del espacio de nombres estándar de Android, esas APIs 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

Las implementaciones de dispositivos DEBEN admitir el formato Dalvik Executable (DEX) completo y la especificación y semántica del código de bytes de Dalvik . Los implementadores de dispositivos DEBEN usar ART, la implementación ascendente de referencia del Formato ejecutable de Dalvik y el sistema de administración de paquetes de la implementación de referencia.

Las implementaciones de dispositivos DEBEN 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). 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 (560dpi) 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 (560dpi) 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 (560dpi) 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 (560dpi) 576 MB
640 dpi (xxxhdpi) 768 MB

3.8. Compatibilidad de la interfaz de usuario

3.8.1. Selector (pantalla principal)

Android incluye una aplicación de selector (pantalla principal) y compatibilidad con aplicaciones de terceros para reemplazar el selector del dispositivo (pantalla principal). Las implementaciones de dispositivos que permiten que aplicaciones de terceros reemplacen la pantalla principal del dispositivo DEBEN declarar la función de plataforma android.software.home_screen.

3.8.2. Widgets

Los widgets son opcionales para todas las implementaciones de dispositivos Android, pero DEBEN ser compatibles con los dispositivos portátiles Android.

Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten que las aplicaciones expongan un "AppWidget" al usuario final, una función que SE RECOMIENDA ENFATICAMENTE que se admita en las implementaciones de dispositivos de mano. Las implementaciones de dispositivos que admiten la incorporación de widgets en la pantalla principal DEBEN cumplir con los siguientes requisitos y declarar la compatibilidad con la función de plataforma android.software.app_widgets.

  • Los selectores de dispositivos DEBEN incluir compatibilidad integrada con AppWidgets y exponer indicaciones de la interfaz de usuario para agregar, configurar, ver y quitar AppWidgets directamente desde el selector.
  • Las implementaciones de dispositivos DEBEN ser capaces 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.
  • Es POSIBLE que las implementaciones de dispositivos que incluyen compatibilidad con la pantalla de bloqueo admitan widgets de aplicaciones en la pantalla de bloqueo.

3.8.3. Notificaciones

Android incluye APIs que permiten a los desarrolladores notificar a los usuarios sobre eventos importantes con las funciones de hardware y software del dispositivo.

Algunas APIs permiten que las aplicaciones realicen notificaciones o atraigan la atención con hardware, específicamente, sonido, vibración y luz. Las implementaciones de dispositivos DEBEN 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 .

Además, la implementación DEBE renderizar correctamente todos los recursos (íconos, archivos de animación, etcétera) que se proporcionan en las APIs o en la guía de estilo de íconos de la barra de estado o del sistema, que, en el caso de un dispositivo Android TV, incluye la posibilidad de no mostrar las notificaciones. Los implementadores de dispositivos PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de referencia de Android Open Source. Sin embargo, esos sistemas de notificaciones alternativos DEBEN admitir los recursos de notificaciones existentes, como se indicó anteriormente.

Las implementaciones de Android Automotive PUEDEN administrar la visibilidad y el tiempo de las notificaciones para mitigar la distracción del conductor, pero DEBEN mostrar notificaciones que usen CarExtender cuando las aplicaciones lo soliciten.

Android incluye compatibilidad con varias notificaciones, como las siguientes:

  • Notificaciones enriquecidas . Vistas interactivas para notificaciones continuas
  • Notificaciones de atención . Los usuarios pueden interactuar con las vistas interactivas o descartarlas sin salir de la app actual.
  • Notificaciones en la pantalla de bloqueo . Notificaciones que se muestran en una pantalla de bloqueo con control detallado de la visibilidad.

Cuando esas notificaciones se hacen visibles, las implementaciones de dispositivos Android DEBEN ejecutar correctamente las notificaciones enriquecidas y emergentes, y deben incluir el título o el nombre, el ícono y el texto como se documenta en las APIs de Android .

Android incluye APIs del servicio de detector de notificaciones 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. Las implementaciones de dispositivos DEBEN enviar notificaciones completas de forma correcta y oportuna a todos los servicios de objeto de escucha instalados y habilitados por el usuario, incluidos todos los metadatos adjuntos al objeto de notificación.

Las implementaciones de dispositivos de mano DEBEN admitir los comportamientos de actualización, eliminación, respuesta y agrupación de notificaciones, como se describe en esta sección .

Además, las implementaciones de dispositivos de mano DEBEN proporcionar lo siguiente:

  • La capacidad de controlar las notificaciones directamente en la cortina de notificaciones
  • El indicador visual para activar el panel de control en la pantalla de notificaciones.
  • La capacidad de BLOQUEAR, SILENCIAR y RESTAURAR la preferencia de notificación desde un paquete, tanto en el panel de control intercalado como en la app de configuración

TODAS las 6 subclases directas de Notification.Style class DEBEN ser compatibles, como se describe en los documentos del SDK .

Las implementaciones de dispositivos que admiten la función No interrumpir DEBEN cumplir con los siguientes requisitos:

  • 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.
  • DEBEN 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.
  • DEBEN 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.

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. Las implementaciones de dispositivos DEBEN implementar las APIs que permiten a los desarrolladores reutilizar esta interfaz de usuario para proporcionar búsquedas en sus propias aplicaciones. Las implementaciones de dispositivos que implementan la interfaz de búsqueda global DEBEN 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 esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar resultados y sugerencias de motores de búsqueda web.

Las implementaciones de dispositivos Android DEBEN implementar un asistente en el dispositivo para controlar la acción de asistencia .

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. Las implementaciones de dispositivos que admiten la acción de Asistente DEBEN indicar claramente al usuario final cuando se comparte el contexto mostrando una luz blanca alrededor de los bordes de la pantalla. Para garantizar una visibilidad clara para el usuario final, la indicación DEBE cumplir o superar la duración y el brillo de la implementación del proyecto de código abierto de Android.

Esta indicación PUEDE estar inhabilitada de forma predeterminada para las apps preinstaladas que usan la API de Assist y VoiceInteractionService si se cumplen todos los siguientes requisitos:

  • La app preinstalada DEBE solicitar que se comparta el contexto solo cuando el usuario la invoque por uno de los siguientes medios y la app se esté ejecutando en primer plano:

    • Invocación de palabra clave
    • entrada de la tecla, el botón o el gesto de navegación de ASSIST

  • La implementación del dispositivo DEBE proporcionar una indicación para habilitar la indicación, a menos de dos navegaciones de la sección 3.2.3.5 (el menú de configuración predeterminado de la entrada de voz y la app del asistente).

3.8.5. Avisos

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. Las implementaciones de dispositivos DEBEN mostrar notificaciones emergentes 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" como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si desean que coincidan con el aspecto y estilo del tema Holo, tal como lo define el SDK de Android. Las implementaciones de dispositivos NO DEBEN alterar ninguno de los atributos del tema de Holo expuestos a las aplicaciones.

Android incluye una familia de temas "Material" como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si desean que el aspecto del tema de diseño coincida con la amplia variedad de diferentes tipos de dispositivos Android. Las implementaciones de dispositivos DEBEN admitir la familia de temas "Material" y NO DEBEN alterar ninguno de los atributos del tema de Material ni sus recursos expuestos a las aplicaciones.

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. Por lo tanto, las implementaciones de dispositivos Android 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. Cuando una app solicita una barra de estado clara, 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).

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. Los fondos de pantalla animados no se ejecutarán de forma confiable en hardware que no admita varios contextos de OpenGL, ya que el uso de un contexto de OpenGL en el fondo de pantalla animado 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 y, cuando se implementen, DEBEN informar la marca de función de la plataforma android.software.live_wallpaper.

3.8.8. Cambio de actividad

Como la tecla de navegación de la función Recientes es OPCIONAL, el requisito de implementar la pantalla de descripción general es OPCIONAL para las implementaciones de Android Watch y Android Automotive, y RECOMENDABLE para los dispositivos Android Television. DEBERÍA haber un método para cambiar entre actividades en las implementaciones de Android Automotive.

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. Las implementaciones de dispositivos que incluyen la tecla de navegación de la función Recientes, como se detalla en la sección 7.2.3, PUEDEN alterar la interfaz, pero DEBEN cumplir con los siguientes requisitos:

  • DEBE admitir al menos 20 actividades mostradas.
  • DEBE mostrar al menos el título de 4 actividades a la vez.
  • DEBEN 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.
  • PUEDE mostrar contenido reciente afiliado como un grupo que se mueve junto.
  • 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.

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos usen 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. Las implementaciones de dispositivos que permiten que los usuarios usen métodos de entrada de terceros DEBEN 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.

Las implementaciones de dispositivos que declaran la función android.software.input_methods DEBEN proporcionar un mecanismo accesible para el usuario para agregar y configurar métodos de entrada de terceros. Las implementaciones de dispositivos DEBEN mostrar la interfaz de configuración en respuesta al intent android.settings.INPUT_METHOD_SETTINGS.

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. Las implementaciones de dispositivos que admiten una pantalla de bloqueo, a menos que sean de Android Automotive o de reloj, DEBEN mostrar las notificaciones de la pantalla de bloqueo, incluida la plantilla de notificación multimedia.

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

Cuando un dispositivo tiene un sensor de hardware (p.ej., GPS) que puede proporcionar las coordenadas de ubicación, los modos de ubicación DEBEN mostrarse 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 9.0 . Todas las implementaciones de dispositivos DEBEN ser capaces de renderizar estos caracteres de emojis en glifos de color y, cuando las implementaciones de dispositivos Android incluyen un IME, DEBEN proporcionar un método de entrada al usuario para estos caracteres de emojis.

Los dispositivos de mano Android DEBEN admitir el tono de piel y los diversos emojis de familia, como se especifica en el Informe técnico Unicode n° 51 .

Android incluye compatibilidad con la fuente Roboto 2 con diferentes grosores (sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light), que DEBEN incluirse para los idiomas disponibles en el dispositivo y la cobertura completa de Unicode 7.0 de los idiomas latín, griego y cirílico, incluidos los rangos A, B, C y D de latín extendido, y todos los glifos del bloque de símbolos de moneda de Unicode 7.0.

3.8.14. Multiventanas

Una implementación de dispositivo PUEDE optar por no implementar ningún modo multiventana, pero si tiene la capacidad de mostrar varias actividades al mismo tiempo, DEBE 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:

  • Las aplicaciones pueden indicar si son capaces de operar en el modo multiventana en el archivo AndroidManifest.xml, ya sea de forma explícita a través del atributo android:resizeableActivity o de forma implícita si tienen targetSdkVersion > 24. Las apps que establezcan explícitamente este atributo como falso en su manifiesto NO DEBEN iniciarse en el modo multiventana. Las apps que no establecen el atributo en su archivo de manifiesto (targetSdkVersion < 24) se pueden iniciar 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.
  • Las implementaciones de dispositivos NO DEBEN ofrecer el modo de pantalla dividida ni de forma libre si la altura y el ancho de la pantalla son inferiores a 440 dp.
  • Las implementaciones de dispositivos con tamaño de pantalla xlarge DEBEN admitir el modo de formato libre.
  • Las implementaciones de dispositivos Android TV DEBEN admitir el modo multiventana de pantalla en pantalla (PIP) y colocar la ventana multiventana de PIP en la esquina superior derecha cuando el PIP esté ACTIVADO.
  • Las implementaciones de dispositivos con compatibilidad con el modo multiventana de PIP DEBEN asignar al menos 240 x 135 dp para la ventana de PIP.
  • Si se admite el modo multiventana de PIP, la clave KeyEvent.KEYCODE_WINDOW DEBE usarse para controlar la ventana de PIP. De lo contrario, la clave DEBE estar disponible para la actividad en primer plano.

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 de Android. Las implementaciones de dispositivos DEBEN proporcionar una implementación de la clase DevicePolicyManager. Las implementaciones de dispositivos que admiten una pantalla de bloqueo segura DEBEN implementar la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android y, además, informar la función de plataforma android.software.device_admin.

3.9.1 Aprovisionamiento de dispositivos

3.9.1.1 Aprovisionamiento del propietario del dispositivo

Si una implementación de dispositivo declara la función android.software.device_admin, DEBE implementar el aprovisionamiento de la app del propietario del dispositivo de una aplicación de cliente de política de dispositivo (DPC) como se indica a continuación:

Las implementaciones de dispositivos PUEDEN tener una aplicación preinstalada que realice funciones de administración de dispositivos, pero esta aplicación NO DEBE configurarse como la app del propietario del dispositivo sin el consentimiento explícito o la acción del usuario o el administrador del dispositivo.

3.9.1.2 Aprovisionamiento de perfiles administrados

Si una implementación de dispositivo declara android.software.managed_users, DEBE ser posible inscribir una aplicación de controlador de política de dispositivo (DPC) como el propietario de un nuevo perfil administrado .

La experiencia del usuario 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.

Las implementaciones de dispositivos DEBEN proporcionar los siguientes indicadores visuales para el usuario en la interfaz de usuario de Configuración para indicarle al usuario cuando el controlador de políticas de dispositivos (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
  • Es 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

Los dispositivos compatibles con perfiles administrados son aquellos que cumplen con los siguientes requisitos:

Los dispositivos compatibles con perfiles administrados DEBEN cumplir con los siguientes requisitos:

  • Declara la marca de función de la plataforma android.software.managed_users .
  • Admite perfiles administrados a través de las APIs de android.app.admin.DevicePolicyManager.
  • Permite que se cree un solo perfil administrado .
  • Usa una insignia de ícono (similar a la insignia de trabajo upstream de AOSP) para representar las aplicaciones y los widgets administrados, y otros elementos de la IU con insignias, como Recientes y Notificaciones.
  • Muestra 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.
  • Muestra un aviso que indica 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.
  • Cuando exista un perfil administrado, muestra 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.
  • Cuando exista un perfil administrado, expone las siguientes indicaciones visuales para el usuario tanto del usuario principal como del 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
  • Asegúrate de que el selector de llamadas, 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. 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.
  • DEBEN garantizar que satisfaga todos los requisitos de seguridad aplicables a un dispositivo con varios usuarios habilitados (consulta la sección 9.5), aunque el perfil administrado no se cuente como otro usuario además del usuario principal.
  • Admite 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 .

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.

Las implementaciones de dispositivos incluyen los siguientes requisitos:

  • Las implementaciones de Android Automotive DEBEN proporcionar una implementación del framework de accesibilidad de Android coherente con la implementación predeterminada de Android.
  • Las implementaciones de dispositivos (se excluye Android Automotive) DEBEN proporcionar una implementación del framework de accesibilidad de Android coherente con la implementación predeterminada de Android.
  • Las implementaciones de dispositivos (se excluye Android Automotive) DEBEN admitir implementaciones de servicios de accesibilidad de terceros a través de las APIs de android.accessibilityservice .
  • Las implementaciones de dispositivos (se excluye Android Automotive) DEBEN generar AccessibilityEvents y entregar estos eventos a todas las implementaciones de AccessibilityService registradas de una manera coherente con la implementación predeterminada de Android.

  • Las implementaciones de dispositivos (se excluyen los dispositivos Android Automotive y Android Watch sin salida de audio) DEBEN proporcionar un mecanismo accesible para el usuario para habilitar y deshabilitar los servicios de accesibilidad, y DEBEN mostrar esta interfaz en respuesta al intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

  • SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos Android con salida de audio proporcionen implementaciones de servicios de accesibilidad en el dispositivo comparables o superiores a la funcionalidad de los servicios de accesibilidad de TalkBack** y Accesibilidad con interruptores (https://github.com/google/talkback).

  • Los dispositivos Android Watch con salida de audio DEBEN proporcionar implementaciones de un servicio de accesibilidad en el dispositivo comparable o superior en funcionalidad al servicio de accesibilidad de TalkBack (https://github.com/google/talkback).
  • Las implementaciones de dispositivos DEBEN 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.

** Para idiomas compatibles con Texto a voz.

Además, ten en cuenta que, si hay un servicio de accesibilidad precargado, DEBE ser una app compatible con el inicio directo {directBootAware} si el dispositivo tiene almacenamiento encriptado con encriptación basada en archivos (FBE).

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. Las implementaciones de dispositivos que informan la función android.hardware.audio.output DEBEN cumplir con estos requisitos relacionados con el framework de TTS de Android .

Implementaciones de Android Automotive:

  • DEBEN admitir las APIs del framework de TTS de Android.
  • PUEDE admitir la instalación de motores de TTS de terceros. Si es compatible, los socios DEBEN proporcionar una interfaz accesible para el usuario que le permita seleccionar un motor de TTS para usarlo a nivel del sistema.

Todas las demás implementaciones de dispositivos:

  • DEBEN admitir las APIs del framework de TTS de Android y DEBEN incluir un motor de TTS que admita los idiomas disponibles en el dispositivo. Ten en cuenta que el software de código abierto de Android upstream incluye una implementación del motor de TTS con todas las funciones.
  • DEBE admitir la instalación de motores de TTS de terceros.
  • DEBEN proporcionar una interfaz accesible para el usuario que les permita seleccionar 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. Las implementaciones de dispositivos Android TV DEBEN admitir el framework de entrada de TV.

Las implementaciones de dispositivos que admiten TIF DEBEN declarar la función de plataforma android.software.live_tv.

3.12.1. App para TV

Cualquier implementación de dispositivo que declare compatibilidad con la TV en vivo DEBE tener instalada una aplicación de TV (app para TV). El Proyecto de código abierto de Android proporciona una implementación de la app para TV.

La app para TV DEBE proporcionar herramientas para instalar y usar canales de TV y cumplir con los siguientes requisitos:

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

3.12.1.1. Guía electrónica de programas

Las implementaciones de dispositivos Android TV DEBEN mostrar una superposición informativa e interactiva, que DEBE incluir una guía de programas electrónicos (EPG) generada a partir de los valores de los campos TvContract.Programs. El EPG DEBE cumplir con los siguientes requisitos:

  • El EPG DEBE mostrar información de todas las entradas instaladas y de terceros.
  • El EPG PUEDE proporcionar una separación visual entre las entradas instaladas y las de terceros.
  • SE RECOMIENDA ENFATICAMENTE que el EPG muestre las entradas instaladas y de terceros con la misma importancia. El EPG NO DEBE mostrar las entradas de terceros a más de una acción de navegación de las entradas instaladas en el EPG.
  • Cuando se cambia de canal, las implementaciones de dispositivos DEBEN mostrar los datos del EPG del programa que se está reproduciendo.

3.12.1.2. Navegación

La app para TV DEBE permitir la navegación por las siguientes funciones a través de las teclas del pad direccional, Atrás y Inicio en los dispositivos de entrada del dispositivo Android TV (es decir, control remoto, aplicación de control remoto o control de juegos):

  • Cómo cambiar canales de TV
  • Cómo abrir el EPG
  • Cómo configurar y ajustar entradas TIF de terceros
  • Cómo abrir el menú de configuración

La app para TV DEBE pasar eventos de teclas a las entradas HDMI a través de CEC.

3.12.1.3. Vinculación de apps de entrada de TV

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

3.12.1.4. Cambio de tiempo

Las implementaciones de dispositivos Android TV DEBEN admitir la pausa en directo, que permite al usuario pausar y reanudar el contenido en vivo. Las implementaciones de dispositivos DEBEN proporcionar al usuario una forma de pausar y reanudar el programa que se está reproduciendo, si el cambio de hora para ese programa está disponible .

3.12.1.5. Grabación de TV

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos Android TV admitan la grabación de TV. Si la entrada de TV admite la grabación, es POSIBLE que el EPG proporcione una forma de grabar un programa si la grabación de ese programa no está prohibida . Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario para reproducir programas grabados.

3.13. Configuración rápida

Las implementaciones de dispositivos Android DEBEN incluir un componente de IU de Configuración rápida que permita un acceso rápido a las acciones que se usan con frecuencia o que se necesitan con urgencia.

Android incluye la API de quicksettings, que permite que las apps de terceros implementen tarjetas que el usuario puede agregar junto con las tarjetas proporcionadas por el sistema en el componente de la IU de Configuración rápida. Si una implementación de dispositivo tiene un componente de IU de Configuración rápida, hace lo siguiente:

  • DEBEN permitir que el usuario agregue o quite tarjetas de una app de terceros a la Configuración rápida.
  • NO DEBE agregar automáticamente una tarjeta de una app de terceros directamente a la Configuración rápida.
  • DEBEN 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. APIs de la IU del vehículo

3.14.1. IU de contenido multimedia del vehículo

Cualquier implementación de dispositivo que declare compatibilidad con Automotive DEBE incluir un framework de IU para admitir apps de terceros que consuman las APIs de MediaBrowser y MediaSession.

El framework de IU que admite apps de terceros que dependen de MediaBrowser y MediaSession tiene los siguientes requisitos visuales:

  • DEBEN mostrar los íconos de MediaItem y los íconos de notificaciones sin modificaciones.
  • DEBEN mostrar esos elementos como lo describe MediaSession, p.ej., metadatos, íconos e imágenes.
  • DEBE mostrar el título de la app.
  • DEBE tener un panel lateral para presentar la jerarquía de MediaBrowser.

4. Compatibilidad de empaquetado de aplicaciones

Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android como los genera la herramienta "aapt" incluida en el SDK oficial de Android . Por este motivo, las implementaciones de dispositivos DEBEN usar el sistema de administración de paquetes de la implementación de referencia.

El administrador de paquetes DEBE admitir la verificación de archivos ".apk" con el Esquema de firma de APK v2 y la firma de JAR .

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

Las implementaciones de dispositivos NO DEBEN permitir que apps que no sean el "instalador de registro" actual del paquete desinstalen la app en silencio sin ningún mensaje, como se documenta en el SDK para el permiso DELETE_PACKAGE. Las únicas excepciones son la app del verificador de paquetes del sistema que controla el intent PACKAGE_NEEDS_VERIFICATION y la app del administrador de almacenamiento que controla el intent ACTION_MANAGE_STORAGE.

5. Compatibilidad multimedia

5.1. Códecs multimedia

Implementaciones de dispositivos:

  • DEBEN admitir los formatos multimedia principales especificados en la documentación del SDK de Android, excepto cuando se permita de forma explícita en este documento.

  • DEBEN admitir los formatos multimedia, los codificadores, los decodificadores, los tipos de archivos y los formatos de contenedor definidos en las tablas que se indican a continuación y que se informan a través de MediaCodecList .

  • TAMBIÉN DEBE poder decodificar todos los perfiles informados en su CamcorderProfile.

  • DEBE poder decodificar todos los formatos que puede codificar. Esto incluye todos los flujos de bits que generan sus codificadores.

Los códecs DEBEN tener como objetivo la latencia mínima del códec, en otras palabras, los códecs:

  • 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 tabla se proporcionan como implementaciones de software en la implementación preferida de Android del Proyecto de código abierto de Android.

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

5.1.1. Códecs de audio

Formato/códec Codificador Decodificador Detalles Formatos de tipos de archivo o contenedores compatibles
Perfil AAC de MPEG-4
(AAC LC) 		OBLIGACIÓN 1 OBLIGATORIO Compatibilidad con contenido mono/estéreo/5.0/5.1 2 con tasas de muestreo estándar de 8 a 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • AAC sin procesar de ADTS (.aac, decodifica en Android 3.1 y versiones posteriores, codifica en Android 4.0 y versiones posteriores, no se admite ADIF)
  • MPEG-TS (.ts, no admite búsquedas, Android 3.0 y versiones posteriores)
Perfil HE AAC de MPEG-4 (AAC+) OBLIGADA 1
(Android 4.1 y versiones posteriores) 		OBLIGATORIO Compatibilidad con contenido mono/estéreo/5.0/5.1 2 con tasas de muestreo estándar de 16 a 48 kHz.
Perfil HE AACv2
de MPEG-4 (AAC+ mejorado) 		OBLIGATORIO Compatibilidad con contenido mono/estéreo/5.0/5.1 2 con tasas de muestreo estándar de 16 a 48 kHz.
AAC ELD (AAC mejorado de bajo retraso) OBLIGADA 1
(Android 4.1 y versiones posteriores) 		OBLIGADA
(Android 4.1 y versiones posteriores) 		Compatibilidad con contenido mono/estéreo con tasas de muestreo estándar de 16 a 48 kHz
AMR-NB OBLIGATORIOS 3 OBLIGATORIOS 3 De 4.75 a 12.2 Kbps con muestreo a 8 kHz 3GPP (.3gp)
AMR-WB OBLIGATORIOS 3 OBLIGATORIOS 3 9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz
FLAC OBLIGADA
(Android 3.1 y versiones posteriores) 		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 OBLIGATORIO Tasa de bits constante (CBR) o variable (VBR) mono/estéreo de 8 a 320 Kbps MP3 (.mp3)
MIDI OBLIGATORIO 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 OBLIGATORIO
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 y versiones posteriores)
PCM/WAVE OBLIGACIÓN 4
(Android 4.1 y versiones posteriores) 		OBLIGATORIO 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 OBLIGADA
(Android 5.0 y versiones posteriores) 		Matroska (.mkv), Ogg(.ogg)

1 Es obligatorio para las implementaciones de dispositivos que definen android.hardware.microphone, pero es opcional para las implementaciones de dispositivos Android Watch.

2 La grabación o la reproducción PUEDEN realizarse en mono o estéreo, pero la decodificación de los 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 DEBE admitir lo siguiente:

  • la decodificación se realiza sin una reducción de canales (p. ej., una transmisión AAC 5.0 se debe decodificar en cinco canales de PCM, una transmisión AAC 5.1 se debe decodificar en seis canales de PCM).
  • metadatos de rango dinámico, como se define en "Control de rango dinámico (DRC)" en ISO/IEC 14496-3, y las claves de DRC de 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 el nivel de 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.

3 Obligatorio para las implementaciones de dispositivos de mano Android.

4 Obligatorio para las implementaciones de dispositivos que definen android.hardware.microphone, incluidas las implementaciones de dispositivos Android Watch.

5.1.2. Códecs de imagen

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

5.1.3. Códecs de video

  • Los códecs que anuncian compatibilidad con perfiles HDR DEBEN admitir el análisis y el manejo de metadatos estáticos HDR.

  • Si un códec multimedia anuncia compatibilidad con la actualización interna, 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.

  • 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 dicten el estándar y la configuración, pero que tampoco asignen más recursos de los necesarios.

  • Los codificadores y decodificadores de video DEBEN admitir el formato de color flexible YUV420 (COLOR_FormatYUV420Flexible).

Formato/códec Codificador Decodificador Detalles Tipos de archivo compatibles/
Formatos de contenedor
H.263 MAYO MAYO
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC OBLIGATORIEDAD 2 OBLIGATORIEDAD 2 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 OBLIGATORIOS 5 Consulta la sección 5.3 para obtener más detalles. MPEG-4 (.mp4)
MPEG-2 MUY RECOMENDADA 6 Perfil principal MPEG2-TS
MPEG-4 SP OBLIGATORIEDAD 2 3GPP (.3gp)
VP8 3 OBLIGADA 2
(Android 4.3 y versiones posteriores) 		OBLIGADA 2
(Android 2.3.3 y versiones posteriores) 		Consulta los artículos 5.2 y 5.3 para obtener más información.
  • WebM (.webm)
  • Matroska (.mkv, Android 4.0 y versiones posteriores) 4
VP9 OBLIGADA 2
(Android 4.4 y versiones posteriores) 		Consulta la sección 5.3 para obtener más detalles.
  • WebM (.webm)
  • Matroska (.mkv, Android 4.0 y versiones posteriores) 4

1 Obligatorio para las implementaciones de dispositivos que incluyen hardware de cámara y definen android.hardware.camera o android.hardware.camera.front.

2 Obligatorio para las implementaciones de dispositivos, excepto para dispositivos Android Watch.

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

4 Las implementaciones de dispositivos DEBEN admitir la escritura de archivos Matroska WebM.

5 MUY RECOMENDADO para Android Automotive, opcional para Android Watch y obligatorio para todos los demás tipos de dispositivos.

6 Solo se aplica a las implementaciones de dispositivos Android TV.

5.2. Codificación de video

Los códecs de video son opcionales para las implementaciones de dispositivos Android Watch.

Codificadores de video H.264, VP8, VP9 y HEVC

  • DEBEN 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.

El codificador de video H.263 y MPEG-4 DEBE admitir tasas de bits configurables de forma dinámica.

Todos los codificadores de video DEBEN cumplir con los siguientes objetivos de tasa de bits en dos ventanas deslizantes:

  • NO DEBE ser superior al 15% de la tasa de bits entre los intervalos de fotogramas intrafotogramas (I-frames).
  • NO DEBE superar el 100% de la tasa de bits en un período deslizante de 1 segundo.

5.2.1. H.263

Las implementaciones de dispositivos Android con codificadores H.263 DEBEN admitir el nivel 45 del perfil de Baseline.

5.2.2. H-264

Implementaciones de dispositivos Android con compatibilidad con el códec H.264:

  • DEBEN admitir el nivel 3 del perfil de Baseline.
    Sin embargo, la compatibilidad con ASO (ordenación arbitraria de segmentos), FMO (ordenación flexible de macrobloques) y RS (segmentos redundantes) es OPCIONAL. Además, para mantener la compatibilidad con otros dispositivos Android, se RECOMIENDA que los codificadores no usen ASO, FMO ni RS para el perfil de Baseline.
  • DEBEN admitir los perfiles de codificación de video SD (definición estándar) 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.
  • Además, se RECOMIENDA ENFATICAMENTE que los dispositivos Android TV codifiquen videos HD 1080p a 30 fps.
SD (baja calidad) SD (alta calidad) HD 720p 1 HD 1080p 1
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

1 Cuando el hardware lo admita, pero SE RECOMIENDA ENFÉMTICAMENTE para dispositivos Android TV.

5.2.3. VP8

Las implementaciones de dispositivos Android con compatibilidad con el códec VP8 DEBEN admitir los perfiles de codificación de video SD y DEBEN admitir los siguientes perfiles de codificación de video HD (alta definición).

SD (baja calidad) SD (alta calidad) HD 720p 1 HD 1080p 1
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

1 Cuando el hardware es compatible.

5.3. Decodificación de video

Los códecs de video son opcionales para las implementaciones de dispositivos Android Watch.

Implementaciones de dispositivos:

  • DEBEN admitir resolución de video dinámica y cambio de velocidad de fotogramas en APIs 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.

  • Implementaciones compatibles con el decodificador Dolby Vision:

  • DEBEN proporcionar un extractor compatible con Dolby Vision.

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

  • Las implementaciones que proporcionan un extractor compatible con Dolby Vision DEBEN establecer el índice de seguimiento de las capas básicas retrocompatibles (si las hay) de modo que sea igual al índice de seguimiento de la capa combinada de Dolby Vision.

5.3.1. MPEG-2

Las implementaciones de dispositivos Android con decodificadores MPEG-2 deben admitir el nivel alto de perfil principal.

5.3.2. H.263

Las implementaciones de dispositivos Android con decodificadores H.263 DEBEN admitir los perfiles de Baseline nivel 30 y nivel 45.

5.3.3. MPEG-4

Las implementaciones de dispositivos Android con decodificadores MPEG-4 DEBEN admitir el perfil simple de nivel 3.

5.3.4. H.264

Implementaciones de dispositivos Android con decodificadores H.264:

  • DEBEN admitir el perfil principal nivel 3.1 y el perfil de Baseline.
    La compatibilidad con ASO (ordenación arbitraria de segmentos), FMO (ordenación flexible de macrobloques) y RS (segmentos redundantes) es OPCIONAL.
  • DEBEN ser capaces 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 los 720p30).
  • DEBE ser capaz de decodificar videos con los perfiles HD (alta definición) como se indica en la siguiente tabla.
  • Además, los dispositivos Android TV:
    • DEBEN admitir el perfil de alto nivel 4.2 y el perfil de decodificación HD 1080p60.
    • DEBEN ser capaces de decodificar videos con los perfiles HD, como se indica en la siguiente tabla, y codificados con el perfil de Baseline, el perfil principal o el perfil alto de nivel 4.2.
SD (baja calidad) SD (alta calidad) HD 720p 1 HD 1080p 1
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 2)
Tasa de bits del video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

1 OBLIGATORIEDAD para cuando la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución de video.

2 OBLIGATORIOS para las implementaciones de dispositivos Android TV.

5.3.5. H.265 (HEVC)

Implementaciones de dispositivos Android, cuando admiten el códec H.265 como se describe en la sección 5.1.3 :

  • DEBEN 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.
  • DEBEN admitir los perfiles de decodificación de HD como se indica en la siguiente tabla si hay un decodificador de hardware.
  • Además, los dispositivos Android TV tienen las siguientes características:
  • DEBE admitir el perfil de decodificación HD 720p.
  • SE RECOMIENDA ALTAMENTE admitir el perfil de decodificación HD 1080p. Si se admite el perfil de decodificación HD 1080p, DEBE admitir el nivel principal del perfil principal nivel 4.1.
  • DEBE admitir el perfil de decodificación UHD. Si se admite el perfil de decodificación UHD, el códec DEBE admitir el perfil de nivel principal Main10 de nivel 5.
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p UHD
Resolución de video 352 x 288 px 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps (60 fps 1) 60 fps
Tasa de bits del video 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 OBLIGATORIEDAD para implementaciones de dispositivos Android TV con decodificación de hardware H.265.

5.3.6. VP8

Implementaciones de dispositivos Android, cuando admiten el códec VP8 como se describe en la sección 5.1.3 :

  • DEBEN admitir los perfiles de decodificación de SD que se indican en la siguiente tabla.
  • DEBE admitir los perfiles de decodificación HD que se muestran en la siguiente tabla.
  • Los dispositivos Android TV DEBEN admitir el perfil de decodificación HD 1080p60.
SD (baja calidad) SD (alta calidad) HD 720p 1 HD 1080p 1
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 2) 30 (60 fps 2)
Tasa de bits del video 800 Kbps 2 Mbps 8 Mbps 20 Mbps

1 OBLIGATORIEDAD para cuando la altura que informa el método Display.getSupportedModes() es igual o mayor que la resolución de video.

2 OBLIGATORIOS para las implementaciones de dispositivos Android TV.

5.3.7. VP9

Implementaciones de dispositivos Android, cuando admiten el códec VP9 como se describe en la sección 5.1.3 :

  • DEBEN 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.
  • DEBEN admitir los perfiles de decodificación de HD como se indica en la siguiente tabla, si hay un decodificador de hardware.

  • Además, los dispositivos Android TV tienen las siguientes características:

    • DEBE admitir el perfil de decodificación HD 720p.
    • SE RECOMIENDA ALTAMENTE admitir el perfil de decodificación HD 1080p.
    • DEBE admitir el perfil de decodificación UHD. Si se admite el perfil de decodificación de video UHD, DEBE admitir una profundidad de color de 8 bits y DEBE admitir el perfil 2 de VP9 (10 bits).
SD (baja calidad) SD (alta calidad) HD: 720p HD: 1080 p UHD
Resolución de video 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 × 2160 px
Velocidad de fotogramas del video 30 fps 30 fps 30 fps 30 fps (60 fps 1) 60 fps
Tasa de bits del video 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 OBLIGATORIEDAD para las implementaciones de dispositivos Android TV con decodificación por hardware de VP9.

5.4. Grabación de audio

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

5.4.1. Captura de audio sin procesar

Las implementaciones de dispositivos que declaran android.hardware.microphone DEBEN 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
  • Canales : Mono

La captura de las tasas de muestreo anteriores DEBE realizarse sin aumento de muestreo, y cualquier reducción de muestreo DEBE incluir un filtro de suavizado adecuado.

Las implementaciones de dispositivos que declaran android.hardware.microphone DEBEN permitir la captura de contenido de audio sin procesar con las siguientes características:

  • Formato : PCM lineal, 16 bits
  • Tasas de muestreo : 22050, 48000
  • Canales : Estéreo

Si se admite la captura para las tasas de muestreo anteriores, la captura DEBE realizarse sin muestreo superior en ninguna proporción superior a 16000:22050 o 44100:48000. Cualquier aumento o disminución de la muestra DEBE incluir un filtro de suavizado adecuado.

5.4.2. Captura para el reconocimiento de voz

La fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION DEBE admitir la captura en una de las tasas de muestreo, 44100 y 48000.

Además de las especificaciones de grabación anteriores, cuando una aplicación comienza a grabar una transmisión de audio con la fuente de audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION, ocurre lo siguiente:

  • El dispositivo DEBE presentar características de amplitud aproximadamente planas en comparación con la frecuencia: específicamente, ±3 dB, de 100 Hz a 4000 Hz.
  • La sensibilidad de entrada de audio DEBE establecerse 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.
  • Los niveles de amplitud de PCM DEBEN seguir 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.
  • La distorsión armónica total DEBE ser inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.
  • El procesamiento de reducción de ruido, si está presente, DEBE estar inhabilitado.
  • Si está presente, el control de ganancia automática DEBE estar inhabilitado.

Si la plataforma admite tecnologías de supresión de ruido ajustadas para el reconocimiento de voz, el efecto DEBE poder controlarse desde la API de android.media.audiofx.NoiseSuppressor. Además, el campo UUID del descriptor de efectos del supresor de ruido DEBE identificar de forma inequívoca cada implementación de la tecnología de supresión de ruido.

5.4.3. Captura para el redireccionamiento de la reproducción

La clase android.media.MediaRecorder.AudioSource incluye la fuente de audio REMOTE_SUBMIX. Los dispositivos que declaran android.hardware.audio.output DEBEN 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, pueda capturar una combinación de todas las transmisiones de audio, excepto las siguientes:

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

5.5. Reproducción de audio

Las implementaciones de dispositivos que declaran android.hardware.audio.output DEBEN cumplir con los requisitos de esta sección.

5.5.1. Reproducción de audio sin procesar

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

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

El dispositivo 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. Implementaciones de dispositivos que declaran la función android.hardware.audio.output:

  • 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.
  • DEBE admitir la implementación de la API del visualizador, que se puede controlar a través de la clase Visualizer.
  • 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 de AudioEffect BassBoost, EnvironmentalReverb, PresetReverb y Virtualizer.

5.5.3. Volumen de salida de audio

Las implementaciones de dispositivos Android TV DEBEN incluir compatibilidad con el volumen principal del sistema y la atenuación del volumen de salida de audio digital en las salidas compatibles, excepto para la salida de transferencia de audio comprimido (en la que no se realiza ninguna decodificación de audio en el dispositivo).

Las implementaciones de dispositivos Android Automotive DEBEN permitir ajustar el volumen de audio por separado para cada transmisión de audio con el tipo de contenido o el uso definido por AudioAttributes y el uso de audio para automóviles definido 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 dentro del NDK de Android .

Se RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos que declaran android.hardware.audio.output cumplan o superen estos requisitos de salida de audio:

  • Latencia de salida en frío de 100 milisegundos o menos
  • latencia de salida continua de 45 milisegundos o menos
  • minimiza el jitter de salida en frío

Si una implementación de dispositivo cumple con los requisitos de esta sección después de cualquier calibración inicial cuando se usa la API de cola de búfer PCM de OpenSL ES, para la latencia de salida continua y la latencia de salida en frío en, al menos, un dispositivo de salida de audio compatible, SE RECOMIENDA ENFATICAMENTE informar la compatibilidad con audio de baja latencia. Para ello, informa la función android.hardware.audio.low_latency a través de la clase android.content.pm.PackageManager. Por el contrario, si la implementación del dispositivo no cumple con estos requisitos, NO DEBE informar la compatibilidad con el audio de baja latencia.

Se RECOMIENDA ALTAMENTE que las implementaciones de dispositivos que incluyen android.hardware.microphone cumplan con estos requisitos de audio de entrada:

  • Latencia de entrada en frío de 100 milisegundos o menos
  • latencia de entrada continua de 30 milisegundos o menos
  • una latencia de ida y vuelta continua de 50 milisegundos o menos
  • minimizar el jitter de entrada en frío

5.7. Protocolos de red

Los 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. Específicamente, los dispositivos DEBEN ser compatibles con los siguientes protocolos de red multimedia:

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)

    SE DEBEN admitir el siguiente perfil de audio y video RTP y los códecs relacionados. Para conocer las excepciones, consulta las notas al pie de la tabla en la sección 5.1 .

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 detalles sobre AMR-NB.
AMR-WB RFC 4867 Consulta la sección 5.1.1 para obtener detalles sobre AMR-WB.
MP4V-ES RFC 6416 Consulta la sección 5.1.3 para obtener detalles sobre MPEG-4 SP.
mpeg4-generic RFC 3640 Consulta la sección 5.1.1 para obtener detalles sobre 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

Las implementaciones de dispositivos que admiten una salida de video segura y son compatibles con superficies seguras DEBEN declarar la compatibilidad con Display.FLAG_SECURE. Las implementaciones de dispositivos que declaran compatibilidad con Display.FLAG_SECURE, si admiten un protocolo de pantalla inalámbrica, DEBEN proteger el vínculo con un mecanismo criptográficamente sólido, como HDCP 2.x o versiones posteriores para pantallas inalámbricas Miracast. Del mismo modo, si admiten una pantalla externa con cable, las implementaciones del dispositivo DEBEN admitir HDCP 1.2 o versiones posteriores. Las implementaciones de dispositivos Android TV DEBEN admitir HDCP 2.2 para dispositivos compatibles con resolución 4K y HDCP 1.4 o versiones posteriores para resoluciones inferiores. La implementación de código abierto de Android upstream incluye compatibilidad con pantallas inalámbricas (Miracast) y con cable (HDMI) que satisfacen este requisito.

5.9. Interfaz digital de instrumentos musicales (MIDI)

Si una implementación de dispositivo admite el transporte de software MIDI entre apps (dispositivos MIDI virtuales) y admite MIDI a través de todos los siguientes transportes de hardware compatibles con MIDI para los que proporciona conectividad genérica no MIDI, SE RECOMIENDA ENFATICAMENTE informar la compatibilidad con la función android.software.midi a través de la clase android.content.pm.PackageManager.

Los transportes de hardware compatibles con MIDI son los siguientes:

  • Modo de host USB (sección 7.7 USB)
  • Modo de periférico USB (sección 7.7 USB)
  • MIDI sobre Bluetooth LE que actúa como elemento central (sección 7.4.3 Bluetooth)

Por el contrario, si la implementación del dispositivo proporciona conectividad genérica no MIDI a través de un transporte de hardware compatible con MIDI en particular de la lista anterior, pero no es compatible con MIDI a través de ese transporte de hardware, NO DEBE informar compatibilidad con la función android.software.midi.

5.10. Audio profesional

Si la implementación de un dispositivo cumple con todos los siguientes requisitos, SE RECOMIENDA ENFATICAMENTE informar la compatibilidad con la función android.hardware.audio.pro a través de la clase android.content.pm.PackageManager.

  • La implementación del dispositivo DEBE informar la compatibilidad con la función android.hardware.audio.low_latency.
  • 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.
  • Si el dispositivo incluye un conector de audio de 3.5 mm de 4 conductores, la latencia de audio de ida y vuelta continua DEBE ser de 20 milisegundos o menos en la ruta del conector de audio y DEBE ser de 10 milisegundos o menos en la ruta del conector de audio.
  • La implementación del dispositivo DEBE incluir puertos USB compatibles con el modo host USB y el modo periférico USB.
  • El modo host USB DEBE implementar la clase de audio USB.
  • Si el dispositivo incluye un puerto HDMI, la implementación del dispositivo 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.
  • La implementación del dispositivo DEBE informar la compatibilidad con la función android.software.midi.
  • Si el dispositivo incluye un conector de audio de 3.5 mm de 4 conductores, se RECOMIENDA ENFATICAMENTE que la implementación del dispositivo cumpla con la sección Especificaciones del dispositivo móvil (conector) de la Especificación de auriculares de audio con cable (v1.1) .

Las latencias y los requisitos de audio USB DEBEN cumplirse con la API de cola de búfer PCM de OpenSL ES.

Además, una implementación de dispositivo que informa compatibilidad con esta función DEBE cumplir con los siguientes requisitos:

  • Proporcionar un nivel sostenible de rendimiento de la CPU mientras el audio está activo
  • Minimiza la imprecisión y la deriva del reloj de audio en relación con la hora estándar.
  • Minimiza la deriva del reloj de audio en relación con la CPU CLOCK_MONOTONIC cuando ambos están activos.
  • Minimiza la latencia de audio a través de transductores integrados en el dispositivo.
  • Minimiza la latencia de audio a través del audio digital USB.
  • Documenta las mediciones de latencia de audio en todas las rutas.
  • Minimiza 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.
  • Proporciona cero subrutinas de audio (salidas) o superrutinas (entradas) durante el uso normal con la latencia informada.
  • Proporciona una diferencia de latencia entre canales de cero.
  • Minimiza la latencia promedio de MIDI en todos los transportes.
  • Minimiza la variabilidad de la latencia de MIDI bajo carga (jitter) en todos los transportes.
  • Proporciona marcas de tiempo MIDI precisas en todos los transportes.
  • Minimiza 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.
  • Proporciona 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.
  • Controla 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, luego, ingresa 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.
  • Minimiza 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.
  • Minimiza la latencia táctil.
  • Minimiza la variabilidad de la latencia táctil bajo carga (jitter).

5.11. Captura para sin procesar

A partir de Android 7.0, se agregó una nueva fuente de grabación. Se puede acceder a él con la fuente de audio android.media.MediaRecorder.AudioSource.UNPROCESSED. En OpenSL ES, se puede acceder a él con el parámetro de configuración de registro SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Un dispositivo DEBE cumplir con todos los siguientes requisitos para informar la compatibilidad con la fuente de audio sin procesar a través de la propiedad android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED :

  • El dispositivo DEBE 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.

  • El dispositivo DEBE mostrar niveles de amplitud en el rango de frecuencia baja: específicamente, de ±20 dB de 5 Hz a 100 Hz en comparación con el rango de frecuencia media.

  • El dispositivo DEBE mostrar niveles de amplitud en el rango de alta frecuencia: específicamente, de ±30 dB de 7,000 Hz a 22 KHz en comparación con el rango de frecuencia media.

  • La sensibilidad de entrada de audio DEBE configurarse 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).

  • SNR superior a 60 dB (diferencia entre 94 dB SPL y el SPL equivalente del ruido propio, ponderado A)

  • La distorsión armónica total DEBE ser inferior al 1% para 1 kHz a un nivel de entrada de SPL de 90 dB en el micrófono.

  • El único procesamiento de indicadores permitido en la ruta es un multiplicador de nivel para llevar el nivel al rango deseado. Este multiplicador de nivel NO DEBE introducir retrasos ni latencia en la ruta de la señal.

  • No se permite ningún otro procesamiento de señal en la ruta de acceso, como el control automático de ganancia, el filtro de paso alto o la cancelación de eco. Si hay algún procesamiento de señal presente en la arquitectura por algún motivo, DEBE inhabilitarse y, de manera efectiva, no debe introducir demoras ni latencia adicional en la ruta de la señal.

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.

SE RECOMIENDA ENFÉCTIVAMENTE que un dispositivo cumpla con la mayor cantidad posible de requisitos de la ruta de señal para la fuente de grabación sin procesar. Sin embargo, un dispositivo debe cumplir con todos los requisitos mencionados anteriormente si afirma admitir la fuente de audio sin procesar.

6. Compatibilidad de las herramientas y opciones para desarrolladores

6.1. Herramientas para desarrolladores

Las implementaciones de dispositivos DEBEN admitir las herramientas para desarrolladores de Android que se proporcionan en el SDK de Android. Los dispositivos compatibles con Android DEBEN ser compatibles con lo siguiente:

  • Android Debug Bridge (adb)
    • Las implementaciones de dispositivos DEBEN admitir todas las funciones de adb, como se documenta en el SDK de Android, incluido dumpsys .
    • El daemon de adb del dispositivo DEBE estar inactivo de forma predeterminada y DEBE haber un mecanismo accesible para el usuario para activar el puente de depuración de Android. Si una implementación de dispositivo omite el modo periférico USB, DEBE implementar el puente de depuración de Android a través de una red de área local (como Ethernet o 802.11).
    • Android incluye compatibilidad con adb seguro. El adb seguro habilita adb en hosts autenticados conocidos. Las implementaciones de dispositivos DEBEN admitir adb seguro.
  • Servicio de Dalvik Debug Monitor (ddms)
    • Las implementaciones de dispositivos DEBEN 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.
  • Las implementaciones de dispositivos Monkey DEBEN incluir el framework de Monkey y ponerlo a disposición de las aplicaciones para que lo usen.
  • SysTrace
    • Las implementaciones de dispositivos DEBEN 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.
    • La mayoría de los sistemas basados en Linux y los sistemas Apple Macintosh reconocen dispositivos Android con las herramientas estándar del SDK de Android, sin compatibilidad adicional. Sin embargo, los sistemas Microsoft Windows suelen requerir un controlador para dispositivos Android nuevos. (por ejemplo, los IDs de proveedores nuevos y, a veces, los IDs de dispositivos nuevos requieren controladores USB personalizados para sistemas Windows).
    • Si la herramienta adb no reconoce una implementación de dispositivo como se proporciona en el SDK de Android estándar, los implementadores de dispositivos DEBEN proporcionar controladores de Windows que permitan a los desarrolladores conectarse al dispositivo con el protocolo adb. Estos controladores DEBEN proporcionarse para Windows XP, Windows Vista, Windows 7, Windows 8 y Windows 10 en versiones de 32 y 64 bits.

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 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ú 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. Las implementaciones de dispositivos DEBEN proporcionar una experiencia coherente para las Opciones para desarrolladores. Específicamente, las implementaciones de dispositivos DEBEN ocultar las Opciones para desarrolladores de forma predeterminada y DEBEN proporcionar un mecanismo para habilitar las Opciones para desarrolladores que sea coherente con la implementación de Android upstream.

Las implementaciones de Android Automotive PUEDEN limitar el acceso al menú Opciones para desarrolladores ocultando o inhabilitando visualmente el menú cuando el vehículo está en movimiento.

7. Compatibilidad de hardware

Si un dispositivo incluye un componente de hardware 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. 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:

  • Aún DEBEN presentarse las definiciones de clases completas (como se documenta en el SDK) para las APIs de los componentes.
  • Los comportamientos de la API DEBEN implementarse como no-ops de alguna manera razonable.
  • Los métodos de la API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita.
  • 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.
  • Los métodos de la API NO DEBEN generar excepciones que no estén documentadas en la documentación del SDK.

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.

Las implementaciones de dispositivos DEBEN informar de forma coherente información de configuración de hardware precisa a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella de compilación.

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 porción 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 de la pantalla

Es POSIBLE que los dispositivos Android Watch (que se detallan en la sección 2) tengan tamaños de pantalla más pequeños, como se describe en esta sección.

El framework de la IU de Android admite una variedad de tamaños de pantalla diferentes y permite que las aplicaciones consulten el tamaño de la pantalla del dispositivo (también conocido como "diseño de pantalla") a través de android.content.res.Configuration.screenLayout con SCREENLAYOUT_SIZE_MASK. Las implementaciones de dispositivos DEBEN informar el tamaño de pantalla correcto, tal como se define en la documentación del SDK de Android y lo determina la plataforma de Android upstream. Específicamente, las implementaciones de dispositivos DEBEN informar el tamaño de pantalla correcto según las siguientes dimensiones lógicas de píxeles independientes de la densidad (dp).

  • Los dispositivos DEBEN tener tamaños de pantalla de al menos 426 dp x 320 dp ("pequeños"), a menos que se trate de un dispositivo Android Watch.
  • Los dispositivos que informan un tamaño de pantalla "normal" DEBEN tener un tamaño de pantalla de al menos 480 dp × 320 dp.
  • Los dispositivos que informan un tamaño de pantalla "grande" DEBEN tener un tamaño de pantalla de al menos 640 dp x 480 dp.
  • Los dispositivos que informan el tamaño de pantalla "extragrande" DEBEN tener tamaños de pantalla de al menos 960 dp x 720 dp.

A su vez:

  • Los dispositivos Android Watch DEBEN tener una pantalla con un tamaño diagonal físico de entre 1.1 y 2.5 pulgadas.
  • Los dispositivos Android Automotive DEBEN tener una pantalla con un tamaño diagonal físico superior o igual a 6 pulgadas.
  • Los dispositivos Android Automotive DEBEN tener un tamaño de pantalla de al menos 750 dp × 480 dp.
  • Otros tipos de implementaciones de dispositivos Android, con una pantalla integrada físicamente, DEBEN tener una pantalla de al menos 6.35 cm (2.5 pulgadas) de tamaño diagonal físico.

Los dispositivos NO DEBEN cambiar el tamaño de pantalla informado en ningún momento.

De manera opcional, las aplicaciones indican qué tamaños de pantalla admiten a través del atributo <supports-screens> en el archivo AndroidManifest.xml. Las implementaciones de dispositivos DEBEN respetar correctamente la compatibilidad declarada de las aplicaciones para pantallas pequeñas, normales, grandes y extragrandes, como se describe en la documentación del SDK de Android.

7.1.1.2. Relación de aspecto de la pantalla

Si bien no hay restricciones para el valor de la relación de aspecto de la pantalla física, la relación de aspecto de la superficie en la que se renderizan las apps de terceros y que se puede obtener de los valores informados a través de DisplayMetrics DEBE cumplir con los siguientes requisitos:

  • Si uiMode está configurado como UI_MODE_TYPE_WATCH, el valor de la relación de aspecto PUEDE establecerse como 1.0 (1:1).
  • Si la app de terceros indica que se puede cambiar el tamaño mediante el atributo android:resizeableActivity, no hay restricciones para el valor de la relación de aspecto.
  • En todos los demás casos, la relación de aspecto DEBE ser un valor entre 1.3333 (4:3) y 1.86 (aproximadamente 16:9), a menos que la app haya indicado explícitamente que admite una relación de aspecto de pantalla más alta a través del valor de metadatos maxAspectRatio.

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. 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 de 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 (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 (560dpi)
  • 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.

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos proporcionen a los usuarios un parámetro de configuración para cambiar el tamaño de la pantalla. Si hay una implementación para cambiar el tamaño de la pantalla del dispositivo, DEBE alinearse con la implementación de AOSP como se indica a continuación:

  • 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.
  • El tamaño de la pantalla NO DEBE escalarse a un tamaño menor que 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

Las implementaciones de dispositivos DEBEN informar valores correctos para todas las métricas de visualización definidas en android.util.DisplayMetrics y DEBEN informar los mismos valores, independientemente de si se usa la pantalla externa o integrada como pantalla predeterminada.

7.1.3. Orientación de pantalla

Los dispositivos 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.

Los dispositivos que informan ambas orientaciones de pantalla DEBEN admitir la orientación dinámica de las aplicaciones a la orientación vertical u horizontal de la pantalla. Es decir, el dispositivo debe respetar la solicitud de la aplicación para una orientación de pantalla específica. Las implementaciones de dispositivos PUEDEN seleccionar la orientación vertical u horizontal como predeterminada.

Los dispositivos DEBEN informar el valor correcto de la orientación actual del dispositivo cada vez que se consulta a través de android.content.res.Configuration.orientation, android.view.Display.getOrientation() o alguna otra API.

Los dispositivos NO DEBEN cambiar el tamaño ni la densidad de la pantalla informados cuando se cambia la orientación.

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

Las implementaciones de dispositivos DEBEN admitir OpenGL ES 1.0 y 2.0, como se indica y detalla en la documentación del SDK de Android. Las implementaciones de dispositivos DEBEN admitir OpenGL ES 3.0, 3.1 o 3.2 en dispositivos que puedan admitirlo. Las implementaciones de dispositivos también DEBEN admitir Android RenderScript , como se detalla en la documentación del SDK de Android.

Las implementaciones de dispositivos también DEBEN identificarse correctamente como compatibles con OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 o OpenGL 3.2. Es decir:

  • Las APIs administradas (como a través del método GLES10.getString()) DEBEN informar la compatibilidad con OpenGL ES 1.0 y OpenGL ES 2.0.
  • Las APIs nativas de OpenGL C/C++ (APIs disponibles para las apps a través de libGLES_v1CM.so, libGLES_v2.so o libEGL.so) DEBEN informar compatibilidad con OpenGL ES 1.0 y OpenGL ES 2.0.
  • Las implementaciones de dispositivos que declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2 DEBEN admitir las APIs administradas correspondientes y deben incluir compatibilidad con las APIs nativas de C/C++. En las implementaciones de dispositivos que declaran compatibilidad con OpenGL ES 3.0, 3.1 o 3.2, libGLESv2.so DEBE exportar los símbolos de función correspondientes, además de los símbolos de función de OpenGL ES 2.0.

Android proporciona un paquete de extensiones de OpenGL ES con interfaces de Java y compatibilidad nativa con funciones gráficas avanzadas, como la teselación y el formato de compresión de texturas ASTC. Las implementaciones de dispositivos Android DEBEN admitir el paquete de extensiones si el dispositivo admite OpenGL ES 3.2 y PUEDEN admitirlo de otro modo. Si el paquete de extensión es compatible en su totalidad, el dispositivo DEBE identificar la compatibilidad a través de la marca de función android.hardware.opengles.aep.

Además, las implementaciones de dispositivos PUEDEN implementar cualquier extensión de OpenGL ES deseada. Sin embargo, las implementaciones de dispositivos DEBEN informar a través de las APIs administradas y nativas de OpenGL ES todas las cadenas de extensión que admiten y, a la inversa, NO DEBEN informar cadenas de extensión que no admiten.

Ten en cuenta que Android incluye compatibilidad con aplicaciones que pueden especificar de forma opcional que requieren formatos de compresión de texturas OpenGL específicos. Por lo general, estos formatos son específicos de cada proveedor. Android no requiere implementaciones de dispositivos para implementar ningún formato de compresión de texturas específico. Sin embargo, DEBEN informar con precisión los formatos de compresión de texturas que admiten a través del método getString() en la API de OpenGL.

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.

Las implementaciones de dispositivos DEBEN habilitar la aceleración de hardware de forma predeterminada y DEBEN 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.

Además, las implementaciones de dispositivos DEBEN 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. Las implementaciones de dispositivos DEBEN admitir la API de TextureView y DEBEN mostrar un comportamiento coherente con la implementación de Android upstream.

Android incluye compatibilidad con EGL_ANDROID_RECORDABLE, un atributo EGLConfig que indica si EGLConfig admite la renderización en un ANativeWindow que graba imágenes en un video. Las implementaciones de dispositivos DEBEN admitir la extensión EGL_ANDROID_RECORDABLE.

7.1.5. Modo de compatibilidad de aplicaciones heredadas

Android especifica un "modo de compatibilidad" en el que el framework opera 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.

  • Android Automotive no admite el modo de compatibilidad heredado.
  • Todas las demás implementaciones de dispositivos DEBEN incluir compatibilidad con el modo de compatibilidad de aplicaciones heredado, 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.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.

  • Los dispositivos DEBEN admitir pantallas capaces de renderizar gráficos en color de 16 bits y DEBEN admitir pantallas capaces de renderizar gráficos en color de 24 bits.
  • Los dispositivos DEBEN admitir pantallas capaces de renderizar animaciones.
  • La tecnología de pantalla que se use DEBE tener una relación de aspecto de píxeles (PAR) de entre 0.9 y 1.15. Es decir, la relación de aspecto de píxeles DEBE ser casi cuadrada (1.0) con una tolerancia de entre el 10 y el 15%.

7.1.7. Pantallas secundarias

Android incluye compatibilidad con pantallas secundarias para habilitar las funciones de uso compartido de contenido multimedia y las APIs para desarrolladores para acceder a pantallas externas. Si un dispositivo admite una pantalla externa a través de una conexión de pantalla adicional con cable, inalámbrica o incorporada, la implementación del dispositivo DEBE implementar la API de Display Manager como se describe en la documentación del SDK de Android.

7.2. Dispositivos de entrada

Los dispositivos DEBEN admitir una pantalla táctil o cumplir con los requisitos que se indican en 7.2.2 para la navegación sin tacto.

7.2.1. Teclado

Las implementaciones de Android Watch y Android Automotive PUEDEN implementar un teclado en pantalla. Todas las demás implementaciones de dispositivos DEBEN implementar un teclado en pantalla y cumplir con los siguientes requisitos:

Implementaciones de dispositivos:

  • DEBEN incluir compatibilidad con el Framework de administración de entradas (que permite que los desarrolladores externos creen editores de métodos de entrada, es decir, teclados en pantalla), como se detalla en http://developer.android.com.
  • DEBEN proporcionar al menos una implementación de teclado en pantalla (independientemente de si hay un teclado físico), excepto para los dispositivos Android Watch, en los que el tamaño de la pantalla hace que sea menos razonable tener un teclado en pantalla.
  • PUEDE incluir implementaciones adicionales del teclado en pantalla.
  • PUEDE incluir un teclado de hardware.
  • NO DEBE incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.keyboard (QWERTY o 12 teclas).

7.2.2. Navegación no táctil

Los dispositivos Android TV DEBEN admitir el pad direccional.

Implementaciones de dispositivos:

  • SE PUEDE omitir una opción de navegación no táctil (bola de seguimiento, pad direccional o rueda) si la implementación del dispositivo no es un dispositivo Android TV.
  • DEBE informar el valor correcto para android.content.res.Configuration.navigation .
  • DEBEN 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

Los requisitos de disponibilidad y visibilidad de las funciones Inicio, Recientes y Atrás difieren entre los tipos de dispositivos, como se describe en esta sección.

Las funciones Inicio, Recientes y Atrás (asociadas a los eventos de teclas KEYCODE_HOME, KEYCODE_APP_SWITCH y KEYCODE_BACK, respectivamente) son esenciales para el paradigma de navegación de Android y, por lo tanto, tienen las siguientes características:

  • Las implementaciones de dispositivos de mano Android DEBEN proporcionar las funciones de Inicio, Recientes y Atrás.
  • Las implementaciones de dispositivos Android TV DEBEN proporcionar las funciones de Inicio y Atrás.
  • Las implementaciones de dispositivos Android Watch DEBEN tener la función de inicio disponible para el usuario y la función Atrás, excepto cuando está en UI_MODE_TYPE_WATCH .
  • Las implementaciones de dispositivos Android Watch, y ningún otro tipo de dispositivo Android, PUEDEN consumir el evento de mantener presionada la tecla en el evento de tecla KEYCODE_BACK y omitir que se envíe a la aplicación en primer plano.
  • Las implementaciones de Android Automotive DEBEN proporcionar la función de inicio y PUEDEN proporcionar las funciones Atrás y Recientes.
  • Todos los demás tipos de implementaciones de dispositivos DEBEN proporcionar las funciones de Inicio y Atrás.

Estas funciones PUEDEN implementarse a través de botones físicos dedicados (como botones táctiles mecánicos o capacitivos) o PUEDEN implementarse con teclas de software dedicadas en una parte distinta de la pantalla, gestos, panel táctil, etc. Android admite ambas implementaciones. Se DEBE poder acceder a todas estas funciones con una sola acción (p.ej., presionar, hacer doble clic o realizar un gesto) cuando estén visibles.

Si se proporciona, la función Recientes DEBE tener un botón o ícono visible, a menos que esté oculto junto con otras funciones de navegación en el modo de pantalla completa. Esto no se aplica a los dispositivos que actualizan desde versiones anteriores de Android que tienen botones físicos para la navegación y no tienen la tecla de apps recientes.

Las funciones de Inicio y Atrás, si se proporcionan, DEBEN tener un botón o ícono visible, a menos que se oculten junto con otras funciones de navegación en el modo de pantalla completa o cuando uiMode UI_MODE_TYPE_MASK esté configurado en UI_MODE_TYPE_WATCH.

La función de menú dejó de estar disponible en favor de la barra de acciones desde Android 4.0. Por lo tanto, las implementaciones de dispositivos nuevas que se envían con Android 7.1 y versiones posteriores NO DEBEN implementar un botón físico exclusivo para la función Menú. Las implementaciones de dispositivos más antiguas NO DEBEN implementar un botón físico dedicado para la función de menú, pero si se implementa el botón de menú físico y el dispositivo ejecuta aplicaciones con targetSdkVersion > 10, la implementación del dispositivo hace lo siguiente:

  • DEBE mostrar el botón de menú ampliado de acciones en la barra de acciones cuando esté visible y el menú emergente resultante no esté vacío. Para una implementación de dispositivo lanzada antes de Android 4.4, pero que se actualiza a Android 7.1, esto es RECOMENDABLE.
  • NO DEBE modificar la posición de la ventana emergente de opciones adicionales de la acción que se muestra cuando se selecciona el botón de opciones adicionales en la barra de acciones.
  • PUEDE renderizar la ventana emergente de acciones adicionales en una posición modificada en la pantalla cuando se muestra seleccionando el botón de menú físico.

Para la retrocompatibilidad, las implementaciones de dispositivos DEBEN hacer que la función de menú esté disponible para las aplicaciones cuando targetSdkVersion sea inferior a 10, ya sea a través de un botón físico, una tecla de software o gestos. Esta función de menú debe presentarse, a menos que se oculte junto con otras funciones de navegación.

Las implementaciones de dispositivos Android que admiten la acción de asistencia o VoiceInteractionService DEBEN poder iniciar una app de asistencia con una sola interacción (p.ej., un toque, un doble clic o un gesto) cuando se ven otras teclas de navegación. SE RECOMIENDA ENFATICAMENTE mantener presionado el botón de inicio como esta interacción. La interacción designada DEBE iniciar la app de asistencia seleccionada por el usuario, es decir, la app que implementa un VoiceInteractionService, o una actividad que controla el intent ACTION_ASSIST.

Las implementaciones de dispositivos PUEDEN usar una parte distinta de la pantalla para mostrar las teclas de navegación, pero, de ser así, DEBEN cumplir con los siguientes requisitos:

  • Las teclas de navegación de implementación del dispositivo 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.
  • Las implementaciones de dispositivos DEBEN 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 .
  • Las implementaciones de dispositivos DEBEN mostrar las teclas de navegación cuando las aplicaciones no especifican un modo de IU del sistema o especifican SYSTEM_UI_FLAG_VISIBLE.
  • Las implementaciones de dispositivos DEBEN presentar las teclas de navegación en un modo "bajo perfil" (p. ej., atenuado) no intrusivo cuando las aplicaciones especifiquen SYSTEM_UI_FLAG_LOW_PROFILE.
  • Las implementaciones de dispositivos DEBEN ocultar las teclas de navegación cuando las aplicaciones especifican SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Entrada táctil

Los dispositivos portátiles y de reloj de Android DEBEN admitir la entrada de pantalla táctil.

Las implementaciones de dispositivos DEBEN tener algún tipo de sistema de entrada de puntero (ya sea táctil o similar a un mouse). Sin embargo, si una implementación de dispositivo no admite un sistema de entrada de puntero, NO DEBE informar la constante de la función android.hardware.touchscreen ni android.hardware.faketouch. Implementaciones de dispositivos que sí incluyen un sistema de entrada de puntero:

  • DEBE admitir punteros con seguimiento completamente independiente, si el sistema de entrada del dispositivo admite varios punteros.
  • DEBE informar el valor de android.content.res.Configuration.touchscreen que corresponde al tipo de pantalla táctil específica del dispositivo.

Android incluye compatibilidad con una variedad de 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. Por el contrario, una 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. Las implementaciones de dispositivos que declaran la función de toque falso DEBEN cumplir con los requisitos de toque falso que se indican en la sección 7.2.5 .

Las implementaciones de dispositivos DEBEN informar la función correcta correspondiente al tipo de entrada que se usa. Las implementaciones de dispositivos que incluyen una pantalla táctil (de un solo toque o superior) DEBEN informar la constante de la función de plataforma android.hardware.touchscreen. Las implementaciones de dispositivos que informan la constante de función de plataforma android.hardware.touchscreen TAMBIÉN DEBEN informar la constante de función de plataforma android.hardware.faketouch. Las implementaciones de dispositivos que no incluyen una pantalla táctil (y solo dependen de un dispositivo de puntero) NO DEBEN informar ninguna función de pantalla táctil y DEBEN informar solo android.hardware.faketouch si cumplen con los requisitos de la pantalla táctil falsa que se indican en la sección 7.2.5 .

7.2.5. Entrada táctil falsa

Implementaciones de dispositivos que declaran compatibilidad con android.hardware.faketouch:

  • DEBEN informar las posiciones absolutas de la pantalla en X e Y de la ubicación del puntero y mostrar un puntero visual en la pantalla.
  • DEBE informar el evento de toque 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 .
  • DEBE admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios emular la presión sobre un objeto en la pantalla.
  • 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.
  • 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.
  • 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.

Los dispositivos que declaran compatibilidad con android.hardware.faketouch.multitouch.distinct DEBEN cumplir con los requisitos de faketouch anteriores y también DEBEN admitir el seguimiento distinto de dos o más entradas de puntero independientes.

7.2.6. Compatibilidad con controles de juegos

Las implementaciones de dispositivos de Android TV DEBEN admitir las asignaciones de botones para los controles de juegos que se indican a continuación. La implementación de Android upstream incluye la implementación de controles de juegos que satisfacen este requisito.

7.2.6.1. Asignaciones de botones

Las implementaciones de dispositivos Android TV DEBEN admitir las siguientes asignaciones de teclas:

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

1 KeyEvent

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

3 Este uso debe tener un valor mínimo lógico de 0, un 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ógicos 1 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

Las implementaciones de dispositivos Android TV DEBEN proporcionar un control remoto para permitir que los usuarios accedan a la interfaz de la TV. El control remoto PUEDE ser físico o basado en software al que se puede acceder desde un teléfono celular o una tablet. El control remoto DEBE cumplir con los requisitos que se definen a continuación.

  • Indicador visual de búsqueda . Las implementaciones de dispositivos DEBEN activar KEYCODE_SEARCH (o KEYCODE_ASSIST si el dispositivo admite un asistente) cuando el usuario invoca la búsqueda por voz en el control remoto físico o basado en software.
  • Navegación . Todos los controles remotos de Android TV DEBEN incluir los botones Atrás, Inicio y Seleccionar, y admitir eventos del mando de dirección .

7.3. Sensores

Android incluye APIs para acceder a una variedad de tipos de sensores. Por lo general, las implementaciones de dispositivos PUEDEN omitir estos sensores, como se indica en las siguientes sub secciones. Si un dispositivo incluye 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 . Por ejemplo, implementaciones de dispositivos:

  • DEBEN informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager.
  • DEBE mostrar una lista precisa de los sensores compatibles a través de SensorManager.getSensorList() y métodos similares.
  • DEBEN comportarse de manera razonable para todas las demás APIs de sensores (por ejemplo, mostrando verdadero o falso según corresponda cuando las aplicaciones intentan registrar objetos de escucha, no llamando a objetos de escucha de sensores cuando los sensores correspondientes no están presentes, etcétera).
  • DEBEN informar todas las mediciones del sensor con los valores relevantes del Sistema Internacional de Unidades (métrico) para cada tipo de sensor, como se define en la documentación del SDK de Android.
  • 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.
  • DEBEN 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 aplicaciones está activo. Esta demora no incluye ninguna demora de filtrado.
  • 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.

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 pueden derivarse 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). Las implementaciones de dispositivos DEBEN implementar estos tipos de sensores, cuando incluyen los sensores físicos previos que se describen en tipos de sensores . Si una implementación de dispositivo incluye un sensor compuesto, DEBE implementarlo como se describe en la documentación de código abierto de Android sobre sensores compuestos .

Algunos sensores de Android admiten un modo de activación "continuo" , que muestra datos de forma continua. 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.

Ten en cuenta que las implementaciones de dispositivos DEBEN garantizar que el flujo de eventos del sensor NO impida que la CPU del dispositivo entre en un estado de suspensión o se active desde un estado de suspensión.

Por último, cuando se activan varios sensores, el consumo de energía NO DEBE superar la suma del consumo de energía informado por cada sensor.

7.3.1. Acelerómetro

Las implementaciones de dispositivos DEBEN incluir un acelerómetro de 3 ejes. SE RECOMIENDA ENFATICAMENTE que los dispositivos Android para manos libres, las implementaciones de Android Automotive y los dispositivos Android Watch incluyan este sensor. Si una implementación de dispositivo incluye un acelerómetro de 3 ejes, tiene las siguientes características:

  • DEBE implementar y notificar el sensor TYPE_ACCELEROMETER .
  • DEBEN poder informar eventos con una frecuencia de al menos 50 Hz para dispositivos Android Watch, ya que estos dispositivos tienen una restricción de energía más estricta, y de 100 Hz para todos los demás tipos de dispositivos.
  • DEBE informar eventos de hasta 200 Hz como mínimo.
  • DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android. Las implementaciones de Android Automotive DEBEN cumplir con el sistema de coordenadas de sensores de automóviles de Android .
  • DEBEN ser capaces de medir desde la caída libre hasta cuatro veces la gravedad (4 g) o más en cualquier eje.
  • DEBEN tener una resolución de al menos 12 bits y DEBEN 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.
  • DEBEN 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.
  • 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. Se RECOMIENDAN los dispositivos Android existentes y nuevos para implementar el sensor compuesto TYPE_SIGNIFICANT_MOTION. Si se implementa alguno de estos sensores, la suma de su consumo de energía DEBE ser siempre inferior a 4 mW y CADA UNO DEBE ser inferior a 2 mW y 0.5 mW cuando el dispositivo está en condiciones dinámicas o estáticas.
  • Si se incluye un sensor de giroscopio, DEBES implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION, y DEBES implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR. Se RECOMIENDA ENFATICAMENTE que los dispositivos Android existentes y nuevos implementen el sensor TYPE_GAME_ROTATION_VECTOR.
  • DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluye un sensor de giroscopio y un sensor de magnetómetro.

7.3.2. Magnetómetro

Las implementaciones de dispositivos DEBEN incluir un magnetómetro de 3 ejes (brújula). Si un dispositivo incluye un magnetómetro de 3 ejes, tiene las siguientes características:

  • DEBE implementar el sensor TYPE_MAGNETIC_FIELD y también DEBE implementar el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED. Se RECOMIENDA ENFATICAMENTE que los dispositivos Android existentes y nuevos implementen el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • DEBEN poder informar eventos hasta una frecuencia de, al menos, 10 Hz y DEBEN informar eventos hasta, al menos, 50 Hz.
  • DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android.
  • DEBEN ser capaces de medir entre -900 µT y +900 µT en cada eje antes de saturarse.
  • DEBE tener un valor de compensación de hierro duro inferior a 700 µT y DEBE tener un valor inferior a 200 µT. Para ello, coloca el magnetómetro lejos de los campos magnéticos dinámicos (inducidos por la corriente) y estáticos (inducidos por el imán).
  • DEBEN tener una resolución igual o superior a 0.6 µT y DEBEN tener una resolución igual o superior a 0.2 µT.
  • DEBE tener compensación de temperatura.
  • DEBEN admitir la calibración y compensación en línea del sesgo de hardware y preservar los parámetros de compensación entre los reinicios del dispositivo.
  • DEBE tener aplicada la compensación de hierro dulce. La calibración se puede realizar durante el uso o la producción del dispositivo.
  • 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 0.5 µT.
  • DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluye un sensor acelerómetro y un sensor giroscopio.
  • PUEDE implementar el sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR si también se implementa un sensor de acelerómetro. Sin embargo, si se implementa, DEBE consumir menos de 10 mW y DEBE consumir menos de 3 mW cuando el sensor se registra para el modo por lotes a 10 Hz.

7.3.3. GPS

Las implementaciones de dispositivos DEBEN incluir un receptor GPS/GNSS. Si una implementación de dispositivo incluye un receptor de GPS/GNSS y le informa la capacidad a las aplicaciones a través de la marca de función android.hardware.location.gps, haz lo siguiente:

  • SE RECOMIENDA ENFÉCTIMO que el dispositivo siga proporcionando salidas normales de GPS/GNSS a las aplicaciones durante una llamada telefónica de emergencia y que no se bloquee la salida de ubicación durante una llamada telefónica de emergencia.
  • DEBE admitir salidas de ubicación a una velocidad de al menos 1 Hz cuando se solicite a través de LocationManager#requestLocationUpdate .
  • DEBE poder determinar la ubicación en condiciones de cielo abierto (señales fuertes, multitrayectoria insignificante, HDOP inferior a 2) en un plazo de 10 segundos (tiempo rápido hasta la primera corrección) cuando está conectado a una conexión a Internet de 0.5 Mbps o 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).
    • Después de realizar ese cálculo de ubicación, se RECOMIENDA ENFÉMTICAMENTE que el dispositivo pueda determinar su ubicación, a cielo abierto, en un plazo de 10 segundos, cuando se reinicien las solicitudes de ubicación, hasta una hora después del cálculo 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é inmóvil o se mueva con menos de 1 metro por segundo cuadrado de aceleración:
    • DEBE 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.
    • DEBE realizar un seguimiento y generar informes de forma simultánea a través de GnssStatus.Callback de al menos 8 satélites de una constelación.
    • DEBE poder hacer un seguimiento simultáneo de al menos 24 satélites, de varias constelaciones (p.ej., GPS + al menos uno de Glonass, Beidou o Galileo).
  • DEBE informar la generación de la tecnología de GNSS a través de la API de prueba "getGnssYearOfHardware".
  • SE RECOMIENDA ENFÉCTIVAMENTE que se cumplan todos los requisitos que se indican a continuación si la generación de la tecnología GNSS se informa como el año "2016" o uno posterior.
    • DEBE informar las mediciones de GPS en cuanto se encuentren, incluso si aún no se informa una ubicación calculada a partir de GPS/GNSS.
    • DEBE informar las pseudorangos y las tasas de pseudorangos del GPS que, en condiciones de cielo abierto después de determinar la ubicación, mientras está inmóvil o se mueve con menos de 0.2 metros por segundo cuadrado de aceleración, son suficientes para calcular la posición dentro de un radio de 20 metros y la velocidad dentro de un radio de 0.2 metros por segundo, al menos el 95% del tiempo.

Ten en cuenta que, si bien algunos de los requisitos de GPS anteriores se indican como MUY RECOMENDADOS, se espera que la Definición de Compatibilidad de la próxima versión principal los cambie a OBLIGATORIOS.

7.3.4. Giroscopio

Las implementaciones de dispositivos DEBEN incluir un giroscopio (sensor de cambio angular). Los dispositivos NO DEBEN incluir un sensor de giroscopio, a menos que también incluyan un acelerómetro de 3 ejes. Si una implementación de dispositivo incluye un giroscopio, hace lo siguiente:

  • DEBE implementar el sensor TYPE_GYROSCOPE y también DEBE implementar el sensor TYPE_GYROSCOPE_UNCALIBRATED. Se RECOMIENDA ENFATICAMENTE que los dispositivos Android existentes y nuevos implementen el sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • DEBEN ser capaces de medir cambios de orientación de hasta 1,000 grados por segundo.
  • DEBEN poder informar eventos con una frecuencia de al menos 50 Hz para dispositivos Android Watch, ya que estos dispositivos tienen una restricción de energía más estricta, y de 100 Hz para todos los demás tipos de dispositivos.
  • DEBE informar eventos de hasta 200 Hz como mínimo.
  • DEBE tener una resolución de 12 bits o más y DEBE tener una resolución de 16 bits o más.
  • DEBEN tener compensación de temperatura.
  • DEBEN calibrarse y compensarse mientras están en uso, y deben conservar los parámetros de compensación entre los reinicios del dispositivo.
  • 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.
  • DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluye un sensor acelerómetro y un sensor magnetómetro.
  • Si se incluye un sensor de acelerómetro, DEBES implementar los sensores compuestos TYPE_GRAVITY y TYPE_LINEAR_ACCELERATION, y DEBES implementar el sensor compuesto TYPE_GAME_ROTATION_VECTOR. Se RECOMIENDA ENFATICAMENTE que los dispositivos Android existentes y nuevos implementen el sensor 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 una implementación de dispositivo incluye un barómetro, hace lo siguiente:

  • DEBE implementar y generar informes sobre el sensor TYPE_PRESSURE.
  • DEBEN poder entregar eventos a 5 Hz o más.
  • DEBEN tener la precisión adecuada para permitir la estimación de la altitud.
  • DEBEN tener compensación de temperatura.

7.3.6. Termómetro

Las implementaciones de dispositivos PUEDEN incluir un termómetro ambiente (sensor de temperatura). Si está presente, DEBE definirse como SENSOR_TYPE_AMBIENT_TEMPERATURE y DEBE medir la temperatura ambiente (de la habitación) en grados Celsius.

Las implementaciones de dispositivos PUEDEN, pero NO DEBEN, incluir un sensor de temperatura de la CPU. Si está presente, DEBE definirse como SENSOR_TYPE_TEMPERATURE, DEBE medir la temperatura de la CPU del dispositivo y 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.

En el caso de las implementaciones de Android Automotive, SENSOR_TYPE_AMBIENT_TEMPERATURE DEBE medir la temperatura dentro de la cabina del vehículo.

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. Los dispositivos que pueden realizar una llamada de voz y que indican cualquier valor que no sea PHONE_TYPE_NONE en getPhoneType DEBEN incluir un sensor de proximidad. Si una implementación de dispositivo incluye un sensor de proximidad, hace lo siguiente:

  • DEBEN 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 la implementación de un dispositivo incluye un sensor de proximidad con cualquier otra orientación, NO SE DEBE poder acceder a él a través de esta API.
  • DEBE tener 1 bit de precisión o más.

7.3.9. Sensores de alta fidelidad

Las implementaciones de dispositivos que admiten un conjunto de sensores de mayor calidad que pueden cumplir con todos los requisitos que se enumeran en esta sección DEBEN identificar la compatibilidad a través de la marca de función android.hardware.sensor.hifi_sensors.

Un dispositivo que declara android.hardware.sensor.hifi_sensors DEBE admitir todos los siguientes tipos de sensores que cumplan con los requisitos de calidad que se indican a continuación:

  • SENSOR_TYPE_ACCELEROMETER
    • DEBE tener un rango de medición de al menos -8 g y +8 g.
    • DEBEN tener una resolución de medición de al menos 1,024 LSB/G.
    • DEBE tener una frecuencia de medición mínima de 12.5 Hz o menos.
    • DEBEN tener una frecuencia de medición máxima de 400 Hz o superior.
    • DEBE tener un ruido de medición no superior a 400 uG/√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.
    • DEBE tener una estabilidad de sesgo de ruido estacionario de menos de 15 μg √Hz a partir del conjunto de datos estáticos de 24 horas.
    • 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.

  • SENSOR_TYPE_GYROSCOPE

    • 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.
    • DEBEN tener una frecuencia de medición máxima de 400 Hz o superior.
    • DEBE tener un ruido de medición no superior a 0.014°/s/√Hz.
    • DEBE tener una estabilidad de sesgo estacionario de menos de 0.0002 °/s √Hz a partir del conjunto de datos estático de 24 horas.
    • DEBE tener un cambio de sesgo en relación con 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.

  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED con los mismos requisitos de calidad que SENSOR_TYPE_GYROSCOPE

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • DEBEN tener un rango de medición de al menos -900 y +900 uT.
    • DEBE tener una resolución de medición de al menos 5 LSB/uT.
    • 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.
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED con los mismos requisitos de calidad que SENSOR_TYPE_GEOMAGNETIC_FIELD y, además, 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.
  • SENSOR_TYPE_PRESSURE
    • DEBE tener un rango de medición de al menos 300 y 1100 hPa.
    • DEBE tener una resolución de medición de al menos 80 LSB/hPa.
    • DEBEN tener una frecuencia de medición mínima de 1 Hz o menos.
    • DEBEN tener una frecuencia de medición máxima de 10 Hz o superior.
    • DEBE tener un ruido de medición no superior a 2 Pa/√Hz.
    • DEBE implementar una forma no activada de este sensor con una capacidad de almacenamiento en búfer de al menos 300 eventos del sensor.
    • DEBE tener un consumo de energía por lotes no superior a 2 mW.
  • SENSOR_TYPE_GAME_ROTATION_VECTOR
    • 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.
  • SENSOR_TYPE_SIGNIFICANT_MOTION
    • 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.
  • SENSOR_TYPE_STEP_DETECTOR
    • 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.
  • SENSOR_TYPE_STEP_COUNTER
    • 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.
  • SENSOR_TILT_DETECTOR
    • 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.

Además, un dispositivo de este tipo DEBE cumplir con los siguientes requisitos del subsistema de sensores:

  • La marca de tiempo del evento del mismo evento físico que informan el acelerómetro, el sensor de giroscopio y el magnetómetro DEBEN estar dentro de un rango de 2.5 milisegundos entre sí.
  • Las marcas de tiempo de los eventos del sensor de giroscopio DEBEN estar en la misma base de tiempo que el subsistema de la cámara y dentro de un error de 1 milisegundo.
  • Los sensores de alta fidelidad DEBEN entregar muestras a las aplicaciones en un plazo de 5 milisegundos a partir del momento en que los datos están disponibles en el sensor físico para la aplicación.
  • El consumo de energía NO DEBE ser superior a 0.5 mW cuando el dispositivo está estático y a 2.0 mW cuando el dispositivo está en movimiento cuando se habilita cualquier combinación de los siguientes sensores:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

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.

Los siguientes tipos de sensores TAMBIÉN PUEDEN admitirse en una implementación de dispositivo que declare android.hardware.sensor.hifi_sensors, pero si estos tipos de sensores están presentes, DEBEN cumplir con el siguiente requisito mínimo de capacidad de almacenamiento en búfer:

  • SENSOR_TYPE_PROXIMITY: 100 eventos del sensor

7.3.10. Sensor de huellas dactilares

Las implementaciones de dispositivos con una pantalla de bloqueo segura DEBEN incluir un sensor de huellas dactilares. Si una implementación de dispositivo incluye un sensor de huellas dactilares y tiene una API correspondiente para desarrolladores externos, hace lo siguiente:

  • DEBE declarar la compatibilidad con la función android.hardware.fingerprint.
  • DEBEN implementar por completo la API correspondiente como se describe en la documentación del SDK de Android.
  • DEBEN tener un porcentaje de aceptación falso no superior al 0.002%.
  • SE RECOMIENDA ENFATICAMENTE tener un porcentaje de rechazo falso inferior al 10%, medido en el dispositivo.
  • 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 limitar la tasa de intentos durante al menos 30 segundos después de cinco intentos falsos de verificación de huellas dactilares.
  • DEBEN tener una implementación de almacén de claves respaldada por hardware y realizar la coincidencia de huellas dactilares en un entorno de ejecución confiable (TEE) o en un chip con un canal seguro al TEE.
  • DEBEN tener todos los datos de huellas dactilares identificables encriptados y autenticados criptográficamente, de modo que no se puedan adquirir, leer ni alterar fuera del entorno de ejecución confiable (TEE), como se documenta en los lineamientos de implementación del sitio del Proyecto de código abierto de Android.
  • DEBE evitar que se agregue una huella digital 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 TEE. La implementación del proyecto de código abierto de Android proporciona el mecanismo en el framework para hacerlo.
  • NO DEBE permitir que las aplicaciones de terceros distingan entre huellas dactilares individuales.
  • DEBE respetar la marca DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
  • Cuando se actualiza 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.
  • DEBE usar el ícono de huella digital de Android que se proporciona en el Proyecto de código abierto de Android.

7.3.11. Sensores exclusivos de Android Automotive

Los sensores específicos para la industria automotriz se definen en android.car.CarSensorManager API .

7.3.11.1. Cambio actual

Las implementaciones de Android Automotive DEBEN proporcionar la marcha actual como SENSOR_TYPE_GEAR.

7.3.11.2. Modo noche día

Las implementaciones de Android Automotive DEBEN admitir el modo diurno/nocturno definido como SENSOR_TYPE_NIGHT. El valor de esta marca 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.3. Estado de conducción

Las implementaciones de Android Automotive DEBEN admitir el estado de conducción definido como SENSOR_TYPE_DRIVING_STATUS, con un valor predeterminado de DRIVE_STATUS_UNRESTRICTED cuando el vehículo está completamente detenido y estacionado. Los fabricantes de dispositivos son responsables de configurar SENSOR_TYPE_DRIVING_STATUS de conformidad con todas las leyes y reglamentaciones que se aplican a los mercados a los que se envía el producto.

7.3.11.4. Velocidad de las ruedas

Las implementaciones de Android Automotive DEBEN proporcionar la velocidad del vehículo definida como SENSOR_TYPE_CAR_SPEED.

7.3.12. Sensor de pose

Las implementaciones de dispositivos PUEDEN admitir un sensor de pose con 6 grados de libertad. SE RECOMIENDA que los dispositivos de mano Android admitan este sensor. Si una implementación de dispositivo admite el sensor de pose con 6 grados de libertad, hace lo siguiente:

  • DEBEN implementar y generar informes sobre el sensor TYPE_POSE_6DOF.
  • 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 DEBEN informar la función android.hardware.telephony ni ninguna subfunción, independientemente de si usan una red móvil 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. Sin embargo, si una implementación de dispositivo incluye telefonía GSM o CDMA, DEBE implementar la compatibilidad total con la API de esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía DEBEN implementar las APIs completas como no-ops.

7.4.1.1. Compatibilidad con el bloqueo de números

Las implementaciones de dispositivos de telefonía de Android DEBEN incluir compatibilidad con el bloqueo de números y lo siguiente:

  • DEBEN implementar por completo BlockedNumberContract y la API correspondiente como se describe en la documentación del SDK.
  • 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.
  • NO DEBE escribir en el proveedor de registros de llamadas de la plataforma para una llamada bloqueada.
  • NO DEBE escribir al Proveedor de telefonía para un mensaje bloqueado.
  • DEBE implementar una IU de administración de números bloqueados, que se abre con el intent que devuelve el método TelecomManager.createManageBlockedNumbersIntent().
  • NO DEBE permitir que los usuarios secundarios vean o editen los números bloqueados en el dispositivo, ya que la plataforma de Android supone que el usuario principal tiene el control total de los servicios de telefonía, una sola instancia, en el dispositivo. TODA la IU relacionada con el bloqueo DEBE 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.2. IEEE 802.11 (Wi-Fi)

Todas las implementaciones de dispositivos Android DEBEN incluir compatibilidad con una o más formas de 802.11. Si una implementación de dispositivo incluye compatibilidad con 802.11 y expone la funcionalidad a una aplicación de terceros, DEBE implementar la API de Android correspondiente y hacer lo siguiente:

  • DEBE informar la marca de función de hardware android.hardware.wifi.
  • DEBEN implementar la API de multidifusión como se describe en la documentación del SDK.
  • DEBEN admitir el DNS multicast (mDNS) y NO DEBEN filtrar los 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.

7.4.2.1. Wi-Fi directo

Las implementaciones de dispositivos DEBEN incluir compatibilidad con Wi-Fi Direct (Wi-Fi entre pares). Si una implementación de dispositivo incluye compatibilidad con Wi-Fi Direct, DEBE implementar la API de Android correspondiente, como se describe en la documentación del SDK. Si una implementación de dispositivo incluye compatibilidad con Wi-Fi Direct, tiene las siguientes características:

  • DEBE informar la función de hardware android.hardware.wifi.direct.
  • DEBEN admitir el funcionamiento normal de Wi-Fi.
  • DEBE admitir la operación simultánea de Wi-Fi y Wi-Fi Direct.

Las implementaciones de dispositivos DEBEN 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 la implementación de un dispositivo incluye compatibilidad con TDLS y la API de WiFiManager habilita TDLS, el dispositivo hace lo siguiente:

  • 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.3. Bluetooth

Las implementaciones de Android Watch DEBEN ser compatibles con Bluetooth. Las implementaciones de Android TV DEBEN ser compatibles con Bluetooth y Bluetooth LE. Las implementaciones de Android Automotive DEBEN ser compatibles con Bluetooth y DEBEN ser compatibles con Bluetooth LE.

Las implementaciones de dispositivos que admiten la función android.hardware.vr.high_performance DEBEN 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 . Las implementaciones de dispositivos que incluyen compatibilidad con Bluetooth y Bluetooth de bajo consumo DEBEN declarar las funciones relevantes de la plataforma (android.hardware.bluetooth y android.hardware.bluetooth_le, respectivamente) y, además, implementar las APIs de la plataforma. Las implementaciones de dispositivos DEBEN implementar perfiles Bluetooth relevantes, como A2DP, AVCP, OBEX, etc., según corresponda.

Las implementaciones de Android Automotive DEBEN admitir el perfil de acceso a mensajes (MAP). Las implementaciones de Android Automotive DEBEN admitir los siguientes perfiles 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)

Implementaciones de dispositivos que incluyen compatibilidad con Bluetooth de bajo consumo:

  • DEBE declarar la función de hardware android.hardware.bluetooth_le.
  • DEBEN habilitar las APIs de Bluetooth basadas en GATT (perfil de atributos genéricos) como se describe en la documentación del SDK y en android.bluetooth .
  • SE RECOMIENDA ENFATICAMENTE implementar un tiempo de espera de la dirección privada resoluble (RPA) de no más de 15 minutos y rotar la dirección al final del tiempo de espera para proteger la privacidad del usuario.
  • DEBE admitir la descarga de la lógica de filtrado al conjunto de chips Bluetooth cuando se implemente la API de ScanFilter y DEBE informar el valor correcto de la ubicación en la que se implementa la lógica de filtrado cada vez que se consulta a través del método android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
  • DEBE admitir la transferencia del escaneo por lotes al conjunto de chips Bluetooth, pero si no es compatible, DEBE informar "false" cada vez que se consulte a través del método android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
  • DEBE admitir anuncios múltiples con al menos 4 ranuras, pero, si no es compatible, DEBE informar "false" cada vez que se consulte a través del método android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Comunicación de campo cercano

Las implementaciones de dispositivos DEBEN incluir un transceptor y el hardware relacionado para la comunicación de campo cercano (NFC). Si la implementación de un dispositivo incluye hardware NFC y planea ponerlo a disposición de apps de terceros, debe cumplir con los siguientes requisitos:

  • 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:
    • DEBEN ser capaces de actuar como lectores o escritores 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 y 4 (definidos por el NFC Forum)
    • SE RECOMIENDA ENFATICAMENTE que sea capaz de leer y escribir mensajes NDEF, así como datos sin procesar, a través de los siguientes estándares de NFC. Ten en cuenta que, si bien los estándares de NFC que se indican a continuación 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 actualizar a las versiones futuras de la plataforma.
      • NFCv (ISO 15693)
    • 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.
    • DEBEN ser capaces de transmitir y recibir datos a través de los siguientes estándares y protocolos de peer-to-peer:
      • 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)
    • DEBEN incluir compatibilidad con Android Beam .
    • 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.
    • DEBE respetar el intent android.settings.NFCSHARING_SETTINGS para mostrar la configuración de uso compartido de NFC .
    • DEBEN 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.
    • 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.
    • DEBEN 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.
    • DEBE habilitar Android Beam de forma predeterminada y DEBE poder enviar y recibir con Android Beam, incluso cuando se activa otro modo P2P de NFC propietario.
    • DEBE admitir la transferencia de conexión NFC a Bluetooth cuando el dispositivo admita el perfil de inserción de objetos Bluetooth. Las implementaciones de dispositivos DEBEN admitir la transferencia de conexión a Bluetooth cuando se usa android.nfc.NfcAdapter.setBeamPushUris, a través de 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 transferencia de objetos Bluetooth para la transferencia de datos real de Bluetooth. Por motivos heredados (para mantener la compatibilidad 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.
    • DEBE sondear todas las tecnologías compatibles mientras está en el 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.

(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 una implementación de dispositivo incluye un chipset de controlador de NFC capaz de HCE (para NfcA o NfcB) y admite el enrutamiento de ID de aplicación (AID), tiene las siguientes características:

  • DEBE informar la constante de función android.hardware.nfc.hce.
  • DEBEN admitir las APIs de NFC HCE como se define en el SDK de Android.

Si una implementación de un dispositivo incluye un chipset de controlador de NFC capaz de HCE para NfcF y también implementa la función para aplicaciones de terceros, hace lo siguiente:

Además, las implementaciones de dispositivos PUEDEN incluir compatibilidad con lectores/grabadores para las siguientes tecnologías MIFARE.

  • MIFARE Classic
  • MIFARE Ultralight
  • NDEF en MIFARE Classic

Ten en cuenta que Android incluye APIs para estos tipos de MIFARE. Si una implementación de dispositivo admite MIFARE en el rol de lector/escritor, hace lo siguiente:

  • DEBEN implementar las APIs de Android correspondientes, según se documenta en el SDK de Android.
  • DEBE informar la función com.nxp.mifare desde el método android.content.pm.PackageManager.hasSystemFeature(). Ten en cuenta que esta no es una función estándar de Android y, por lo tanto, no aparece como una constante en la clase android.content.pm.PackageManager.
  • NO DEBE implementar las APIs de Android correspondientes ni informar la función com.nxp.mifare, a menos que también implemente la compatibilidad general con NFC como se describe en esta sección.

Si una implementación de dispositivo no incluye hardware NFC, NO DEBE declarar la función android.hardware.nfc desde el método android.content.pm.PackageManager.hasSystemFeature() y DEBE implementar la API de NFC de Android como una operación no realizada.

Como las clases android.nfc.NdefMessage y android.nfc.NdefRecord representan un formato de representación de datos independiente del protocolo, las implementaciones de dispositivos DEBEN implementar estas APIs, incluso si no incluyen compatibilidad con NFC ni declaran la función android.hardware.nfc.

7.4.5. Capacidad de red mínima

Las implementaciones de dispositivos DEBEN 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, PAN de Bluetooth, etcétera.

Las implementaciones de dispositivos en las que un estándar de red física (como Ethernet) es la conexión de datos principal DEBEN incluir compatibilidad con al menos un estándar de datos inalámbrico común, como 802.11 (Wi-Fi).

Los dispositivos PUEDEN implementar más de una forma de conectividad de datos.

Los dispositivos DEBEN 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. El nivel requerido de compatibilidad con IPv6 depende del tipo de red, como se indica a continuación:

  • Los dispositivos que admiten redes Wi-Fi DEBEN admitir el funcionamiento de pila doble y solo IPv6 en Wi-Fi.
  • Los dispositivos que admiten redes Ethernet DEBEN admitir el funcionamiento de pila doble en Ethernet.
  • Los dispositivos que admiten datos móviles DEBEN admitir el funcionamiento de IPv6 (solo IPv6 y, posiblemente, pila doble) en los datos móviles.
  • Cuando un dispositivo está conectado simultáneamente a más de una red (p.ej., Wi-Fi y datos móviles), DEBE cumplir simultáneamente con estos requisitos en cada red a la que se conecte.

IPv6 DEBE estar habilitado de forma predeterminada.

Para garantizar que la comunicación IPv6 sea tan confiable como IPv4, los paquetes unicast IPv6 que se envían al dispositivo NO DEBEN descartarse, incluso cuando la pantalla no está en un estado activo. Es POSIBLE que los paquetes IPv6 multicast redundantes, como los anuncios de router idénticos repetidos, tengan un límite de velocidad en el hardware o el firmware si es necesario para ahorrar energía. En esos casos, 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.

La conectividad IPv6 DEBE mantenerse en modo de suspensión.

7.4.6. Configuración de sincronización

Las implementaciones de dispositivos DEBEN tener la configuración de sincronización automática maestra activada de forma predeterminada para que el método getMasterSyncAutomatically() devuelva “true”.

7.4.7. Ahorro de datos

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos con una conexión de uso medido proporcionen el modo de ahorro de datos.

Si una implementación de dispositivo proporciona el modo de ahorro de datos, hace lo siguiente:

  • DEBE admitir todas las APIs de la clase ConnectivityManager como se describe en la documentación del SDK.

  • DEBE proporcionar una interfaz de usuario en la configuración que permita a los usuarios agregar aplicaciones a la lista de entidades permitidas o quitarlas de ella.

Por el contrario, si una implementación de dispositivo no proporciona el modo Ahorro de datos, sucede lo siguiente:

  • DEBE mostrar el valor RESTRICT_BACKGROUND_STATUS_DISABLED para ConnectivityManager.getRestrictBackgroundStatus().

  • NO DEBEN transmitir ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

  • 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.5. Cámaras

Las implementaciones de dispositivos DEBEN incluir una cámara posterior y PUEDEN incluir una cámara frontal. 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. 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.

Si una implementación de dispositivo incluye al menos una cámara, 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 la vista previa básica y la captura de imágenes fijas.

7.5.1. Cámara posterior

Las implementaciones de dispositivos DEBEN incluir una cámara posterior. Si una implementación de dispositivo incluye al menos una cámara posterior, tiene las siguientes características:

  • DEBEN informar las marcas de función android.hardware.camera y android.hardware.camera.any.
  • 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, 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

Las implementaciones de dispositivos PUEDEN incluir una cámara frontal. Si una implementación de dispositivo incluye al menos una cámara frontal, tiene las siguientes características:

  • DEBEN informar las marcas de función android.hardware.camera.any y android.hardware.camera.front.
  • DEBEN tener una resolución de al menos VGA (640 × 480 píxeles).
  • NO DEBE usar una cámara frontal como la predeterminada de la API de Camera. La API de la cámara en Android tiene compatibilidad específica con las cámaras frontales, y las implementaciones de dispositivos NO DEBEN 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.
  • PUEDEN incluir funciones (como enfoque automático, flash, etc.) disponibles para las cámaras posteriores, como se describe en la sección 7.5.1 .
  • DEBEN reflejar horizontalmente (es decir, duplicar) la transmisión que muestra una app en una CameraPreview, de la siguiente manera:
    • Si el usuario puede rotar la implementación del dispositivo (por ejemplo, automáticamente a través de un acelerómetro o de forma manual a través de la entrada del usuario), la vista previa de la cámara DEBE reflejarse horizontalmente en relación con la orientación actual del dispositivo.
    • Si la aplicación actual solicitó explícitamente que la pantalla de la cámara se gire mediante una llamada al método android.hardware.Camera.setDisplayOrientation(), la vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación especificada por la aplicación.
    • De lo contrario, la vista previa DEBE reflejarse a lo largo del eje horizontal predeterminado del dispositivo.
  • DEBEN 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. Si la implementación del dispositivo no admite la vista posterior, este requisito no se aplica.
  • NO DEBE duplicar las transmisiones de video o imágenes estáticas capturadas finales que se devuelven a las devoluciones de llamada de la aplicación o se confirman en el almacenamiento de contenido multimedia.

7.5.3. Cámara externa

Las implementaciones de dispositivos PUEDEN incluir compatibilidad con una cámara externa que no siempre está conectada. Si un dispositivo incluye compatibilidad con una cámara externa, tiene las siguientes características:

  • DEBES declarar las marcas de funciones de la plataforma android.hardware.camera.external y android.hardware camera.any .
  • PUEDE admitir varias cámaras.
  • DEBE admitir la clase de video USB (UVC 1.0 o superior) si la cámara externa se conecta a través del puerto USB.
  • 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 codificación de video basada en la cámara. Si es compatible, la implementación del dispositivo DEBE tener acceso 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, como debería seguir disponible para que las apps usen 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.

Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara, para todas las cámaras disponibles:

  • Si una aplicación nunca llamó a android.hardware.Camera.Parameters.setPreviewFormat(int), el dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para los datos de vista previa proporcionados a las devoluciones de llamada de la aplicación.
  • Si una aplicación registra una instancia de android.hardware.Camera.PreviewCallback y el sistema llama al método onPreviewFrame() cuando el formato de vista previa es YCbCr_420_SP, los datos en el byte[] que se pasa a onPreviewFrame() deben estar en el formato de codificación NV21. Es decir, NV21 DEBE ser el valor predeterminado.
  • En el caso de android.hardware.Camera, las implementaciones de dispositivos DEBEN admitir el formato YV12 (como se indica en la constante android.graphics.ImageFormat.YV12) para las vistas previas de la cámara, tanto frontal como posterior. (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).
  • En el caso de android.hardware.camera2, las implementaciones de dispositivos deben 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.

Las implementaciones de dispositivos DEBEN implementar la API de Camera completa incluida en la documentación del SDK de Android, independientemente de si el dispositivo incluye enfoque automático de hardware o alguna otra función. Por ejemplo, las cámaras que no tienen enfoque automático DEBEN llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback (aunque esto no sea relevante para una cámara sin enfoque automático). Ten en cuenta que esto se aplica a las cámaras frontales. Por ejemplo, aunque la mayoría de las cámaras frontales no admiten el enfoque automático, las devoluciones de llamada de la API aún deben ser "falsas", como se describe.

Las implementaciones de dispositivos DEBEN reconocer y respetar cada nombre de parámetro definido como una constante en la clase android.hardware.Camera.Parameters, si el hardware subyacente admite la función. Si el hardware del dispositivo no admite una función, la API debe comportarse como se documenta. Por el contrario, las implementaciones de dispositivos NO DEBEN respetar ni reconocer constantes de cadena 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.

Debido a que no todas las implementaciones de dispositivos pueden admitir todas las funciones de la API de android.hardware.camera2, las implementaciones de dispositivos DEBEN 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 correspondientes .

Las implementaciones de dispositivos también DEBEN declarar sus capacidades de cámara individuales de android.hardware.camera2 a través de la propiedad android.request.availableCapabilities y declarar las marcas de función adecuadas. Un dispositivo debe definir la marca de función si alguno de sus dispositivos de cámara conectados admite la función.

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

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

7.5.5. Orientación de la cámara

Si están presentes, las cámaras frontal y posterior DEBEN estar orientadas 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

Los dispositivos Android TV DEBEN tener al menos 4 GB de almacenamiento no volátil disponible para los datos privados de la aplicación.

La memoria disponible para el kernel y el espacio de usuario en las implementaciones de dispositivos DEBE ser, al menos, igual o mayor que los valores mínimos especificados en la siguiente tabla. (Consulta la sección 7.1.1 para ver las definiciones de tamaño y densidad de pantalla).

Densidad y tamaño de pantalla Dispositivo de 32 bits Dispositivo de 64 bits
Dispositivos Android Watch (debido a las pantallas más pequeñas) 416 MB No aplicable
  • 280 dpi o menos en pantallas pequeñas o normales
  • mdpi o inferior en pantallas grandes
  • ldpi o inferior en pantallas extragrandes
512 MB 816 MB
  • xhdpi o superior en pantallas pequeñas o normales
  • hdpi o superior en pantallas grandes
  • mdpi o superior en pantallas extra grandes
608 MB 944 MB
  • 400 dpi o superior en pantallas pequeñas o normales
  • xhdpi o superior en pantallas grandes
  • tvdpi o superior en pantallas extragrandes
896 MB 1,280 MB
  • 560 dpi o superior en pantallas pequeñas o normales
  • 400 dpi o superior en pantallas grandes
  • xhdpi o superior en pantallas extragrandes
1,344 MB 1,824 MB

Los valores de memoria mínimos DEBEN ser adicionales a cualquier espacio de memoria ya dedicado a componentes de hardware, como radio, video, etcétera, que no estén bajo el control del kernel.

Las implementaciones de dispositivos con menos de 512 MB de memoria disponible para el kernel y el espacio de usuario, a menos que sean un reloj Android, DEBEN mostrar el valor "true" para ActivityManager.isLowRamDevice().

Los dispositivos Android TV DEBEN tener al menos 4 GB, y otras implementaciones de dispositivos DEBEN tener al menos 3 GB de almacenamiento no volátil disponible para los datos privados de la aplicación. Es decir, la partición /data DEBE tener al menos 4 GB para dispositivos Android TV y al menos 3 GB para otras implementaciones de dispositivos. Se RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos que ejecutan Android tengan al menos 4 GB de almacenamiento no volátil para los datos privados de la aplicación, de modo que puedan actualizarse a las versiones futuras de la plataforma.

Las APIs de Android incluyen un Administrador de descargas que las aplicaciones PUEDEN usar para descargar archivos de datos. La implementación del Administrador de descargas en el dispositivo DEBE ser capaz 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

Las implementaciones de dispositivos DEBEN ofrecer almacenamiento compartido para aplicaciones, que también se suele denominar "almacenamiento externo compartido".

Las implementaciones de dispositivos DEBEN configurarse con el almacenamiento compartido activado de forma predeterminada, "listo para usar". Si el almacenamiento compartido no está activado en la ruta de acceso de Linux /sdcard, el dispositivo DEBE incluir un vínculo simbólico de Linux desde /sdcard hasta el punto de activación real.

Las implementaciones de dispositivos PUEDEN tener hardware para almacenamiento extraíble al que el usuario pueda acceder, como una ranura para tarjeta Secure Digital (SD). Si se usa este zócalo para satisfacer el requisito de almacenamiento compartido, la implementación del dispositivo hace lo siguiente:

  • DEBE implementar una interfaz de usuario emergente o de notificación breve para advertir al usuario cuando no haya una tarjeta SD.
  • DEBEN incluir una tarjeta SD con formato FAT de 1 GB o superior O indicar en la caja y en el otro material disponible en el momento de la compra que la tarjeta SD se debe comprar por separado.
  • DEBE activar la tarjeta SD de forma predeterminada.

Como alternativa, las implementaciones de dispositivos PUEDEN asignar almacenamiento interno (no extraíble) como almacenamiento compartido para apps, como se incluye en el Proyecto de código abierto de Android upstream. Las implementaciones de dispositivos DEBEN usar esta configuración y la implementación de software. Si una implementación de dispositivo usa almacenamiento interno (no extraíble) para satisfacer el requisito de almacenamiento compartido, si bien ese almacenamiento PUEDE compartir espacio con los datos privados de la aplicación, DEBE tener un tamaño de al menos 1 GB y estar activado en /sdcard (o /sdcard DEBE ser un vínculo simbólico a la ubicación física si está activado en otro lugar).

Las implementaciones de dispositivos DEBEN aplicar, como se documenta, el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido. De lo contrario, cualquier aplicación que obtenga ese permiso DEBE poder escribir en el almacenamiento compartido.

Las implementaciones de dispositivos que incluyen varias rutas de acceso de almacenamiento compartido (como una ranura para tarjeta SD y un almacenamiento interno compartido) DEBEN permitir que solo las aplicaciones para Android preinstaladas y con privilegios que tengan el permiso WRITE_EXTERNAL_STORAGE escriban en el almacenamiento externo secundario, excepto cuando se escriben en sus directorios específicos del paquete o dentro del URI que devuelve el intent ACTION_OPEN_DOCUMENT_TREE.

Sin embargo, las implementaciones de dispositivos DEBEN 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.

Independientemente del tipo de almacenamiento compartido que se use, si la implementación del dispositivo tiene un puerto USB con compatibilidad con el modo periférico USB, DEBE proporcionar algún mecanismo para acceder al contenido del almacenamiento compartido desde una computadora host. Las implementaciones de dispositivos PUEDEN usar el almacenamiento masivo USB, pero DEBEN usar el Protocolo de transferencia multimedia para satisfacer este requisito. Si la implementación del dispositivo admite el Protocolo de transferencia de contenido multimedia, hace 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

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos implementen el almacenamiento adoptable si el puerto del dispositivo de almacenamiento extraíble se encuentra en una ubicación estable a largo plazo, como dentro del compartimento de la batería o en otra cubierta protectora.

Las implementaciones de dispositivos, como una televisión, PUEDEN habilitar la adopción a través de puertos USB, ya que se espera que el dispositivo sea estático y no móvil. Sin embargo, para otras implementaciones de dispositivos que son móviles, SE RECOMIENDA 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.

7.7. USB

Las implementaciones de dispositivos DEBEN admitir el modo de periférico USB y el modo host USB.

7.7.1. Modo periférico USB

Si la implementación de un dispositivo incluye un puerto USB que admite el modo periférico, haz lo siguiente:

  • El puerto DEBE poder conectarse a un host USB que tenga un puerto USB estándar tipo A o tipo C.
  • 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.
  • 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.
  • DEBE permitir que un host USB conectado con el dispositivo Android acceda al contenido del volumen de almacenamiento compartido mediante el almacenamiento masivo en USB o el Protocolo de transferencia de contenido multimedia.
  • DEBE implementar la API y la especificación de Android Open Accessory (AOA) como se documenta en la documentación del SDK de Android y, si es un dispositivo de mano de Android, DEBE implementar la API de AOA. Implementaciones de dispositivos que implementan la especificación de AOA:
    • DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.accessory .
    • DEBEN implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
    • 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.
  • DEBE implementar la compatibilidad para extraer una corriente de 1.5 A durante el chirp y el tráfico HS, como se especifica en la especificación de carga de baterí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.
  • Los dispositivos tipo C DEBEN detectar cargadores de 1.5 A y 3.0 A según el estándar de resistencia tipo C y deben detectar cambios en el anuncio.
  • SE RECOMIENDA ENFATICAMENTE que los dispositivos tipo C que también admitan el modo host USB admitan la entrega de energía para el intercambio de roles de datos y energía.
  • Los dispositivos tipo C DEBEN admitir Power Delivery para la carga de alto voltaje y los modos alternativos, como la salida de pantalla.
  • El valor de iSerialNumber en el descriptor de dispositivo estándar USB DEBE ser igual al valor de android.os.Build.SERIAL.
  • SE RECOMIENDA ENFATICAMENTE que los dispositivos tipo C no admitan 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 cargadores tipo C estándar.

7.7.2. Modo de host USB

Si una implementación de dispositivo incluye un puerto USB que admite el modo host, hace lo siguiente:

  • DEBE usar un puerto USB tipo C si la implementación del dispositivo admite USB 3.1.
  • PUEDE usar un factor de forma de puerto no estándar, pero, de ser así, DEBE enviarse con un cable o cables que adapten el puerto a un puerto USB estándar tipo A o tipo C.
  • PUEDE usar un puerto USB micro-AB, pero, de ser así, DEBE enviarse con un cable o cables que adapten el puerto a un puerto USB estándar tipo A o tipo C.
  • Se RECOMIENDA ENFATICAMENTE implementar la clase de audio USB como se documenta en la documentación del SDK de Android.
  • DEBEN implementar la API de host USB de Android como se documenta en el SDK de Android y DEBEN declarar la compatibilidad con la función de hardware android.hardware.usb.host .
  • DEBE admitir la carga del dispositivo 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 cables y conectores USB tipo C, revisión 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) 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, revisión 1.2 para conectores Micro-AB.
  • SE RECOMIENDA ENFATICAMENTE que los dispositivos USB tipo C admitan DisplayPort, DEBEN admitir velocidades de datos SuperSpeed USB y SE RECOMIENDA ENFATICAMENTE que admitan Power Delivery para el intercambio de roles de datos y energía.
  • Los dispositivos con puertos tipo A o tipo AB NO DEBEN enviarse con un adaptador que convierta este puerto en un receptáculo tipo C.
  • DEBE reconocer cualquier dispositivo MTP (protocolo de transferencia de contenido 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 se admite el framework de acceso al almacenamiento (SAF).
  • SI SE USA UN PUERTO USB TIPO C Y SE INCLUYE COMPATIBILIDAD CON EL MODO PERIFÉRICO, SE DEBE IMPLEMENTAR LA FUNCIÓN DE PUERTO DE DOBLE ROL COMO SE DEFINE EN LA ESPECIFICACIÓN DE USB TIPO C (SECCIÓN 4.5.1.3.3).
  • SI SE ADMITE LA FUNCIÓN DE PUERTO DE DOBLE ROL, DEBE implementarse 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

Las implementaciones de Android para dispositivos móviles, relojes y vehículos DEBEN incluir un micrófono.

Las implementaciones de dispositivos PUEDEN omitir un micrófono. Sin embargo, si una implementación de dispositivo omite un micrófono, NO DEBE informar la constante de la función android.hardware.microphone y DEBE implementar la API de grabación de audio, al menos como no-ops, según la sección 7 . Por el contrario, las implementaciones de dispositivos que sí tienen un micrófono:

  • DEBE informar la constante de función android.hardware.microphone.
  • DEBEN cumplir con los requisitos de grabación de audio de la sección 5.4 .
  • DEBEN cumplir con los requisitos de latencia de audio que se indican en la sección 5.6 .
  • SE RECOMIENDA URGENTEMENTE admitir la grabación de ultrasonido cercano, como se describe en la sección 7.8.3 .

7.8.2. Salida de audio

Es POSIBLE que los dispositivos Android Watch incluyan una salida de audio.

Implementaciones de dispositivos que incluyen una bocina o un puerto de salida de audio/multimedia para un periférico de salida de audio, como auriculares o bocinas externas:

  • DEBE informar la constante de función android.hardware.audio.output.
  • DEBEN cumplir con los requisitos de reproducción de audio de la sección 5.5 .
  • DEBEN cumplir con los requisitos de latencia de audio que se indican en la sección 5.6 .
  • SE RECOMIENDA URGENTEMENTE admitir la reproducción de ultrasonido cercano, como se describe en la sección 7.8.3 .

Por el contrario, si una implementación de dispositivo no incluye una bocina o un puerto de salida de audio, NO DEBE informar la función de salida de android.hardware.audio y DEBE implementar las APIs relacionadas con la salida de audio como no-ops como mínimo.

La implementación de dispositivos Android Watch PUEDE tener una salida de audio, pero NO DEBE tenerla. Sin embargo, otros tipos de implementaciones de dispositivos Android DEBEN tener una salida de audio y declarar android.hardware.audio.output.

7.8.2.1. Puertos de audio analógicos

Para ser compatible con los auriculares y otros accesorios de audio que usan el conector de audio de 3.5 mm en el ecosistema de Android, si la implementación de un dispositivo incluye uno o más puertos de audio analógico, al menos uno de los puertos de audio DEBE ser un conector de audio de 3.5 mm con 4 conductores. Si la implementación de un dispositivo tiene un conector de audio de 3.5 mm de 4 conductores, tiene las siguientes características:

  • DEBEN admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono, y DEBEN admitir la grabación de audio desde auriculares estéreo con micrófono.
  • DEBEN admitir conectores de audio TRRS con el orden de pines CTIA y DEBEN admitir conectores de audio con el orden de pines OMTP.
  • DEBEN admitir la detección del micrófono en el accesorio de audio conectado, si la implementación del dispositivo admite un micrófono, y transmitir android.intent.action.HEADSET_PLUG con el valor adicional del micrófono establecido como 1.
  • DEBEN 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
  • SE RECOMIENDA ENFATICAMENTE 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 Ohm: KEYCODE_VOICE_ASSIST
  • 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.
  • DEBEN ser capaces de generar al menos 150 mV ± 10% de voltaje de salida en una impedancia de bocina de 32 Ohm.
  • DEBE tener un voltaje de polarización del micrófono de entre 1.8 V y 2.9 V.

7.8.3. Ultrasonido de proximidad

El audio cercano al ultrasonido es la banda de 18.5 kHz a 20 kHz. Las 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 "true", las fuentes de audio VOICE_RECOGNITION y UNPROCESSED deben cumplir con los siguientes requisitos:
    • 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.
    • La relación señal/ruido sin ponderar del micrófono de más 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", 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

Las implementaciones de dispositivos de mano de Android que admiten un modo para aplicaciones de RA que controlan la renderización estereoscópica de notificaciones y que inhabilitan los componentes de la IU del sistema monocular mientras una aplicación de RA tiene el enfoque del usuario DEBEN declarar la función android.software.vr.mode. Los dispositivos que declaran esta función DEBEN 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 .

7.9.2. Alto rendimiento de realidad virtual

Las implementaciones de dispositivos de mano de Android DEBEN identificar la compatibilidad con la realidad virtual de alto rendimiento para períodos de uso más largos a través de la marca de función android.hardware.vr.high_performance y cumplir con los siguientes requisitos.

  • Las implementaciones de dispositivos DEBEN tener al menos 2 núcleos físicos.
  • Las implementaciones de dispositivos DEBEN declarar la función android.software.vr.mode.
  • Las implementaciones de dispositivos PUEDEN proporcionar un núcleo exclusivo a la aplicación en primer plano y PUEDEN admitir la API de Process.getExclusiveCores para mostrar los números de los núcleos de CPU que son exclusivos de la aplicación en primer plano. Si se admite el núcleo exclusivo, este 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.
  • Las implementaciones de dispositivos DEBEN admitir el modo de rendimiento sostenido.
  • Las implementaciones de dispositivos DEBEN ser compatibles con OpenGL ES 3.2.
  • Las implementaciones de dispositivos DEBEN ser compatibles con el nivel 0 de hardware de Vulkan y DEBEN ser compatibles con el nivel 1 de hardware de Vulkan.
  • Las implementaciones de dispositivos DEBEN implementar EGL_KHR_mutable_render_buffer y EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync y EGL_KHR_wait_sync para que se puedan usar en el modo de búfer compartido y exponer las extensiones en la lista de extensiones de EGL disponibles.
  • 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.
  • Las implementaciones de dispositivos DEBEN implementar EGL_IMG_context_priority y exponer la extensión en la lista de extensiones de EGL disponibles.
  • Las implementaciones de dispositivos DEBEN implementar GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 y GL_OVR_multiview_multisampled_render_to_texture, y exponer las extensiones en la lista de extensiones de GL disponibles.
  • Las implementaciones de dispositivos DEBEN implementar EGL_EXT_protected_content y GL_EXT_protected_textures para que se puedan usar en la reproducción de video de texturas seguras y exponer las extensiones en la lista de extensiones de EGL y GL disponibles.
  • Las implementaciones de dispositivos DEBEN admitir la decodificación de H.264 de al menos 3840 x 2160 a 30 fps y 40 Mbps (equivalente a 4 instancias de 1920 x 1080 a 30 fps y 10 Mbps o 2 instancias de 1920 x 1080 a 60 fps y 20 Mbps).
  • Las implementaciones de dispositivos DEBEN admitir HEVC y VP9, DEBEN ser capaces de decodificar al menos 1920 × 1080 a 30 fps y 10 Mbps, y DEBEN ser capaces de decodificar 3840 × 2160 a 30 fps y 20 Mbps (equivalente a 4 instancias de 1920 × 1080 a 30 fps y 5 Mbps).
  • SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos admitan la función android.hardware.sensor.hifi_sensors y DEBEN cumplir con los requisitos relacionados con el giroscopio, el acelerómetro y el magnetómetro para android.hardware.hifi_sensors.
  • Las implementaciones de dispositivos DEBEN admitir la API de HardwarePropertiesManager.getDeviceTemperatures y mostrar valores precisos de la temperatura de la piel.
  • La implementación del dispositivo DEBE tener una pantalla incorporada, y su resolución DEBE ser de al menos FullHD(1080p) y SE RECOMIENDA ENFÉMTICAMENTE que sea QuadHD (1440p) o superior.
  • La pantalla DEBE medir entre 4.7" y 6" de diagonal.
  • La pantalla DEBE actualizarse a al menos 60 Hz mientras está en modo VR.
  • La latencia de la pantalla en el tiempo de cambio de gris a gris, de blanco a negro y de negro a blanco DEBE ser inferior o igual a 3 ms.
  • La pantalla DEBE admitir un modo de baja persistencia con una persistencia de ≤5 ms,que se define como la cantidad de tiempo durante la cual un píxel emite luz.
  • Las implementaciones de dispositivos DEBEN admitir Bluetooth 4.2 y la extensión de longitud de datos de Bluetooth LE sección 7.4.3 .

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. Los dispositivos Android Watch DEBEN cumplir con los siguientes criterios, y otros tipos de implementaciones de dispositivos DEBEN hacerlo.

8.1. Coherencia de la experiencia del usuario

Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario fluida, lo que garantiza una velocidad de fotogramas y tiempos de respuesta coherentes para las aplicaciones y los juegos. Las implementaciones de dispositivos DEBEN cumplir con los siguientes requisitos:

  • 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.
  • 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, como lo define el Conjunto de pruebas de compatibilidad (CTS) de Android, en menos de 36 segundos.
  • 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.

8.2. Rendimiento de acceso a la E/S de archivos

Las implementaciones de dispositivos DEBEN garantizar la coherencia del rendimiento de acceso a archivos de almacenamiento interno para las operaciones de lectura y escritura.

  • Escritura secuencial . Las implementaciones de dispositivos DEBEN garantizar un rendimiento de escritura secuencial de al menos 5 MB/s para un archivo de 256 MB con un búfer de escritura de 10 MB.
  • Escritura aleatoria . Las implementaciones de dispositivos DEBEN garantizar un rendimiento de escritura aleatoria de al menos 0.5 MB/s para un archivo de 256 MB con un búfer de escritura de 4 KB.
  • Lectura secuencial . Las implementaciones de dispositivos DEBEN garantizar un rendimiento de lectura secuencial de al menos 15 MB/s para un archivo de 256 MB con un búfer de escritura de 10 MB.
  • Lectura aleatoria . Las implementaciones de dispositivos DEBEN garantizar un rendimiento de lectura aleatoria de al menos 3.5 MB/s para un archivo de 256 MB con un búfer de escritura de 4 KB.

8.3. Modos de ahorro de energía

Android 6.0 introdujo los modos de ahorro de energía App Standby y Descanso para optimizar el uso de batería. Todas las apps exentas de estos modos DEBEN ser visibles para el usuario final. Además, los algoritmos de activación, mantenimiento y activación, y el uso de la configuración del sistema global de estos modos de ahorro de energía NO DEBEN desviarse del Proyecto de código abierto de Android.

Además de los modos de ahorro de energía, las implementaciones de dispositivos Android PUEDEN implementar cualquiera de los 4 estados de energía de suspensión, según se define en la interfaz avanzada de configuración y energía (ACPI), pero si implementan los estados de energía S3 y S4, solo pueden ingresar a estos estados cuando se cierra una tapa que forma parte físicamente del dispositivo.

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. Por lo tanto, las implementaciones de dispositivos tienen las siguientes características:

  • DEBEN poder hacer un seguimiento del consumo de energía de los componentes de hardware y atribuir ese consumo a aplicaciones específicas. Específicamente, las implementaciones hacen lo siguiente:
    • DEBEN proporcionar un perfil de energía por componente que defina el valor de consumo actual de 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.
    • DEBEN informar todos los valores de consumo de energía en miliamperios hora (mAh).
    • 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.
    • 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.
  • 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.
  • DEBE respetar el intent android.intent.action.POWER_USAGE_SUMMARY y mostrar un menú de configuración que muestre este uso de energía.

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.

Las implementaciones de dispositivos DEBEN admitir el modo de rendimiento sostenido, que puede proporcionarle a la aplicación en primer plano un nivel de rendimiento coherente durante un período prolongado cuando se solicita a través del método de la API de Window.setSustainedPerformanceMode(). Una implementación de dispositivo 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().

Las implementaciones de dispositivos con dos o más núcleos de CPU DEBEN proporcionar al menos un núcleo exclusivo que la aplicación en primer plano superior pueda reservar. Si se proporcionan, las implementaciones DEBEN cumplir con los siguientes requisitos:

  • Las implementaciones DEBEN 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.
  • Las implementaciones de dispositivos NO DEBEN permitir ningún proceso de espacio de usuario, excepto los controladores de dispositivos que usa la aplicación para ejecutarse en los núcleos exclusivos, pero PUEDEN permitir que se ejecuten algunos procesos del kernel según sea necesario.

Si una implementación de dispositivo no admite un núcleo exclusivo, DEBE mostrar una lista vacía a través del método de la API de Process.getExclusiveCores().

9. Compatibilidad de modelos de seguridad

Las implementaciones de dispositivos DEBEN implementar un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, como se define en el documento de referencia de seguridad y permisos de las APIs en la documentación para desarrolladores de Android. Las implementaciones de dispositivos DEBEN admitir la instalación de aplicaciones autofirmadas sin requerir permisos ni certificados adicionales de terceros o autoridades. En particular, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad que se describen en las siguientes subsecciones.

9.1. Permisos

Las implementaciones de dispositivos DEBEN admitir el modelo de permisos de Android, como se define en la documentación para desarrolladores de Android. Específicamente, las implementaciones DEBEN aplicar cada permiso definido como se describe en la documentación del SDK. No se pueden omitir, alterar ni ignorar permisos. Las implementaciones PUEDEN agregar permisos adicionales, siempre y cuando las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.*.

Los permisos con un protectionLevel de 'PROTECTION_FLAG_PRIVILEGED' SOLO DEBEN otorgarse a las apps precargadas en las rutas de acceso privilegiadas de la lista de entidades permitidas de la imagen del sistema, como la ruta de acceso system/priv-app en la implementación de AOSP.

Los permisos con un nivel de protección peligroso son permisos de tiempo de ejecución. Las aplicaciones con targetSdkVersion > 22 las solicitan durante el tiempo de ejecución. Implementaciones de dispositivos:

  • DEBEN 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.
  • DEBEN tener una y solo una implementación de ambas interfaces de usuario.
  • NO DEBE otorgar ningún permiso de tiempo de ejecución a las apps preinstaladas, a menos que se cumpla una de las siguientes condiciones:
    • el consentimiento del usuario se puede obtener antes de que la aplicación lo use
    • los permisos de tiempo de ejecución están asociados con un patrón de intent para el que la aplicación preinstalada se establece como el controlador predeterminado

9.2. Aislamiento de UID y procesos

Las implementaciones de dispositivos DEBEN 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. Las implementaciones de dispositivos DEBEN admitir la ejecución de varias aplicaciones como el mismo ID de usuario de Linux, siempre que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de seguridad y permisos .

9.3. Permisos del sistema de archivos

Las implementaciones de dispositivos DEBEN 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 PUEDEN incluir entornos de ejecución que ejecuten aplicaciones con algún otro software o tecnología que no sea el formato ejecutable de Dalvik o el código nativo. Sin embargo, estos entornos de ejecución alternativos NO DEBEN poner en riesgo el modelo de seguridad de Android ni la seguridad de las aplicaciones de Android instaladas, como se describe en esta sección.

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 .

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

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.

Los entornos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android. Específicamente, los entornos de ejecución alternativos:

  • DEBE instalar apps a través de PackageManager en zonas de pruebas de Android independientes (IDs de usuario de Linux, etc.).
  • PUEDE proporcionar una sola zona de pruebas de Android que compartan todas las aplicaciones que usan el entorno de ejecución alternativo.
  • Las aplicaciones instaladas que usan un entorno 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.
  • NO DEBE iniciarse con acceso a las zonas de pruebas correspondientes a otras aplicaciones para Android, ni otorgarlo ni recibirlo.
  • NO DEBEN iniciarse con privilegios de superusuario (root) ni otorgarlos a otras aplicaciones, ni tampoco otorgarlos a otras aplicaciones.

Los archivos .apk de tiempos de ejecución alternativos PUEDEN incluirse en la imagen del sistema de una implementación de dispositivo, pero DEBEN estar firmados con una clave distinta de la que se usa para firmar otras aplicaciones incluidas con la implementación del dispositivo.

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

9.5. Compatibilidad con varios usuarios

Esta función es opcional para todos los tipos de dispositivos.

Android incluye compatibilidad con varios usuarios y proporciona compatibilidad con el aislamiento total de usuarios. Las implementaciones de dispositivos PUEDEN habilitar varios usuarios, pero, cuando se habilitan, DEBEN cumplir con los siguientes requisitos relacionados con la compatibilidad con varios usuarios :

  • Las implementaciones de dispositivos Android Automotive con compatibilidad multiusuario habilitada DEBEN incluir una cuenta de invitado que permita todas las funciones que proporciona el sistema del vehículo sin que el usuario deba acceder.
  • Las implementaciones de dispositivos que no declaran la marca de función android.hardware.telephony DEBEN admitir perfiles restringidos, una función que permite a los propietarios de dispositivos administrar usuarios adicionales y sus capacidades en el dispositivo. Con los perfiles restringidos, los propietarios de dispositivos pueden configurar rápidamente entornos separados para que otros usuarios trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
  • Por el contrario, las implementaciones de dispositivos que declaran la marca de función android.hardware.telephony NO DEBEN admitir perfiles restringidos, pero DEBEN alinearse con la implementación de controles de AOSP para habilitar o inhabilitar que otros usuarios accedan a las llamadas de voz y los SMS.
  • Las implementaciones de dispositivos DEBEN implementar, para cada usuario, un modelo de seguridad coherente con el modelo de seguridad de la plataforma de Android, como se define en el documento de referencia de seguridad y permisos de las APIs.
  • Cada instancia de usuario en un dispositivo Android DEBE tener directorios de almacenamiento externo separados y aislados. Las implementaciones de dispositivos PUEDEN almacenar datos de varios usuarios en el mismo volumen o sistema de archivos. Sin embargo, la implementación del dispositivo DEBE garantizar que las aplicaciones que pertenecen a un usuario determinado y se ejecutan en su nombre no puedan enumerar, leer ni escribir datos que pertenezcan a ningún otro usuario. Ten en cuenta que los medios extraíbles, como las ranuras para tarjetas SD, pueden permitir que un usuario acceda a los datos de otro a través de una PC host. Por este motivo, las implementaciones de dispositivos que usan medios extraíbles para las APIs de almacenamiento externo DEBEN encriptar el contenido de la tarjeta SD si se habilita el modo multiusuario con una clave almacenada solo en medios no extraíbles a los que solo pueda acceder el sistema. 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. Por lo tanto, las implementaciones de dispositivos PUEDEN, pero NO DEBEN, habilitar el modo multiusuario si usan contenido multimedia extraíble para el almacenamiento externo principal.

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. Las implementaciones de dispositivos que declaran compatibilidad con android.hardware.telephony DEBEN 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 del kernel

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. SELinux o cualquier otra función de seguridad implementada debajo del framework de Android:

  • DEBEN mantener la compatibilidad con las aplicaciones existentes.
  • NO DEBE tener una interfaz de usuario visible cuando se detecta una violación de seguridad y se bloquea correctamente, pero PUEDE tener una interfaz de usuario visible cuando se produce una violación de seguridad no bloqueada que genera un exploit exitoso.
  • NO DEBE ser configurable por el usuario ni por el desarrollador.

Si alguna API para la configuración de políticas está expuesta a una aplicación que puede afectar a otra (como una API de administración de dispositivos), la API NO DEBE permitir configuraciones que rompan la compatibilidad.

Los dispositivos DEBEN implementar SELinux o, si usan un kernel que no sea Linux, un sistema de control de acceso obligatorio equivalente. Los dispositivos TAMBIÉN DEBEN cumplir con los siguientes requisitos, que se satisfacen con la implementación de referencia en el Proyecto de código abierto de Android upstream.

Implementaciones de dispositivos:

  • DEBES configurar SELinux en el modo de aplicación forzosa global.
  • 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.
  • 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.
  • DEBEN 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.

Las implementaciones de dispositivos DEBEN 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. Las implementaciones de dispositivos DEBEN ser compatibles con el proyecto de código abierto de Android upstream.

Los dispositivos DEBEN implementar un mecanismo de zona de pruebas de aplicaciones del kernel que permita filtrar las llamadas del sistema con una política configurable desde programas de varios subprocesos. El Proyecto de código abierto de Android upstream cumple con este requisito habilitando seccomp-BPF con sincronización de grupos de subprocesos (TSYNC), como se describe en la sección Configuración del kernel de source.android.com .

9.8. Privacidad

Si el dispositivo implementa una funcionalidad en el sistema que captura el contenido que se muestra en la pantalla o graba la transmisión de audio que se reproduce en el dispositivo, DEBE notificar al usuario de forma continua cada vez que esta funcionalidad esté habilitada y esté capturando o grabando de forma activa.

Si una implementación de dispositivo tiene un mecanismo que enruta el tráfico de datos de red a través de un servidor proxy o una puerta de enlace de VPN de forma predeterminada (por ejemplo, la carga previa de un servicio de VPN con android.permission.CONTROL_VPN otorgado), la implementación del dispositivo DEBE solicitar el consentimiento del usuario antes de habilitar ese mecanismo, a menos que el controlador de políticas de dispositivos habilite esa VPN a través de DevicePolicyManager.setAlwaysOnVpnPackage() , en cuyo caso el usuario no necesita proporcionar un consentimiento independiente, pero DEBE recibir una notificación.

Las implementaciones de dispositivos DEBEN enviarse con un almacén de la autoridad certificadora (AC) vacío agregado por el usuario y DEBEN preinstalar los mismos certificados raíz para el almacén de AC de confianza del sistema que se proporciona en el proyecto de código abierto de Android upstream.

Cuando los dispositivos se enrutan a través de una VPN o se instala una AC raíz del usuario, la implementación DEBE mostrar una advertencia que indique al usuario que se puede supervisar el tráfico de red.

Si la implementación de un dispositivo tiene un puerto USB con compatibilidad con el modo periférico USB, 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.9. Encriptación de almacenamiento de datos

Opcional para implementaciones de dispositivos Android sin una pantalla de bloqueo segura.

Si la implementación del dispositivo admite una pantalla de bloqueo segura, como se describe en el artículo 9.11.1, el dispositivo DEBE admitir la encriptación de almacenamiento de datos de los datos privados de la aplicación (partición /data) y la partición de almacenamiento compartido de la aplicación (partición /sdcard) si es una parte permanente y no extraíble del dispositivo.

En el caso de las implementaciones de dispositivos que admiten la encriptación del almacenamiento de datos y con un rendimiento de criptografía del estándar de encriptación avanzada (AES) superior a 50 MiB/s, la encriptación del almacenamiento de datos DEBE estar habilitada de forma predeterminada en el momento en que el usuario completa la experiencia de configuración lista para usar. Si ya se lanzó una implementación de dispositivo en una versión anterior de Android con la encriptación inhabilitada de forma predeterminada, ese dispositivo no puede cumplir con el requisito mediante una actualización de software del sistema y, por lo tanto, PUEDE estar exento.

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

Todos los dispositivos DEBEN implementar las APIs del modo de inicio directo, incluso si no admiten la encriptación de almacenamiento. En particular, los intents LOCKED_BOOT_COMPLETED y ACTION_USER_UNLOCKED aún deben transmitirse para indicar a las aplicaciones que admiten el inicio directo que las ubicaciones de almacenamiento encriptadas por el dispositivo (DE) y encriptadas por credenciales (CE) están disponibles para el usuario.

9.9.2. Encriptación basada en archivos

Implementaciones de dispositivos compatibles con FBE:

  • DEBEN iniciarse sin solicitar credenciales al usuario y permitir que las apps compatibles con el inicio directo accedan al almacenamiento encriptado por dispositivo (DE) después de que se transmita el mensaje LOCKED_BOOT_COMPLETED.
  • SOLO DEBE permitir el acceso al almacenamiento encriptado por credenciales (CE) después de que el usuario desbloquee el dispositivo con sus credenciales (p. ej., contraseña, PIN, patrón o huella dactilar) y se transmita el mensaje ACTION_USER_UNLOCKED. Las implementaciones de dispositivos NO DEBEN ofrecer ningún método para desbloquear el almacenamiento protegido por CE sin las credenciales que proporciona el usuario.
  • 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.
  • DEBE admitir la encriptación del contenido de los archivos con AES con una longitud de clave de 256 bits en modo XTS.
  • DEBE admitir la encriptación del nombre de archivo con AES con una longitud de clave de 256 bits en modo CBC-CTS.
  • PUEDE admitir algoritmos de cifrado, longitudes de claves y modos alternativos para la encriptación de nombres y contenido de archivos, pero DEBE usar los algoritmos de cifrado, longitudes de claves y modos admitidos de forma obligatoria de forma predeterminada.
  • DEBE hacer que las apps esenciales precargadas (p.ej., Alarm, Phone, Messenger) sean compatibles con el inicio directo.

Las claves que protegen las áreas de almacenamiento de CE y DE:

  • DEBEN estar vinculados de forma criptográfica a un almacén de claves con copia de seguridad en hardware. Las claves de CE deben estar vinculadas a las credenciales de la pantalla de bloqueo de un usuario. Si el usuario no especificó credenciales de pantalla de bloqueo, las claves de CE DEBEN estar vinculadas a una contraseña predeterminada.
  • DEBEN ser únicas y distintas. En otras palabras, ninguna clave de CE o DE de un usuario puede coincidir con las claves de CE o DE de ningún otro usuario.

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

Implementaciones de dispositivos compatibles con la encriptación de disco completo (FDE). DEBE usar AES con una clave de 128 bits (o superior) y un modo diseñado para el almacenamiento (por ejemplo, AES-XTS, AES-CBC-ESSIV). La clave de encriptación NO DEBE escribirse en el almacenamiento en ningún momento sin encriptarse. SE DEBE proporcionar al usuario la posibilidad de encriptar la clave de encriptación con AES, 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). Si el usuario no especificó credenciales de pantalla de bloqueo o inhabilitó el uso de la contraseña para la encriptación, el sistema DEBE usar una contraseña predeterminada para unir la clave de encriptación. Si el dispositivo proporciona un almacén de claves con copia de seguridad en hardware, el algoritmo de estiramiento de contraseña DEBE estar vinculado criptográficamente a ese almacén de claves. La clave de encriptación NO DEBE enviarse fuera del dispositivo (incluso cuando se une 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.

Las implementaciones de dispositivos DEBEN informar correctamente a través del método PersistentDataBlockManager.getFlashLockState() de la API del sistema si el estado del bootloader permite la escritura en la memoria flash 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.

El inicio verificado es una función que garantiza la integridad del software del dispositivo. Si una implementación de dispositivo admite la función, DEBE cumplir con los siguientes requisitos:

  • Declara la marca de función de la plataforma android.software.verified_boot.
  • Realiza la verificación en cada secuencia de inicio.
  • Inicia la verificación desde una clave de hardware inmutable que sea la raíz de confianza y llega hasta la partición del sistema.
  • Implementa 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.
  • Usa 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).
  • 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.
  • NO DEBE permitir que se modifiquen las particiones verificadas del dispositivo, a menos que el usuario haya desbloqueado explícitamente el cargador de arranque.

El Proyecto de código abierto de Android upstream proporciona una implementación preferida de esta función basada en la función dm-verity del kernel de Linux.

A partir de Android 6.0, las implementaciones de dispositivos con un rendimiento de criptografía de Advanced Encryption Standard (AES) superior a 50 MiB/segundo DEBEN admitir el inicio verificado para la integridad del dispositivo.

Si ya se lanzó una implementación de dispositivo sin admitir el inicio verificado en una versión anterior de Android, ese dispositivo no puede agregar compatibilidad con esta función con una actualización de software del sistema y, por lo tanto, está exento del requisito.

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 .

Todas las implementaciones de dispositivos Android DEBEN cumplir con los siguientes requisitos:

  • NO DEBE limitar la cantidad de claves que se pueden generar y DEBE permitir, al menos, que se importen más de 8,192 claves.
  • La autenticación de la pantalla de bloqueo DEBE tener un límite de frecuencia de 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.
  • Cuando la implementación del dispositivo admite una pantalla de bloqueo segura, DEBE crear una copia de seguridad de la implementación del almacén de claves con hardware seguro y cumplir con los siguientes requisitos:
    • DEBEN 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 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.
    • 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. 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.

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 con copia de seguridad en hardware, a menos que declare la función android.hardware.fingerprint, que requiere un almacén de claves con copia de seguridad en hardware.

9.11.1. Pantalla de bloqueo segura

Las implementaciones de dispositivos PUEDEN agregar o modificar los métodos de autenticación para desbloquear la pantalla de bloqueo, pero DEBEN cumplir con los siguientes requisitos:

  • Si el método de autenticación se basa en un secreto conocido, NO DEBE tratarse como una pantalla de bloqueo segura, a menos que cumpla con todos los siguientes requisitos:
    • La entropía de la longitud más corta permitida de las entradas DEBE ser mayor que 10 bits.
    • La entropía máxima de todas las entradas posibles DEBE ser superior a 18 bits.
    • NO DEBE reemplazar ninguno de los métodos de autenticación existentes (PIN, patrón o contraseña) implementados y proporcionados en AOSP.
    • DEBE estar inhabilitado cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de calidad de la contraseña a través del método DevicePolicyManager.setPasswordQuality() con una constante de calidad más restrictiva que PASSWORD_QUALITY_SOMETHING .
  • Si el método de autenticación se basa en un token físico o la ubicación, NO DEBE tratarse como una pantalla de bloqueo segura, a menos que cumpla con todos los siguientes requisitos:
    • DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales que se base en un secreto conocido y cumpla con los requisitos para que se considere una pantalla de bloqueo segura.
    • DEBE estar inhabilitada y solo permitir que la autenticación principal desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (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 .
  • Si el método de autenticación se basa en datos biométricos, NO DEBE tratarse como una pantalla de bloqueo segura, a menos que cumpla con todos los siguientes requisitos:
    • DEBE tener un mecanismo de resguardo para usar uno de los métodos de autenticación principales que se base en un secreto conocido y cumpla con los requisitos para que se considere una pantalla de bloqueo segura.
    • DEBE estar inhabilitada y solo permitir que la autenticación principal desbloquee la pantalla cuando la aplicación del controlador de política de dispositivo (DPC) haya establecido la política de la función de bloqueo de teclas llamando al método DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) .
    • DEBE tener una tasa de aceptación falsa igual o más estricta que la requerida para un sensor de huellas dactilares, como se describe en el artículo 7.3.10, o DEBE estar inhabilitado y solo permitir que la autenticación principal desbloquee la pantalla cuando la aplicación del controlador de políticas de dispositivos (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_BIOMETRIC_WEAK .
  • Si el método de autenticación no se puede considerar una pantalla de bloqueo segura, sucederá lo siguiente:
  • Si el método de autenticación se basa en un token físico, la ubicación o los datos biométricos que tienen una tasa de aceptación falsa más alta que la requerida para los sensores de huellas dactilares, como se describe en la sección 7.3.10, sucede lo siguiente:

9.12. Eliminación de Datos

Los dispositivos DEBEN proporcionar a los usuarios un mecanismo para realizar un "Restablecimiento de datos de fábrica" que permita la eliminación lógica y física de todos los datos, excepto los siguientes:

  • La imagen del sistema
  • Cualquier archivo del sistema operativo que requiera la imagen del sistema

SE DEBEN borrar todos los datos generados por el usuario. Esto DEBE satisfacer los estándares relevantes de la industria para la eliminación de datos, como NIST SP800-88. SE DEBE usar para la implementación de la API de wipeData() (parte de la API de administración de dispositivos de Android) que se describe en la sección 3.9 Administración de dispositivos .

Es POSIBLE que los dispositivos proporcionen una limpieza de datos rápida que realice un borrado lógico de los datos.

9.13. Modo de inicio seguro

Android proporciona un modo que permite a los usuarios iniciar 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 permite al usuario desinstalar apps de terceros potencialmente dañinas.

SE RECOMIENDA ENFATICAMENTE que las implementaciones de dispositivos Android implementen el modo de arranque seguro y cumplan con los siguientes requisitos:

  • Las implementaciones de dispositivos DEBEN proporcionar al usuario una opción para ingresar al modo de arranque seguro desde el menú de inicio, al que se puede acceder a través de un flujo de trabajo diferente al del inicio normal.

  • Las implementaciones de dispositivos DEBEN proporcionar al usuario una opción para ingresar al modo de inicio seguro de una manera que no se pueda interrumpir 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.

  • Las implementaciones de dispositivos DEBEN proporcionar al usuario la capacidad de desinstalar cualquier app de terceros en el modo seguro.

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, p.ej., mediante el HAL del vehículo para enviar y recibir mensajes a través de redes de vehículos, como el bus CAN. Las implementaciones de dispositivos Android Automotive DEBEN implementar funciones de seguridad debajo de las capas del framework de Android para evitar interacciones maliciosas o no intencionales entre el framework de Android o las apps de terceros y los subsistemas del vehículo. Estas funciones de seguridad son las siguientes:

  • Control de acceso de mensajes de los subsistemas de vehículos del framework de Android, p. ej., la lista de entidades permitidas de tipos y fuentes de mensajes permitidos
  • Supervisor contra ataques de denegación del servicio del framework de Android o 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.

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)

Las implementaciones de dispositivos DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android disponible en el Proyecto de código abierto de Android con el software de envío final en el dispositivo. Además, los implementadores de dispositivos DEBEN usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible y DEBEN garantizar la compatibilidad en caso de ambigüedad 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 7.1. Las implementaciones de dispositivos DEBEN aprobar la versión más reciente de CTS disponible en el momento en que se completa el software del dispositivo.

10.2. Verificador del CTS

Las implementaciones de dispositivos DEBEN ejecutar correctamente todos los casos aplicables en el verificador de 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 los sensores.

El verificador del CTS tiene pruebas para muchos tipos de hardware, incluido algunos que son opcionales. Las implementaciones de dispositivos 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.

Todos los dispositivos y todas las compilaciones DEBEN ejecutar correctamente el verificador de CTS, como se señaló 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

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

Sin embargo, si la implementación del dispositivo incluye compatibilidad con una conexión de datos sin medición, como el perfil 802.11 o PAN (red de área personal) de Bluetooth, DEBE admitir descargas inalámbricas con actualización sin conexión a través de un reinicio.

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.

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 un binario idéntico 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 del producto que se determina en consulta con el equipo de compatibilidad de Android y que afecta la compatibilidad de las aplicaciones de terceros, 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. Para facilitar esto, el subsistema de actualización del sistema para dispositivos que informan android.software.device_admin 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:

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 del documento
  13. Comunicarte con nosotros

12.1. Sugerencias para ver el registro de cambios

Los cambios se marcan de la siguiente manera:

  • CDD
    Cambios sustanciales en los requisitos de compatibilidad.

  • Documentos
    Cambios estéticos o relacionados con la compilación.

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