Revisión 1
Última actualización: 12 de enero de 2015
Copyright © 2015, Google Inc. Todos los derechos reservados.
compatibility@android.com
Índice
1. Introducción
En este documento, se enumeran los requisitos que deben cumplir los dispositivos para ser compatibles con Android 5.0.
El uso de los términos "DEBER", "NO DEBER", "REQUERIDO", "DEBEN", "NO DEBEN", "DEBEN", "NO DEBEN", "RECOMENDADO", "PUEDEN" y "OPCIONAL" se realiza de acuerdo con el estándar de la IETF definido en RFC2119 [Recursos, 1].
Según se usa en 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 5.0. Una “implementación de dispositivos” o “implementación” es la solución de hardware y software que se desarrolló.
Para que se consideren compatibles con Android 5.0, 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 [Recursos, 2] es la implementación de referencia y preferida de Android. Se recomienda a los implementadores de dispositivos que basen sus implementaciones en la medida de lo posible en el código fuente "upstream" disponible en el Proyecto de código abierto de Android. Si bien, hipotéticamente, algunos componentes se pueden reemplazar con implementaciones alternativas, se desaconseja 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 que se enumeran en la sección 14 se derivan directamente o indirectamente del SDK de Android y serán funcionalmente idénticos a la información de la documentación de ese SDK. En cualquier caso en el que esta definición de compatibilidad o el conjunto de pruebas de compatibilidad no coincidan con la documentación del SDK, la documentación del SDK se considerará oficial. Cualquier detalle técnico que se proporcione en las referencias incluidas en la sección 14 se considera 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 con 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.
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 sillón reclinable" o "de 10 pies"). 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 [Recursos, 3].
Dispositivo de reloj Android hace referencia a una implementación de dispositivo Android diseñada para usarse en el cuerpo, quizás en la muñeca, y que tiene las siguientes características:
- DEBE 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 [Resources, 4]
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 5.0, a menos que se describa explícitamente que el requisito solo se aplica a un tipo de dispositivo Android específico.
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 |
Nombre de la |
Sección |
Dispositivos de mano |
Televisión |
Reloj |
Otro |
|
Entrada |
Pad direccional |
DEBER |
||||
|
Pantalla táctil |
DEBER |
DEBER |
DEBE |
|||
|
Micrófono |
DEBER |
DEBE |
DEBER |
DEBE |
||
|
Sensores |
Acelerómetro |
DEBE |
DEBE |
DEBE |
||
|
GPS |
DEBE |
|||||
|
Conectividad |
Wi-Fi |
DEBE |
DEBER |
DEBE |
||
|
Wi-Fi directo |
DEBE |
DEBE |
DEBE |
|||
|
Bluetooth |
DEBE |
DEBER |
DEBER |
DEBE |
||
|
Bluetooth de bajo consumo |
DEBE |
DEBER |
DEBE |
DEBE |
||
|
Modo de host o periférico USB |
DEBE |
|
DEBE |
|||
|
Salida |
Puertos de salida de audio o bocinas |
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 tiempo 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 [Recursos, 5] o cualquier API decorada con el marcador "@SystemApi" en el código fuente de Android upstream.
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 de forma específica.
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.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 [Recursos, 6]. 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 [Recursos, 7] 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 [Recursos, 8]. |
|
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 5.0, este campo DEBE tener el valor de número entero 21. |
|
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 5.0, este campo DEBE tener el valor de número entero 21. |
|
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, en formato legible por humanos. Este valor NO se DEBE volver a usar para diferentes compilaciones que se ponen a disposición de los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de código fuente se usó para generar la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni una cadena vacía (""). |
|
JUEGOS DE MESA |
Es un valor que elige el implementador del dispositivo que identifica el hardware interno específico que usa el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9_-]+$". |
|
SEGURIDAD |
Es un valor que refleja el nombre de la marca asociado con el dispositivo, tal como lo conocen los usuarios finales. DEBEN estar en formato legible por humanos y DEBEN representar al fabricante del dispositivo o la marca de la empresa con la que se comercializa el dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9_-]+$". |
|
SUPPORTED_ABIS |
Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
|
SUPPORTED_32_BIT_ABIS |
Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
|
SUPPORTED_64_BIT_ABIS |
Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
|
CPU_ABI |
Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
|
CPU_ABI2 |
Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta la sección 3.3. Compatibilidad con la API nativa. |
|
DISPOSITIVO |
Es un valor que elige el implementador del dispositivo y que contiene el nombre de desarrollo o el nombre de código que identifica la configuración de las funciones de hardware y el diseño industrial del dispositivo. El valor de este campo DEBE poder codificarse como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9_-]+$". |
|
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:5.0/LRWXX/3359:userdebug/test-keys La huella digital NO DEBE incluir caracteres de espacio en blanco. Si otros campos incluidos en la plantilla anterior tienen caracteres de espacio en blanco, DEBEN reemplazarse en la huella digital de compilación por otro carácter, como el 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 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 como lo conoce el usuario final. DEBE ser el mismo nombre con el que se comercializa y se 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_-]+$". |
|
SERIAL |
Un número de serie de hardware que DEBE estar disponible. El valor de este campo DEBE 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 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 (""). |
3.2.3. Compatibilidad con intents
Las implementaciones de dispositivos DEBEN respetar el sistema de intents de vinculación flexible de Android, como se describe en las siguientes secciones. Cuando se dice que se "respeta", se refiere a que el implementador del dispositivo DEBE proporcionar una actividad o un servicio de Android que especifique un filtro de intents coincidente que se vincule y que implemente el comportamiento correcto para cada patrón de intents especificado.
3.2.3.1. Intents de la aplicación principales
Los intents de Android permiten que los componentes de la aplicación soliciten funcionalidades de otros componentes de Android. El proyecto upstream de Android incluye una lista de aplicaciones 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, pero DEBEN incluir un componente que implemente los mismos patrones de intents definidos por todos los componentes de actividad o servicio "públicos" de estas aplicaciones principales de Android. Ten en cuenta que los componentes de Activity o Service se consideran "públicos" cuando no está presente el atributo android:exported o tiene el valor verdadero.
3.2.3.2. Anulaciones de intents
Como Android es una plataforma extensible, las implementaciones de dispositivos DEBEN permitir que las aplicaciones de terceros anulen cada patrón de intent al que se hace referencia en la sección 3.2.3.1. La implementación de código abierto de Android upstream permite esto 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, 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.
Sin embargo, las implementaciones de dispositivos PUEDEN proporcionar actividades predeterminadas para patrones de URI específicos (p. ej., http://play.google.com) si la actividad predeterminada proporciona un filtro más específico para el URI de datos. Por ejemplo, un filtro de intents que especifica el URI de datos "http://www.android.com" es más específico que el filtro del navegador para "http://". Las implementaciones de dispositivos DEBEN proporcionar una interfaz de usuario para que los usuarios modifiquen la actividad predeterminada de los intents.
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 ningún componente de Android que respete ningún intent nuevo o patrones de intent de transmisión con una ACTION, CATEGORY o alguna otra cadena clave en 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 obvia con su propia organización. Esta prohibición es similar a la especificada para las clases del lenguaje Java en la sección 3.6.
3.2.3.4. Intents de transmisión
Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intents y notificarles sobre los cambios en el entorno de hardware o software. 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 la app predeterminada para la pantalla principal, si la implementación del dispositivo informa android.software.home_screen [Resources, 10]
- DEBE proporcionar un menú de configuración que llame al intent android.provider.Telephony.ACTION_CHANGE_DEFAULT para mostrar un diálogo para cambiar la aplicación de SMS predeterminada, si la implementación del dispositivo informa android.hardware.telephony [Recursos, 9].
- DEBE respetar el intent android.settings.NFC_PAYMENT_SETTINGS para mostrar un menú de configuración predeterminado de la app para el pago sin contacto, si la implementación del dispositivo informa android.hardware.nfc.hce [Recursos, 10]
3.3. Compatibilidad con la API nativa
3.3.1 Interfaces binarias de la aplicación
El código de bytes de Dalvik administrado puede llamar al código nativo proporcionado en el archivo .apk de la aplicación como un archivo .so ELF compilado para la arquitectura de hardware del dispositivo adecuada. Como el código nativo depende en gran medida de la tecnología del procesador subyacente, Android define una serie de interfaces binarias de aplicación (ABI) en el NDK de Android. 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:
- DEBE incluir compatibilidad con el código que se ejecuta en el entorno administrado para llamar al código nativo con la semántica estándar de la interfaz nativa de Java (JNI).
- DEBEN ser compatibles con la fuente (es decir, con el encabezado) y con el código binario (para la ABI) con cada biblioteca requerida de la siguiente lista.
- 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 en la versión más reciente del NDK de Android, "NDK Programmer's Guide | ABI Management" en el directorio docs/.
- DEBE compilarse con el código fuente y los archivos de encabezado disponibles en el proyecto de código abierto de Android upstream.
Las siguientes APIs de código nativo DEBEN estar disponibles para las apps que incluyen código nativo:
- libc (biblioteca C)
- libm (biblioteca matemática)
- Compatibilidad mínima con C++
- Interfaz de JNI
- liblog (registro de Android)
- libz (compresión zlib)
- libdl (vinculador dinámico)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libEGL.so (administración nativa de la superficie de OpenGL)
- libjnigraphics.so
- libOpenSLES.so (Compatibilidad con audio de OpenSL ES 1.0.1)
- libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
- libandroid.so (compatibilidad con actividades nativas de Android)
- libmediandk.so (compatibilidad con APIs de contenido multimedia nativas)
- Compatibilidad con OpenGL, como se describe a continuación
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.
Ten en cuenta que las implementaciones de dispositivos DEBEN incluir libGLESv3.so y DEBEN crear un symlink (vínculo simbólico) a libGLESv2.so. A su vez, DEBEN exportar todos los símbolos de función de OpenGL ES 3.1 y el paquete de extensión de Android [Recursos, 11] como se define en la versión android-21 del NDK. Aunque todos los símbolos deben estar presentes, solo las funciones correspondientes para las versiones y extensiones de OpenGL ES que el dispositivo admite deben implementarse por completo.
La compatibilidad con el código nativo es un desafío. Por este motivo, se recomienda encarecidamente a los implementadores de dispositivos que usen las implementaciones de las bibliotecas mencionadas anteriormente desde el proyecto de código abierto de Android upstream.
3.4. Compatibilidad web
3.4.1. Compatibilidad con WebView
|
La implementación completa de la API de android.webkit.Webview PUEDE proporcionarse en dispositivos Android Watch, pero DEBE proporcionarse en todos los demás tipos de implementaciones de dispositivos. |
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 [Recursos, 12]. 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 5.0. Esta compilación incluye un conjunto específico de correcciones de funcionalidad y seguridad para WebView [Recursos, 13].
- La cadena de usuario-agente que informa WebView DEBE tener el siguiente formato:
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)) 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 [Recursos, 14].
3.4.2. Compatibilidad del navegador
|
Los dispositivos Android TV y de reloj 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 que se base en la aplicación de navegador WebKit upstream o en un reemplazo de terceros) DEBE incluir compatibilidad con la mayor cantidad posible de HTML5 [Recursos, 14]. Como mínimo, las implementaciones de dispositivos DEBEN admitir cada una de estas APIs asociadas con HTML5:
- caché de la aplicación/operación sin conexión [Recursos, 15]
- la etiqueta
- geolocation [Resources, 17]
Además, las implementaciones de dispositivos DEBEN admitir la API de HTML5/W3C WebStorage [Recursos, 18] y DEBEN admitir la API de HTML5/W3C IndexedDB [Recursos, 19]. 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 [Recursos, 2]. 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 tales 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 para uso interno, pero esas modificaciones NO DEBEN anunciarse ni exponerse de otra manera 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
Si un implementador de dispositivos propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando una funcionalidad nueva y útil a una API existente o agregando una API nueva), el implementador DEBE visitar source.android.com y comenzar el proceso para contribuir con cambios y código, según la información de ese sitio.
Ten en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar APIs en el lenguaje de programación Java. El objetivo de esta sección es reforzar esas convenciones y hacerlas vinculantes a través de su inclusión en esta Definición de Compatibilidad.
3.7. Compatibilidad con el entorno de ejecución
Las implementaciones de dispositivos DEBEN admitir el formato ejecutable de Dalvik (DEX) completo y la especificación y semántica del código de bytes de Dalvik [Recursos, 20]. Los implementadores de dispositivos DEBEN usar ART, la implementación upstream de referencia del formato ejecutable de Dalvik y el sistema de administración de paquetes de la implementación de referencia.
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 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 |
|
pequeño / normal |
120 dpi (ldpi) |
16 MB |
|
160 dpi (mdpi) |
||
|
213 dpi (tvdpi) |
32 MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
64 MB |
|
|
400 dpi (400dpi) |
96 MB |
|
|
480 dpi (xxhdpi) |
128 MB |
|
|
560 dpi (560dpi) |
192 MB |
|
|
640 dpi (xxxhdpi) |
256 MB |
|
|
grande |
120 dpi (ldpi) |
16 MB |
|
160 dpi (mdpi) |
32 MB |
|
|
213 dpi (tvdpi) |
64 MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
128 MB |
|
|
400 dpi (400dpi) |
192 MB |
|
|
480 dpi (xxhdpi) |
256 MB |
|
|
560 dpi (560dpi) |
384 MB |
|
|
640 dpi (xxxhdpi) |
512 MB |
|
|
Extragrande |
160 dpi (mdpi) |
64 MB |
|
213 dpi (tvdpi) |
96 MB |
|
|
240 dpi (hdpi) |
||
|
320 dpi (xhdpi) |
192 MB |
|
|
400 dpi (400dpi) |
288 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 Android para dispositivos portátiles. |
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 [Recursos, 21], una función que se RECOMIENDA que sea compatible con 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 los indicadores 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 los Lineamientos de diseño de widgets de apps en la documentación del SDK de Android [Recursos, 21] para obtener más información.
- Es posible que las implementaciones de dispositivos que incluyen compatibilidad con la pantalla de bloqueo admitan widgets de la aplicación en la pantalla de bloqueo.
3.8.3. Notificaciones
Android incluye APIs que permiten a los desarrolladores notificar a los usuarios sobre eventos importantes [Recursos, 22] con 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 la 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 sonido, etc.) que se proporcionan en las APIs [Recursos, 23] o en la guía de estilo de íconos de la barra de estado o del sistema [Recursos, 24]. Los implementadores de dispositivos PUEDEN proporcionar una experiencia del usuario alternativa para las notificaciones que la que proporciona la implementación de código abierto de Android de referencia. Sin embargo, esos sistemas de notificaciones alternativos DEBEN admitir los recursos de notificaciones existentes, como se indicó anteriormente.
Android incluye compatibilidad con varias notificaciones, como las siguientes:
- Notificaciones enriquecidas: Vistas interactivas para notificaciones continuas.
- Notificaciones de alerta: Los usuarios de Views interactivas pueden descartarlas o interactuar con ellas sin salir de la app actual.
- Notificaciones en la pantalla de bloqueo: Son notificaciones que se muestran en una pantalla de bloqueo con control detallado de la visibilidad.
Las implementaciones de dispositivos DEBEN mostrar y ejecutar correctamente estas notificaciones, incluido el título o nombre, el ícono y el texto, como se documenta en las APIs de Android [Resources, 25].
Android incluye APIs de Notification Listener Service 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.
3.8.4. Buscar
Android incluye APIs [Recursos, 26] que permiten a los desarrolladores incorporar la búsqueda en sus aplicaciones y exponer los datos de su aplicación 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 en 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 realizar 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 que usen esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar resultados y sugerencias de motores de búsqueda web.
3.8.5. Avisos
Las aplicaciones pueden usar la API de "Toast" para mostrarle al usuario final cadenas breves no modales que desaparecen después de un breve período [Recursos, 27]. 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 a 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 su apariencia coincida con la del tema Holo, como lo define el SDK de Android [Recursos, 28]. Las implementaciones de dispositivos NO DEBEN alterar ninguno de los atributos del tema de Holo expuestos a las aplicaciones [Resources, 29].
Android 5.0 incluye una familia de temas "Material" como un conjunto de estilos definidos que los desarrolladores de aplicaciones pueden usar si desean que el aspecto y la sensación del tema de diseño coincidan con la amplia variedad de 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 Material ni sus recursos expuestos a las aplicaciones [Recursos, 30].
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 y la sensación del tema del dispositivo, según lo define el implementador del dispositivo. Las implementaciones de dispositivos PUEDEN modificar los atributos del tema predeterminado del dispositivo expuestos a las aplicaciones [Recursos, 29].
Android admite un nuevo 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 [Recursos, 29].
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 en vivo" al usuario final [Recursos, 31]. Los fondos de pantalla animados son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como un fondo de pantalla detrás de otras aplicaciones.
Se considera que el hardware es capaz de ejecutar fondos de pantalla en vivo de forma confiable si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones en la funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware hacen que los fondos de pantalla o las aplicaciones fallen, funcionen mal, consuman energía de la CPU o de la batería de forma excesiva, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware no es capaz de ejecutar fondos de pantalla en vivo. A modo de ejemplo, algunos fondos de pantalla animados pueden usar un contexto de OpenGL 2.0 o 3.x para renderizar su contenido. Los fondos de pantalla animados no se ejecutarán de forma confiable en hardware que no admita varios contextos de OpenGL, ya que el uso de un contexto de OpenGL 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 que pueden ejecutar fondos de pantalla de forma confiable, como se describió anteriormente, DEBEN implementar fondos de pantalla 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, los requisitos para implementar la pantalla de descripción general son OPCIONES para dispositivos Android TV y Android Watch. |
El código fuente de Android upstream incluye la pantalla de descripción general [Resources, 32], 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:
- DEBEN mostrar los elementos recientes afiliados como un grupo que se mueve junto
- DEBE admitir al menos 20 actividades mostradas.
- DEBE mostrar, al menos, el título de 4 actividades a la vez.
- DEBE mostrar el color de resaltado, el ícono y el título de la pantalla en Recientes.
- DEBEN implementar el comportamiento de fijación de pantalla [Recursos, 33] y proporcionarle al usuario un menú de configuración para activar o desactivar la función.
- DEBE mostrar una indicación visual de cierre ("x"), pero PUEDE retrasarla hasta que el usuario interactúe con las pantallas.
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 entradas y con editores de métodos de entrada de terceros [Recursos, 34]. Las implementaciones de dispositivos que permiten que los usuarios usen métodos de entrada de terceros en el dispositivo 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 [Recursos, 35]. Las implementaciones de dispositivos que admiten una pantalla de bloqueo DEBEN admitir la plantilla de notificación multimedia junto con otras notificaciones.
3.8.11. Sueños
Android incluye compatibilidad con protectores de pantalla interactivos llamados Dreams [Recursos, 36]. Dreams permite que los usuarios interactúen con aplicaciones cuando un dispositivo conectado a una fuente de alimentación está inactivo o en una estación de carga para escritorio. Los dispositivos Android Watch PUEDEN implementar Dreams, pero otros tipos de implementaciones de dispositivos DEBEN incluir compatibilidad con Dreams y proporcionar una opción de configuración para que los usuarios configuren Dreams 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 dentro de Configuración [Recursos, 37].
3.8.13. Unicode y fuente
Android incluye compatibilidad con caracteres de emojis en color. Cuando las implementaciones de dispositivos Android incluyen un IME, los dispositivos DEBEN proporcionar un método de entrada al usuario para los caracteres de emoji definidos en Unicode 6.1 [Recursos, 38]. Todos los dispositivos DEBEN ser capaces de renderizar estos caracteres de emojis en glifos de color.
Android 5.0 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 y sans-serif-condensed-light, que DEBEN incluirse para los idiomas disponibles en el dispositivo y la cobertura completa de Unicode 7.0 de 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.9. Administración del dispositivo
Android incluye funciones que permiten que las aplicaciones conscientes de la seguridad realicen funciones de administración de dispositivos a nivel del sistema, como aplicar políticas de contraseñas o realizar limpiezas remotas, a través de la API de administración de dispositivos Android [Recursos, 39]. Las implementaciones de dispositivos DEBEN proporcionar una implementación de la clase DevicePolicyManager [Recursos, 40]. Las implementaciones de dispositivos que incluyen compatibilidad con la pantalla de bloqueo DEBEN admitir la gama completa de políticas de administración de dispositivos definidas en la documentación del SDK de Android [Recursos, 39] y deben informar la función de plataforma android.software.device_admin.
Las implementaciones de dispositivos PUEDEN tener una aplicación preinstalada que realice funciones de administración del dispositivo, pero esta aplicación NO DEBE configurarse de forma predeterminada como la app de propietario del dispositivo [Recursos, 41].
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 [Recursos, 42]. Las implementaciones de dispositivos DEBEN proporcionar una implementación del framework de accesibilidad de Android coherente con la implementación predeterminada de Android. Las implementaciones de dispositivos DEBEN cumplir con los siguientes requisitos:
- DEBEN admitir implementaciones de servicios de accesibilidad de terceros a través de las APIs de android.accessibilityservice [Recursos, 43].
- 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.
- A menos que se trate de un dispositivo Android Watch sin salida de audio, las implementaciones de dispositivos 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.
Además, las implementaciones de dispositivos DEBEN proporcionar una implementación de un servicio de accesibilidad en el dispositivo y DEBEN proporcionar un mecanismo para que los usuarios habiliten el servicio de accesibilidad durante la configuración del dispositivo. El proyecto Eyes Free [Recursos, 44] ofrece una implementación de código abierto de un servicio de accesibilidad.
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 [Recursos, 45]. 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 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 TV (TIF) simplifica la entrega de contenido en vivo a los dispositivos Android TV. El TIF proporciona una API estándar para crear módulos de entrada que controlen dispositivos de Android TV. Las implementaciones de dispositivos Android TV DEBEN admitir el marco de trabajo de entrada de TV [Recursos, 46].
Las implementaciones de dispositivos que admiten TIF DEBEN declarar la función de la plataforma android.software.live_tv.
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 [Recursos, 47].
Las implementaciones de dispositivos NO DEBEN extender los formatos de código de bytes .apk [Recursos, 48], manifiesto de Android [Recursos, 49], Dalvik [Recursos, 20] ni RenderScript de manera tal que se impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles.
5. Compatibilidad multimedia
5.1. Códecs multimedia
Las implementaciones de dispositivos DEBEN admitir los formatos multimedia principales especificados en la documentación del SDK de Android [Recursos, 50], excepto cuando se permita de forma explícita en este documento. Específicamente, las implementaciones de dispositivos DEBEN admitir los formatos multimedia, los codificadores, los decodificadores, los tipos de archivos y los formatos de contenedor definidos en las siguientes tablas. Todos estos códecs se proporcionan como implementaciones de software en la implementación preferida de Android del Proyecto de código abierto de Android.
Ten en cuenta que ni Google ni la Open Handset Alliance hacen ninguna representación de que estos códecs no tengan patentes de terceros. Se recomienda a quienes tengan la intención de usar este código fuente en productos de hardware o software que las implementaciones de este código, incluido en software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes relevantes.
5.1.1. Códecs de audio
|
Formato / códec |
Codificador |
Decodificador |
Detalles |
Tipos de archivo o formatos de contenedor compatibles |
|
Perfil AAC de MPEG-4 (AAC LC) |
REQUIRED1 |
OBLIGATORIO |
Compatibilidad con contenido mono/estéreo/5.0/5.12 con tasas de muestreo estándar de 8 a 48 kHz. |
• 3GPP (.3gp) • MPEG-4 (.mp4, .m4a) • AAC sin procesar de ADTS (.aac, decodificación en Android 3.1 y versiones posteriores, codificación en Android 4.0 y versiones posteriores, ADIF no es compatible) • MPEG-TS (.ts, no admite búsquedas, Android 3.0 y versiones posteriores) |
|
Perfil HE AAC de MPEG-4 (AAC+) |
REQUIRED1 (Android 4.1 y versiones posteriores) |
OBLIGATORIO |
Compatibilidad con contenido mono/estéreo/5.0/5.12 con tasas de muestreo estándar de 16 a 48 kHz. |
|
|
MPEG-4 HE AACv2 Perfil (AAC+ mejorado) |
|
OBLIGATORIO |
Compatibilidad con contenido mono/estéreo/5.0/5.12 con tasas de muestreo estándar de 16 a 48 kHz. |
|
|
AAC ELD (AAC mejorado de bajo retraso) |
REQUIRED1 (Android 4.1 y versiones posteriores) |
OBLIGATORIO (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 |
REQUIRED3 |
REQUIRED3 |
4.75 a 12.2 kbps con muestreo a 8 kHz |
3GPP (.3gp) |
|
AMR-WB |
REQUIRED3 |
REQUIRED3 |
9 tasas de 6.60 kbit/s a 23.85 kbit/s con muestreo a 16 kHz |
|
|
FLAC |
|
OBLIGATORIO (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 |
REQUIRED4 (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 |
OBLIGATORIO (Android 5.0 y versiones posteriores) |
Matroska (.mkv) |
1 Es obligatorio para las implementaciones de dispositivos que definen android.hardware.microphone, pero es opcional para las implementaciones de dispositivos Android Watch.
2 Solo se requiere la reducción de formato de contenido 5.0/5.1. La grabación o renderización de más de 2 canales es opcional.
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 |
Tipos de archivo o formatos de contenedor 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) |
5.1.3. Códecs de video
|
Los códecs de video son opcionales para las implementaciones de dispositivos Android Watch. |
|
Formato / códec |
Codificador |
Decodificador |
Detalles |
Formatos de tipos de archivo/contenedores compatibles |
|
H.263 |
REQUIRED1 |
REQUIRED2 |
|
• 3GPP (.3gp) • MPEG-4 (.mp4) |
|
H.264 AVC |
REQUIRED2 |
REQUIRED2 |
Consulta los artículos 5.2 y 5.3 para obtener más información. |
• 3GPP (.3gp) • MPEG-4 (.mp4) • MPEG-TS (.ts, AAC solo de audio, no admite búsquedas, Android 3.0 y versiones posteriores) |
|
H.265 HEVC |
REQUIRED2 |
Consulta la sección 5.3 para obtener más detalles. |
MPEG-4 (.mp4) |
|
|
MPEG-4 SP |
|
REQUIRED2 |
|
3GPP (.3gp) |
|
VP83 |
REQUIRED2 (Android 4.3 y versiones posteriores) |
REQUIRED2 (Android 2.3.3 y versiones posteriores) |
Consulta los artículos 5.2 y 5.3 para obtener más información. |
• WebM (.webm) [Recursos, 110] • Matroska (.mkv, Android 4.0 y versiones posteriores)4 |
|
VP9 |
REQUIRED2 (Android 4.4 y versiones posteriores) |
Consulta el artículo 5.3 para obtener más información. |
• WebM (.webm) [Recursos, 110] • 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 de [Recursos, 51].
4 Las implementaciones de dispositivos DEBEN admitir la escritura de archivos Matroska WebM.
5.2. Codificación de video
|
Los códecs de video son opcionales para las implementaciones de dispositivos Android Watch. |
Las implementaciones de dispositivos Android con compatibilidad con el códec H.264 DEBEN admitir el nivel 3 del perfil de Baseline y los siguientes perfiles de codificación de video de definición estándar (SD) y DEBEN admitir el nivel 4 del perfil principal y los siguientes perfiles de codificación de video de alta definición (HD). Se RECOMIENDA encarecidamente que los dispositivos Android TV codifiquen videos HD 1080p a 30 fps.
|
SD (baja calidad) |
SD (alta calidad) |
HD 720p1 |
HD 1080p1 |
|
|
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 de video |
384 Kbps |
2 Mbps |
4 Mbps |
10 Mbps |
1 Cuando el hardware es compatible, pero SE RECOMIENDA ENFATICAMENTE para dispositivos Android TV.
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 720p1 |
HD 1080p1 |
|
|
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 de 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. |
Las implementaciones de dispositivos DEBEN admitir el cambio dinámico de resolución de video dentro de la misma transmisión para los códecs VP8, VP9, H.264 y H.265.
Las implementaciones de dispositivos Android con decodificadores H.264 DEBEN admitir el nivel 3 del perfil de Baseline y los siguientes perfiles de decodificación de video SD, y DEBEN admitir los perfiles de decodificación de HD. Los dispositivos Android TV DEBEN ser compatibles con el perfil de alto nivel 4.2 y el perfil de decodificación HD 1080p.
|
SD (baja calidad) |
SD (alta calidad) |
HD 720p1 |
HD 1080p1 |
|
|
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 |
30 fps / 60 fps2 |
30 fps / 60 fps2 |
|
Tasa de bits de video |
800 Kbps |
2 Mbps |
8 Mbps |
20 Mbps |
1 Obligatorio para las implementaciones de dispositivos Android TV, pero para otros tipos de dispositivos solo cuando el hardware es compatible.
2 Obligatorio para las implementaciones de dispositivos Android TV.
Las implementaciones de dispositivos Android, cuando admiten el códec VP8 como se describe en la sección 5.1.3, DEBEN admitir los siguientes perfiles de decodificación de SD y DEBEN admitir los perfiles de decodificación de HD. Los dispositivos Android TV DEBEN admitir el perfil de decodificación HD 1080p.
|
SD (baja calidad) |
SD (alta calidad) |
HD 720p1 |
HD 1080p1 |
|
|
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 fps2 |
30 / 60 fps2 |
|
Tasa de bits de video |
800 Kbps |
2 Mbps |
8 Mbps |
20 Mbps |
1 Obligatorio para las implementaciones de dispositivos Android TV, pero para otros tipos de dispositivos solo cuando el hardware es compatible.
2 Obligatorio para las implementaciones de dispositivos Android TV.
Cuando las implementaciones de dispositivos Android admiten el códec VP9, como se describe en la sección 5.1.3, DEBEN admitir los siguientes perfiles de decodificación de video SD y DEBEN admitir los perfiles de decodificación de HD. Se RECOMIENDA encarecidamente que los dispositivos Android TV admitan el perfil de decodificación HD 1080p y DEBEN admitir el perfil de decodificación UHD. Cuando el perfil de decodificación de video UHD es compatible, DEBE admitir una profundidad de color de 8 bits.
|
SD (baja calidad) |
SD (alta calidad) |
HD 720p 1 |
HD 1080p 2 |
UHD 2 |
|
|
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 |
30 fps |
|
Tasa de bits de video |
600 Kbps |
1.6 Mbps |
4 Mbps |
10 Mbps |
20 Mbps |
1 Obligatorio para las implementaciones de dispositivos Android TV, pero para otros tipos de dispositivos solo cuando el hardware es compatible.
2 SE RECOMIENDA ENFATICAMENTE para implementaciones de dispositivos Android TV cuando el hardware es compatible.
Cuando las implementaciones de dispositivos Android admiten el códec H.265, como se describe en la sección 5.1.3, DEBEN admitir el nivel principal del perfil principal nivel 3 y los siguientes perfiles de decodificación de video en SD, y DEBEN admitir los perfiles de decodificación en HD. Los dispositivos Android TV DEBEN ser compatibles con el nivel principal del perfil principal nivel 4.1 y el perfil de decodificación HD 1080p, y DEBEN ser compatibles con el perfil de nivel principal Main10 nivel 5 y el perfil de decodificación UHD.
|
SD (baja calidad) |
SD (alta calidad) |
HD 720p 1 |
HD 1080p 1 |
UHD 2 |
|
|
Resolución de video |
352 x 288 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 |
30 fps |
|
Tasa de bits de video |
600 Kbps |
1.6 Mbps |
4 Mbps |
10 Mbps |
20 Mbps |
1 Obligatorio para la implementación de dispositivos Android TV, pero para otros tipos de dispositivos solo cuando el hardware es compatible.
2 Obligatorio para las implementaciones de dispositivos Android TV cuando el hardware es compatible.
5.4. Grabación de audio
Si bien algunos de los requisitos que se describen en esta sección se indican como RECOMENDABLE desde Android 4.3, se planea que la definición de compatibilidad de una versión futura los cambie a OBLIGACIÓN. Se recomienda encarecidamente que los dispositivos Android existentes y nuevos cumplan con estos requisitos, 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
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
5.4.2. Captura para el reconocimiento de voz
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 mostrar 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.
- El control automático de ganancia, si está presente, 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 silenciador 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 [Recursos, 52]. 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, EMPACTE_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 la decodificación de audio en el dispositivo).
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 un objeto de escucha externo puede escuchar el sonido correspondiente o un transductor puede observarlo.
- Latencia de salida en frío: Es la latencia de salida del primer fotograma, cuando el sistema de salida de audio estuvo inactivo y apagado antes de la solicitud.
- Latencia de salida continua: Es la latencia de salida de los fotogramas posteriores, después de que el dispositivo reproduce audio.
- Latencia de entrada: Es el intervalo entre el momento en que se presenta un sonido externo al dispositivo y el momento en que una aplicación lee la trama correspondiente de datos codificados en PCM.
- Latencia de entrada fría: Es la suma del tiempo de entrada perdido y la latencia de entrada del primer fotograma, cuando el sistema de entrada de audio estuvo inactivo y apagado antes de la solicitud.
- Latencia de entrada continua: Es la latencia de entrada de los fotogramas posteriores, mientras el dispositivo captura audio.
- Jitter de salida fría: Es la varianza entre mediciones independientes de los valores de latencia de salida fría.
- Jitter de entrada fría: Es la variación 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 5 ms.
- API de cola de búfer PCM de OpenSL ES: Es el conjunto de APIs de OpenSL ES relacionadas con PCM dentro del NDK de Android. Consulta NDK_root/docs/opensles/index.html.
Las implementaciones de dispositivos que declaran android.hardware.audio.output DEBEN cumplir o superar 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 la cola de búfer PCM de OpenSL ES, para la latencia de salida continua y la latencia de salida en frío en al menos un dispositivo de salida de audio compatible, PUEDE informar la compatibilidad con audio de baja latencia, a través de la función android.hardware.audio.low_latency a través de la clase android.content.pm.PackageManager [Resources, 53]. 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.
Las implementaciones de dispositivos que incluyen android.hardware.microphone DEBEN cumplir 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 [Recursos, 50]. Específicamente, los dispositivos DEBEN ser compatibles con los siguientes protocolos de red multimedia:
- RTSP (RTP, SDP)
- Transmisión progresiva de HTTP(S)
- Protocolo de transmisión en vivo HTTP(S), versión 3 [Recursos, 54]
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.
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) [Recursos, 55]
Las implementaciones de dispositivos DEBEN admitir todas las funciones de adb como se documenta en el SDK de Android, incluido dumpsys [Recursos, 56]. 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 monitor de depuración de Dalvik (ddms) [Recursos, 57]
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.
- Monkey [Recursos, 58]
Las implementaciones de dispositivos DEBEN incluir el framework de Monkey y ponerlo a disposición de las aplicaciones.
- SysTrace [Resources, 59]
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 9 en versiones de 32 y 64 bits.
6.2. Opciones para desarrolladores
Android incluye compatibilidad para que los desarrolladores configuren parámetros de configuración relacionados con el desarrollo de aplicaciones. Las implementaciones de dispositivos DEBEN respetar el intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS para mostrar la configuración relacionada con el desarrollo de la aplicación [Recursos, 60]. La implementación de Android upstream oculta el menú de Opciones para desarrolladores de forma predeterminada y permite que los usuarios inicien las Opciones para desarrolladores después de presionar siete (7) veces el elemento de menú Configuración > Acerca del dispositivo > Número de compilación. 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.
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 del componente.
- 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 precisa de configuración de hardware a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String) en la clase android.content.pm.PackageManager para la misma huella digital de compilación. [Resources, 53]
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, a fin de garantizar que las aplicaciones de terceros se ejecuten bien en una variedad de configuraciones de hardware [Recursos, 61]. Los dispositivos DEBEN implementar correctamente estas APIs y comportamientos, como se detalla en esta sección.
Las unidades a las que hacen referencia los requisitos de esta sección se definen de la siguiente manera:
- Tamaño diagonal físico: Es la distancia en pulgadas entre dos esquinas opuestas de la parte iluminada de la pantalla.
- Puntos por pulgada (dpi): Es la cantidad de píxeles que abarca un intervalo lineal horizontal o vertical de 1". Cuando se enumeran los valores de dpi, los dpi horizontales y verticales deben estar dentro del rango.
- relación de aspecto: Es la proporción entre la dimensión más larga de la pantalla y la más corta. Por ejemplo, una pantalla de 480 × 854 píxeles sería 854 / 480 = 1.779, o aproximadamente "16:9".
- Píxel independiente de la densidad (dp): Es la unidad de píxeles virtual normalizada a una pantalla de 160 dpi, que 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 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, como se define en la documentación del SDK de Android [Recursos, 61] 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 sea un dispositivo Android Watch.
- Los dispositivos que informan un tamaño de pantalla "normal" DEBEN tener tamaños de pantalla de al menos 480 dp x 320 dp.
- Los dispositivos que informan el tamaño de pantalla "grande" DEBEN tener tamaños 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.
Además,
- Los dispositivos Android Watch DEBEN tener una pantalla con un tamaño diagonal físico de entre 1.1 y 2.5 pulgadas.
- 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
7.1.1.2. Relación de aspecto de la pantalla
|
Los dispositivos Android Watch PUEDEN tener una relación de aspecto de 1.0 (1:1). |
La relación de aspecto de la pantalla DEBE ser un valor de 1.3333 (4:3) a 1.86 (alrededor de 16:9), pero los dispositivos Android Watch PUEDEN tener una relación de aspecto de 1.0 (1:1) porque una implementación de ese dispositivo usará un UI_MODE_TYPE_WATCH como android.content.res.Configuration.uiMode.
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. Las implementaciones de dispositivos deben informar solo una de las siguientes densidades lógicas del framework de Android a través de las APIs de android.util.DisplayMetrics, y deben ejecutar aplicaciones con esta densidad estándar y no deben cambiar el valor en ningún momento para la pantalla predeterminada.
- 120 dpi (ldpi)
- 160 dpi (mdpi)
- 213 dpi (tvdpi)
- 240 dpi (hdpi)
- 320 dpi (xhdpi)
- 400 dpi (400dpi)
- 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.
7.1.2. Métricas de Display
Las implementaciones de dispositivos DEBEN informar los valores correctos para todas las métricas de visualización definidas en android.util.DisplayMetrics [Resources, 62] y DEBEN informar los mismos valores, independientemente de si se usa la pantalla externa o la incorporada 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 o 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 de otras APIs.
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 o 3.1 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 [Recursos, 63].
Las implementaciones de dispositivos también DEBEN identificarse correctamente como compatibles con OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 o OpenGL 3.1. Es decir:
- Las APIs administradas (como a través del método GLES10.getString()) DEBEN informar 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 la compatibilidad con OpenGL ES 1.0 y OpenGL ES 2.0.
- Las implementaciones de dispositivos que declaran compatibilidad con OpenGL ES 3.0 o 3.1 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 o 3.1, 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.
Además de OpenGL ES 3.1, Android proporciona un paquete de extensión con interfaces de Java [Resources, 64] y compatibilidad nativa con funciones de gráficos avanzados, como la teselación y el formato de compresión de texturas ASTC. Las implementaciones de dispositivos Android PUEDEN admitir este paquete de extensión y, solo si se implementan por completo, DEBEN 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 para especificar de manera 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 [Recursos, 65].
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 Android View.
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 [Recursos, 65].
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 [Resources, 66].
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 de tamaño de pantalla "normal" (ancho de 320 dp) para el beneficio de las aplicaciones heredadas que no se desarrollaron para versiones anteriores de Android que son anteriores a la independencia del tamaño de pantalla. Las implementaciones de dispositivos DEBEN incluir compatibilidad con el modo de compatibilidad de aplicaciones heredadas, tal como lo implementa el código fuente abierto de Android upstream. Es decir, las implementaciones de dispositivos NO DEBEN alterar los activadores ni los umbrales en los que se activa el modo de compatibilidad, ni alterar el comportamiento del modo de compatibilidad.
7.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 externas
Android incluye compatibilidad con pantallas secundarias para habilitar las capacidades 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 integrada, la implementación del dispositivo DEBE implementar la API del administrador de pantalla como se describe en la documentación del SDK de Android [Recursos, 67].
7.2. Dispositivos de entrada
7.2.1. Teclado
|
Los dispositivos Android Watch PUEDEN implementar un teclado en pantalla, pero otros tipos de implementaciones de dispositivos DEBEN hacerlo. |
Implementaciones de dispositivos:
- DEBE incluir compatibilidad con el framework de administración de entradas (que permite a los desarrolladores externos crear editores de métodos de entrada, es decir, teclado en pantalla), como se detalla en http://developer.android.com.
- DEBE 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 de 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 [Resources, 68] (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 [Resources, 68].
- 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 varían según el tipo de dispositivo, como se describe en esta sección. |
Las funciones Inicio, Recientes y Atrás (asignadas 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,
- Las implementaciones de dispositivos de mano con Android DEBEN proporcionar las funciones Inicio, Recientes y Atrás.
- Las implementaciones de dispositivos Android TV DEBEN proporcionar las funciones Inicio y Atrás.
- Las implementaciones de dispositivos Android Watch DEBEN tener la función Inicio disponible para el usuario y la función Atrás, excepto cuando está en UI_MODE_TYPE_WATCH.
- 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étera. Android admite ambas implementaciones. Se DEBE poder acceder a todas estas funciones con una sola acción (p.ej., un toque, un doble clic o un gesto) cuando estén visibles.
La función Recientes, si se proporciona, 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 como 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 5.0 NO DEBEN implementar un botón físico exclusivo para la función de menú. Las implementaciones de dispositivos más antiguos 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 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 5.0, se RECOMIENDA usar esta opción.
- NO DEBE modificar la posición de la ventana emergente de acciones ampliadas que se muestra cuando se selecciona el botón de menú ampliado en la barra de acciones.
- PUEDE renderizar la ventana emergente de desbordamiento de acciones 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 menor o igual a 10, ya sea a través de un botón físico, una tecla de software o gestos. Esta función de menú se debe presentar, a menos que se oculte junto con otras funciones de navegación.
Android admite la acción de asistencia [Recursos, 69]. Las implementaciones de dispositivos Android, excepto los dispositivos Android Watch, DEBEN hacer que la acción de Asistente esté disponible para el usuario en todo momento cuando se ejecutan aplicaciones. La acción de Asistente DEBE implementarse como un mantenimiento presionado del botón de inicio o un gesto de deslizar hacia arriba en la tecla de inicio del software. Esta función PUEDE implementarse a través de otro botón físico, una tecla de software o un gesto, pero DEBE ser accesible con una sola acción (p.ej., presionar, hacer doble clic o hacer un gesto) cuando otras teclas de navegación estén visibles.
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 estos 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 especifiquen un modo de IU del sistema o especifiquen SYSTEM_UI_FLAG_VISIBLE.
- Las implementaciones de dispositivos DEBEN presentar las teclas de navegación en un modo "de perfil bajo" (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 especifiquen 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 la implementación de un 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 [Resources, 68] 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áctiles falsos. Las implementaciones de dispositivos basadas en pantallas táctiles se asocian con una pantalla [Recursos, 70] 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 indicaciones adicionales 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 5.0 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 toques falsos DEBEN cumplir con los requisitos de toques falsos que se indican en la sección 7.2.5.
Las implementaciones de dispositivos DEBEN informar la función correcta que corresponde al tipo de entrada que se usó. 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 función de 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 X e Y de la ubicación del puntero y mostrar un puntero visual en la pantalla [Recursos, 71].
- DEBE informar el evento táctil con el código de acción que especifica el cambio de estado que se produce cuando el puntero se mueve hacia abajo o hacia arriba en la pantalla [Recursos, 71].
- DEBEN admitir el puntero hacia abajo y hacia arriba en un objeto en la pantalla, lo que permite a los usuarios imitar el toque en un objeto en la pantalla.
- DEBEN 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 [Recursos, 71]
- 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 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 para controles de juegos que satisface este requisito.
7.2.6.1. Asignaciones de botones
Las implementaciones de dispositivos Android TV DEBEN admitir las siguientes asignaciones de teclas:
|
Button |
Uso de HID2 |
Botón de Android |
|
A1 |
0x09 0x0001 |
KEYCODE_BUTTON_A (96) |
|
B1 |
0x09 0x0002 |
KEYCODE_BUTTON_B (97) |
|
X1 |
0x09 0x0004 |
KEYCODE_BUTTON_X (99) |
|
Y1 |
0x09 0x0005 |
KEYCODE_BUTTON_Y (100) |
|
0x01 0x00393 |
||
|
0x01 0x00393 |
||
|
0x09 0x0007 |
KEYCODE_BUTTON_L1 (102) |
|
|
0x09 0x0008 |
KEYCODE_BUTTON_R1 (103) |
|
|
0x09 0x000E |
KEYCODE_BUTTON_THUMBL (106) |
|
|
0x09 0x000F |
KEYCODE_BUTTON_THUMBR (107) |
|
|
0x0c 0x0223 |
KEYCODE_HOME (3) |
|
|
0x0c 0x0224 |
KEYCODE_BACK (4) |
1 [Recursos, 72]
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 [Recursos, 71]
|
Controles analógicos1 |
Uso de HID |
Botón de Android |
|
0x02 0x00C5 |
AXIS_LTRIGGER |
|
|
0x02 0x00C4 |
AXIS_RTRIGGER |
|
|
0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
|
|
0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
1 [Recursos, 71]
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 un control 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.
- Indicadores visuales de búsqueda: Las implementaciones de dispositivos DEBEN activar KEYCODE_SEARCH 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 control [Recursos, 72].
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 en la documentación de código abierto de Android sobre sensores [Recursos, 73]. Por ejemplo, implementaciones de dispositivos:
- DEBEN informar con precisión la presencia o ausencia de sensores según la clase android.content.pm.PackageManager [Resources, 53].
- 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, devolviendo verdadero o falso según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamando a objetos de escucha de sensores cuando los sensores correspondientes no estén presentes, etcétera).
- DEBEN informar todas las mediciones del sensor con los valores relevantes del Sistema Internacional de Unidades (métrica) para cada tipo de sensor, como se define en la documentación del SDK de Android [Recursos, 74].
- 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 encarecidamente que los dispositivos Android existentes y nuevos cumplan con este requisito 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 [Recursos, 75].
La lista anterior no es exhaustiva. Se debe considerar como fuente de autoridad el comportamiento documentado del SDK de Android y la documentación de código abierto de Android sobre sensores [Recursos, 73].
Algunos tipos de sensores son compuestos, lo que significa que se pueden obtener a partir de datos proporcionados por uno o más sensores. (entre los ejemplos, se incluyen el sensor de orientación y el sensor de aceleración lineal). Las implementaciones de dispositivos DEBEN implementar estos tipos de sensores, cuando incluyen los sensores físicos previos como se describe en [Recursos, 76]. 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 [Recursos, 76].
Algunos sensores de Android admiten un modo de activación "continuo", que muestra datos de forma continua [Recursos, 77]. 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 el sensor individual.
7.3.1. Acelerómetro
Las implementaciones de dispositivos DEBEN incluir un acelerómetro de 3 ejes. Se recomienda que los dispositivos portátiles y los relojes Android 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 [Recursos, 78]
- DEBEN poder informar eventos hasta una frecuencia de al menos 100 Hz y DEBEN informar eventos hasta al menos 200 Hz.
- DEBEN cumplir con el sistema de coordenadas del sensor de Android, como se detalla en las APIs de Android [Recursos, 74].
- 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 8 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
- DEBE tener una desviación estándar no superior a 0.05 m/s², donde la desviación estándar se debe calcular por eje en muestras recopiladas durante un período de al menos 3 segundos con 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 recomienda encarecidamente que los dispositivos Android existentes y nuevos implementen el sensor compuesto TYPE_SIGNIFICANT_MOTION. Si se implementa alguno de estos sensores, la suma de su consumo de energía SIEMPRE DEBE ser inferior a 4 mW y CADA UNO DEBE ser inferior a 2 mW y 0.5 mW cuando el dispositivo está en una condición dinámica o estática.
- 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 encarecidamente 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 incluyen un sensor de giroscopio y un sensor magnetómetro.
7.3.2. Magnetómetro
Las implementaciones de dispositivos DEBEN incluir un magnetómetro de 3 ejes (brújula). Si un dispositivo sí 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 encarecidamente que los dispositivos Android existentes y nuevos implementen el sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
- DEBEN ser capaces de 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 [Recursos, 74].
- 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).
- DEBE tener una resolución igual o superior a 0.6 μT y DEBE 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 aplicarse 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 con la tasa de muestreo más rápida, que no sea superior a 0.5 μT.
- DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluye un sensor de acelerómetro y un sensor de 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 está registrado para el modo por lotes a 10 Hz.
7.3.3. GPS
Las implementaciones de dispositivos DEBEN incluir un receptor GPS. Si la implementación de un dispositivo incluye un receptor GPS, DEBE incluir algún tipo de técnica de "GPS asistido" para minimizar el tiempo de bloqueo del GPS.
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 se incluya 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 encarecidamente 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 hasta una frecuencia de al menos 100 Hz y DEBEN informar eventos hasta al menos 200 Hz.
- 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 preservar los parámetros de compensación entre los reinicios del dispositivo.
- DEBE tener una varianza no superior a 1e-7 rad^2 / s^2 por Hz (varianza por Hz o rad^2 / s). La varianza puede variar con la tasa de muestreo, pero debe estar restringida por este valor. En otras palabras, si mides la varianza del giroscopio a una tasa de muestreo de 1 Hz, no debe ser superior a 1e-7 rad^2/s^2.
- DEBE implementar un sensor compuesto TYPE_ROTATION_VECTOR si también se incluye un sensor de acelerómetro y un sensor de 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 encarecidamente 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
- DEBE poder entregar eventos a 5 Hz o más.
- DEBEN tener una 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.
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 está en uso por parte del usuario. Si la implementación de un dispositivo incluye un sensor de proximidad con cualquier otra orientación, NO DEBE ser accesible a través de esta API.
- DEBE tener 1 bit de precisión o más
7.4. Conectividad de datos
7.4.1. Telefonía
El término "telefonía", tal como lo usan las APIs de Android y este documento, hace referencia específicamente al hardware relacionado con la realización de llamadas de voz y el envío de mensajes SMS 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 la implementación de un 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.2. IEEE 802.11 (Wi-Fi)
|
Las implementaciones de dispositivos Android TV DEBEN incluir compatibilidad con Wi-Fi. |
Las implementaciones de dispositivos Android TV DEBEN incluir compatibilidad con una o más formas de 802.11 (b/g/a/n, etc.), y otros tipos de 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.
- DEBE implementar la API de multidifusión como se describe en la documentación del SDK [Recursos, 79]
- 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, incluso cuando la pantalla no esté en un estado activo.
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 [Recursos, 80]. 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
7.4.2.2. Configuración de vínculo directo con túnel Wi-Fi
|
Las implementaciones de dispositivos Android TV DEBEN incluir compatibilidad con la configuración de vínculo directo con túnel Wi-Fi (TDLS). |
Las implementaciones de dispositivos Android Television DEBEN incluir compatibilidad con la configuración de vínculo directo con túnel Wi-Fi (TDLS) y otros tipos de implementaciones de dispositivos Android DEBEN incluir compatibilidad con TDLS Wi-Fi, como se describe en la documentación del SDK de Android [Recursos, 81]. Si la implementación de un dispositivo incluye compatibilidad con TDLS y la API de WiFiManager habilita el 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 sea peor que pasar por el punto de acceso Wi-Fi.
7.4.3. Bluetooth
|
Las implementaciones de dispositivos Android TV DEBEN ser compatibles con Bluetooth y Bluetooth LE, y las implementaciones de dispositivos Android Watch DEBEN ser compatibles con Bluetooth. |
Android incluye compatibilidad con Bluetooth y Bluetooth de bajo consumo [Recursos, 82]. 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 dispositivos Android Television DEBEN ser compatibles con Bluetooth y Bluetooth LE.
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 [Recursos, 82].
- DEBE admitir la descarga de la lógica de filtrado al conjunto de chips Bluetooth cuando se implemente la API de ScanFilter [Recursos, 83] y DEBE informar el valor correcto de dónde 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.BluetoothAdapater.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() [Recursos, 53]
- 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 6319-4)
- IsoDep (ISO 14443-4)
- Tipos de etiquetas del NFC Forum 1, 2, 3 y 4 (definidos por el NFC Forum)
- DEBE ser capaz de leer y escribir mensajes NDEF 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 establecen como DEBER, se planea que la definición de compatibilidad de una versión futura los cambie a DEBE. Estos estándares son opcionales en esta versión, pero serán obligatorios en versiones futuras. Se recomienda encarecidamente que los dispositivos existentes y nuevos que ejecutan esta versión de Android cumplan con estos requisitos ahora para que puedan actualizar a las versiones futuras de la plataforma.
- NFCv (ISO 15693)
- DEBEN ser capaces de transmitir y recibir datos a través de los siguientes protocolos y estándares de peer-to-peer:
- ISO 18092
- LLCP 1.0 (definido por el NFC Forum)
- SDP 1.0 (definido por NFC Forum)
- Protocolo de envío de NDEF [Recursos, 84]
- SNEP 1.0 (definido por el NFC Forum)
- DEBEN incluir compatibilidad con Android Beam [Recursos, 85]:
- 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 [Recursos, 86].
- 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" [Resources, 87] y "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Resources, 88] del NFC Forum. Dicha implementación DEBE implementar el servicio LLCP de transferencia con el nombre de servicio "urn:nfc:sn:handover" para intercambiar la solicitud de transferencia o seleccionar registros a través de NFC, y DEBE usar el perfil de Push de objetos Bluetooth para la transferencia real de datos de Bluetooth. Por motivos heredados (para seguir siendo compatible 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 en sí 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.
- 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:
(Ten en cuenta que los vínculos disponibles públicamente no están disponibles para las especificaciones de JIS, ISO y NFC Forum citadas anteriormente).
Android 5.0 incluye compatibilidad con el modo de emulación de tarjeta de host (HCE) de NFC. Si una implementación de dispositivo incluye un controlador de NFC capaz de enrutar HCE y el ID de aplicación (AID), hace lo siguiente:
- 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 [Recursos, 10]
Además, las implementaciones de dispositivos PUEDEN incluir compatibilidad con lectores/grabadores para las siguientes tecnologías de MIFARE.
- MIFARE Classic
- MIFARE Ultralight
- NDEF en MIFARE Classic
Ten en cuenta que Android incluye APIs para estos tipos de MIFARE. Si la implementación de un 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() [Resources, 53]. 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 PackageManager.
- NO DEBEN implementar las APIs de Android correspondientes ni informar la función com.nxp.mifare, a menos que también implementen 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() [Recursos, 53] y DEBE implementar la API de NFC de Android como una operación sin efecto.
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 satisfacen 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.
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" [Resources, 89].
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 iguales al tamaño de las imágenes que produce el sensor de cámara de mayor resolución en el dispositivo.
7.5.1. Cámara posterior
Las implementaciones de dispositivos DEBEN incluir una cámara posterior. Si la implementación de un dispositivo incluye al menos una cámara posterior, tiene las siguientes características:
- DEBE informar la marca 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 del 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 la implementación de un dispositivo incluye al menos una cámara frontal, tiene las siguientes características:
- DEBEN informar la marca 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 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, automaticamente 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ó de forma explícita que la pantalla de la cámara se rote a través de una llamada al método android.hardware.Camera.setDisplayOrientation()[Resources, 90], la vista previa de la cámara DEBE duplicarse horizontalmente en relación con la orientación que especifique 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 con modo host USB PUEDEN incluir compatibilidad con una cámara externa que se conecta al puerto USB. Si un dispositivo incluye compatibilidad con una cámara externa, tiene las siguientes características:
- DEBE declarar la función de plataforma android.hardware.camera.external y android.hardware camera.any.
- DEBE ser compatible con la clase de video USB (UVC 1.0 o superior)
- PUEDE admitir varias cámaras
SE RECOMIENDA la compatibilidad con la compresión 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). ES POSIBLE que se admita la codificación de video basada en la cámara. Si es así, la implementación del dispositivo DEBE tener acceso a una transmisión simultánea sin codificar o MJPEG (QVGA o 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, android.hardware.camera2, expone el control de la cámara de nivel inferior a la app, incluidos flujos de transmisión o ráfaga eficientes sin copia y controles por fotograma de exposición, ganancia, ganancias de balance de blancos, conversión de colores, reducción de ruido, nitidez y mucho más.
El paquete de API anterior, android.hardware.Camera, está marcado como obsoleto en Android 5.0, pero, como aún debería estar 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 frontal y 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 [Recursos, 91], 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 [Recursos, 92].
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 [Recursos, 93], y las marcas de función del framework adecuadas [Recursos, 94].
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 [Recursos, 94]. 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 graba un video nuevo y se agrega 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, se aplica a dispositivos con orientación horizontal principal y a 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 5 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 la pantalla |
Dispositivo de 32 bits |
Dispositivo de 64 bits |
|
Dispositivos Android Watch (debido a las pantallas más pequeñas) |
416 MB |
No aplicable |
|
xhdpi o inferior en pantallas pequeñas o normales hdpi o inferior en pantallas grandes mdpi o inferior en pantallas extragrandes |
512 MB |
832 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 que ya esté dedicado a componentes de hardware, como radio, video, etcétera, que no esté bajo el control del kernel.
Los dispositivos Android TV DEBEN tener al menos 5 GB, y otras implementaciones de dispositivos DEBEN tener al menos 1.5 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 5 GB para dispositivos Android TV y al menos 1.5 GB para otras implementaciones de dispositivos. Se recomienda encarecidamente que las implementaciones de dispositivos que ejecutan Android tengan al menos 3 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 [Recursos, 95]. 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. Si el almacenamiento compartido no está activado en la ruta de acceso /sdcard de Linux, 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 espacio 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 que le advierta 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, ese almacenamiento DEBE tener un tamaño de 1 GB o superior 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 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 los directorios específicos del paquete en el almacenamiento externo secundario, pero DEBEN exponer el contenido de ambas rutas de acceso de almacenamiento de forma transparente a través del servicio de escáner de contenido multimedia de Android y android.provider.MediaStore.
Independientemente de la forma de almacenamiento compartido que se use, las implementaciones de dispositivos DEBEN proporcionar algún mecanismo para acceder al contenido del almacenamiento compartido desde una computadora host, como el almacenamiento masivo USB (UMS) o el protocolo de transferencia multimedia (MTP). Las implementaciones de dispositivos PUEDEN usar el almacenamiento masivo USB, pero DEBEN usar el Protocolo de transferencia de contenido multimedia. 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 [Recursos, 96].
- DEBE informar una clase de dispositivo USB de 0x00.
- DEBE informar un nombre de interfaz USB de “MTP”.
Si la implementación del dispositivo no tiene puertos USB, DEBE proporcionar a una computadora anfitrión acceso al contenido del almacenamiento compartido por algún otro medio, como un sistema de archivos de red.
7.7. USB
Las implementaciones de dispositivos DEBEN admitir el modo de periférico USB y el modo de host 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 RECOMIENDAN ALTAMENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a 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 URGENTE que los dispositivos Android existentes y nuevos cumplan con estos requisitos para que puedan actualizarse a versiones futuras de la plataforma.
- 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 la AOA:
- DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.accessory [Recursos, 97].
- DEBE implementar la clase de audio USB como se documenta en la documentación del SDK de Android [Recursos, 98].
- DEBE implementar la compatibilidad para extraer una corriente de 1.5 A durante el chirp y el tráfico HS, como se especifica en la Especificación de Carga de Batería USB, Revisión 1.2 [Recursos, 99]. 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 valor de iSerialNumber en el descriptor de dispositivo estándar USB DEBE ser igual al valor de android.os.Build.SERIAL.
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 implementar la clase de audio USB como se documenta en la documentación del SDK de Android [Recursos, 98].
- 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 [Recursos, 100].
- DEBE admitir el rango de corriente de salida del puerto descendente de carga de 1.5 A a 5 A, como se especifica en la Especificación de Carga de Batería USB, Revisión 1.2 [Recursos, 99].
7.8. Audio
7.8.1. Micrófono
|
Los dispositivos portátiles y relojes Android 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 de la sección 5.6.
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 de la sección 5.6.
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, pero NO DEBE tener salida de audio, pero 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 [Recursos, 101], 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 de 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:
- DEBE admitir la reproducción de audio en auriculares estéreo y auriculares estéreo con micrófono, y DEBE 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.
- DEBE admitir la detección de 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 micrófono de valor adicional establecido como 1.
- DEBE admitir la detección y la asignación a los códigos de teclas para los siguientes 3 rangos de impedancia equivalente entre el micrófono y los conductores de masa en el enchufe de audio:
- 70 ohmios o menos: KEYCODE_HEADSETHOOK
- 210–290 Ohm: KEYCODE_VOLUME_UP
- 360 Ohm a 680 Ohm: KEYCODE_VOLUME_DOWN
- DEBE admitir la detección y la asignación al código de tecla para 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.
- DEBE ser capaz de generar al menos 150 mV ± 10% de voltaje de salida en una impedancia de bocina de 32 ohmios.
- DEBE tener un voltaje de polarización del micrófono entre 1.8 V y 2.9 V.
8. Compatibilidad de rendimiento
Algunos criterios de rendimiento mínimos 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 una 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 de lista, como lo define el Conjunto de pruebas de compatibilidad (CTS) de Android, en menos de 36 segundos.
- Cambio de tareasCuando se inician varias aplicaciones, el reinicio de 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 para las operaciones de lectura y escritura.
- Escritura secuencial: Las implementaciones de dispositivos DEBEN garantizar un rendimiento de escritura secuencial de 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 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 15 MB/s para un archivo de 256 MB con un búfer de escritura de 10 MB.
- Las implementaciones de dispositivos de lectura aleatoria DEBEN garantizar un rendimiento de lectura aleatoria de 3.5 MB/s para un archivo de 256 MB con un búfer de escritura de 4 KB.
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 [Recursos, 102] en la documentación para desarrolladores de Android. Las implementaciones de dispositivos DEBEN admitir la instalación de aplicaciones con firma propia sin requerir permisos ni certificados adicionales de terceros o autoridades. Específicamente, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad que se describen en las siguientes sub secciones.
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 [Recursos, 102]. 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 que las nuevas cadenas de ID de permiso no estén en el espacio de nombres android.*.
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 compiladas correctamente, como se define en la referencia de seguridad y permisos [Recursos, 102].
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 [Recursos, 102].
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 comprometer 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.
Los entornos de ejecución alternativos NO DEBEN tener acceso a recursos protegidos por permisos que no se solicitaron en el archivo AndroidManifest.xml del entorno de ejecución a través del
Los entornos 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étera).
- PUEDE proporcionar una sola zona de pruebas de Android que compartan todas las aplicaciones que usan el tiempo de ejecución alternativo.
- y las aplicaciones instaladas con 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 del 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, el entorno de ejecución DEBE enumerar todos los permisos que tiene el entorno de ejecución cuando se instala cualquier aplicación que lo use.
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 completo de usuarios [Recursos, 103]. 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 [Recursos, 104]:
- 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 los usuarios adicionales trabajen en ellos, con la capacidad de administrar restricciones más detalladas en las apps que están disponibles en esos entornos.
- 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 [Recursos, 102].
- Las implementaciones de dispositivos PUEDEN admitir la creación de usuarios y perfiles administrados a través de las APIs de android.app.admin.DevicePolicyManager y, si es así, DEBEN declarar la marca de función de la plataforma android.software.managed_users.
- Las implementaciones de dispositivos que declaran la marca de función android.software.managed_users DEBEN usar la insignia de ícono de AOSP upstream para representar las aplicaciones administradas y otros elementos de la IU de la insignia, como Recents y Notifications.
- 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 principales 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 medios extraíbles [Recursos, 105] 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 [Recursos, 106] . 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) 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 un incumplimiento de seguridad y se bloquea correctamente, pero PUEDE tener una interfaz de usuario visible cuando se produce un incumplimiento de seguridad desbloqueado que genera un exploit exitoso.
- NO DEBE ser configurable por el usuario ni 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 external/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.
Las implementaciones de dispositivos DEBEN retener la política predeterminada de SELinux proporcionada en la carpeta external/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.
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.
9.9. Encriptación de disco completo
|
Opcional para implementaciones de dispositivos Android sin pantalla de bloqueo. |
Si la implementación del dispositivo tiene una pantalla de bloqueo, el dispositivo DEBE admitir la encriptación de disco completo de los datos privados de la aplicación (partición /data) y la partición de la tarjeta SD si es una parte permanente y no extraíble del dispositivo [Recursos, 107]. En el caso de los dispositivos que admiten la encriptación de disco completo, esta DEBE estar habilitada todo el tiempo después de que el usuario complete la experiencia lista para usar. Si bien este requisito se indica como DEBE para esta versión de la plataforma de Android, SE RECOMIENDA DE FORMA MUY ENÉRGICA, ya que esperamos que cambie a DEBE en las versiones futuras de Android. La encriptación 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. Excepto cuando está en uso activo, la clave de encriptación DEBE estar encriptada con AES con la contraseña de la pantalla de bloqueo extendida con un algoritmo de estiramiento lento (p.ej., PBKDF2 o scrypt). Si el usuario no especificó una contraseña 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 el hardware, el algoritmo de estiramiento de contraseñas 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. Inicio verificado
Las implementaciones de dispositivos DEBEN admitir el inicio verificado para la integridad del dispositivo y, si la función es compatible, DEBEN declarar la marca de función de la plataforma android.software.verified_boot. Si bien este requisito se indica como DEBE para esta versión de la plataforma de Android, SE RECOMIENDA ENFATICAMENTE, ya que esperamos que cambie a DEBE en las versiones futuras de Android. 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.
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 encarecidamente a los implementadores de dispositivos que realicen la menor cantidad posible de cambios en la implementación de referencia y preferida de Android disponible en 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 [Recursos, 108] 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 reimplementación de partes del código fuente de referencia.
El CTS está diseñado para ejecutarse en un dispositivo real. Al igual que cualquier software, el CTS puede contener errores. El CTS tendrá control de versiones independientemente de esta definición de compatibilidad, y es posible que se lancen varias revisiones del CTS para Android 5.0. Las implementaciones de dispositivos DEBEN pasar 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 no puede probar un sistema automatizado, como el funcionamiento correcto de una cámara y 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. Los casos de prueba para las funciones que se indican como opcionales en este documento de definición de compatibilidad PUEDEN omitirse.
Cada dispositivo y cada compilación DEBEN ejecutar correctamente el verificador de CTS, como se indicó anteriormente. Sin embargo, como muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos ejecuten de forma explícita 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étera, 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 que 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 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 ilimitada, como 802.11 o el perfil de PAN (red de área personal) de Bluetooth, el dispositivo DEBE admitir la descarga inalámbrica 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 5.0 y versiones posteriores, el mecanismo de actualización DEBE admitir la verificación de que la imagen del sistema sea un objeto 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.0, satisface este requisito.
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 para afectar 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.
12. Registro de cambios del documento
En la siguiente tabla, se incluye un resumen de los cambios en la definición de compatibilidad de esta versión.
|
Secciones |
Resumen del cambio |
|
1. Introducción |
Se actualizaron los requisitos para consultar la documentación del SDK como fuente de información. |
|
2. Tipos de dispositivos |
Se incluyeron definiciones para los tipos de dispositivos de mano, televisión y reloj. |
|
2.1 Configuración del dispositivo |
Se agregó una lista no exhaustiva para ilustrar la desviación de la configuración de hardware en los dispositivos. |
|
3.1. Compatibilidad de APIs administradas |
También DEBEN proporcionar implementaciones completas de las APIs con el marcador "@SystemApi" en el código fuente de Android upstream. |
|
3.2.2. Parámetros de compilación |
Se incluyeron los parámetros SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS y SUPPORTED_64_BIT_ABIS en la lista, se actualizó PRODUCT para que requiera SKUs de productos únicos y se actualizaron las ETIQUETAS. |
|
3.2.3.1. Intents de la aplicación principales |
Se aclaró el lenguaje que indica que el requisito de compatibilidad es principalmente para el patrón de intents. |
|
3.2.3.5. Configuración predeterminada de la app |
Se incluyeron nuevos requisitos para la pantalla principal, NFC y las aplicaciones de SMS predeterminadas. |
|
3.3.1 Interfaces binarias de la aplicación |
Se agregaron requisitos para admitir ABI de 32 bits equivalentes si se admite alguna ABI de 64 bits. Se actualizaron los parámetros para reflejar este cambio. |
|
3.4.1. Compatibilidad con WebView |
Se requiere compatibilidad con Webview para todos los dispositivos, excepto los dispositivos Android Watch. Se quitó el requisito de cadena de configuración regional. |
|
3.4.2. Compatibilidad del navegador |
Los dispositivos Android TV y Wear PUEDEN omitir una aplicación de navegador, pero todos los demás tipos de implementaciones de dispositivos DEBEN incluir una. |
|
3.7. Compatibilidad con el entorno de ejecución |
Se actualizaron los requisitos mínimos de memoria de la aplicación |
|
3.8.2. Widgets |
La compatibilidad con widgets es opcional para todos los tipos de dispositivos, pero se recomienda para dispositivos de mano. |
|
3.8.3. Notificaciones |
Se ampliaron las definiciones de los tipos de notificaciones compatibles. |
|
3.8.4. Buscar |
Los dispositivos Android TV DEBEN incluir la búsqueda global. Todos los demás tipos de dispositivos DEBEN hacerlo. |
|
3.8.6. Temas |
Los dispositivos DEBEN ser compatibles con el tema de Material. |
|
3.8.7. Fondos de pantalla animados |
Los dispositivos que incluyen fondos de pantalla animados DEBEN informar la marca de función de la plataforma android.software.live_wallpaper. |
|
3.8.8. Cambio de actividad |
Se recomienda que se admita la nueva interfaz de usuario de Recientes. DEBE mostrar al menos el título de 4 actividades a la vez. |
|
3.8.10. Control remoto de contenido multimedia de la pantalla de bloqueo |
La API de cliente de control remoto dejó de estar disponible a favor de la plantilla de notificación de medios |
|
3.8.11. Sueños |
Opcional para dispositivos Android Watch. Obligatorio para todos los demás tipos de dispositivos. |
|
3.8.13 Unicode y fuente |
DEBEN admitir Roboto 2, además de los requisitos existentes. |
|
3.12. Framework de entrada de TV |
Las implementaciones de dispositivos Android TV DEBEN admitir el framework de entrada de TV. |
|
5.1. Códecs multimedia |
Se agregaron 3 secciones para los códecs de audio, imagen y video. |
|
5.4 Grabación de audio |
Dividido en subsecciones |
|
5.4.1. Captura de audio sin procesar |
Características definidas para la captura de audio sin procesar en dispositivos que declaran android.hardware.microphone |
|
5.5. Reproducción de audio |
Se agregó la sección 5.5. Reproducción de audio con 2 sub secciones: 5.5.1 Efectos de audio y 5.5.2. Volumen de salida de audio |
|
5.6 Latencia de audio |
Se agregaron definiciones y requisitos para el jitter de salida en frío, el jitter de entrada en frío y la latencia de ida y vuelta continua. |
|
5.8 Medios seguros |
Se incluyeron los requisitos de contenido multimedia seguro a partir de la versión 7.1.8. Pantallas externas y requisitos agregados para Android TV. |
|
6.1. Herramientas para desarrolladores |
Recursos actualizados |
|
6.2.1. Experimental |
Sección quitada |
|
7. Compatibilidad de hardware |
Se actualizó para reflejar que las implementaciones de dispositivos DEBEN informar de forma coherente una configuración de hardware precisa para la misma huella de compilación. |
|
7.1.1.1. Tamaño de la pantalla |
Se actualizó para reflejar el tamaño de pantalla de los dispositivos Android Watch y que el valor no puede cambiar. |
|
7.1.1.2. Relación de aspecto de la pantalla |
Se actualizó para reflejar la relación de aspecto de la pantalla de los dispositivos Android Watch (1:1). |
|
7.1.3. Orientación de pantalla |
Se actualizó para reflejar que los dispositivos con una pantalla horizontal de orientación fija DEBEN informar solo esa orientación. |
|
7.1.4. Aceleración de gráficos 2D y 3D |
Se agregó que los dispositivos Android PUEDEN admitir el paquete de extensión de Android. |
|
(anterior) 7.1.6. Tipos de pantalla |
Se quitó la sección |
|
7.1.6. Tecnología de la pantalla |
Se actualizó la relación de aspecto de píxeles (PAR) para que esté entre 0.9 y 1.15. (tolerancia de un 15% aproximadamente) |
|
7.1.7. Pantallas externas |
Se movió parte de la sección a la sección 5.8. Medios seguros |
|
7.2.2. Navegación no táctil |
Los dispositivos Android TV DEBEN admitir el pad direccional. |
|
7.2.3. Teclas de navegación |
Se incluye el idioma para brindar asistencia en diferentes tipos de dispositivos. |
|
7.2.4. Entrada táctil |
Los dispositivos Android Watch DEBEN admitir la entrada de la pantalla táctil. |
|
7.2.6. Compatibilidad con controles de juegos |
Se agregó una sección con los requisitos de Android TV. |
|
7.2.7. Control remoto |
Se agregó una sección con los requisitos de Android TV. |
|
7.3. Sensores |
Se redefinieron los sensores sintéticos como sensores compuestos y los sensores de transmisión como continuos. Los sensores deben informar la hora del evento en nanosegundos. |
|
7.3.1. Acelerómetro |
Se aclararon los tipos de sensores obligatorios y se revisaron los umbrales de requisitos. |
|
7.3.2. Magnetómetro |
Se aclararon los tipos de sensores obligatorios y se revisaron los umbrales de requisitos. |
|
7.3.4. Giroscopio |
Se aclararon los tipos de sensores obligatorios y se revisaron los umbrales de requisitos. |
|
7.3.5. Barómetro |
Se cambió de PUEDE a DEBE implementar el barómetro. DEBE implementar y notificar el sensor TYPE_PRESSURE. |
|
7.3.6. Termómetro |
Los dispositivos PUEDEN incluir un termómetro ambiente. PUEDE, PERO NO DEBE, incluir un termómetro de CPU. |
|
7.3.8. 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. |
|
7.4.2. IEEE 802.11 (Wi-Fi) |
Los dispositivos Android TV DEBEN incluir compatibilidad con Wi-Fi. Los dispositivos que sí admiten Wi-Fi deben informar android.hardware.wifi. |
|
7.4.2.1. Wi-Fi directo |
DEBE informar la función de hardware android.hardware.wifi.direct. |
|
7.4.2.2. Configuración de vínculo directo con túnel Wi-Fi |
Los dispositivos Android TV DEBEN incluir compatibilidad con Wi-Fi TDLS. |
|
7.5. Cámaras |
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 iguales al tamaño de las imágenes que produce el sensor de cámara de mayor resolución en el dispositivo. |
|
7.5.3. Cámaras externas |
Se agregaron requisitos que indican que las implementaciones de dispositivos con modo host USB PUEDEN incluir compatibilidad con una cámara externa. |
|
7.5.5. Funciones del sistema de la cámara |
Se agregó una lista de las funciones de la cámara y cuándo se deben definir. |
|
7.6.1. Memoria y almacenamiento mínimos |
Se actualizaron los requisitos para dispositivos de 32 y 64 bits. Se quitó el requisito de memoria de SVELTE. Los dispositivos DEBEN tener al menos 1.5 GB de almacenamiento no volátil. |
|
7.6.2. Almacenamiento compartido de la aplicación |
Actualización de los requisitos para el almacenamiento extraíble al que puede acceder el usuario |
| 7.6.2. Almacenamiento compartido de la aplicación | Se actualizaron los requisitos para que las apps del sistema preinstaladas puedan escribir en el almacenamiento externo secundario. |
|
7.7. USB |
Se quitaron los requisitos de que los puertos que no sean de carga estén en el mismo borde que el puerto micro-USB. Se actualizaron los requisitos para el modo host y periférico. |
|
7.7. USB |
Se corrigieron erratas en la sección USB. |
|
7.8.1. Audio |
Se movió la sección del micrófono aquí. Se agregaron requisitos para los puertos de salida de audio y audio analógico. |
|
8. Compatibilidad de rendimiento |
Se agregaron requisitos para la coherencia de la interfaz de usuario. |
|
9.5. Compatibilidad con varios usuarios |
La función de compatibilidad con varios usuarios es opcional para todos los tipos de dispositivos. Requisitos detallados por tipo de dispositivo en la sección |
|
9.5. Compatibilidad con varios usuarios |
Se requiere encriptación de la tarjeta SD para el almacenamiento externo principal. |
|
9.7. Funciones de seguridad del kernel |
PUEDE tener una interfaz de usuario visible cuando se produce un incumplimiento de seguridad desbloqueado que genera un exploit exitoso. No se permiten dominios de modo permisivo. |
|
9.9. Encriptación de disco completo |
Los dispositivos con una pantalla de bloqueo DEBEN admitir la encriptación completa del disco. En el caso de los dispositivos nuevos, la encriptación de disco completo debe estar habilitada de forma predeterminada. |
|
9.10 Inicio verificado |
Se agregó una sección para recomendar que las implementaciones de dispositivos admitan el inicio verificado para la integridad del dispositivo. |
|
10.3. Aplicaciones de referencia |
Se quitó la sección del CDD. |
|
11. Software actualizable |
Si un dispositivo admite el perfil 802.11 o PAN (red de área personal) de Bluetooth, entonces DEBE admitir la descarga inalámbrica con actualización sin conexión a través del reinicio. |
|
14. Recursos |
Se movieron recursos de la sección 2 a la sección 14 |
13. Comunícate con nosotros
Puedes unirte al foro de compatibilidad con Android [Recursos, 109] y solicitar aclaraciones o plantear cualquier problema que creas que no se aborda en el documento.
14. Recursos
1. Niveles de requisitos de la RFC2119 del IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Proyecto de código abierto de Android: http://source.android.com/
3. Funciones de Android TV: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK
4. Función de reloj Android: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH
5. Definiciones y documentación de la API: http://developer.android.com/reference/packages.html
6. Referencia de permisos de Android: http://developer.android.com/reference/android/Manifest.permission.html
7. Referencia de android.os.Build: http://developer.android.com/reference/android/os/Build.html
8. Cadenas de versión permitidas de Android 5.0: http://source.android.com//docs/compatibility/5.0/versions
9. Proveedor de telefonía: http://developer.android.com/reference/android/provider/Telephony.html
10. Emulación de tarjetas basada en host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
11. Paquete de extensiones de Android: http://developer.android.com/guide/topics/graphics/opengl.html#aep
12. Clase android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
13. Compatibilidad con WebView: http://www.chromium.org/
14. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
15. Funciones sin conexión de HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
16. Etiqueta de video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
17. API de Geolocation de HTML5/W3C: http://www.w3.org/TR/geolocation-API/
18. API de almacenamiento web de HTML5/W3C: http://www.w3.org/TR/webstorage/
19. API de IndexedDB de HTML5/W3C: http://www.w3.org/TR/IndexedDB/
20. Especificación de código de bytes y formato Dalvik Executable: Disponible en el código fuente de Android, en dalvik/docs
21. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
22. Notificaciones: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
23. Recursos de la aplicación: https://developer.android.com/guide/topics/resources/available-resources.html
24. Guía de estilo de íconos de la barra de estado: http://developer.android.com/design/style/iconography.html
25. Recursos de notificaciones: https://developer.android.com/design/patterns/notifications.html
26. Administrador de búsqueda: http://developer.android.com/reference/android/app/SearchManager.html
27. Toasts: http://developer.android.com/reference/android/widget/Toast.html
28. Temas: http://developer.android.com/guide/topics/ui/themes.html
29. Clase R.style: http://developer.android.com/reference/android/R.style.html
30. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material
31. Fondos de pantalla animados: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html
32. Recursos de la pantalla de descripción general: http://developer.android.com/guide/components/recents.html
33. Fijar pantalla: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning
34. Métodos de entrada: http://developer.android.com/guide/topics/text/creating-input-method.html
35. Notificación multimedia: https://developer.android.com/reference/android/app/Notification.MediaStyle.html
36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html
37. Settings.Secure LOCATION_MODE:
http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
39. Administración de dispositivos Android: http://developer.android.com/guide/topics/admin/device-admin.html
40. Referencia de DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
41. App del propietario del dispositivo Android:
42. APIs de Accessibility Service de Android: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html
43. APIs de accesibilidad de Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html
44. Proyecto Eyes Free: http://code.google.com/p/eyes-free
45. APIs de Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html
46. Framework de entrada de TV: /devices/tv/index.html
47. Documentación de herramientas de referencia (para adb, aapt, ddms y systrace): http://developer.android.com/guide/developing/tools/index.html
48. Descripción del archivo APK de Android: http://developer.android.com/guide/components/fundamentals.html
49. Archivos de manifiesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html
50. Formatos multimedia de Android: http://developer.android.com/guide/appendix/media-formats.html
51. Requisitos de codificación de hardware de RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
52. API de AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html
53. Clase android.content.pm.PackageManager y lista de funciones de hardware de Android:
http://developer.android.com/reference/android/content/pm/PackageManager.html
54. Protocolo de borrador de HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
55. ADB: http://developer.android.com/tools/help/adb.html
56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html
57. DDMS: http://developer.android.com/tools/debugging/ddms.html
58. Herramienta de prueba de Monkey: http://developer.android.com/tools/help/monkey.html
59. Herramienta SysyTrace: http://developer.android.com/tools/help/systrace.html
60. Configuración relacionada con el desarrollo de aplicaciones para Android:
61. Compatibilidad con varias pantallas: http://developer.android.com/guide/practices/screens_support.html
62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
63. RenderScript: http://developer.android.com/guide/topics/renderscript/
64. Paquete de extensiones de Android para OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html
65. Aceleración de hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html
66. Extensión de EGL: EGL_ANDROID_RECORDABLE:
http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
67. Administrador de pantalla: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
69. Acción de asistencia: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
70. Configuración de entrada táctil: http://source.android.com/docs/core/interaction/input/touch-devices
71. API de Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
72. API de eventos de teclas: http://developer.android.com/reference/android/view/KeyEvent.html
73. Sensores de código abierto de Android: http://source.android.com/docs/core/interaction/sensors
74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
75. Marca de tiempo del evento del sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp
76. Sensores compuestos de código abierto de Android: http://source.android.com/devices/sensors/composite_sensors.html
77. Modo de activador continuo: http://source.android.com/devices/sensors/base_triggers.html#continuous
78. Sensor de acelerómetro: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER
79. API de Wi-Fi Multicast: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
81. API de WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html
82. API de Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html
83. API de Bluetooth ScanFilter: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html
84. Protocolo de envío de NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html
86. Configuración de uso compartido de NFC de Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
87. NFC Connection Handover: http://www.nfc-forum.org/specs/spec_list/#conn_handover
88. Vinculación simple segura por Bluetooth con NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf
89. Agente de resolución de contenido: http://developer.android.com/reference/android/content/ContentResolver.html
90. API de orientación de la cámara: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
91. Cámara: http://developer.android.com/reference/android/hardware/Camera.html
92. Cámara: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
93. Nivel de hardware de la cámara: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL
94. Compatibilidad con versiones de la cámara: http://source.android.com/docs/core/camera/versioning
95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
96. Transferencia de archivos de Android: http://www.android.com/filetransfer
97. Accesorios abiertos de Android: http://developer.android.com/guide/topics/usb/accessory.html
98. Audio USB de Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
99. Especificación de carga de baterías USB, revisión 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip
100. API de host USB: http://developer.android.com/guide/topics/usb/host.html
101. Auriculares de audio con cable: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec
102. Referencia de seguridad y permisos de Android: http://developer.android.com/guide/topics/security/permissions.html
103. Referencia de UserManager: http://developer.android.com/reference/android/os/UserManager.html
104. Referencia de almacenamiento externo: http://source.android.com/docs/core/storage
105. APIs de almacenamiento externo: http://developer.android.com/reference/android/os/Environment.html
106. Código corto de SMS: http://en.wikipedia.org/wiki/Short_code
107. Cifrado de código abierto de Android: http://source.android.com/devices/tech/encryption/index.html
108. Descripción general del programa de compatibilidad de Android: http://source.android.com/docs/compatibility
109. Foro de compatibilidad con Android: https://groups.google.com/forum/#!forum/android-compatibility
110. Proyecto WebM: http://www.webmproject.org/
Muchos de estos recursos 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, esta última se considerará como fuente de autoridad. Cualquier detalle técnico que se proporcione en las referencias anteriores se considera parte de esta definición de compatibilidad.